Reason is that ifm_data does not store BMCR data but a media index
that gets poked into the BMCR register.
Setting the BMCR and ANAR registers is correctly handled by the
generic function mii_phy_setmedia.
IEEE 802.3 Annex 28B.3 specifies the following relative
priorities of the technologies supported by
802.3 Selector Field value:
1000BASE-T full duplex
1000BASE-T
100BASE-T2 full duplex
100BASE-TX full duplex
100BASE-T2
100BASE-T4
100BASE-TX
10BASE-T full duplex
10BAST-T
Our drivers give 100BASE-T4 a higher priority than
100BASE-TX full duplex.
Fix this. This patch is based on changes in FreeBSD and OpenBSD.
Patch presented on tech-kern and tech-net:
http://mail-index.netbsd.org/tech-kern/2009/02/15/msg004397.htmlhttp://mail-index.netbsd.org/tech-net/2009/02/15/msg001064.html
got no comments, no objections.
service routine. Add a wrapper for PHY_SERVICE(), called phy_service(),
and check device_is_active() there. Make the mii_*() routines call
the PHY service routines thorugh phy_service() instead of PHY_SERVICE().
In mii_phy_resume(), restore a PHY's state after resetting it by
sending a MII_MEDIACHG command. This change makes bnx(4) resume
more reliably and more quickly; it should help other NICs to resume,
too, if they attach PHYs through MII.
This makes autonegotiation on rlphy(4) at re(4)
on landisk (8139C+) select 100baseTX full-duplex
at boot time (before first ifconfig) properly,
and there is no bad side effect on rlphy(4) at nfe(4).
This may also fix PR kern/34109.
