On Fri, 22 Jul 2011 23:44:01 +0400
Dmitry Eremin-Solenikov <dbarysh...@gmail.com> wrote:
> On 7/19/11, Scott Wood <scottw...@freescale.com> wrote:
> > On Tue, 19 Jul 2011 12:53:50 +0400
> > Dmitry Eremin-Solenikov <dbarysh...@gmail.com> wrote:
> >
> >> +static struct of_device_id __initdata mpc85xx_common_ids[] = {
> >> + { .type = "soc", },
> >> + { .compatible = "soc", },
> >> + { .compatible = "simple-bus", },
> >> + { .compatible = "gianfar", },
> >> + { .compatible = "fsl,qe", },
> >> + { .compatible = "fsl,cpm2", },
> >> + {},
> >> +};
> >
> > Same comment as for 83xx regarding localbus and compatibility with old
> > device trees.
>
> I checked for in-kernel device trees. Unless I miss something, there are no
> leftovers from this list. (83xx provided no simple-bus property for localbus,
> so your argument is valid there). If we should care about strange cases,
> not even blessed by kernel trees, I can add some of the old probes back.
I see simple-bus missing in sbc8560 and ksi8560 -- were these included in
the consolidation? Plus some of the others may have had simple-bus added
after their initial version.
As for out-of-tree trees (which could include trees dynamically
generated/augmented by firmware, as well as device trees for custom boards
that forked off of an old reference board tree), it's still nice to not
break them as long as they stick to the binding.
While the localbus binding is deficient regarding the compatible property,
IIRC localbus preceded the introduction of simple-bus, which appears to be
defined only in ePAPR (not in Linux or on devicetree.org). The ePAPR
language does not suggest that it's mandatory for all buses that don't need
special handling -- in fact, the language could be read as suggesting that
it's only applicable to the "internal I/O bus" on an SoC (whereas this
is an external bus), though that wasn't the intent behind it.
The notion of probing buses isn't really a part of the device tree specs;
they're more concerned with binding the devices themselves. In theory
Linux should probably be probing everything that a driver will match,
regardless of where in the tree it is, except where an ancestor node is
diasbled, has matched a driver that wants to do things differently, or is
on a blacklist. Of course, that's somewhat of a philosophical question on
whether it's better to risk probing someting that shouldn't be, or not
probing something that should be. The former is often nastier but more
obvious, the latter is more likely until simple-bus is more widely used,
and either one results in something not working.
Leaving the localbus in may help someone, and it shouldn't hurt anything.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
