Board level compatibility matching

[Josh Boyer]

On Fri, 01 Aug 2008 14:25:39 +1000
Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:

> About this whole generic board mumbo-jumbo: not happening. It's a pipe
> dream, it doesn't work, and it leads to the sort of mess we have in chrp
> where we end up having hacks to identify what exact sort of chrp we have
> and do things differently etc...
> 
> NOT HAPPENING.
> 
> Now, there are two approaches here that are possible:
> 
>  - Your board is really pretty much exactly the same as board XXX,
> except maybe you have a different flash size or such, and the support
> for board XXX can cope perfectly with it simply due to the device-tree
> the right information.
> 
> If that happens to be the case, make your board compatible with board
> XXX. Make that entry -second- in your compatible list, because one day
> you'll figure out that there -is- indeed a difference and I don't want
> to see board XXX code start to grow code to recognise your other board
> and work around the difference. So at that stage, copy board XXX.c file
> and start over with your own board support that matches on your first
> compatible propery entry.

44x does this today for a small number of boards.  The "issue", if
there really is one, is that there's no clear definition on what is
acceptable to be called "compatible".  If _Linux_ platform support for
board FOO
> 
>  - Once you figure out that really, those 5 boards here -do- share 99%
> of the code... it's just that one need a workaround at the IRQ fixup
> level, maybe one needs a tweak on a GPIO at boot and one has an issue on
> reboot that needs to be whacked a bit differently ... well, make
> -library- code.
> 
> I have no objection of having something like for each ppc_md field
> called X, having a utility file providing an mpc52xx_generic_X function.
> Such a board could then basically have a small .c file whose ppc_md just
> use the generic functions for all except the ones that need to be
> hooked/wrapped/replaced/whatever.

This is sort of the part that sucks.  Look at 44x.  There are 10
board.c files there.  There really only needs to be 3 or 4 (sam440ep,
warp, virtex, and "generic") because the board files are identical in
everything except name. By doing the library code approach, one still
has to create a board.c file for a new board and plug in the library
functions to ppc_md.

Alternatively, you could do the:

compatible = "specific-board", "similar-board"

approach that has been done for e.g. Bamboo and Yosemite.  Again, the
issue is that is that OK?  Is it OK for a board to claim compatibility
with another board when it might not have all the devices of that
board, or might have additional devices, etc.  I was of the opinion
it is, and the device tree handles this just fine, as does the platform
code. But it can be confusing, hence the discussion here.

josh