upstream/opnsense-src
1
0
Fork 0
mirror of https://github.com/opnsense/src.git synced 2026-04-08 19:06:52 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
opnsense-src/sys/modules/mii/Makefile

25 lines
652 B
Makefile
Raw Normal View History

$Id$ -> $FreeBSD$
1999-08-27 21:08:13 -04:00
# $FreeBSD$
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 13:40:53 -04:00
sys/modules: normalize .CURDIR-relative paths to SRCTOP This simplifies make output/logic Tested with: `cd sys/modules; make ALL_MODULES=` on amd64 MFC after: 1 month Sponsored by: Dell EMC Isilon
2017-03-04 05:10:17 -05:00
.PATH: ${SRCTOP}/sys/dev/mii
Use a consistent style and one much closer to the rest of /usr/src
2001-01-06 09:00:42 -05:00
KMOD= miibus
New PHY driver for the internal PHY found in the AX88790. There's a number of quirks for this device, and this implements just the basics. The 2.5s powerdown recommended in the datasheet will be next...
2009-03-30 12:01:09 -04:00
SRCS= acphy.c amphy.c atphy.c axphy.c bmtphy.c brgphy.c bus_if.h
SRCS+= ciphy.c device_if.h
- 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 4k. The only potential in-tree user left unconverted is xe(4), which 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 xe(4) just for the MII bitbang'ing code. 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)
2011-11-01 12:13:59 -04:00
SRCS+= e1000phy.c gentbi.c icsphy.c ip1000phy.c jmphy.c lxtphy.c
SRCS+= miibus_if.c miibus_if.h mii.c miidevs.h mii_bitbang.c mii_physubr.c
Add a driver for the National Semiconductor DP83815, DP83843 and DP83847 PHYs. The main reason for using a specific driver for these PHYs are reset quirks similar to the nsphy(4) driven DP83840A. PR: 112654 Obtained from: NetBSD MFC after: 2 weeks Thanks to: mlaier for testing w/ DP83815
2008-01-26 20:10:41 -05:00
SRCS+= mlphy.c nsgphy.c nsphy.c nsphyter.c pci_if.h pnaphy.c qsphy.c
Merging of projects/armv6, part 5 - Driver for SMSC LAN95XX and LAN8710A ethernet controllers - Driver for LAN8710A PHY Submitted by: Ben Gray, Damjan Marion, Tim Kientzle
2012-08-15 00:03:55 -04:00
SRCS+= rdcphy.c rgephy.c rlphy.c smcphy.c
SRCS+= smscphy.c tdkphy.c tlphy.c truephy.c
Add RDC Semiconductor R6040 10/100 PHY driver.
2010-12-30 18:50:25 -05:00
SRCS+= ukphy.c ukphy_subr.c
Sort values according to style.Makefile(5).
2008-01-26 20:02:29 -05:00
SRCS+= xmphy.c
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 13:40:53 -04:00
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 18:01:40 -04:00
EXPORT_SYMS= mii_attach \
- 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 4k. The only potential in-tree user left unconverted is xe(4), which 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 xe(4) just for the MII bitbang'ing code. 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)
2011-11-01 12:13:59 -04:00
mii_bitbang_readreg \
mii_bitbang_sync \
mii_bitbang_writereg \
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 18:01:40 -04:00
mii_mediachg \
Sort values according to style.Makefile(5).
2008-01-26 20:02:29 -05:00
mii_pollstat \
mii_tick
Export symbols that constitute APIs defined by these modules. Note that in the case of 'mii' the API is not clearly defined, and the symbols exported represent a subset defined by current usage.
2002-01-10 20:16:00 -05:00
Use .include <bsd.kmod.mk> to get to ../../*/conf/kmod.mk instead of encoding the relative path.
2000-05-26 21:14:33 -04:00
.include <bsd.kmod.mk>
Reference in a new issue Copy permalink