FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F9.0.0 2011-11-06T21:09:10Z 2011-11-06T21:09:10Z Marius Strobl marius@FreeBSD.org 2011-11-06T21:09:10Z urn:sha1:760aa6fde505699baa4d096bdcc573d6c05e7f14 - 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) Approved by: re (kib) Obtained from: NetBSD (partially) 2011-11-06T17:23:49Z Marius Strobl marius@FreeBSD.org 2011-11-06T17:23:49Z urn:sha1:42d9ccc9c871ec3dc35ebcfde15d3c4a3a8aba64 - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. Approved by: re (kib) 2011-08-19T19:12:58Z Marius Strobl marius@FreeBSD.org 2011-08-19T19:12:58Z urn:sha1:6e3f30748689bbb1a8c506c8e410fad2332916f2 isolated but also powered down after a reset and while they just work fine [sic] when both is the case they don't if they are only deisolate but still powered down. So in order to put PHYs in an overall normal operation mode for the common case, ensure in mii_phy_reset() that they are not powered down after a reset. Unfortunately, this only helps in case of BCM5421, while BCM5709S apparently only work when they remain isolated and powered down after a reset. So don't call mii_phy_reset() in brgphy_reset() and implement the reset locally leaving the problematic bits alone. Effectively this bypasses r221812 for brgphy(4). Thanks to Justin Hibbits for doing a binary search in order to identify the problematic commit. PR: 157405, 158156 Reviewed by: yongari (mii_phy_reset() part) Approved by: re (kib) MFC after: 3 days 2011-06-30T05:20:02Z Warner Losh imp@FreeBSD.org 2011-06-30T05:20:02Z urn:sha1:f2033ea22baa98fcc25fac8acda3482b2ab935bf 88E1149. 2011-05-14T20:31:04Z Marius Strobl marius@FreeBSD.org 2011-05-14T20:31:04Z urn:sha1:087a4650e2f4affdf81f1a74c1d5a171283b925e - Fix whitespace. 2011-05-12T17:11:31Z Pyun YongHyeon yongari@FreeBSD.org 2011-05-12T17:11:31Z urn:sha1:f6d9580d0d82c8ddd45556c34b1030fb5936e632 AR8132 FastEthernet controller. The PHY has no ability to establish a gigabit link. Previously only link parters which support down-shifting was able to establish link. This change should fix a long standing link establishment issue of AR8132. PR: kern/156935 MFC after: 1 week 2011-05-12T14:16:07Z Marius Strobl marius@FreeBSD.org 2011-05-12T14:16:07Z urn:sha1:7bd2d458c25fa25523aacbbcd33b3565cb5d6af4 after rest, in which case we may need to deisolate it. Tested by: nwhitehorn MFC after 1 week 2011-05-10T18:41:46Z Marius Strobl marius@FreeBSD.org 2011-05-10T18:41:46Z urn:sha1:d648297f32757dc3348386b5b16c6b804f224e8e 2011-05-10T18:38:01Z Marius Strobl marius@FreeBSD.org 2011-05-10T18:38:01Z urn:sha1:693ad91c2b7bfd08f04e5adc40cc5acf7c7fc08e PR: 156893 2011-05-09T20:20:43Z Pyun YongHyeon yongari@FreeBSD.org 2011-05-09T20:20:43Z urn:sha1:4c83f2f32b4a33a47d407d9843fbd7dc9ca32299 Submitted by: Geans Pin at Broadcom