Board level compatibility matching

[Grant Likely]

On Fri, Aug 1, 2008 at 6:06 AM, Josh Boyer <jwboyer at linux.vnet.ibm.com> wrote:
> 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

As stated in my previous email; I dislike this approach.  I far prefer
making the board support code provide an explicit list rather than
trying to define what it means for one board to be compatible with
another.

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

I say no [but you already know that. :-) ]

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