On Dec 12, 2006, at 3:47 PM, Benjamin Herrenschmidt wrote:

quoted

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.

I'm against the idea of "mpc83xx_generic" if they want to introduce a  
"mpc83xx_freescale" or "mpc83xx_fsl_generic" I'm fine with that, but  
there is not such thing as a "mpc83xx_generic".

- kumar