we start polling the BMCR again. Greg Woods noted on tech-net@
that the DP83840A manual states that there should be a 500us delay
between asserting software reset and attempting MII serial operations.
I've also noted that a DP83815 can get into a bad state on cable
removal and reinsertion if we do not delay here.
This may well address PR/16346, and I seem to recall occasional
reports of auto-negotiation and flaky kinds of errors that this
might also alleviate.
autonegotiation to take place if IFM_AUTO is selected in mii_media_set.
Make the gem driver use it. (XXX hme probably should use it but I can't
test that).
and default every PHY to 5 seconds (what we used before). If we find
Gig-E media on a PHY, bump it to 10 seconds, since it can take 5
seconds just to negotiate a Gig-E link.
802.3 doens't specify ANAR or ANLPAR bits for GMII. Need to
use PHY-specific registers for this, for now, which means we
need specific drivers for the Gigabit-capable PHYs (I think the
most common is the BCM5400).
instead of discrete function pointers, and extend this to include
a "reset" entry point. Make sure any PHY-specific reset routine is
always used, and provide one for the LXT-970 which disables MII
interrupts (as is done for a few other PHYs we have drivers for).
timeout()/untimeout() API:
- Clients supply callout handle storage, thus eliminating problems of
resource allocation.
- Insertion and removal of callouts is constant time, important as
this facility is used quite a lot in the kernel.
The old timeout()/untimeout() API has been removed from the kernel.
so that they are not includes if no PHY is configured
(avoids code bloat if an interface driver has the "mii" attribute but
mii is not used by the particular version)
