d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fdfe249b63
freebsd-skq/sys/dev/mii/mii.h

242 lines
10 KiB
C
Raw Normal View History

Merge from NetBSD: o rev. 1.10: Nuke trailing whitespace. o rev. 1.15: Fix typo in comment. o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22: - PSE control register (0x0b) - PSE status register (0x0c) - MMD access control register (0x0d) - MMD access address data register (0x0e) o rev. 1.17 (comments only): The bit location of link ability is different between 1000Base-X and others (see Annex 28B.2 and 28D). o rev. 1.18: Nuke dupe word. Obtained from: NetBSD MFC after: 1 week Sponsored by: genua mbh
2015-06-16 13:27:06 +00:00
/* $NetBSD: mii.h,v 1.18 2014/06/16 14:43:22 msaitoh Exp $ */
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 22:01:40 +00:00
Start each of the license/copyright comments with /*-, minor shuffle of lines
2005-01-06 01:43:34 +00:00
/*-
sys/dev: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
2017-11-27 14:52:40 +00:00
* SPDX-License-Identifier: BSD-2-Clause
*
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 17:40:53 +00:00
* Copyright (c) 1997 Manuel Bouyer. All rights reserved.
*
* Modification to match BSD/OS 3.0 MII interface by Jason R. Thorpe,
* Numerical Aerospace Simulation Facility, NASA Ames Research Center.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
$Id$ -> $FreeBSD$
1999-08-28 01:08:13 +00: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 17:40:53 +00:00
*/
#ifndef _DEV_MII_MII_H_
#define _DEV_MII_MII_H_
/*
* Registers common to all PHYs.
*/
#define MII_NPHY 32 /* max # of PHYs per MII */
/*
* MII commands, used if a device must drive the MII lines
* manually.
*/
#define MII_COMMAND_START 0x01
#define MII_COMMAND_READ 0x02
#define MII_COMMAND_WRITE 0x01
#define MII_COMMAND_ACK 0x02
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 22:01:40 +00:00
#define MII_BMCR 0x00 /* Basic mode control register (rw) */
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 17:40:53 +00:00
#define BMCR_RESET 0x8000 /* reset */
#define BMCR_LOOP 0x4000 /* loopback */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define BMCR_SPEED0 0x2000 /* speed selection (LSB) */
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 17:40:53 +00:00
#define BMCR_AUTOEN 0x1000 /* autonegotiation enable */
#define BMCR_PDOWN 0x0800 /* power down */
#define BMCR_ISO 0x0400 /* isolate */
#define BMCR_STARTNEG 0x0200 /* restart autonegotiation */
#define BMCR_FDX 0x0100 /* Set duplex mode */
#define BMCR_CTEST 0x0080 /* collision test */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define BMCR_SPEED1 0x0040 /* speed selection (MSB) */
#define BMCR_S10 0x0000 /* 10 Mb/s */
#define BMCR_S100 BMCR_SPEED0 /* 100 Mb/s */
#define BMCR_S1000 BMCR_SPEED1 /* 1000 Mb/s */
#define BMCR_SPEED(x) ((x) & (BMCR_SPEED0|BMCR_SPEED1))
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 17:40:53 +00:00
#define MII_BMSR 0x01 /* Basic mode status register (ro) */
#define BMSR_100T4 0x8000 /* 100 base T4 capable */
#define BMSR_100TXFDX 0x4000 /* 100 base Tx full duplex capable */
#define BMSR_100TXHDX 0x2000 /* 100 base Tx half duplex capable */
#define BMSR_10TFDX 0x1000 /* 10 base T full duplex capable */
#define BMSR_10THDX 0x0800 /* 10 base T half duplex capable */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define BMSR_100T2FDX 0x0400 /* 100 base T2 full duplex capable */
#define BMSR_100T2HDX 0x0200 /* 100 base T2 half duplex capable */
#define BMSR_EXTSTAT 0x0100 /* Extended status in register 15 */
#define BMSR_MFPS 0x0040 /* MII Frame Preamble Suppression */
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 17:40:53 +00:00
#define BMSR_ACOMP 0x0020 /* Autonegotiation complete */
#define BMSR_RFAULT 0x0010 /* Link partner fault */
#define BMSR_ANEG 0x0008 /* Autonegotiation capable */
#define BMSR_LINK 0x0004 /* Link status */
#define BMSR_JABBER 0x0002 /* Jabber detected */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define BMSR_EXTCAP 0x0001 /* Extended capability */
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 17:40:53 +00: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 22:01:40 +00:00
#define BMSR_DEFCAPMASK 0xffffffff
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
/*
* Note that the EXTSTAT bit indicates that there is extended status
* info available in register 15, but 802.3 section 22.2.4.3 also
Merge from NetBSD: o rev. 1.10: Nuke trailing whitespace. o rev. 1.15: Fix typo in comment. o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22: - PSE control register (0x0b) - PSE status register (0x0c) - MMD access control register (0x0d) - MMD access address data register (0x0e) o rev. 1.17 (comments only): The bit location of link ability is different between 1000Base-X and others (see Annex 28B.2 and 28D). o rev. 1.18: Nuke dupe word. Obtained from: NetBSD MFC after: 1 week Sponsored by: genua mbh
2015-06-16 13:27:06 +00:00
* states that all 1000 Mb/s capable PHYs will set this bit to 1.
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
*/
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 17:40:53 +00:00
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define BMSR_MEDIAMASK (BMSR_100T4|BMSR_100TXFDX|BMSR_100TXHDX| \
BMSR_10TFDX|BMSR_10THDX|BMSR_100T2FDX|BMSR_100T2HDX)
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 17:40:53 +00:00
/*
* Convert BMSR media capabilities to ANAR bits for autonegotiation.
* Note the shift chopps off the BMSR_ANEG bit.
*/
#define BMSR_MEDIA_TO_ANAR(x) (((x) & BMSR_MEDIAMASK) >> 6)
#define MII_PHYIDR1 0x02 /* ID register 1 (ro) */
#define MII_PHYIDR2 0x03 /* ID register 2 (ro) */
#define IDR2_OUILSB 0xfc00 /* OUI LSB */
#define IDR2_MODEL 0x03f0 /* vendor model */
#define IDR2_REV 0x000f /* vendor revision */
#define MII_ANAR 0x04 /* Autonegotiation advertisement (rw) */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
/* section 28.2.4.1 and 37.2.6.1 */
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 17:40:53 +00:00
#define ANAR_NP 0x8000 /* Next page (ro) */
#define ANAR_ACK 0x4000 /* link partner abilities acknowledged (ro) */
#define ANAR_RF 0x2000 /* remote fault (ro) */
Merge from NetBSD: o rev. 1.10: Nuke trailing whitespace. o rev. 1.15: Fix typo in comment. o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22: - PSE control register (0x0b) - PSE status register (0x0c) - MMD access control register (0x0d) - MMD access address data register (0x0e) o rev. 1.17 (comments only): The bit location of link ability is different between 1000Base-X and others (see Annex 28B.2 and 28D). o rev. 1.18: Nuke dupe word. Obtained from: NetBSD MFC after: 1 week Sponsored by: genua mbh
2015-06-16 13:27:06 +00:00
/* Annex 28B.2 */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define ANAR_FC 0x0400 /* local device supports PAUSE */
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 17:40:53 +00:00
#define ANAR_T4 0x0200 /* local device supports 100bT4 */
#define ANAR_TX_FD 0x0100 /* local device supports 100bTx FD */
#define ANAR_TX 0x0080 /* local device supports 100bTx */
#define ANAR_10_FD 0x0040 /* local device supports 10bT FD */
#define ANAR_10 0x0020 /* local device supports 10bT */
#define ANAR_CSMA 0x0001 /* protocol selector CSMA/CD */
o Flesh out the generic IEEE 802.3 annex 31B full duplex flow control support in mii(4): - Merge generic flow control advertisement (which can be enabled by passing by MIIF_DOPAUSE to mii_attach(9)) and parsing support from NetBSD into mii_physubr.c and ukphy_subr.c. Unlike as in NetBSD, IFM_FLOW isn't implemented as a global option via the "don't care mask" but instead as a media specific option this. This has the following advantages: o allows flow control advertisement with autonegotiation to be turned on and off via ifconfig(8) with the default typically being off (though MIIF_FORCEPAUSE has been added causing flow control to be always advertised, allowing to easily MFC this changes for drivers that previously used home-grown support for flow control that behaved that way without breaking POLA) o allows to deal with PHY drivers where flow control advertisement with manual selection doesn't work or at least isn't implemented, like it's the case with brgphy(4), e1000phy(4) and ip1000phy(4), by setting MIIF_NOMANPAUSE o the available combinations of media options are readily available from the `ifconfig -m` output - Add IFM_FLOW to IFM_SHARED_OPTION_DESCRIPTIONS and IFM_ETH_RXPAUSE and IFM_ETH_TXPAUSE to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so these are understood by ifconfig(8). o Make the master/slave support in mii(4) actually usable: - Change IFM_ETH_MASTER from being implemented as a global option via the "don't care mask" to a media specific one as it actually is only applicable to IFM_1000_T to date. - Let mii_phy_setmedia() set GTCR_MAN_MS in IFM_1000_T slave mode to actually configure manually selected slave mode (like we also do in the PHY specific implementations). - Add IFM_ETH_MASTER to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so it is understood by ifconfig(8). o Switch bge(4), bce(4), msk(4), nfe(4) and stge(4) along with brgphy(4), e1000phy(4) and ip1000phy(4) to use the generic flow control support instead of home-grown solutions via IFM_FLAGs. This includes changing these PHY drivers and smcphy(4) to no longer unconditionally advertise support for flow control but only if the selected media has IFM_FLOW set (or MIIF_FORCEPAUSE is set) and implemented for these media variants, i.e. typically only for copper. o Switch brgphy(4), ciphy(4), e1000phy(4) and ip1000phy(4) to report and set IFM_1000_T master mode via IFM_ETH_MASTER instead of via IFF_LINK0 and some IFM_FLAGn. o Switch brgphy(4) to add at least the the supported copper media based on the contents of the BMSR via mii_phy_add_media() instead of hardcoding them. The latter approach seems to have developed historically, besides causing unnecessary code duplication it was also undesirable because brgphy_mii_phy_auto() already based the capability advertisement on the contents of the BMSR though. o Let brgphy(4) set IFM_1000_T master mode on all supported PHY and not just BCM5701. Apparently this was a misinterpretation of a workaround in the Linux tg3 driver; BCM5701 seem to require RGPHY_1000CTL_MSE and BRGPHY_1000CTL_MSC to be set when configuring autonegotiation but this doesn't mean we can't set these as well on other PHYs for manual media selection. o Let ukphy_status() report IFM_1000_T master mode via IFM_ETH_MASTER so IFM_1000_T master mode support now is generally available with all PHY drivers. o Don't let e1000phy(4) set master/slave bits for IFM_1000_SX as it's not applicable there. Reviewed by: yongari (plus additional testing) Obtained from: NetBSD (partially), OpenBSD (partially) MFC after: 2 weeks
2010-11-14 13:26:10 +00:00
#define ANAR_PAUSE_NONE (0 << 10)
#define ANAR_PAUSE_SYM (1 << 10)
#define ANAR_PAUSE_ASYM (2 << 10)
#define ANAR_PAUSE_TOWARDS (3 << 10)
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 17:40:53 +00:00
Merge from NetBSD: o rev. 1.10: Nuke trailing whitespace. o rev. 1.15: Fix typo in comment. o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22: - PSE control register (0x0b) - PSE status register (0x0c) - MMD access control register (0x0d) - MMD access address data register (0x0e) o rev. 1.17 (comments only): The bit location of link ability is different between 1000Base-X and others (see Annex 28B.2 and 28D). o rev. 1.18: Nuke dupe word. Obtained from: NetBSD MFC after: 1 week Sponsored by: genua mbh
2015-06-16 13:27:06 +00:00
/* Annex 28D */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define ANAR_X_FD 0x0020 /* local device supports 1000BASE-X FD */
#define ANAR_X_HD 0x0040 /* local device supports 1000BASE-X HD */
#define ANAR_X_PAUSE_NONE (0 << 7)
#define ANAR_X_PAUSE_SYM (1 << 7)
#define ANAR_X_PAUSE_ASYM (2 << 7)
#define ANAR_X_PAUSE_TOWARDS (3 << 7)
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 17:40:53 +00:00
#define MII_ANLPAR 0x05 /* Autonegotiation lnk partner abilities (rw) */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
/* section 28.2.4.1 and 37.2.6.1 */
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 17:40:53 +00:00
#define ANLPAR_NP 0x8000 /* Next page (ro) */
#define ANLPAR_ACK 0x4000 /* link partner accepted ACK (ro) */
#define ANLPAR_RF 0x2000 /* remote fault (ro) */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define ANLPAR_FC 0x0400 /* link partner supports PAUSE */
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 17:40:53 +00:00
#define ANLPAR_T4 0x0200 /* link partner supports 100bT4 */
#define ANLPAR_TX_FD 0x0100 /* link partner supports 100bTx FD */
#define ANLPAR_TX 0x0080 /* link partner supports 100bTx */
#define ANLPAR_10_FD 0x0040 /* link partner supports 10bT FD */
#define ANLPAR_10 0x0020 /* link partner supports 10bT */
#define ANLPAR_CSMA 0x0001 /* protocol selector CSMA/CD */
o Flesh out the generic IEEE 802.3 annex 31B full duplex flow control support in mii(4): - Merge generic flow control advertisement (which can be enabled by passing by MIIF_DOPAUSE to mii_attach(9)) and parsing support from NetBSD into mii_physubr.c and ukphy_subr.c. Unlike as in NetBSD, IFM_FLOW isn't implemented as a global option via the "don't care mask" but instead as a media specific option this. This has the following advantages: o allows flow control advertisement with autonegotiation to be turned on and off via ifconfig(8) with the default typically being off (though MIIF_FORCEPAUSE has been added causing flow control to be always advertised, allowing to easily MFC this changes for drivers that previously used home-grown support for flow control that behaved that way without breaking POLA) o allows to deal with PHY drivers where flow control advertisement with manual selection doesn't work or at least isn't implemented, like it's the case with brgphy(4), e1000phy(4) and ip1000phy(4), by setting MIIF_NOMANPAUSE o the available combinations of media options are readily available from the `ifconfig -m` output - Add IFM_FLOW to IFM_SHARED_OPTION_DESCRIPTIONS and IFM_ETH_RXPAUSE and IFM_ETH_TXPAUSE to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so these are understood by ifconfig(8). o Make the master/slave support in mii(4) actually usable: - Change IFM_ETH_MASTER from being implemented as a global option via the "don't care mask" to a media specific one as it actually is only applicable to IFM_1000_T to date. - Let mii_phy_setmedia() set GTCR_MAN_MS in IFM_1000_T slave mode to actually configure manually selected slave mode (like we also do in the PHY specific implementations). - Add IFM_ETH_MASTER to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so it is understood by ifconfig(8). o Switch bge(4), bce(4), msk(4), nfe(4) and stge(4) along with brgphy(4), e1000phy(4) and ip1000phy(4) to use the generic flow control support instead of home-grown solutions via IFM_FLAGs. This includes changing these PHY drivers and smcphy(4) to no longer unconditionally advertise support for flow control but only if the selected media has IFM_FLOW set (or MIIF_FORCEPAUSE is set) and implemented for these media variants, i.e. typically only for copper. o Switch brgphy(4), ciphy(4), e1000phy(4) and ip1000phy(4) to report and set IFM_1000_T master mode via IFM_ETH_MASTER instead of via IFF_LINK0 and some IFM_FLAGn. o Switch brgphy(4) to add at least the the supported copper media based on the contents of the BMSR via mii_phy_add_media() instead of hardcoding them. The latter approach seems to have developed historically, besides causing unnecessary code duplication it was also undesirable because brgphy_mii_phy_auto() already based the capability advertisement on the contents of the BMSR though. o Let brgphy(4) set IFM_1000_T master mode on all supported PHY and not just BCM5701. Apparently this was a misinterpretation of a workaround in the Linux tg3 driver; BCM5701 seem to require RGPHY_1000CTL_MSE and BRGPHY_1000CTL_MSC to be set when configuring autonegotiation but this doesn't mean we can't set these as well on other PHYs for manual media selection. o Let ukphy_status() report IFM_1000_T master mode via IFM_ETH_MASTER so IFM_1000_T master mode support now is generally available with all PHY drivers. o Don't let e1000phy(4) set master/slave bits for IFM_1000_SX as it's not applicable there. Reviewed by: yongari (plus additional testing) Obtained from: NetBSD (partially), OpenBSD (partially) MFC after: 2 weeks
2010-11-14 13:26:10 +00:00
#define ANLPAR_PAUSE_MASK (3 << 10)
#define ANLPAR_PAUSE_NONE (0 << 10)
#define ANLPAR_PAUSE_SYM (1 << 10)
#define ANLPAR_PAUSE_ASYM (2 << 10)
#define ANLPAR_PAUSE_TOWARDS (3 << 10)
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 17:40:53 +00:00
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define ANLPAR_X_FD 0x0020 /* local device supports 1000BASE-X FD */
#define ANLPAR_X_HD 0x0040 /* local device supports 1000BASE-X HD */
#define ANLPAR_X_PAUSE_MASK (3 << 7)
#define ANLPAR_X_PAUSE_NONE (0 << 7)
#define ANLPAR_X_PAUSE_SYM (1 << 7)
#define ANLPAR_X_PAUSE_ASYM (2 << 7)
#define ANLPAR_X_PAUSE_TOWARDS (3 << 7)
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 17:40:53 +00:00
#define MII_ANER 0x06 /* Autonegotiation expansion (ro) */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
/* section 28.2.4.1 and 37.2.6.1 */
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 17:40:53 +00:00
#define ANER_MLF 0x0010 /* multiple link detection fault */
#define ANER_LPNP 0x0008 /* link parter next page-able */
#define ANER_NP 0x0004 /* next page-able */
#define ANER_PAGE_RX 0x0002 /* Page received */
#define ANER_LPAN 0x0001 /* link parter autoneg-able */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define MII_ANNP 0x07 /* Autonegotiation next page */
/* section 28.2.4.1 and 37.2.6.1 */
#define MII_ANLPRNP 0x08 /* Autonegotiation link partner rx next page */
/* section 32.5.1 and 37.2.6.1 */
/* This is also the 1000baseT control register */
#define MII_100T2CR 0x09 /* 100base-T2 control register */
#define GTCR_TEST_MASK 0xe000 /* see 802.3ab ss. 40.6.1.1.2 */
#define GTCR_MAN_MS 0x1000 /* enable manual master/slave control */
#define GTCR_ADV_MS 0x0800 /* 1 = adv. master, 0 = adv. slave */
#define GTCR_PORT_TYPE 0x0400 /* 1 = DCE, 0 = DTE (NIC) */
#define GTCR_ADV_1000TFDX 0x0200 /* adv. 1000baseT FDX */
#define GTCR_ADV_1000THDX 0x0100 /* adv. 1000baseT HDX */
/* This is also the 1000baseT status register */
#define MII_100T2SR 0x0a /* 100base-T2 status register */
#define GTSR_MAN_MS_FLT 0x8000 /* master/slave config fault */
#define GTSR_MS_RES 0x4000 /* result: 1 = master, 0 = slave */
#define GTSR_LRS 0x2000 /* local rx status, 1 = ok */
Merge from NetBSD: o rev. 1.10: Nuke trailing whitespace. o rev. 1.15: Fix typo in comment. o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22: - PSE control register (0x0b) - PSE status register (0x0c) - MMD access control register (0x0d) - MMD access address data register (0x0e) o rev. 1.17 (comments only): The bit location of link ability is different between 1000Base-X and others (see Annex 28B.2 and 28D). o rev. 1.18: Nuke dupe word. Obtained from: NetBSD MFC after: 1 week Sponsored by: genua mbh
2015-06-16 13:27:06 +00:00
#define GTSR_RRS 0x1000 /* remote rx status, 1 = ok */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define GTSR_LP_1000TFDX 0x0800 /* link partner 1000baseT FDX capable */
#define GTSR_LP_1000THDX 0x0400 /* link partner 1000baseT HDX capable */
#define GTSR_LP_ASM_DIR 0x0200 /* link partner asym. pause dir. capable */
#define GTSR_IDLE_ERR 0x00ff /* IDLE error count */
Merge from NetBSD: o rev. 1.10: Nuke trailing whitespace. o rev. 1.15: Fix typo in comment. o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22: - PSE control register (0x0b) - PSE status register (0x0c) - MMD access control register (0x0d) - MMD access address data register (0x0e) o rev. 1.17 (comments only): The bit location of link ability is different between 1000Base-X and others (see Annex 28B.2 and 28D). o rev. 1.18: Nuke dupe word. Obtained from: NetBSD MFC after: 1 week Sponsored by: genua mbh
2015-06-16 13:27:06 +00:00
#define MII_PSECR 0x0b /* PSE control register */
#define PSECR_PACTLMASK 0x000c /* pair control mask */
#define PSECR_PSEENMASK 0x0003 /* PSE enable mask */
#define PSECR_PINOUTB 0x0008 /* PSE pinout Alternative B */
#define PSECR_PINOUTA 0x0004 /* PSE pinout Alternative A */
#define PSECR_FOPOWTST 0x0002 /* Force Power Test Mode */
#define PSECR_PSEEN 0x0001 /* PSE Enabled */
#define PSECR_PSEDIS 0x0000 /* PSE Disabled */
#define MII_PSESR 0x0c /* PSE status register */
#define PSESR_PWRDENIED 0x1000 /* Power Denied */
#define PSESR_VALSIG 0x0800 /* Valid PD signature detected */
Fix yet another comment typo in NetBSD rev. 1.16, missed when merging it in r284447. Submitted by: yongari Sponsored by: genua mbh
2015-06-18 14:13:16 +00:00
#define PSESR_INVALSIG 0x0400 /* Invalid PD signature detected */
Merge from NetBSD: o rev. 1.10: Nuke trailing whitespace. o rev. 1.15: Fix typo in comment. o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22: - PSE control register (0x0b) - PSE status register (0x0c) - MMD access control register (0x0d) - MMD access address data register (0x0e) o rev. 1.17 (comments only): The bit location of link ability is different between 1000Base-X and others (see Annex 28B.2 and 28D). o rev. 1.18: Nuke dupe word. Obtained from: NetBSD MFC after: 1 week Sponsored by: genua mbh
2015-06-16 13:27:06 +00:00
#define PSESR_SHORTCIRC 0x0200 /* Short circuit condition detected */
#define PSESR_OVERLOAD 0x0100 /* Overload condition detected */
#define PSESR_MPSABSENT 0x0080 /* MPS absent condition detected */
#define PSESR_PDCLMASK 0x0070 /* PD Class mask */
#define PSESR_STATMASK 0x000e /* PSE Status mask */
#define PSESR_PAIRCTABL 0x0001 /* PAIR Control Ability */
#define PSESR_PDCL_4 (4 << 4) /* Class 4 */
#define PSESR_PDCL_3 (3 << 4) /* Class 3 */
#define PSESR_PDCL_2 (2 << 4) /* Class 2 */
#define PSESR_PDCL_1 (1 << 4) /* Class 1 */
#define PSESR_PDCL_0 (0 << 4) /* Class 0 */
#define MII_MMDACR 0x0d /* MMD access control register */
#define MMDACR_FUNCMASK 0xc000 /* function */
#define MMDACR_DADDRMASK 0x001f /* device address */
#define MMDACR_FN_ADDRESS (0 << 14) /* address */
#define MMDACR_FN_DATANPI (1 << 14) /* data, no post increment */
#define MMDACR_FN_DATAPIRW (2 << 14) /* data, post increment on r/w */
#define MMDACR_FN_DATAPIW (3 << 14) /* data, post increment on wr only */
#define MII_MMDAADR 0x0e /* MMD access address data register */
Merge in rev 1.9 from NetBSD.
2002-04-28 18:43:30 +00:00
#define MII_EXTSR 0x0f /* Extended status register */
#define EXTSR_1000XFDX 0x8000 /* 1000X full-duplex capable */
#define EXTSR_1000XHDX 0x4000 /* 1000X half-duplex capable */
#define EXTSR_1000TFDX 0x2000 /* 1000T full-duplex capable */
#define EXTSR_1000THDX 0x1000 /* 1000T half-duplex capable */
#define EXTSR_MEDIAMASK (EXTSR_1000XFDX|EXTSR_1000XHDX| \
EXTSR_1000TFDX|EXTSR_1000THDX)
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 17:40:53 +00:00
#endif /* _DEV_MII_MII_H_ */
Reference in New Issue Copy Permalink