On Fri, 1 Aug 2008 08:27:41 -0600 "Grant Likely" <[EMAIL PROTECTED]> wrote:
> > 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. > > 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. There is that possibility yes. And it is even non-theoretical to a degree, as the situation may occur with the existing Bamboo/Yosemite scenario when we get around to fixing up the horror that is the EBC on Bamboo. Admittedly, a single person did both those ports so the inherent knowledge is already there, but that won't always be the case. > 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. To me, the solution you are using there seems like the best compromise between the various options. It allows a common "board".c (or platform) file in the kernel, while still adhering to a form of purity in the device tree itself. The only slightly annoying issue is the need to change the explicit list, but I don't consider that a burden really. If you haven't noticed, my primary reason for wanting to do _something_ is to prevent the proliferation of code duplication that we've seen. Cleanup time is in order, and this is the most expedient and seemingly correct way of doing things. > 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. > > 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. I think there is too much momentum behind the old method, and not a clear enough definition on how one would bind to a generic SoC without dealing with things like link order, etc. Also, not every platform has SoC nodes (as you already pointed out), and adding them to the DTS files (or adding a new property or binding to the CPU node, etc) for this purpose seems to be both overkill and contrary to not wanting to break existing products out there that use the old DTS files and method. They should be few in number, but they do exist (see PIKA Warp). I'm growing very much of the opinion that the way you are _currently_ handling 52xx is more or less the way we should go. josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
