quoted

The point here is that other developpers making their own mpc83xx based
boards will not want to use your ppc_md.

They *may* not want to (and they certainly shouldn't be forced to), but 
some may not want to define a new ppc_md (or modify a probe function) 
for every new board if all of the differences are encapsulated in the 
device tree.  I thought one of the main goals of having a device tree is 
that if it's done right, the kernel need not know about every single 
model of board, just the different components that a device tree can 
specify.

That's the ideal situation yes. However, from a more realistic point of
view, I do expect embedded vendors to have their own ppc_md (though it
may cover multiple boards from that vendor). For things like board
specific initialisations, magic GPIOs, reset lines, etc...

The problem with Kim initial patch is that it matches on anything that
says "mpc83xx", thus you completely lose the ability to match somethign
else unless you remove that property, which I find a bit gross.

I do prefer the middle ground approach he (and you) proposed to have an
"mpc83xx_generic" in the compatible property and match on that, but I'm
not 100% certain we are really there yet and I would have been a bit
more comfortable limiting that to known fsl boards. But you are the guys
to maintain those things, so do as you like there.

More generally (and longer-term), what about a completely generic 
platform init file that implements the "booting-without-of.txt" 
platform?  That is, a string that can be placed in the compatible 
property, regardless of board or CPU, in order to assert that nothing 
board-specific has to be done other than as specified by the device 
tree.  The model property could still hold the actual board ID if needed 
to present to the user, or for matching a more specialized machine 
description if problems arise and the device tree cannot be easily 
changed (the generic probe could be arranged to run last).

Alternately, just allow the kernel to boot without finding a matching 
probe, if generic code is able to extract enough information from the 
device tree for generic versions of any non-optional ppc_md functions to 
work.  If a probe does match, then it can fill in any ppc_md fields it 
wants to override (and/or do special initialization, etc).  ppc_md 
fields can also be filled in by CPU-specific code, or by drivers the 
device tree instantiates.

That's sort of a very long term ideal, yes, but again, we aren't quite
there and I'd rather not try to go too fast in that direction. We still
have plenty of stuff to port over from arch/ppc, cleanups to do (like
merging the PCI code, the kernel init code) etc... before we should
spend too much time on that I think.

Ben.