and into in6_if_link_up.
This fixes a possible panic where link is up but not the interface.
Note that a better solution would be to listen to the routing socket
in the kernel, but I don't know how to do that.
Reachable Router tests for IFF_UP as well.
(See annex 28B.2 and 28D). The old mii.h defined ANAR_X_PAUSE_* macros. Those
macros were named for 1000Base-X, but the bit definitions were not for
1000Base-X but for others (e.g. 1000BaseT). So there was bug in auto
negotiation for 1000Base-X, but there was no bug for other media. Define new
macro named ANAR_PAUSE_* and ANLPAR_PAUSE_* for other than 1000Base-X and fix
the bit definitions of ANAR_X_PAUSE_* and ANLPPAR_X_*. Change some PHY drivers
to use true macro. Same as other *BSDs.
and non-const types, and the kernel uses both const and non-const
PMF qualifiers and device suspensors, so change the pmf_qual_t and
device_suspensor_t typedefs from "pointers to const" to non-pointer,
non-const types.
This delay cause 500us loops under splnet() per linkdown port per mii_tick.
It causes periodically drop packets. It's not acceptable for other devices.
Move gphyter and nsphyter specific delay(500) into the drivers from
mii_physubr.c.
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.
of calling rt_ifmsg directly. This allows other parts of the kernel
to change the behaviour depending on the link state and is a
prerequirement for CARP.
Hide mii_phy_statusmsg, mii_phy_update should be used instead.
Don't send routing messages for baudrate changes, if_baudrate is
currently not exported via this interface.
OK tls@
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).
