On Fri, Aug 1, 2008 at 6:06 AM, Josh Boyer <[EMAIL PROTECTED]> wrote: > On Fri, 01 Aug 2008 14:25:39 +1000 > Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
