On 7/23/11, Scott Wood [off-list ref] wrote:

On Fri, 22 Jul 2011 23:44:01 +0400
Dmitry Eremin-Solenikov [off-list ref] wrote:

quoted

On 7/19/11, Scott Wood [off-list ref] wrote:

quoted

On Tue, 19 Jul 2011 12:53:50 +0400
Dmitry Eremin-Solenikov [off-list ref] wrote:

quoted

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

Patches for those are included in the patch serie. Kumar has applied them
to next-3.2.

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.

I see your point. I just wasn't thinking too much about ot-of-tree trees.
My thought was that if someone updates the kernel, he can also update the dtb.

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.

Could you please update the lbc.txt suggesting the compatibility
with simple-bus for lbc? Or you thing that it would be wrong?

I think we should define compatibility list as "fsl,mpcXXXX-localbus",
"fsl,pqXXXXX-localbus", "simple-bus", noting that by default new
platforms/boards should only use "simple-bus" internally. Does this
look reasonable for you? I can then try to provide a patch.

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.

What do you suggest/prefer? To add .name="localbus" to generic code
or to have board-specific hooks (like one for mpc834xemitx)?

So,

-Scott

-- 
With best wishes
Dmitry