[RFC][PATCH] identify_ppc_sys_by_name_and_id function implementation

Kumar,

This is preliminary version of the identify_ppc_sys_by_name_and_id(...).
Tested with pq2 devices/sys for 8272ADS and fs_enet. This will BUG_ON if 
nothing found or duplicates exist (guess if we call identify_ppc_sys.. 
hit is expected).

Signed-off-by: Vitaly Bordug <redacted>

-- 
Sincerely,
Vitaly

The same as above but with correct kernel bracing style.

Signed-off-by: Vitaly Bordug <redacted>
-- 
Sincerely,
Vitaly

Finally correct indentation style.

Signed-off-by: Vitaly Bordug <redacted>

-- 
Sincerely,
Vitaly

+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+    int ret = -1;
+    unsigned int i = 0;
+    unsigned int j = 0;
+    unsigned int dups = 0;
+
+    unsigned int matched[count_sys_specs()];

Is is legit in the kernel to use dynamically sized array?

+
+    while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
+        if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+            matched[j++] = i;
+        i++;
+    }
+    if (j != 0) {
+        for (i = 0; i < j; i++) {
+            if ((ppc_sys_specs[matched[i]].mask & id) ==
+                ppc_sys_specs[matched[i]].value) {
+                ret = matched[i];
+                dups++;
+            }
+        }
+        ret = (dups == 1) ? ret : (-1 * dups);
+    }
+    return ret;
+}

On Aug 10, 2005, at 1:01 PM, Vitaly Bordug wrote:

Finally correct indentation style.

Signed-off-by: Vitaly Bordug <redacted>

-- 
Sincerely,
Vitaly

<ppc_sys_add.patch>
<ATT87954.txt>

On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:

+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+    int ret = -1;
+    unsigned int i = 0;
+    unsigned int j = 0;
+    unsigned int dups = 0;
+
+    unsigned int matched[count_sys_specs()];

Is is legit in the kernel to use dynamically sized array?

kmalloc() is certainly safer - why not use it? 

+
+    while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
+        if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+            matched[j++] = i;
+        i++;
+    }
+    if (j != 0) {
+        for (i = 0; i < j; i++) {
+            if ((ppc_sys_specs[matched[i]].mask & id) ==
+                ppc_sys_specs[matched[i]].value) {
+                ret = matched[i];
+                dups++;
+            }
+        }
+        ret = (dups == 1) ? ret : (-1 * dups);
+    }
+    return ret;
+}

On Aug 10, 2005, at 1:01 PM, Vitaly Bordug wrote:

quoted

Finally correct indentation style.

Signed-off-by: Vitaly Bordug <redacted>

quoted

quoted

-- 

Sincerely,
Vitaly

<ppc_sys_add.patch>
<ATT87954.txt>

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Marcelo Tosatti wrote:

On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:

quoted

+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+    int ret = -1;
+    unsigned int i = 0;
+    unsigned int j = 0;
+    unsigned int dups = 0;
+
+    unsigned int matched[count_sys_specs()];

Is is legit in the kernel to use dynamically sized array?

kmalloc() is certainly safer - why not use it? 

Practically , version with kmalloc works, but  setup_arch and thus this 
function is called before mem_init, so I just wonder if kmalloc can 
handle this case. On the other hand, I don't like to deal with
alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp 
does) just for the temporary buffer.

But it's the only _right_ way (or I 've missed something) - sure I'll 
follow it.

-- 
Sincerely,
Vitaly

On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:

Marcelo Tosatti wrote:

quoted

On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:

quoted

+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+    int ret = -1;
+    unsigned int i = 0;
+    unsigned int j = 0;
+    unsigned int dups = 0;
+
+    unsigned int matched[count_sys_specs()];

Is is legit in the kernel to use dynamically sized array?

kmalloc() is certainly safer - why not use it? 

Practically , version with kmalloc works, but  setup_arch and thus this 
function is called before mem_init, so I just wonder if kmalloc can 
handle this case. On the other hand, I don't like to deal with
alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp 
does) just for the temporary buffer.

But it's the only _right_ way (or I 've missed something) - sure I'll 
follow it.

I dont see any problem with dynamic array usage on the kernel (maybe someone
else has good argumentation against it).

Just that you have a 4kb stack. Does count_sys_specs() have an appropriate
maximum?

Marcelo Tosatti wrote:

On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:

quoted

Marcelo Tosatti wrote:

quoted

On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:

quoted

+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+    int ret = -1;
+    unsigned int i = 0;
+    unsigned int j = 0;
+    unsigned int dups = 0;
+
+    unsigned int matched[count_sys_specs()];

Is is legit in the kernel to use dynamically sized array?

kmalloc() is certainly safer - why not use it? 

Practically , version with kmalloc works, but  setup_arch and thus this 
function is called before mem_init, so I just wonder if kmalloc can 
handle this case. On the other hand, I don't like to deal with
alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp 
does) just for the temporary buffer.

But it's the only _right_ way (or I 've missed something) - sure I'll 
follow it.

I dont see any problem with dynamic array usage on the kernel (maybe someone
else has good argumentation against it).

Just that you have a 4kb stack. Does count_sys_specs() have an appropriate
maximum?

Yes it does, but there is no define for it. The ppc_sys_specs array 
should always end at the "default match" - element with name field set 
to "" and value=0 (without it every existing ppc_sys identify will fall 
into infinite loop). This array is defined in syslib/<board>_sys.c end 
is finite of course. Its size depends on amount of supported boards.

So, if the dynamic array is ok with conditions, it will be great.
But now I'm inclined to implement the same using kmalloc/alloc_bootmem 
to prevent flame when it will proceed. BTW, will free_bootmem properly 
release the memory allocated by alloc_bootmem()? I haven't encountered
examples of this so far...


-- 
Sincerely,
Vitaly

Can you do a sizeof instead?

#define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)

Something like matchted[num_ele] ??

- kumar

On Aug 12, 2005, at 10:37 AM, Vitaly Bordug wrote:

Marcelo Tosatti wrote:

quoted

On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:

quoted

Marcelo Tosatti wrote:

quoted

On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:

quoted

+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+    int ret = -1;
+    unsigned int i = 0;
+    unsigned int j = 0;
+    unsigned int dups = 0;
+
+    unsigned int matched[count_sys_specs()];

Is is legit in the kernel to use dynamically sized array?

kmalloc() is certainly safer - why not use it?

Practically , version with kmalloc works, but  setup_arch and  
thus this
function is called before mem_init, so I just wonder if kmalloc can
handle this case. On the other hand, I don't like to deal with
alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
does) just for the temporary buffer.

But it's the only _right_ way (or I 've missed something) - sure  
I'll
follow it.

I dont see any problem with dynamic array usage on the kernel  
(maybe someone
else has good argumentation against it).

Just that you have a 4kb stack. Does count_sys_specs() have an  
appropriate
maximum?

Yes it does, but there is no define for it. The ppc_sys_specs array
should always end at the "default match" - element with name field set
to "" and value=0 (without it every existing ppc_sys identify will  
fall
into infinite loop). This array is defined in syslib/<board>_sys.c end
is finite of course. Its size depends on amount of supported boards.

So, if the dynamic array is ok with conditions, it will be great.
But now I'm inclined to implement the same using kmalloc/alloc_bootmem
to prevent flame when it will proceed. BTW, will free_bootmem properly
release the memory allocated by alloc_bootmem()? I haven't encountered
examples of this so far...


-- 
Sincerely,
Vitaly

Kumar Gala wrote:

Can you do a sizeof instead?

#define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)

Something like matchted[num_ele] ??

That's what the first I tried actually :)
gcc is not happy with it:

arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
arch/ppc/syslib/ppc_sys.c:54: error: parse error before ']' token

and if I remove [] from the ppc_sys_specs, it outputs:

arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
arch/ppc/syslib/ppc_sys.c:54: error: invalid application of `sizeof' to 
incomplete type `({anonymous})'

So I cannot use sizeof this case, I think...

- kumar

On Aug 12, 2005, at 10:37 AM, Vitaly Bordug wrote:

quoted

Marcelo Tosatti wrote:

quoted

On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:

quoted

Marcelo Tosatti wrote:

quoted

On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:

quoted

+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+    int ret = -1;
+    unsigned int i = 0;
+    unsigned int j = 0;
+    unsigned int dups = 0;
+
+    unsigned int matched[count_sys_specs()];

Is is legit in the kernel to use dynamically sized array?

kmalloc() is certainly safer - why not use it?

Practically , version with kmalloc works, but  setup_arch and  thus 
this
function is called before mem_init, so I just wonder if kmalloc can
handle this case. On the other hand, I don't like to deal with
alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
does) just for the temporary buffer.

But it's the only _right_ way (or I 've missed something) - sure  I'll
follow it.

I dont see any problem with dynamic array usage on the kernel  (maybe 
someone
else has good argumentation against it).

Just that you have a 4kb stack. Does count_sys_specs() have an  
appropriate
maximum?

Yes it does, but there is no define for it. The ppc_sys_specs array
should always end at the "default match" - element with name field set
to "" and value=0 (without it every existing ppc_sys identify will  fall
into infinite loop). This array is defined in syslib/<board>_sys.c end
is finite of course. Its size depends on amount of supported boards.

So, if the dynamic array is ok with conditions, it will be great.
But now I'm inclined to implement the same using kmalloc/alloc_bootmem
to prevent flame when it will proceed. BTW, will free_bootmem properly
release the memory allocated by alloc_bootmem()? I haven't encountered
examples of this so far...


-- 
Sincerely,
Vitaly

-- 
Sincerely,
Vitaly

On Aug 12, 2005, at 11:30 AM, Vitaly Bordug wrote:

Kumar Gala wrote:

quoted

Can you do a sizeof instead?

#define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)

Something like matchted[num_ele] ??

That's what the first I tried actually :)
gcc is not happy with it:

arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
arch/ppc/syslib/ppc_sys.c:54: error: parse error before ']' token

and if I remove [] from the ppc_sys_specs, it outputs:

arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
arch/ppc/syslib/ppc_sys.c:54: error: invalid application of  
`sizeof' to
incomplete type `({anonymous})'

So I cannot use sizeof this case, I think...

Realized the same thing.  I'm thinking that your original method is  
the best solution to just do this on the stack.  In general the  
number or processors (array size) is going to be less than 100.  So  
at most this array is going to end up being 100 bytes on the stack.   
I dont think that's a big deal at the point we are calling this.

- kumar

Kumar Gala wrote:

On Aug 12, 2005, at 11:30 AM, Vitaly Bordug wrote:

quoted

Kumar Gala wrote:

quoted

Can you do a sizeof instead?

#define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)

Something like matchted[num_ele] ??

That's what the first I tried actually :)
gcc is not happy with it:

arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
arch/ppc/syslib/ppc_sys.c:54: error: parse error before ']' token

and if I remove [] from the ppc_sys_specs, it outputs:

arch/ppc/syslib/ppc_sys.c: In function `find_chip_by_name_and_id':
arch/ppc/syslib/ppc_sys.c:54: error: invalid application of  `sizeof' to
incomplete type `({anonymous})'

So I cannot use sizeof this case, I think...

Realized the same thing.  I'm thinking that your original method is  the 
best solution to just do this on the stack.  In general the  number or 
processors (array size) is going to be less than 100.  So  at most this 
array is going to end up being 100 bytes on the stack.   I dont think 
that's a big deal at the point we are calling this

Thus, are there any modifications needed for the original approach?
Or maybe it's simpler to add say MAX_PPC_SPECS to ppc_sys.h since this 
list will be limited anyway? We could have the simple array with static 
size then, and additional ppc_sys_specs sanity check (whether it has 
"default" element with both 0 id and "" name) could be easily 
implemented as well.


-- 
Sincerely,
Vitaly