On Fri, 2008-08-01 at 08:27 -0600, Grant Likely wrote: > > I agree with most of your argument, except I really have problems with > boards claiming compatibility with an older board. My reason is > exactly the reason you state; One day you'll figure out that there is > indeed a difference. The problem is; when the original board (the one > others are claiming compatibility with) gains additional code to fixup > quirks or something, then that code will get changed with no > visibility that it is borking up other boards that are currently > depending on it.
Then just use your own .c file. It's not like it was a big deal. I don't know why it's -so- appealing to not have to do one at all. > I far prefer the solution I'm currently using in 5200-land where there > is a simple (boring?) board port which *explicitly* states which > boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c). > When someone goes to modify that file, it is explicit that it > currently supports multiple boards. If a board becomes 'non-boring', > then it is removed from the simple platform; the simple platform is > *not* extended to accommodate it. As long as you stick to -never- extend the simple platform to accomodate for a variant, then I suppose that's ok I suppose, though that does raise the point of what to put in the compatible property. > I *fully* agree that it is insane for the code to grow detection logic > and I've been explicit about not doing anything of the sort in 5200 > land. What I am suggesting is that if nothing else claims the board, > then allow the simple platform to bind against it based on the fact > that it uses the same SoC. See my comment in my reply to Josh about changing the board probe into a multi-pass probe so that first, we only match on the first entry of the compatible property, then we match on the second, etc... to go from more specific to less specific. > However, if I can't get concensus on this approach, then I do /not/ > want to go to a boards compatible with other boards scheme. It will > cause breakage and pain that is non-obvious to debug for many users. As far as I'm concerned, this approach is mostly useful for revisions of a board. Oh and I'm not going to whack you with a stick if in the end, you do have a little bit of variation in a single board .c file to deal with a glitch in rev. C of the board that wired something backward for example ... it's a matter of perspective. But I would prefer a different board (from a different vendor for example) to use a different .c file even if it only differs by the same little glitch. > BTW, I am also not suggesting that the .dts files themselves try to > claim some kind of 'generic' compatibility. I'm proposing handling > any catch-all cases in the Linux code itself, where it is easy to > change because it is just an implementation detail. Trying to make > the dt 'generic' doesn't make any sense because doing so is almost > always wrong (or will become wrong in the future). The problem is that I don't see a sane way to do the catch all in the linux code, other than explicitely doing what you already do which is to list all supported boards in the simple platform. It's either that or adding some compatible "socname,linux-simple" or so property in your .dts. I don't believe matching on SoC is of any use. It will incorrectly try to match things that don't work and that's bad. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
