Hi David, On Sun, Sep 4, 2011 at 4:14 AM, David Gibson <[email protected]> wrote: > On Sat, Sep 03, 2011 at 08:18:08PM -0700, Simon Glass wrote: >> Hi David, >> >> On Sat, Sep 3, 2011 at 7:33 AM, David Gibson >> <[email protected]> wrote: >> > On Fri, Sep 02, 2011 at 10:54:28AM -0700, Simon Glass wrote: > [snip] >> >> >> This is wrong. properties do not have paths - they exist in a >> >> >> separate namespace to nodes. The node path and property name should >> >> >> be supplied as separate parameters. As well as being actually right, >> >> >> it will greatly simplify this function's convoluted logic. >> >> > >> >> > Well yes, but I feel that it makes it harder to use also. My thinking >> >> > with this was to try to make it easy to extract information. In my >> >> > view: >> >> > >> >> > /lcd/width >> >> > >> >> > is better than >> >> > >> >> > /lcd width >> >> > >> >> > But this is the kind of discussion / feedback I was hoping to get as I >> >> > am new to device trees. My thoughts: >> >> > >> >> > 1. / is not generally used in property names so there is no conflict >> >> > 2. Neither is there any ambiguity >> > >> > Yes there is. Real device trees exist where a node has both a >> > property and a subnode with the same name. >> >> Er, ok. How about something like: >> >> /path/to/node/.property >> >> as a compromise? It removes the ambiguity I think, and still lets me > > That's not a compromise, that's worse!
Oh dear. > >> avoid having 3 parameters in fdtput per assignment. > > For pete's sake, just add the extra parameter. It's the right way to > do it. Right oh. Thanks for the quick response. Regards, Simon > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson > _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
