src-test/sys/dev/dc, branch stable/7

MFC r227675:

2012-01-04T01:53:53Z

Partially revert r218788. r218788 removed calling dc_setcfg() for !DC_IS_ADMTEK in dc_miibus_statchg(). This change broke link establishment of Intel 21143 with dcphy(4) where it stuck in "ability detect" state without completing auto-negotiation. Also nuke dc_if_media as it's not actually used.

MFC r226701:

2012-01-02T23:40:09Z

Add support for ALi/ULi, now NVIDIA, M5261/M5263 PCI FastEthernet controller which is found on ULi M1563 South Bridge & M1689 Bridge. These controllers look like a tulip clone. M5263 controller does not support MII bitbang so use DC_ROM register to access MII registers. Like other tulip variants, ULi controller uses a setup frame to configure RX filter and uses new setup frame format. It's not clear to me whether the controller supports a hash based multicast filtering so this patch uses 14 perfect multicast filter to filter multicast frames. If number of multicast addresses is greater than 14, controller is put into a mode that receives all multicast frames. Due to lack of access to M5261, this change was not tested with M5261 but it probably works. Many thanks to Marco who provided remote access to M5263. Tested by: Marco Steinbach executive-computing dot de>, Martin MATO orange dot fr>

MFC r226699:

2012-01-02T23:22:11Z

When driver is run for the first time there would be no established link such that calling dc_setcfg() right after media change would be meaningless unless controller in question is not Davicom DM9102. Ideally dc_setcfg() should be called when speed/duplex is resolved otherwise it would reprogram controller with wrong speed/duplex information. Because MII status change callback already calls dc_setcfg() I think calling dc_setcfg() in dc_init_locked() is wrong. For instance, it would take some time to establish a link after mii_mediachg(), so blindly calling dc_setcfg() right after mii_mediachg() will always yield wrong media configuration. Extend dc_ifmedia_upd() to handle media change and still allow 21143 and Davidcom controllers program speed/duplex regardless of current resolved speed/duplex of link. In theory 21143 may not need to call dc_setcfg() right after media change, but leave it as it is because there are too many variants to test that change. Probably dc(4) shall need a PHY reset in dc_ifmedia_upd() but it's hard to verify correctness of the change. This change reliably makes ULi M5263 establish a link. While I'm here correctly report media change result. Previously it always reported a success.

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 r226695-226696:

2011-10-27T16:48:19Z

r226695: Fix a regression introduced in r218832. For TX status check, driver should use a TX list DMA tag. r226696: Add missing bus_dmamap_sync() in setup frame transmit.

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: r220046, r220106

2011-04-10T09:35:44Z

Wait until the DMA engine is stopped before unmapping buffers and descriptors, which fixes DMA errors seen on sparc64.

MFC r201449:

2011-03-28T00:19:01Z

Fix CardBus spelling.

MFC r219701:

2011-03-28T00:14:56Z

Remove too expensive bus_dmamap_sync(9) call in dc_rx_resync(). With this change, driver may not notice updated descriptor status change when bounce buffers are active. However, rxeof() in next run will handle the synchronization. Change dc_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. Reviewed by: marius

MFC r219407:

2011-03-27T23:14:02Z

Rearrange dc_tx_underrun() a bit to correctly set TX FIFO threshold value. Controllers that always require "store and forward" mode( Davicom and PNIC 82C168) have no way to recover from TX underrun except completely reinitializing hardware. Previously only Davicom was reinitialized and the TX FIFO threshold was changed not to use "store and forward" mode after reinitialization since the default FIFO threshold value was 0. This effectively disabled Davicom controller's "store and forward" mode once it encountered TX underruns. In theory, this can cause watchodg timeouts. Intel 21143 controller requires TX MAC should be idle before changing TX FIFO threshold. So driver tried to disable TX MAC and checked whether it saw the idle state of TX MAC. Driver should perform full hardware reinitialization on failing to enter to idle state and it should not touch TX MAC again once it performed full reinitialization. While I'm here remove resetting TX FIFO threshold to 0 when interface is put into down state. If driver ever encountered TX underrun, it's likely to trigger TX underrun again whenever interface is brought to up again. Keeping old/learned TX FIFO threshold value shall reduce the chance of seeing TX underrns in next run.