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

Merge r240680 from head:

2012-10-28T13:21:35Z

Align the PCI Express #defines with the style used for the PCI-X #defines. This has the advantage that it makes the names more compact, and also allows us to correct the non-uniform naming of the PCIM_LINK_* defines, making them all consistent amongst themselves. This is a mostly mechanical rename: s/PCIR_EXPRESS_/PCIER_/g s/PCIM_EXP_/PCIEM_/g s/PCIM_LINK_/PCIEM_LINK_/g In this MFC, #defines have been added for the old names to assist merges and out-of-tree drivers.

MFC r234643:

2012-05-19T22:50:38Z

Do not toggle IFCAP_TSO4 if we would also do TSO6. Given the driver does not currently announce/support TSO6 that cannot happen. Clean it up anyway for consistency.

MFC r232246:

2012-03-26T04:30:46Z

Prefer RL_GMEDIASTAT register to RGEPHY_MII_SSR register to extract a link status of PHY when parent driver is re(4). RGEPHY_MII_SSR register does not seem to report correct PHY status on some integrated PHYs used with re(4). Unfortunately, RealTek PHYs have no additional information to differentiate integrated PHYs from external ones so relying on PHY model number is not enough to know that. However, it seems RGEPHY_MII_SSR register exists for external RealTek PHYs so checking parent driver would be good indication to know which PHY was used. In other words, for non-re(4) controllers, the PHY is external one and its revision number is greater than or equal to 2. This change fixes intermittent link UP/DOWN messages reported on RTL8169 controller. Also, mii_attach(9) is tried after setting interface name since rgephy(4) have to know parent driver name. PR: kern/165509

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

2012-02-23T11:28:19Z

For RTL8168/8111D controller, make sure to wake PHY from power down mode. Otherwise, PHY access times out under certain conditions. Approved by: re (kib)

MFC r230336:

2012-02-15T03:51:09Z

Fix a logic error which resulted in putting PHY into sleep when WOL is active. If WOL is active driver should not put PHY into sleep. This change makes WOL work on RTL8168E.

MFC r230575-230576:

2012-02-15T03:43:46Z

r230275: Use a RX DMA tag to free loaded RX DMA maps. Previously it used a TX DMA tag. r230276: Free allocated jumbo buffers when controller is stopped.

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)