src-test/sys/pci, branch stable/7

MFC r232145:

2012-03-26T03:56:52Z

Use correct Config registers for RTL8139 family. Unlike RTL8168 and RTL810x family , RTL8139 has different register map for Config registers. While here, follow the lead of re(4) in WOL configuration. - Disable WOL_UCAST and WOL_MCAST capabilities by default. - Config5 register write does not need to unlock EEPROM access on RTL8139 family but unlocking EEPROM access does not affect its operation and make it consistent with re(4). Reported by: Matt Renzelmann mjr <> cs dot wisc dot edu

MFC r227850-227851,227854,227914,227916:

2012-01-04T23:32:50Z

r227850: Writing access to RL_CFG5 register also requires EEPROM write access. While I'm here, enable WOL through magic packet but disable waking up system via unicast, multicast and broadcast frames. Otherwise, multicast or unicast frame(e.g. ICMP echo request) can wake up system which is not probably wanted behavior on most environments. This was not known as problem because RL_CFG5 register access had not effect until this change. The capability to wake up system with unicast/multicast frames are still set in driver, default off, so users who need that feature can still activate it with ifconfig(8). r227851: Perform media change after setting IFF_DRV_RUNNING flag. Without it, driver would ignore the first link state update if controller already established a link such that it would have to take additional link state handling in re_tick(). r227854: Disable accepting frames in re_stop() to put RX MAC into idle state. Because there is no reliable way to know whether RX MAC is in stopped state, rejecting all frames would be the only way to minimize possible races. Otherwise it's possible to receive frames while stop command execution is in progress and controller can DMA the frame to freed RX buffer during that period. This was observed on recent PCIe controllers(i.e. RTL8111F). While this change may not be required on old controllers it wouldn't make negative effects on old controllers. One side effect of this change is disabling receive so driver reprograms RL_RXCFG to receive WOL frames when it is put into suspend or shutdown. This should address occasional 'memory modified free' errors seen on recent RealTek controllers. r227914: Make sure to stop TX MAC before freeing queued TX frames. For RTL8111DP, check if the TX MAC is active by reading RL_GTXSTART register. For RTL8402/8168E-VL/8168F/8411, wait until TX queue is empty. r227916: To save more power, switch to 10/100Mbps link when controller is put into suspend/shutdown. Old PCI controllers performed that operation in firmware but for RTL8111C or newer controllers, it's responsibility of driver. It's not clear whether the firmware of RTL8111B still downgrades its speed to 10/100Mbps so leave it as it was.

MFC r227587,227590-227591,227593,227638-227639:

2012-01-04T22:57:04Z

r227587: Add preliminary support for RTL8402 PCIe FastEthernet with integrated card reader. r227590: Add preliminary support for RTL8411 PCIe Gigabit ethernet with integrated card reader. r227591: Add missing driver lock in SIOCSIFCAP handler. r227593: Disable PCIe ASPM (Active State Power Management) for all controllers. More and more RealTek controllers started to implement EEE feature. Vendor driver seems to load a kind of firmware for EEE with additional PHY fixups. It is known that the EEE feature may need ASPM support. Unfortunately there is no documentation for EEE of the controller so enabling ASPM may cause more problems. r227638: Add preliminary support for second generation RTL8105E PCIe FastEthernet. r227639: Add preliminary support for RTL8168/8111F PCIe Gigabit ethernet.

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: r226995 (partially), r227042

2011-11-06T21:11:22Z

- Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially)

MFC: r199560

2011-10-30T01:24:56Z

- Hook into the existing stat timer to drive the transmit watchdog instead of using if_watchdog and if_timer. - Reorder detach to call ether_ifdetach() before anything else in tl(4) and wb(4).

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 r224506:

2011-08-15T17:10:23Z

Add new device id of D-Link DGE-530T Rev. C controller. DGE-503T Rev A1 and B1 is supported by sk(4) but the DGE-530T Rev. C controller is re-branded RealTek 8169 controller. PR: kern/159116

MFC r221565-221568,221579:

2011-05-27T21:45:21Z

r221565: Reuse the TX descriptor(DPD) if xl_encap() failed instead of just picking the next available one. This may explain why xl(4) sees TX underrun error with no queued frame. I hope this addresses a long standing xl(4) watchdog timeout issue as well. Obtained from: OpenBSD r221566,221579: Rename xl_stats_update() callout handler to xl_tick() and move MII tick driving logic to xl_tick(). Now xl_tick() handles MII tick as well as periodic updating of statistics. This change removes a hack used in interrupt handler where it wanted to update statistics without driving MII tick. r221567: Rearm watchdog timer if driver kick controller to recover from TX underrun error. While here, prepend 0x to status code to show TX status is hex number. r221568: XL_DMACTL is 32bit register, use 32bit write macro. While I'm here add more bits for the register.

MFC r221563-221564:

2011-05-27T20:34:23Z

r221563: Terminate interrupt handler if driver detect it's not running. Also add check for driver running state before trying to send frames. While I'm here, use for loop. r221564: Change xl_rxeof() a bit to return the number of processed frames in RX descriptor ring. Previously it returned the number of frames that were successfully passed to upper stack which in turn means it ignored frames that were discarded due to errors. The number of processed frames in RX descriptor ring is used to detect whether driver is out of sync with controller's current descriptor pointer. Returning number of processed frames reduces unnecessary (probably wrong) re-synchronization. While here, remove unnecessary local variable initialization.