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

[Simon Glass]

Hi David,

On Sun, Sep 4, 2011 at 4:14 AM, David Gibson
<david at gibson.dropbear.id.au> 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
>> <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!

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
>