MII reset and the sticky Link bit

[Yisrael]

Donald and Company (sorry, sort of sounds like Disney :-),

Due to some strange behavior of the eepro100 NICs, I've been
going over the driver again and as a result, I have several
questions...

Below is a section of code from the speedo_tx_timeout routine
in the eepro100 driver (version 1.09t) that performs a reset
of the MII transceiver. There are several details that I don't
understand. No, this isn't a BASIC program, I just included
line numbers for reference.

01 /* Reset the MII transceiver, suggested by Fred Young @ scalable.com. */
02 if ((sp->phy[0] & 0x8000) == 0) {
03    int phy_addr = sp->phy[0] & 0x1f;
04    int advertising = mdio_read(ioaddr, phy_addr, 4);
05    int mii_bmcr = mdio_read(ioaddr, phy_addr, 0);
06    mdio_write(ioaddr, phy_addr, 0, 0x0400);
07    mdio_write(ioaddr, phy_addr, 1, 0x0000);
08    mdio_write(ioaddr, phy_addr, 4, 0x0000);
09    mdio_write(ioaddr, phy_addr, 0, 0x8000);
10 #ifdef honor_default_port
11    mdio_write(ioaddr, phy_addr, 0, mii_ctrl[dev->default_port & 7]);
12 #else
13    mdio_read(ioaddr, phy_addr, 0);
14    mdio_write(ioaddr, phy_addr, 0, mii_bmcr);
15    mdio_write(ioaddr, phy_addr, 4, advertising);
16 #endif

line 06 - 0x0400 is being written to MDI register 0.
   According to the Intel 82558 datasheet, this is a
   reserved bit. Is this line an error? Is this bit
   in fact defined somewhere? Or is another bit
   intended here? Restart Auto negotiation? What is
   the intention of this line of code?

line 07 - MDI register 1 is defined as Read Only (according
   to the datasheet). Will writing to this register cause a
   problem, or is it just ignored? What is the [intended]
   purpose for writing to this register here?

line 13 - According to the datasheet, for bit 15 (the reset
   bit) "The PHY returns a value of one until the reset
   process has completed and accepts a read or write
   transaction." Should the result from this read be checked
   for a one (1) before proceeding? Perhaps the subsequent
   lines (14 and 15) need to wait for the reset to finish
   first? And what does Intel mean by "one"? I assume this
   means that bit 15 stays 1 and doesn't clear (become 0)
   until the reset is complete.

Also, in the routine speedo_timer the following code segment
appears:

01 /* Clear sticky bit. */
02 mdio_read(ioaddr, phy_num, 1);
03 /* If link beat has returned... */
04 if (mdio_read(ioaddr, phy_num, 1) & 0x0004)
05    dev->flags |= IFF_RUNNING;
06 else
07    dev->flags &= ~IFF_RUNNING;

line 01 - The comment indicates that a bit (the link status
   bit from MDI register 1) is sticky. I've noticed that
   this bit does in fact get stuck. This can be seen by
   running the utility program "ifconfig". There are times
   when ifconfig indicates a "RUNNING" status, even though
   no cable is connected to the connector on the NIC (a new
   wireless feature :-). This indicates that the link status
   bit is "stuck". Further experiments with the driver have
   also shown this, so it's not just an ifconfig problem.

line 02 - This read should be unnecessary - and in fact from
   what I've seen, it has no affect. The routine speedo_timer
   gets called every 2 seconds, so in any case, MDI register
   1 gets read every 2 seconds. Even being read every 2
   seconds doesn't succeed in unsticking this bit. The
   question is... Why does this bit get stuck? Is it due to a
   bug in the driver? Or a bug in the NIC?

As my references, I'm using:
- Datasheet, 82558 Fast Ethernet PCI Bus Controller with
   Integrated PHY
- Intel 82557 User's Guide (marked Intel Confidential)
I'm still waiting for the '558 or '559 User's Guide.
Will it help?

I'm going to be playing around with the driver the beginning
of next week to see if I can make some sense out of the above
issues. I don't feel like chasing my tail however, so I thought
I'd ask first to see if anyone has additional information
concerning these matters. If I come up with anything, I will
of course inform you all.

As usual, thanks to Donald Becker for his extraordinary
efforts in the development of these drivers. We really should
all buy him a beer - uh, not all at once though.

Take care and have a good weekend,

Yisrael (Russ) Hersch
Allot Communications
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-eepro100-request@beowulf.org