fast ethernet driver MII phy serial clock rates

[David Burns]

Mike Silbersack wrote:

> 
> On Sat, 24 Apr 2004, David Burns wrote:
> 
> 
>>Hello all,
>>
>>It appears that quite a few of the "el cheapo" hardware Fast Ethernet
>>drivers (at least rl, sis, ste, vr, wb - these are just the ones I found
>>in /usr/src/sys/pci) have added DELAY(1) statements around MII serial
>>clock ops which will result in a max Management Data Clock (MDC)
>>frequency of 500kHz for the serial management interface. Which means
>>that a mii_readreg (or writereg) operation will take a minimum of 128?s
>>(64?s for mii_sync + 64?s for data read/write). During which time the
>>driver is locked.
> 
> 
> This is an old problem, most of us leave it alone because hardware can
> break in strange ways. :)
> 

I was afraid someone would say that... :-)

We should still implement this where testing succeeds on at least a few 
hardware platforms.

Alternatively implement a driver.mii_phy_fast tunable which allows the 
DELAY to be disabled.

> 
>>NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't
>>think it is ... :-(
> 
> 
> Correct, DELAY takes far longer than it should.
> 
> If you're really interested in fixing the problem and not inadvertantly
> breaking older cards, what you should do is implement a nanodelay function
> that actually delays for the time it's supposed to and then delay the
> rated amount.  Removing all delays will probably break something
> somewhere.
> 

We could probably build a driver specific nanodelay function based on 
dummy PCI operations. Some will say this sucks but then I'd argue it's 
better than the current DELAY implementation.

Of course just sending one bit of data on the MDIO will take us about 
600 nanoseconds - resulting in a 1.6MHz clock.

Probably need input from the guys who originally cut these drivers years 
ago (eg wpaul) to help identify the pathological PHYs out there...

David