[PATCH 2/9] Add dtget utility to read property values from device tree
David Gibson
david at gibson.dropbear.id.au
Sun Sep 4 21:14:48 EST 2011
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
> <david at gibson.dropbear.id.au> 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!
> 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.
--
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
More information about the devicetree-discuss
mailing list