Re: [PATCH 2/9] Add dtget utility to read property values from device tree

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

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-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> 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