of_n_{addr,size}_cells(struct device_node *np) - Allow for returning value of node passed in

of_n_{addr,size}_cells(struct device_node *np) - Allow for returning value of node passed in

[Ray Clinton]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

Hi,

I only just started doing anything with kernel development, this is my
first email on this list, so I'm sorry if I ask a dumb question or mess up
on any rules of etiquette, I'm trying to follow them.

I'm sure there is a reason for this, but of_n_{addr,size}_cells() will only
return a parent's #address-cells or #size-cells values. I realize
of_property_read_u32(np, "#address-cells", &cells), for example, could be
called on the current node to get that value, but is seems to be that
of_n_{addr,size}_cells() is a little bit of a misleading name; I expected
it to return the above mentioned values of the node passed in, and if that
was not explicitly defined it would look to the parents. I ask because I
ran into a problem when working on a driver and trying to include an .dtsi
that contained a node with different values for #address-cells and
#size-cells; I could never get the correct values returned, I only got the
parents'. So my questions are

1) If the methods are not meant to return the values for #address-cells and
#size-cells should it be named something like of_n_parent_{addr,size}_cells?
2) If they are meant to return the values for the current node could there
be a check that looks something like this?:

int of_n_addr_cells(struct device_node *np)
{
u32 cells;

*       if (!of_property_read_u32(np, "#address-cells", &cells))*
*               return cells;*

do {
if (np->parent)
np = np->parent;
if (!of_property_read_u32(np, "#address-cells", &cells))
return cells;
} while (np->parent);
/* No #address-cells property for the root node */
return OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
}

I realize I could be missing something and that this isn't an important
change, but I just thought I'd ask. Thanks so much!

[-- Attachment #2: Type: text/html, Size: 3733 bytes --]

of_n_{addr,size}_cells(struct device_node *np) - Allow for returning value of node passed in

[Ray Clinton]

(I accidentally sent this originally with HTML formatting, sorry if
you are getting this twice.)

Hi,

I only just started doing anything with kernel development, this is my
first email on this list, so I'm sorry if I ask a dumb question or
mess up on any rules of etiquette, I'm trying to follow them.

I'm sure there is a reason for this, but of_n_{addr,size}_cells() will
only return a parent's #address-cells or #size-cells values. I realize
of_property_read_u32(np, "#address-cells", &cells), for example, could
be called on the current node to get that value, but is seems to be
that of_n_{addr,size}_cells() is a little bit of a misleading name; I
expected it to return the above mentioned values of the node passed
in, and if that was not explicitly defined it would look to the
parents. I ask because I ran into a problem when working on a driver
and trying to include an .dtsi that contained a node with different
values for #address-cells and #size-cells; I could never get the
correct values returned, I only got the parents'. So my questions are

1) If the methods are not meant to return the values for
#address-cells and #size-cells should it be named something like
of_n_parent_{addr,size}_cells?
2) If they are meant to return the values for the current node could
there be a check that looks something like this?:

int of_n_addr_cells(struct device_node *np)
{
       u32 cells;

       if (!of_property_read_u32(np, "#address-cells", &cells))
               return cells;

       do {
              if (np->parent)
              np = np->parent;
              if (!of_property_read_u32(np, "#address-cells", &cells))
                     return cells;
       } while (np->parent);
       /* No #address-cells property for the root node */
       return OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
}

I realize I could be missing something and that this isn't an
important change, but I just thought I'd ask. Thanks so much!

Ray