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

[Grant Likely]

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.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195