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

[Grant Likely]

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 agree with dwg in that I think embedding a "node-index" or similar
property into the node is not a good solution.  This may be yet
another situation where an aliases node would be a good solution.
Have the aliases node populated with the device enumeration (ie. eth0
mapped to "/full/path/to/ethernet at addr") an allow either a full path
to be specified or an alias.

Cheers,
g.

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