Kumar Gala wrote:

On Dec 12, 2006, at 3:30 PM, Scott Wood wrote:

quoted

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 true, and if that's the case you'd just set your "model" to  
match an existing supported ppc_md.

Having an 831x explicitly claim to be an 834x is just a tad icky...

quoted

If a board has truly board-specific logic that needs custom code in  the
kernel itself (rather than the bootloader), then it can go in as a
driver with a device tree node (this should be done with the BCSR  stuff
where needed).

This is not always the case, there are times when you have board  
specific modifications you make in the early kernel code.

Sure -- I'm not proposing doing away with board-specific machine 
descriptions entirely, just reducing the circumstances where they're 
required.

True, but I dont see what the desire is to create a 'generic' 83xx  
support.  Who gets to define what is considered 'generic'?  

"Generic" is any board that has needs that aren't expressed in the 
device tree.

I'm all for refactoring code so my board code  
is simpler, but at the end of the day I know there are people that  are 
going to need board specific code for their environments.

And an 83xx-generic machine description does not stop them from doing 
so.  "Generic" does not mean "universal".  It means "there's nothing 
special about this board".  If you need board-specific code in the 
kernel, then don't label it generic.

-Scott