Accton EN2220

[Donald Becker]

On Tue, 13 Apr 1999, Ning Ye wrote:

>     When compiling the new driver, I found in line 168:
> #if LINUX_VERSION_CODE < 0x20155  ||  defined(CARDBUS)
> the compiler reports a warning about pci bus.  As my kernel version is 2.2.3, I
> think maybe && is more better?  So with the new include files?

Argggg.  The header files changed again.
In 2.1.85+ the pci.h file was broken and unusable, and the driver had to use
the old bios32.h.
I see that pci.h has been fixed, but the old brokenness has been moved to
bios32.h.  The changed code is an attempt to patch-up IRQ mapping for
little-used hardware, and once again breaks things for CardBus drivers.

Grrrr, Martin doesn't seem to understand the idea of not gratuitously
breaking working code.  This could have been written in a way that worked
for existing code.

>  The new driver still has some problem about MII.  Please take a look at my
> log file and tulip-diag's output in the attached file.
> Do MII PHY #x transceiver registers seem normal?  Why the values almost the
> same?  And using this interface cause the transmit time out and the driver tries
> another mode.

You card was designed incorrectly.  The idle level of the of the MII serial
mangement line is suppose to be '1', and a missing transceiver should show
up as a read of 0xffff.  The driver also supports an idle level of '0',
which results in a read of 0x0000.  What it can't handle is a floating line
that slowly floats from 1 to 0, resulting in reads such as 0x8000 or 0xC000
on the odd numbered registers.
These are potentially valid values, and they driver decides that it has
detected a MII transceiver.

In a better world, without other broken cards, I could work around this
problem in many ways:
  - I wouldn't search for MII transceivers unless the EEPROM indicated one
    existed.  But many cards have bogus EEPROMs, using the Digital
    symbol-mode example while actually having an MII transceiver.
  - The MII read routine would look for a initial 0 transition, designed so
    that you could still detect that a register read of 0xffff was valid.
    But some transceivers don't generate this transition.
  - The MII transceiver detect routine would read an even-addressed register
    and check for 0x0000.  I used to do this, but had to change because one
    bogus version of the D-Link boards returned 0x0000 for the control
    register setting.  (Forcing 10baseT half duplex non-autonegotiate.)

I haven't *yet* come up with a simple detection scheme that would work around
the hardware bug on your card.  Ideally it would happen with a single MII
read checking for two always-clear and two always-set bits.

I'm continuing to thinks about this problem.

> In this version, it reports "+ ioctl: Operation not supported", but in the
> source, I see a ioctl interface is defined.  What's wrong there?

No obvious problem.. I'll check it out.

>  And a little more about the document.  Now the note IVb. References should
> have some changes.  We may search Intel for "21*4*" and
> http://www.national.com/pf/DP/DP83840a.html from national.com.

Checked, "840A", not "840a".  Corrected in the source code.

Donald Becker					  becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882	     http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html