Hi Manuel, Sergei, Le Wednesday 29 July 2009 16:27:02 Manuel Lauss, vous avez écrit : > Hi Sergei, > > >> Yes I know ;) I was just wanting to get this out quickly before you kill > >> platform.c > > > > I'd NAK such patch (and have already done so, AFAIR). > > I've already surrendered myself to the fact that I'll never be able to get > rid of this file in my lifetime. However I've set a timer on my mail > machine to send a patch (which I'll keep rebasing to latest sources) trying > that again in 80 years or so ;-) > > >> I will make the au1000-eth devices be registered on a per-board basis. > > > > Please don't. You can register them in platform.c, and yet leave > > actually board specific platform data in the board files. There's no > > reason to duplicate the platfrom device itself. > > Let's say I have 2 pieces of hardware, indentical in all things, > except one has an Au1100, and the other Au1500 (different MAC mmio > address and unit counts). I want to build a kernel which runs on both. > This can certainly be done, but the existence of common/platform.c and > your insistence on maintaining the status-quo limits me to one board > per kernel (theoretical example currently, i know). I am still a big fan of a single kernel approach for a SoC whenever runtime identification is possible. > > I also dislike having to #ifdef around this file when a new platform > is introduced which doesn't need/use all devices registered in there! > (for example au1200 mmc platform data. Suppose I have a platform > which doesn't use mmc; I can either add a #ifdef for my new board or > provide empty platform data stubs in my board code. Both solutions > suck IMO; the former because then when I (and others) submit new > board code upstream common/platform.c will develop into a mess of > random #ifdefs (just look at common/reset.c!) and the latter because > platform data and -device registration are in different places in the > source tree. Well, right now, the au1000_eth driver has been converted in a way that even passing no platform_data to it makes it pick the right defaults (searching for PHY1 on MAC0) so this is not a big problem here, this might not be the case with other drivers. Even though it duplicates quite a lot of code, it's still cleaner when you either have to pick up the eval board which is the closest to your design, or have to add a new board. I am going to respin the patches with the Ethernet driver registered in a per-board platform.c file, which lets room for other platform devices to be registered there too. Everyone can then make up his mid about which approach he prefers ;) -- Best regards, Florian Fainelli Email: florian@xxxxxxxxxxx Web: http://openwrt.org IRC: [florian] on irc.freenode.net -------------------------------
