[U-Boot-Users] [RFC][PATCH] fdt fixup

[Kumar Gala]

On Nov 1, 2007, at 11:55 PM, Grant Likely wrote:

> On 11/2/07, Kumar Gala <galak at kernel.crashing.org> wrote:
>>
>> On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
>>
>>> On 11/2/07, Kumar Gala <galak at kernel.crashing.org> wrote:
>>>>> [snip a bunch more setter functions]
>>>>>
>>>>> Hi Kumar,
>>>>>
>>>>> The direction Grant Likely went with 5xxx and where Sergej was
>>>>> heading with 82xx (if only I got around to applying his patch) and
>>>>> where I want to go is to replace the table-driven methodology with
>>>>> direct calls to more generic functions, eliminating the hordes of
>>>>> specialized "setter" functions (all nearly identical).
>>>>>
>>>>> Discussions and patches:
>>>>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/
>>>>> focus=32573>
>>>>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577>
>>>>>
>>>>> If we get the mpc5xxx style setter functions combined with your
>>>>> fdt_node_offset_by_prop_and_compat() finding changes, I think we
>>>>> would be in fat city.
>>>>
>>>> So we can easily extend what I have to include generic call  
>>>> backs and
>>>> remove the specific set props.  The problem I have with the 5xxx
>>>> mechanism is its requires too much knowledge of how the device tree
>>>> is laid out since it uses explicit paths to the nodes.
>>>
>>> Yes, I agree.  The hard coded paths are stinky.  Looking for
>>> device_type or compatible might be better.
>>>
>>> However, even with using some combination of property values,  
>>> figuring
>>> out which device is which is still a problem.  (ie, which network
>>> device is eth0 and which is eth1?).  Relying on the implicit  
>>> order in
>>> the device tree is just as fragile as using the full path.  At least
>>> with using the full path, you don't run the risk of getting the  
>>> wrong
>>> node (you just don't find the node at all).
>>
>> I wasn't thinking of using implicit order,  We can use reg or the
>> node name in addition to compat.
>
> Ah, okay.  I wasn't sure if name was optional in your last email.
>
> However, if name is specified does compatible even matter?
>
> Or, on the other hand, is name specific enough?  For example; is it
> still possible to wire up two 82xx chips back to back and have one CPU
> control both socs?  In which case you could end up with 2 identical
> devices with identical node names in the tree.

If you have one cpu controller things will have different reg props  
than.

Name is one way to distinguish.  For a given board you're going to  
know some level of detail about the setup such that you can choose  
the best mechanism to match on.

- k