Board level compatibility matching

[Grant Likely]

This topic keeps coming up, so it is probably time to address it once
and for all.

When it comes to machine level support in arch/powerpc, there seems to
me that there are two levels or machine support.

Level 1 is the board specific stuff.  Board X has a, b, and c things
that need to be done for Linux to work correctly, but the fixups are
entirely board specific and will only ever be used on a single board
port.  The lite5200 support in arch/powerpc/platforms/52xx is an
example of this kind of board support.  It binds on a value in the top
level compatible property.

Level 2 is kind of the generic catch-all machine support for systems
that are unremarkable and don't require any special code to be run.
In most cases, new boards can be supported by this generic code
without any changes to the Linux kernel.
arch/powerpc/platforms/52xx/mpc5200_simple.c is an example here.
mpc5200_simple maintains a list of boards that are known to work with
it.

At the moment, every new board port forces a linux kernel source tree
change, even if it is just adding a single string to the match table.
I'm willing to wager that 99 times out of 100, boards based on the
mpc5200 SoC will want to use the common board support code and that
maintaining an explicit list of supported boards is completely
unnecessary.  I expect that the exact same is true for 8xxx and 4xx
SoCs.  So, rather than continuing to need to maintain explicit lists,
I propose the following:

- Add a property to the device tree that explicitly specifies the SoC
that the board is based on.  Something like 'soc-model =
"fsl,mpc5200b"' would be appropriate.  This in and of itself does not
change the usage conventions, it just provides more information about
the hardware.  (Another idea is to add a string to the top level
compatible property, but there are still arguments about what
compatible really means in the root node.)

- Prioritize board ports in the arch/powerpc/platforms directory to
identify level-1 machines support from the level-2 ones.  Make sure
that level-1 stuff always gets probed before level-2 stuff within each
SoC family.  In all likelyhood, this would probably just involve
making sure that board specific machines get linked in before the
catchall machine.

- Change level-2 machine support to bind on soc-model instead of an
explicit compatible list.

Doing so should simplify adding new board ports.  In many cases it
would just involve dropping in a new .dts file.  However, it retains
the flexability of overriding generic code with platform specific
fixups as the need arises.  I know we've been cautious about adding
catch-all bindings to the device tree, and it is a big deal to avoid
adding wildcards to compatible values.  However, this solution should
be workable because it doesn't involve stating something that is not
true in the device tree and it maintains the ability to override
cleanly when new bugs are discovered.  It also doesn't try to define
wildcard values in compatible or other device tree properties.

Thoughts?
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.