src-test2/sys/dev/nfe, branch stable/7

MFC r226478:

2011-12-31T01:10:29Z

Close a race where SIOCGIFMEDIA ioctl get inconsistent link status. Because driver is accessing a common MII structure in mii_pollstat(), updating user supplied structure should be done before dropping a driver lock. Reported by: Karim (fodillemlinkarimi <> gmail dot com)

MFC: r221407 (partial)

2011-09-11T20:25:57Z

- Let mii_phy_add_media() also announce the support of IFM_NONE. - Add a PHY-specific reset routine is for lxtphy(4) which disables MII interrupts. - Remove redundant checks in NIC drivers for mii->mii_instance not being zero before calling the reset routines because as soon as one PHY driver attaches mii->mii_instance is incremented and we hardly can end up in their media change callbacks etc if no PHY driver has attached as mii_attach() would have failed in that case and not attach a miibus(4) instance. - Convert the mebers of the MII data structure to unsigned where appropriate. This is partly inspired by NetBSD/OpenBSD. - Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that weren't explicitly converted to support flow control before. It's unclear whether flow control actually works with these but typically it should and their net behavior should be more correct with these changes in place than without if the MAC driver sets MIIF_DOPAUSE. Obtained from: NetBSD (partially)

MFC r222542:

2011-06-22T00:39:36Z

If driver is not running, disable interrupts and do not try to process received frames. Previously it was possible to handle RX interrupts even if controller is not fully initialized. This resulted in non-working driver after system is up and running. Reported by: hselasky Tested by: hselasky

MFC r215432:

2011-02-20T01:26:29Z

MCP55 is the only NVIDIA controller that supports VLAN tag insertion/stripping and it also supports TSO over VLAN. Implement TSO over VLAN support for MCP55 controller. While I'm here clean up SIOCSIFCAP ioctl handler. Since nfe(4) sets ifp capabilities based on various hardware flags in device attach, there is no need to check hardware flags again in SIOCSIFCAP ioctl handler. Also fix a bug which toggled both TX and RX checksum offloading even if user requested either TX or RX checksum configuration change. Tested by: Rob Farmer ( rfarmer <> predatorlabs dot net )

MFC r217794:

2011-02-20T01:22:48Z

Reinitialize driver when MTU is changed and driver is running. Reported by: Huang, Yusheng ( yusheng.huang <> bluecoat com )

MFC r216925,217331,217349,217542:

2011-02-02T18:44:02Z

r216925: Add a 'locked' variant of the foo_start() routine and call it directly from interrupt handlers and watchdog routines instead of queueing a task to call foo_start(). r217331: Make sure to invoke unlocked foo_start since the taskqueue does not hold a driver lock. This should fix a regression introduced in r216925. r217349: Forgot to remove unlock of the driver lock from age_start_locked() when converting it to a locked variant. r217542: Fix some bugs in my last set of changes to ale(4): - Remove extra unlock from end of ale_start_locked(). - Expand scope of locking in interrupt handler. - Move ether_ifdetach() earlier and retire now-unneeded DETACH flag. Tested by: Aryeh Friedman

MFC: r214608, r215297(partial), r215713

2010-11-26T19:48:27Z

o Flesh out the generic IEEE 802.3 annex 31B full duplex flow control support in mii(4): - Merge generic flow control advertisement (which can be enabled by passing by MIIF_DOPAUSE to mii_attach(9)) and parsing support from NetBSD into mii_physubr.c and ukphy_subr.c. Unlike as in NetBSD, IFM_FLOW isn't implemented as a global option via the "don't care mask" but instead as a media specific option this. This has the following advantages: o allows flow control advertisement with autonegotiation to be turned on and off via ifconfig(8) with the default typically being off (though MIIF_FORCEPAUSE has been added causing flow control to be always advertised, allowing to easily MFC this changes for drivers that previously used home-grown support for flow control that behaved that way without breaking POLA) o allows to deal with PHY drivers where flow control advertisement with manual selection doesn't work or at least isn't implemented, like it's the case with brgphy(4), e1000phy(4) and ip1000phy(4), by setting MIIF_NOMANPAUSE o the available combinations of media options are readily available from the `ifconfig -m` output - Add IFM_FLOW to IFM_SHARED_OPTION_DESCRIPTIONS and IFM_ETH_RXPAUSE and IFM_ETH_TXPAUSE to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so these are understood by ifconfig(8). o Make the master/slave support in mii(4) actually usable: - Change IFM_ETH_MASTER from being implemented as a global option via the "don't care mask" to a media specific one as it actually is only applicable to IFM_1000_T to date. - Let mii_phy_setmedia() set GTCR_MAN_MS in IFM_1000_T slave mode to actually configure manually selected slave mode (like we also do in the PHY specific implementations). - Add IFM_ETH_MASTER to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so it is understood by ifconfig(8). o Switch bge(4), bce(4), msk(4), nfe(4) and stge(4) along with brgphy(4), e1000phy(4) and ip1000phy(4) to use the generic flow control support instead of home-grown solutions via IFM_FLAGs. This includes changing these PHY drivers and smcphy(4) to no longer unconditionally advertise support for flow control but only if the selected media has IFM_FLOW set (or MIIF_FORCEPAUSE is set) and implemented for these media variants, i.e. typically only for copper. o Switch brgphy(4), ciphy(4), e1000phy(4) and ip1000phy(4) to report and set IFM_1000_T master mode via IFM_ETH_MASTER instead of via IFF_LINK0 and some IFM_FLAGn. o Switch brgphy(4) to add at least the the supported copper media based on the contents of the BMSR via mii_phy_add_media() instead of hardcoding them. The latter approach seems to have developed historically, besides causing unnecessary code duplication it was also undesirable because brgphy_mii_phy_auto() already based the capability advertisement on the contents of the BMSR though. o Let brgphy(4) set IFM_1000_T master mode on all supported PHY and not just BCM5701. Apparently this was a misinterpretation of a workaround in the Linux tg3 driver; BCM5701 seem to require RGPHY_1000CTL_MSE and BRGPHY_1000CTL_MSC to be set when configuring autonegotiation but this doesn't mean we can't set these as well on other PHYs for manual media selection. o Let ukphy_status() report IFM_1000_T master mode via IFM_ETH_MASTER so IFM_1000_T master mode support now is generally available with all PHY drivers. o Don't let e1000phy(4) set master/slave bits for IFM_1000_SX as it's not applicable there. Reviewed by: yongari (plus additional testing) Obtained from: NetBSD (partially), OpenBSD (partially) Unlike as in head, bge(4), bce(4), msk(4), nfe(4) and stge(4) are changed to set MIIF_FORCEPAUSE in stable/7 so they continue to always advertise support of flow control and brgphy(4), ciphy(4), e1000phy(4) as well as ip1000phy(4) are changed to still also accept IFF_LINK0 in addition to the master media option for setting master mode, both in order to not violate POLA.

MFC r215327,215350:

2010-11-23T19:14:17Z

r215327: P5N32-SLI PREMIUM from ASUSTeK is known to have MSI/MSI-X issue such that nfe(4) does not work with MSI-X. When MSI-X support was introduced, I remember MCP55 controller worked without problems so the issue could be either PCI bridge or BIOS issue. But I also noticed snd_hda(4) disabled MSI on all MCP55 chipset so I'm still not sure this is generic issue of MCP55 chipset. If this was PCI bridge issue we would have added it to a system wide black-list table but it's not clear to me at this moment whether it was caused by either broken BIOS or silicon bug of MCP55 chipset. To workaround the issue, maintain a MSI/MSI-X black-list table in driver and lookup base board manufacturer and product name from the table before attempting to use MSI-X. If driver find an matching entry, nfe(4) will not use MSI/MSI-X and fall back on traditional INTx mode. This approach should be the last resort since it relies on smbios and if another instance of MSI/MSI-X breakage is reported with different maker/product, we may have to get the PCI bridge black-listed instead of adding an new entry. PR: kern/152150 r215350: Plug memory leakage introduced in r215327. Submitted by: jkim

MFC r215132,215194:

2010-11-18T17:49:24Z

r215132: Add basic WOL support for MCP ethernet controllers. It seems the controller does not perform automatic switching from 1000Mbps link to 10/100Mbps link when WOL is activated. Implement establishing 10/100Mps link with auto-negotiation in driver. Link status change handler was modified to remove taskqueue based approach since driver now needs synchronous handling for link establishment. Submitted by: Yamagi Burmeister (lists <> yamagi.org ) (initial version) Tested by: Yamagi Burmeister (lists <> yamagi.org ) r215194: Fix regression introduced in r215132. Caller always holds a driver lock before accessing mii, so locking is not needed here. Reported by: Rob Farmer (rfarmer <> predatorlabs dot net)

MFC: r213894, r213896, r214913

2010-11-07T17:38:54Z

Converted the remainder of the NIC drivers to use the mii_attach() introduced in r213878 (MFC'ed to stable/7 in r214685) instead of mii_phy_probe(). Unlike r213893 (MFC'ed to stable/7 in r214910) these are mostly straight forward conversions though.