Andrey Savochkin wrote:
> 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()!
A tangent subject: as I mentioned in a previous message, this inw() is
really writew() in disguise, because eepro100 defaults to MMIO
operation.
This is fairly common in many Becker drivers, and also not a little bit
misleading. I have converted 8139too over to a scheme which defines
driver-specific register read/write macros, for example
#ifdef USE_IO
#define EE_W16(reg,data) outw((data), ioaddr+(reg))
#define EE_W16_F EE_W16
#else
#define EE_W16(reg,data) writew((data), ioaddr+(reg))
#define EE_W16_F(reg,data) do { \
writew((data), ioaddr+(reg)); \
readw(ioaddr+(reg)); } while (0)
#endif
The purpose is twofold -- stop the misleading practice of redefining inw
to be an MMIO operation -- and also make use of Donald's standard
"ioaddr" temp var in the macro, to make code more readable.
I think that redefining inw (etc.) is not good because it leads to bugs
and confusion.. In general redefining a well-known function is not good
practice.
Donald, maybe you could be convinced to consider an alternative to
'#define inw writew' in the next rev of your code?
Regards,
Jeff
--
Jeff Garzik | Liberty is always dangerous, but
Building 1024 | it is the safest thing we have.
MandrakeSoft, Inc. | -- Harry Emerson Fosdick
|