[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: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.

If you have two identical SoCs back-to-back, the soc nodes will have
different ranges, but the device nodes themselves will be pretty much
identical.  You'd need to parse all the ranges properties to get a
real physaddr before you as sure to get a unique addr.

>
> 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.

Possibly true; but I am concerned that it just trades one fragile
method (strict path) for another (expected differences between nodes
for identical devices in the tree)

Cheers,
g.

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