Board level compatibility matching

[Grant Likely]

On Fri, Aug 01, 2008 at 12:54:39PM +1000, David Gibson wrote:
> On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
> > 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.)
> 
> No.  This sort of information belongs in the board compatible
> property.  compatible = "myspecificboard", "generic-mpc5200-board" or
> the like.

The last number of times this topic came up, there was opposition to
using any kind of "generic-<blah>-board".  Mostly because of the
definition of what it means to be 'compatible' tends to change over
time.  That is why I suggested a new property explicitly for defining
the SoC used.  It encodes real information without trying to stretch the
meaning of 'compatible'.

However, I'm raising this question as an RFC.  I can probably be
convinced otherwise.

> Groups of boards sufficiently similar to share platform
> code are *usually* divided by which SoC they're based on, but not
> always.  Sometimes they're divided by the main bridge chip, or by
> vendor (if the vendor is careful to use the same conventions on
> different boards even with different SoCs).  And sometimes boards will
> have idiosyncratic wiring that requires special platform support, even
> if all the major components are the same as some standard design.

Which is another reason I didn't want to encode it in compatible.
However, it still leaves the problem of how to bind across platform
lines.  For the SoC case, I expect that the catch-all machines really
perform a 'best-effort' match, as in if nothing has claimed the before
it gets to it, and the SoC matches (or some other property for that
matter), then it should be okay to bind.

> > - 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.
> 
> Again, this is imposing too much structure on which boards are
> compatible with which.  Certainly compatibility by SoC with a few
> exceptions is common, but it's not universal.
> 
> Splitting highly-specific from fairly-generic platform code might help
> readability.  But, we have to remember that the distinction is only a
> useful-guideline one, not a true structural difference.

Heh; I probably sounded more rigid than I intended to be.  I fully
understand that the distinction is in the useful guideline category and
that Linux must always have the option of doing something different.

g.