Re: [PATCH] powerpc: consolidate mpc83xx platform files

[Scott Wood <scottwood@freescale.com>]

Benjamin Herrenschmidt wrote:
> Well, either you want all freescale boards have one platform.
> in which case you write one ppc_md() structure, call it
> mpc83xx_fslboards or something like that, and have a probe routine that
> test for all matches, or create as many ppc_md structures as you have
> boards each with it's own probe().
> 
> 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.

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

What about something like the original patch, but with "mpc83xx-generic" 
(or similar) as the compatible match?  This would address the "matches 
everything with mpc83xx in it" concern, without requiring kernel changes 
when a new device tree is all that's really needed, and without 
requiring non-freescale boards to have something like "fslboards" in the 
  compatible property just in order to use generic platform 
initialization code *if they want to*.  Once the BCSR and RTC stuff is 
(re)moved, there's really not much of anything fslboard-specific in 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.

-Scott