[U-Boot] [PATCH 1/4] net: ll_temac: Add LL TEMAC driver to u-boot

[Stephan Linz <linz@li-pro.net>]

Hello Joe and Michal,

Am Mittwoch, den 28.03.2012, 09:53 +0200 schrieb Michal Simek: 
> Hi Joe,
> 
> >> Stephan Linz wrote:
> >>> Xilinx LocalLink Tri-Mode Ether MAC driver can be
> >>> used by Xilinx Microblaze or Xilinx ppc405/440 in
> >>> SDMA and FIFO mode. DCR or XPS bus can be used.
> >> Joe, Wolfgang: I don't agree with this driver because it is doing the same
> >> things as my origin
> >> version but on 800 lines instead of 1860lines. The next thing is that plb
> >> bus on Xilinx fpgas
> >> is getting obsolete.
> > 
> > Are you meaning that you already have a driver in u-boot that works on
> > this hardware or do you mean the original version somewhere else, like
> > Linux?

No, there is no u-boot custodian tree with an already merged driver.

> 
> There is really long history about this u-boot driver. The origin version for ppc was sent to mailing list
> April 26, 2008 by Yoshio Kashiwagi. I have tried to add it to mainline several times
> and my latest attempts end with result that I didn't want to follow u-boot coding style because
> of ppc/microblaze differences (not using offset with structure because of ppc/microblaze differences - dcr/plb access).
> That driver has 800 lines.
> Based on this strict rule I decided not to continue to push this driver to mainline
> because it is just a lot of work to change it and especially test it. My origin driver is used by many our customers
> on microblaze and ppc and none reported any problem with it.
> 
> After this Stephan decided to change it to be acceptable to mainline submission.

Yes, I've reworked the driver since November 2011 and now, in contrast
to the "800 lines" driver submitted by Michal, the new driver has more
features than the differnet memory access methods for ppc/microblaze:

  - eliminates all private data exchange buffer
  - supports the NetBuf handling for FIFO and DMA mode
  - supports the new MII bus framework
  - supports potentially more than just the two memory access methods
  - includes a complete register description (structs and defines)
  - split into differnet parts for better overview and readability

> 
> 
> > As for plb being near obsolescence, are you recommending a change to
> > the driver to drop support for that bus option? Or do you mean for
> > that reason the driver itself should be omitted?
> 
> should be obsolete in a year or so and if you add it to mainline it will be there
> but in 2013 there will be minimal number of users for it.

No! It may be that PLB will no longer be interesting for new designs.
But there are many existing FPGA solutions which will use the latest
software releases on it.

Moreover, this also aplied to the PowerPC at FPGA world (DCR part).

> 
> >> I am not going to add it to my microblaze custodian tree.
> >> If you like this patch please add it to u-boot-net tree or directly to
> >> mainline.

I like it ;) but unfortunately I have no custodian tree :(

> > 
> > I was actually going to recommend that it go through the microblaze
> > branch if it is primarily for microblaze targets.  If you don't want
> > it, then I think Stephan needs to work to convince you by making
> > revisions.
> 
> None can convince me that 1860 code lines which fulfill all u-boot rules
> is better than origin well tested 800 code lines (and commercially used)
> which break one u-boot rule.

Why not? The currently submitted driver has changes undergone a long
review process by different submitters and maintainers of U-Boot. This
driver is ready for future use (ex. the new MII bus and PHY device
abstraction, fully qualified register description for further extensions
if needed).

> I agree with rules but none can expect that I will assist and help to add
> it to mainline. I don't want to have responsibility for that.
> 
> BTW: Target is also ppc because there is DCR support.

If the DCR support is a problem, I can split the patches and separate
the DCR support. Currently the DCR related code is about 80 LOCs and
already enclosed by CONFIG_XILINX_440 and CONFIG_XILINX_405.


br,
Stephan