[En-Nut-Discussion] at91_emac.c

[Ulrich Prinz]

Hi Tim!

We must have overlooked that post, sorry!

I am very interested in your fixes. May be you can get into some more 
details and even post your already done fixes in a diff or as you 
version of at91_emac.c file? I can integrate and check if it works 
flawless. I have some AT91SAM7X boards at hand.

As I will start the port for STM32F107 EMAC in the next days I would 
like to use something as a reference driver and thought about the AT91 
version. But I think I don't like to port the bugs too :)

Best regards
Ulrich

Am 28.06.2010 15:45, schrieb DeBaillie, Tim:
> How old is the arch/arm/dev/at91_emac.c file?  It looks like it needs
> some major rework.  A few examples:
>
> * EmacStart always returns 0 which is used as a check during initialization.
I dislike that too, but sometimes it is difficult to decide what is an 
error and what is acceptable.

> * EMAC_TX_BUFFERS is configurable, but the functions used for TX and
> initialization are coded to accept only 2 as a proper answer.
Ups. Bad solution :) need to fix that.

> * Reinitialization of the interface is not done properly.
In what cases precisely?

> * TX errors are not checked nor handled.
Ok, that should not be.

> * Blocking of multicast packets isn't configurable.
That should be implemented, if not for comfort it must be configurable 
for security and memory saving on small devices.

> * Phy and MII interface needs to be much more configurable, including
> a non-NRST line tied to the reset of the PHY/MII device.
Yes especially as the PHYs are as long living as LCD driver chips... 
below 6 month...
>
> Some of these issues I can resolve myself, but the "reinitialization
> of the interface" requires some major work.
>
Would be great to hear from you!

Best regards
Ulrich