Re: [PATCH 1/4] alchemy: register au1000_eth as a platform driver part one

[Florian Fainelli <florian@openwrt.org>]

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@openwrt.org
Web: http://openwrt.org
IRC: [florian] on irc.freenode.net
-------------------------------