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)
with IEEE, so use the "real" OUIs for definitions.
Now unfortunately vendors differ in how the MII ID register bits are
used wrt bit and byte ordering. There is a straightforward way - bits
numbered from LSB to MSB - used by AMD, Intel, NS and QS. This is used
by the current MII_OUI() conversion macro. ICS, Seeq, SiS and TI count
the bits as they appear on the wire, and some differ completely.
Account for these cases by "xx" prefixed OUI definitions which compensate
for this, so the MII_OUI() macro can still be used.
Add AMD (the "real" AMD this time) and the 79c973 PCnet internal PHY.
PHYs we don't have specific drivers for. While this will not give
optimum operation, it will allow network interface drivers to at least
function while drivers for their specific PHYs are written.
mii_softc (generic phy goo), and just switch all of the PHY drivers
(except tlphy, which really does have special stuff) to use an mii_softc
instead of a private one.
current ifmedia_entry, not from the user-supplied media word. The
user supplied media word may not necessarily match e.g. instance (if
the parent MAC driver is intentionally ignoring instance if its expecting
multiple PHYs with non-overlapping media, e.g. TI ThunderLAN) the media
word we are actually switching to.
Since PHY drivers use `instance' to determine if they should isolate
themselves, the ThunderLAN PHY was sometimes being incorrectly isolated
when in fact the user attempted to select that PHY (for e.g. BNC operation).
that we may have (TLPHY_MEDIA_10_x | TLPHY_MEDIA_NO_10_T).
- add carrier detect for AUI/BNC.
This now works properly with a "Compaq Netelligent 10/100 TX" and a
"Compaq ProLiant Integrated Netelligent 10/100 TX", untested with others
(but should work as well).
properly! Work around this by determing current active media by taking
the highest-order common bit of our advertised capabilites and the link
partner's.
If the link partner doens't do autonegotiation, then parallel detection will
pick up the media type, which will never be full-duplex, so reading the PAR
is ok in this case.
Bug pointed out by Matthias Drochner, work-around inspired by reading
the dp83840 manual, section 3.9 (IEEE 802.3u auto-negotiation).
soren