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
IRC: [florian] on irc.freenode.net