[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200905211034.39762.kosmo@semihalf.com>
Date: Thu, 21 May 2009 10:34:39 +0200
From: Piotr Zięcik <kosmo@...ihalf.com>
To: Grant Likely <grant.likely@...retlab.ca>
Cc: Wolfgang Denk <wd@...x.de>, Scott Wood <scottwood@...escale.com>,
John Rigby <jrigby@...il.com>, linuxppc-dev@...abs.org,
Detlev Zundel <dzu@...x.de>, netdev@...r.kernel.org,
Kumar Gala <galak@...nel.crashing.org>,
Becky Bruce <Becky.Bruce@...escale.com>
Subject: Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
Thursday 14 May 2009 16:00:33 Grant Likely wrote:
> > MPC5121 support was added to drivers/net/fs_enet. MPC52xx uses
> > drivers/net/fec_mpc52xx.c. Do you think that creating one universal
> > driver from these two is now possible? You said that it should be easy,
> > however you also said that cache coherency issues makes this imposible.
>
> Not impossible. Hard.
I thought a bit more about merging FEC drivers and I see one problem more.
Driver fs_enet works with FEC's with own DMA engine and fec_mpc52xx.c uses
BestComm. Integration of these two drivers will need a DMA abstraction layer
to keep everything clean. Unfortuanetly BestComm driver does not provide any
abstraction - it only exports set of functions to deal with specific
hardware: FEC and PATA.
More #ifdef's will be needed to remove linking with BestComm driver if kernel
will be compiled without 52xx support and resulting code will not be much
better than existing one. Especially that new DMA abstraction layer probably
will be quite complex.
--
Best Regards.
Piotr Ziecik
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists