Andrey Savochkin wrote:
>
> Hello,
>
> On Thu, May 18, 2000 at 06:05:59PM -0700, Dragan Stancevic wrote:
> > From looking at the error messages that you are getting I second Andrey's
> > mail, this is happening because the driver is experiencing problems when
> > reading the eeprom and fails to detect you PHY. Unless you have no PHY :^)
> >
> > The driver has issues with reading the eeprom, it doesn't drive the
> > eeprom serial clock correctly. By not following clock frequency
> > specification it clocks data "into/out of" epprom incorrectly.
>
> It may be some other problems...
> Original Donald's driver worked with udelay(100) until Donald himself
> replaced the udelay by a delay implemented as a single inw()!
> The available Intel's driver uses udelay(100).
> NetBSD uses udelay(1).
Think about what Donald is doing, and remember that inw() is not really
inw() here!
Remember first that eepro100 is generally MMIO, so you the following is
in effect:
#define inw writew
So, by replacing the udelay() with writew(), Donald not only introduces
a small delay, but also posts any pending PCI writes. That may be
important, may be nothing...
In any case, if you were thinking about it, I wouldn't blindly replace
writew() with udelay() or anything like that -- leave the writew() in
there, and add an additional udelay() if the circumstances call for it.
Excluding the writew() increases the potential for seeming EEPROM code
flakiness, because few drivers have thus far been completely audited,
updated, and tested for correct MMIO flush semantics.
Jeff
-- Jeff Garzik | Liberty is always dangerous, but Building 1024 | it is the safest thing we have. MandrakeSoft, Inc. | -- Harry Emerson Fosdick- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:18 EST