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

221 lines
9.4 KiB
Plaintext
Raw Normal View History

$Id$ -> $FreeBSD$
1999-09-05 15:21:05 +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
/*$NetBSD: miidevs,v 1.6 1999/05/14 11:37:30 drochner Exp $*/
/*-
* Copyright (c) 1998, 1999 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Jason R. Thorpe of the 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.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the NetBSD
* Foundation, Inc. and its contributors.
* 4. Neither the name of The NetBSD Foundation nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``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 FOUNDATION OR CONTRIBUTORS
* 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.
*/
/*
* List of known MII OUIs.
* For a complete list see http://standards.ieee.org/regauth/oui/
*
* XXX Vendors do obviously not agree how OUIs (18 bit) are mapped
* to the 16 bits available in the id registers. The MII_OUI() macro
* in "mii.h" reflects the most obvious way. If a vendor uses a
* different mapping, an "xx" prefixed OUI is defined here which is
* mangled accordingly to compensate.
*/
Added Altima Communications OUI and their AC101 10/100 media interface to the list of known chips. miidevs.h regenerated also.
2000-06-21 19:26:01 +00:00
oui ALTIMA 0x0010a9 Altima Communications
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
oui AMD 0x00001a Advanced Micro Devices
The ASIC on the 3c905C appears to be manufactured by Broadcom (previous ones were made by Lucent). The Broadcom chip also appears to use an internal PHY made by Broadcom which uses the Broadcom OUI. This is different from previous ASICs which always returned 0 in the PHY ID registers. To account for this, I added the necessary ID values for the Broadcom PHY so that it can be detected and attached using the 3Com PHY driver instead of defaulting to the generic one.
1999-08-29 15:42:04 +00:00
oui BROADCOM 0x001018 Broadcom Corporation
Add device driver support for the VIA Networking Technologies VT6122 gigabit ethernet chip and integrated 10/100/1000 copper PHY. The vge driver has been added to GENERIC for i386, pc98 and amd64, but not to sparc or ia64 since I don't have the ability to test it there. The vge(4) driver supports VLANs, checksum offload and jumbo frames. Also added the lge(4) and nge(4) drivers to GENERIC for i386 and pc98 since I was in the neighborhood. There's no reason to leave them out anymore.
2004-09-10 20:57:46 +00:00
oui CICADA 0x0003F1 Cicada Semiconductor
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
oui DAVICOM 0x00606e Davicom Semiconductor
Add IC Plus IP1000A integrated PHY id.
2006-07-25 00:14:00 +00:00
oui ICPLUS 0x0090c3 IC Plus Corp.
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
oui ICS 0x00a0be Integrated Circuit Systems
oui INTEL 0x00aa00 Intel
Tweak the xmphy driver a little bit based on something I learned about the built-in 1000baseX interface in the Level 1 LXT1001 chip. The Level 1 PHY comes up with the isolate bit in the control register set by default, but it also has the autonegotiate bit set. When you tell the xmphy driver to select IFM_AUTO mode, it sees that the autoneg bit is already on, and thus doesn't bother updating the control register. However this means that the isolate bit is never turned off (unless you manually select 1000baseSX full or half duplex mode, which does result in the control register being modified and the ISO bit being turned off). This subtle and unusual behavioral difference stopped me from being able to receive packets on the SMC9462TX card for several days, since isolating the PHY disconnects it from the MAC's data interface. The fix is to omit the 'is the autoneg big set?' test, since it doesn't really provide much of an optimization anyway. This commit also updates the xmphy driver to support the Jato/Level 1 internal PHY. (I'm not sure how Jato Technologies is related to Level 1: all I know is the OUI from the PHY ID registers maps to Jato in the OUI database.) This will be used once I add the if_lge driver to support the LXT10010 chip.
2001-05-23 22:10:55 +00:00
oui JATO 0x00e083 Jato Technologies
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
oui LEVEL1 0x00207b Level 1
oui NATSEMI 0x080017 National Semiconductor
oui QUALSEMI 0x006051 Quality Semiconductor
Teach the rlphy driver how to do parallel link detection. If the link partner doesn't support NWAY, the RealTek PHY (both the integrated ones on 8139 chips and the RTL8201L 10/100 PHY) will not report the link speed via the ANLPAR or BMSR registers. For the 8201L, we need to look in magic vendor-specific PHY register 0x19. For the 8139 MAC+PHY combo, we have to be able to test the RL_MEDIASTAT register. The changes to rlphy.c are based largely on the patch from PR 30836, however I tried to eliminate some magic numbers by creating an entry for the 8201 PHY in miidevs. Also updated if_rl.c to allow the rlphy driver to read the RL_MEDIASTAT register via the rl_miibus_readreg() routine.
2002-04-07 20:55:50 +00:00
oui REALTEK 0x000020 RealTek Semicondctor
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
oui SEEQ 0x00a07d Seeq
oui SIS 0x00e006 Silicon Integrated Systems
Add mii entry for tdk phy found on some cardbus cards.
2000-10-12 00:15:10 +00:00
oui TDK 0x00c039 TDK
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
oui TI 0x080028 Texas Instruments
Add OUI for Vitesse Semiconductor. Add Vitesse VSC8601 PHY.
2007-06-06 06:53:40 +00:00
oui VITESSE 0x0001c1 Vitesse Semiconductor
Add entries for the XMAC II's internal PHY and the Broadcom BCM5400 1000baseTx PHY.
2000-04-22 01:54:55 +00:00
oui XAQTI 0x00e0ae XaQti Corp.
Add Marvell PHY support for 10/100/1000 LIVENGOOD_CU Intel NIC. Parag Patel did all of the grunt work, so he gets the credit. Register definitions and actions inferred from a Linux driver, so Intel also gets some 'credit'.
2001-04-09 21:29:44 +00:00
oui MARVELL 0x005043 Marvell Semiconductor
Cleanup pass for mii drivers. . Make internal service routines static. . Use a consistent ordering of checks in MII_TICK. Do the work in the mii_phy_tick() subroutine if appropriate. . Call mii_phy_update() to trigger the callbacks.
2001-09-29 19:18:52 +00:00
oui xxMARVELL 0x000ac2 Marvell Semiconductor
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
/* in the 79c873, AMD uses another OUI (which matches Davicom!) */
oui xxAMD 0x00606e Advanced Micro Devices
Add some definitions for Intel 82553 PHYs
2001-03-12 02:27:10 +00:00
/* Intel 82553 A/B steppings */
oui xxINTEL 0x00f800 Intel
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
/* some vendors have the bits swapped within bytes
(ie, ordered as on the wire) */
Added Altima Communications OUI and their AC101 10/100 media interface to the list of known chips. miidevs.h regenerated also.
2000-06-21 19:26:01 +00:00
oui xxALTIMA 0x000895 Altima Communications
Add entries for the XMAC II's internal PHY and the Broadcom BCM5400 1000baseTx PHY.
2000-04-22 01:54:55 +00:00
oui xxBROADCOM 0x000818 Broadcom Corporation
Teach the brgphy about some new Broadcom IDs. Submitted by: David Christenson Sponsored by: www.UIA.net
2006-12-11 01:29:40 +00:00
oui xxBROADCOM_ALT1 0x0050ef Broadcom Corporation
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
oui xxICS 0x00057d Integrated Circuit Systems
oui xxSEEQ 0x0005be Seeq
oui xxSIS 0x000760 Silicon Integrated Systems
oui xxTI 0x100014 Texas Instruments
Add entries for the XMAC II's internal PHY and the Broadcom BCM5400 1000baseTx PHY.
2000-04-22 01:54:55 +00:00
oui xxXAQTI 0x350700 XaQti Corp.
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
/* Level 1 is completely different - from right to left.
(Two bits get lost in the third OUI byte.) */
oui xxLEVEL1 0x1e0400 Level 1
/* Don't know what's going on here. */
oui xxDAVICOM 0x006040 Davicom Semiconductor
Add a newer RTL8211B(L) PHY.
2007-10-29 02:17:44 +00:00
/* This is the OUI of the gigE PHY in the RealTek 8169S/8110S/8211B chips */
Add a PHY driver to support the built-in gigE PHY in the 8169S/8110S ethernet chips. This driver is pretty simple, however it contains special DSP initialization code which is needed in order to get the chip to negotiate a gigE link. (This special initialization may not be needed in subsequent chip revs.) Also: - Fix typo in if_rlreg.h (RL_GMEDIASTAT_1000MPS -> RL_GMEDIASTAT_1000MBPS) - Deal with shared interrupts in re_intr(): if interface isn't up, return. - Fix another bug in re_gmii_writereg() (properly apply data field mask) - Allow PHY driver to read the RL_GMEDIASTAT register via the re_gmii_readreg() register (this is register needed to determine real time link/media status).
2003-09-11 03:53:46 +00:00
oui xxREALTEK 0x000732
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
/*
* List of known models. Grouped by oui.
*/
Added Altima Communications OUI and their AC101 10/100 media interface to the list of known chips. miidevs.h regenerated also.
2000-06-21 19:26:01 +00:00
/* Altima Communications PHYs */
model xxALTIMA AC101 0x0021 AC101 10/100 media interface
Partial support for the nVidia nForce2 chipset's on-board Broadcom/Altima PHY and 3com MAC. Specifications for the Altima PHY are available at: http://www.altimacom.com/products/ac101L.html Submitted by: Mikko S. Hyvarinen <morphy@morphy.iki.fi>
2003-01-12 21:03:38 +00:00
model xxALTIMA AC101L 0x0012 AC101L 10/100 media interface
- Add another Altima PHY, which is a AC101 workalike and integrated in at least ADMtek ADM8511 but apparently is not mentioned in any publically available data sheet so the actual identifier is unknown. - Add Davicom DM9102 PHY. - Add DM9101 to the description of AMD 79C873 as at least some Davicom DM9101F identify identical to AMD 79C873. Obtained from: NetBSD MFC after: 2 weeks
2006-12-02 21:18:56 +00:00
model xxALTIMA ACXXX 0x0001 ACXXX 10/100 media interface
Added Altima Communications OUI and their AC101 10/100 media interface to the list of known chips. miidevs.h regenerated also.
2000-06-21 19:26:01 +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
/* Advanced Micro Devices PHYs */
model AMD 79c973phy 0x0036 Am79c973 internal PHY
Add the ID for the built-in homePNA PHY in the AMD 79C798 controller.
2000-09-20 17:02:16 +00:00
model AMD 79c978 0x0039 Am79c978 HomePNA PHY
- Add another Altima PHY, which is a AC101 workalike and integrated in at least ADMtek ADM8511 but apparently is not mentioned in any publically available data sheet so the actual identifier is unknown. - Add Davicom DM9102 PHY. - Add DM9101 to the description of AMD 79C873 as at least some Davicom DM9101F identify identical to AMD 79C873. Obtained from: NetBSD MFC after: 2 weeks
2006-12-02 21:18:56 +00:00
model xxAMD 79C873 0x0000 Am79C873/DM9101 10/100 media interface
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
The ASIC on the 3c905C appears to be manufactured by Broadcom (previous ones were made by Lucent). The Broadcom chip also appears to use an internal PHY made by Broadcom which uses the Broadcom OUI. This is different from previous ASICs which always returned 0 in the PHY ID registers. To account for this, I added the necessary ID values for the Broadcom PHY so that it can be detected and attached using the 3Com PHY driver instead of defaulting to the generic one.
1999-08-29 15:42:04 +00:00
/* Broadcom Corp. PHYs. */
Add a driver for the Broadcom BCM52xx "mini-theta" PHY. This includes the internal PHY on the 3COM 3C905B and 3C905C parts, however I've rigged it so that xlphy (aka exphy) takes precedence for the time being. If people try this with their xl cards and decide that it's a better choice, we can switch this later. This is the PHY used in various iMacs and possibly other GMAC-equipped Macintoshes with 10/100 PHYs (the ones with 10/100/1000 appear to use brgphy). Obtained from: NetBSD
2002-07-05 11:07:24 +00:00
model BROADCOM 3C905B 0x0012 3c905B 10/100 internal PHY
Use 3C905C instead of 3c905Cphy as the identifier for the Broadcom PHY used in the 3C905C. This is mainly cosmetic. I'm doing this mainly so we share the same identifier as NetBSD.
2002-07-05 11:02:17 +00:00
model BROADCOM 3C905C 0x0017 3c905C 10/100 internal PHY
Add a driver for the Broadcom BCM52xx "mini-theta" PHY. This includes the internal PHY on the 3COM 3C905B and 3C905C parts, however I've rigged it so that xlphy (aka exphy) takes precedence for the time being. If people try this with their xl cards and decide that it's a better choice, we can switch this later. This is the PHY used in various iMacs and possibly other GMAC-equipped Macintoshes with 10/100 PHYs (the ones with 10/100/1000 appear to use brgphy). Obtained from: NetBSD
2002-07-05 11:07:24 +00:00
model BROADCOM BCM5201 0x0021 BCM5201 10/100baseTX PHY
model BROADCOM BCM5221 0x001e BCM5221 10/100baseTX PHY
Add a device driver for the Broadcom BCM4401 ethernet controller, written by Stuart Walsh and Duncan Barclay (with some kibbitzing by me). I'm checking it in on Stuart's behalf. The BCM4401 is built into several x86 laptop and desktop systems. For the moment, I have only enabled it in the x86 kernel config because although it's a PCI device, I haven't heard of any standalone NICs that use it. If somebody knows of one, we can easily add it to the other arches. This driver uses register/structure data gleaned from the Linux driver released by Broadcom, but does not contain any of the code from the Linux driver itself. It uses busdma.
2003-09-09 18:17:23 +00:00
model BROADCOM BCM4401 0x0036 BCM4401 10/100baseTX PHY
Add entries for the XMAC II's internal PHY and the Broadcom BCM5400 1000baseTx PHY.
2000-04-22 01:54:55 +00:00
model xxBROADCOM BCM5400 0x0004 Broadcom 1000baseTX PHY
Add support for the BCM5401 and BCM5411 10/100/1000Mbps copper gigE PHYs. This basically updates the brgphy driver to support 10/100 modes in addition to 1000Mbps modes.
2001-09-04 22:00:33 +00:00
model xxBROADCOM BCM5401 0x0005 BCM5401 10/100/1000baseTX PHY
model xxBROADCOM BCM5411 0x0007 BCM5411 10/100/1000baseTX PHY
Teach the brgphy about some new Broadcom IDs. Submitted by: David Christenson Sponsored by: www.UIA.net
2006-12-11 01:29:40 +00:00
model xxBROADCOM BCM5754 0x000e BCM5754 10/100/1000baseTX PHY
Add Broadcom BCM5752 PHY id.
2006-08-31 11:13:51 +00:00
model xxBROADCOM BCM5752 0x0010 BCM5752 10/100/1000baseTX PHY
Teach the brgphy driver about the BCM5701's internal copper PHY.
2002-03-22 06:38:52 +00:00
model xxBROADCOM BCM5701 0x0011 BCM5701 10/100/1000baseTX PHY
New features: - Moved BCM5706S/5708S SerDes support to brgphy (since they are not technically TBI interfaces) - Added 2.5G support for BCM5708S Comments: Since this driver is shared with bge I tested several available controllers supported by bge and all worked as expected, however the list was not exhaustive. Need wider testing. MFC after: 4 weeks
2007-06-07 02:21:38 +00:00
model xxBROADCOM BCM5706 0x0015 BCM5706 10/100/1000baseTX/SX PHY
Add support for the BCM5703x chips. I do not have one of these cards to test; however the submitter reports that this patch works with the on-board interface on the IBM x235 server. Submitted by: Jung-uk Kim <jkim@niksun.com> MFC after: 1 month
2002-09-08 19:12:02 +00:00
model xxBROADCOM BCM5703 0x0016 BCM5703 10/100/1000baseTX PHY
Add untested support for the Broadcom 5704. Obtained from: NetBSD
2003-05-02 19:53:40 +00:00
model xxBROADCOM BCM5704 0x0019 BCM5704 10/100/1000baseTX PHY
Add support for the BCM5705 and its ilk. Changes: - 5705 doesn't support jumbo frames - Statistics must be read from registers - RX return ring must be capped at 512 entries - Omit initialization of certain device blocks - Acknowledge link change interrupts by setting the 'link changed' bit in the status register (used to have no effect) - Remember to toggle the MI completion bit too - Set the mbuf low watermark differently (on-chip memory buffers, not BSD mbufs) - Don't enable Ethernet@WireSpeed feature for certain 5705 chip revs - Add additional PCI IDs for 5705 and 5782 parts - Add a forgotten 5704 PCI ID Most changes ripped kicking and screaming from the Broadcom linux driver. Thanks to Paul Saab for sanity testing. (My lack of sanity has been confirmed.)
2003-07-16 00:09:56 +00:00
model xxBROADCOM BCM5705 0x001a BCM5705 10/100/1000baseTX PHY
Add support for the BCM5750/5751. Unfortunately the documentation I have from Broadcom does not give much information on these devices, so the Broadcom Linux driver was used for clues to what these chips support. It turns out they are similar to the 5705 with the 5751 being the PCI-Express version and needing special work-arounds and settings.
2004-09-24 22:24:33 +00:00
model xxBROADCOM BCM5750 0x0018 BCM5750 10/100/1000baseTX PHY
Support the 5714C Submitted by: John Cagle <john dot cagle at hp dot com>
2005-05-19 21:08:59 +00:00
model xxBROADCOM BCM5714 0x0034 BCM5714 10/100/1000baseTX PHY
Add basic support for BCM5780 PHY. Submitted by: grehan Approved by: glebius (mentor) MFC after: 1 week
2006-03-23 09:53:39 +00:00
model xxBROADCOM BCM5780 0x0035 BCM5780 10/100/1000baseTX PHY
Restore support for the 5706C bce(4) phy that was broken during the addition of SerDes support. According to the docs, the 5706C and 5708C phys are supposed to use the same MII model that is separate from the SerDes parts, but the 5706C actually uses the MII model of the SerDes parts. To fix this, readd the old 5706C entry to miidevs and add a special check in brgphy_probe() for phys that match the 5706C ID. If the phy is supported by the gentbi(4) driver, then it's a SerDes phy, so we fail the probe and let gentbi(4) grab it. Otherwise, it's a 5706C phy, so we let brgphy(4) grab it. In coordination with: dwhite
2007-02-21 18:17:44 +00:00
model xxBROADCOM BCM5708C 0x0036 BCM5708C 10/100/1000baseTX PHY
Let brgphy(4) attach for the Broadcom BCM5755 ASIC based chipsets as well. Obtained from: OpenBSD MFC after: 1 week
2007-04-10 20:43:23 +00:00
model xxBROADCOM_ALT1 BCM5755 0x000c BCM5755 10/100/1000baseTX PHY
- Fix BCM5754 support found in Dell PowerEdge SC440. - Move some PHY bug detections from brgphy.c to if_bge.c. - Do not penalize working PHYs. - Re-arrange bge_flags roughly by their categories. - Fix minor style(9) nits. PR: kern/107257 Obtained from: OpenBSD Tested by: Mike Hibler <mike at flux dot utah dot edu>
2007-01-15 21:43:43 +00:00
model xxBROADCOM_ALT1 BCM5787 0x000e BCM5787 10/100/1000baseTX PHY
New features: - Moved BCM5706S/5708S SerDes support to brgphy (since they are not technically TBI interfaces) - Added 2.5G support for BCM5708S Comments: Since this driver is shared with bge I tested several available controllers supported by bge and all worked as expected, however the list was not exhaustive. Need wider testing. MFC after: 4 weeks
2007-06-07 02:21:38 +00:00
model xxBROADCOM_ALT1 BCM5708S 0x0015 BCM5708S 1000/2500BaseSX PHY
The ASIC on the 3c905C appears to be manufactured by Broadcom (previous ones were made by Lucent). The Broadcom chip also appears to use an internal PHY made by Broadcom which uses the Broadcom OUI. This is different from previous ASICs which always returned 0 in the PHY ID registers. To account for this, I added the necessary ID values for the Broadcom PHY so that it can be detected and attached using the 3Com PHY driver instead of defaulting to the generic one.
1999-08-29 15:42:04 +00:00
Add device driver support for the VIA Networking Technologies VT6122 gigabit ethernet chip and integrated 10/100/1000 copper PHY. The vge driver has been added to GENERIC for i386, pc98 and amd64, but not to sparc or ia64 since I don't have the ability to test it there. The vge(4) driver supports VLANs, checksum offload and jumbo frames. Also added the lge(4) and nge(4) drivers to GENERIC for i386 and pc98 since I was in the neighborhood. There's no reason to leave them out anymore.
2004-09-10 20:57:46 +00:00
/* Cicada Semiconductor PHYs (now owned by Vitesse?) */
model CICADA CS8201 0x0001 Cicada CS8201 10/100/1000TX PHY
model CICADA CS8201A 0x0020 Cicada CS8201 10/100/1000TX PHY
model CICADA CS8201B 0x0021 Cicada CS8201 10/100/1000TX PHY
Add OUI for Vitesse Semiconductor. Add Vitesse VSC8601 PHY.
2007-06-06 06:53:40 +00:00
model VITESSE VSC8601 0x0002 Vitesse VSC8601 10/100/1000TX PHY
Add device driver support for the VIA Networking Technologies VT6122 gigabit ethernet chip and integrated 10/100/1000 copper PHY. The vge driver has been added to GENERIC for i386, pc98 and amd64, but not to sparc or ia64 since I don't have the ability to test it there. The vge(4) driver supports VLANs, checksum offload and jumbo frames. Also added the lge(4) and nge(4) drivers to GENERIC for i386 and pc98 since I was in the neighborhood. There's no reason to leave them out anymore.
2004-09-10 20:57:46 +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
/* Davicom Semiconductor PHYs */
- Add another Altima PHY, which is a AC101 workalike and integrated in at least ADMtek ADM8511 but apparently is not mentioned in any publically available data sheet so the actual identifier is unknown. - Add Davicom DM9102 PHY. - Add DM9101 to the description of AMD 79C873 as at least some Davicom DM9101F identify identical to AMD 79C873. Obtained from: NetBSD MFC after: 2 weeks
2006-12-02 21:18:56 +00:00
model DAVICOM DM9102 0x0004 DM9102 10/100 media interface
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
model xxDAVICOM DM9101 0x0000 DM9101 10/100 media interface
/* Integrated Circuit Systems PHYs */
Add ICS1889/ICS1892/ICS1893 PHY. Submitted by: Ed Schouten <ed@fxq.nl>
2007-06-11 02:02:20 +00:00
model xxICS 1889 0x0001 ICS1889 10/100 media interface
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
model xxICS 1890 0x0002 ICS1890 10/100 media interface
Add ICS1889/ICS1892/ICS1893 PHY. Submitted by: Ed Schouten <ed@fxq.nl>
2007-06-11 02:02:20 +00:00
model xxICS 1892 0x0003 ICS1892 10/100 media interface
model xxICS 1893 0x0004 ICS1893 10/100 media interface
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 IC Plus IP1000A integrated PHY id.
2006-07-25 00:14:00 +00:00
/* IC Plus Corp. PHYs */
Add IC Plus IP101 PHY
2007-06-06 07:05:02 +00:00
model ICPLUS IP101 0x0005 IC Plus 10/100 PHY
Add IC Plus IP1000A integrated PHY id.
2006-07-25 00:14:00 +00:00
model ICPLUS IP1000A 0x0008 IC Plus 10/100/1000 media interface
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
/* Intel PHYs */
Add some definitions for Intel 82553 PHYs
2001-03-12 02:27:10 +00:00
model xxINTEL I82553AB 0x0000 i83553 10/100 media interface
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
model INTEL I82555 0x0015 i82555 10/100 media interface
Correctly recognize the i82562{EM} PHYs. Obtained from: OpenBSD
2001-05-11 20:34:38 +00:00
model INTEL I82562EM 0x0032 i82562EM 10/100 media interface
model INTEL I82562ET 0x0033 i82562ET 10/100 media interface
model INTEL I82553C 0x0035 i82553 10/100 media interface
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
Tweak the xmphy driver a little bit based on something I learned about the built-in 1000baseX interface in the Level 1 LXT1001 chip. The Level 1 PHY comes up with the isolate bit in the control register set by default, but it also has the autonegotiate bit set. When you tell the xmphy driver to select IFM_AUTO mode, it sees that the autoneg bit is already on, and thus doesn't bother updating the control register. However this means that the isolate bit is never turned off (unless you manually select 1000baseSX full or half duplex mode, which does result in the control register being modified and the ISO bit being turned off). This subtle and unusual behavioral difference stopped me from being able to receive packets on the SMC9462TX card for several days, since isolating the PHY disconnects it from the MAC's data interface. The fix is to omit the 'is the autoneg big set?' test, since it doesn't really provide much of an optimization anyway. This commit also updates the xmphy driver to support the Jato/Level 1 internal PHY. (I'm not sure how Jato Technologies is related to Level 1: all I know is the OUI from the PHY ID registers maps to Jato in the OUI database.) This will be used once I add the if_lge driver to support the LXT10010 chip.
2001-05-23 22:10:55 +00:00
/* Jato Technologies PHYs */
model JATO BASEX 0x0000 Jato 1000baseX media interface
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
/* Level 1 PHYs */
model xxLEVEL1 LXT970 0x0000 LXT970 10/100 media interface
/* National Semiconductor PHYs */
model NATSEMI DP83840 0x0000 DP83840 10/100 media interface
model NATSEMI DP83843 0x0001 DP83843 10/100 media interface
Add support for gigabit ethernet cards based on the NatSemi DP83820 and DP83821 gigabit ethernet MAC chips and the NatSemi DP83861 10/100/1000 copper PHY. There are a whole bunch of very low cost cards available with this chipset selling for $150USD or less. This includes the SMC9462TX, D-Link DGE-500T, Asante GigaNIX 1000TA and 1000TPC, and a couple cards from Addtron. This chip supports TCP/IP checksum offload, VLAN tagging/insertion. 2048-bit multicast filter, jumbograms and has 8K TX and 32K RX FIFOs. I have not done serious performance testing with this driver. I know it works, and I want it under CVS control so I can keep tabs on it. Note that there's no serious mutex stuff in here yet either: I need to talk more with jhb to figure out the right way to do this. That said, I don't think there will be any problems. This driver should also work on the alpha. It's not turned on in GENERIC.
2001-05-11 19:56:39 +00:00
model NATSEMI DP83891 0x0005 DP83891 10/100/1000 media interface
model NATSEMI DP83861 0x0006 DP83861 10/100/1000 media interface
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
/* Quality Semiconductor PHYs */
model QUALSEMI QS6612 0x0000 QS6612 10/100 media interface
Teach the rlphy driver how to do parallel link detection. If the link partner doesn't support NWAY, the RealTek PHY (both the integrated ones on 8139 chips and the RTL8201L 10/100 PHY) will not report the link speed via the ANLPAR or BMSR registers. For the 8201L, we need to look in magic vendor-specific PHY register 0x19. For the 8139 MAC+PHY combo, we have to be able to test the RL_MEDIASTAT register. The changes to rlphy.c are based largely on the patch from PR 30836, however I tried to eliminate some magic numbers by creating an entry for the 8201 PHY in miidevs. Also updated if_rl.c to allow the rlphy driver to read the RL_MEDIASTAT register via the rl_miibus_readreg() routine.
2002-04-07 20:55:50 +00:00
/* RealTek Semiconductor PHYs */
model REALTEK RTL8201L 0x0020 RTL8201L 10/100 media interface
MFp4: add basic driver for RTL8305SC switch in PHY emulation
2007-01-05 01:46:26 +00:00
model xxREALTEK RTL8305SC 0x0005 RTL8305SC 10/100 802.1q switch
Add a newer RTL8211B(L) PHY.
2007-10-29 02:17:44 +00:00
model xxREALTEK RTL8169S 0x0011 RTL8169S/8110S/8211B media interface
Teach the rlphy driver how to do parallel link detection. If the link partner doesn't support NWAY, the RealTek PHY (both the integrated ones on 8139 chips and the RTL8201L 10/100 PHY) will not report the link speed via the ANLPAR or BMSR registers. For the 8201L, we need to look in magic vendor-specific PHY register 0x19. For the 8139 MAC+PHY combo, we have to be able to test the RL_MEDIASTAT register. The changes to rlphy.c are based largely on the patch from PR 30836, however I tried to eliminate some magic numbers by creating an entry for the 8201 PHY in miidevs. Also updated if_rl.c to allow the rlphy driver to read the RL_MEDIASTAT register via the rl_miibus_readreg() routine.
2002-04-07 20:55:50 +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
/* Seeq PHYs */
model xxSEEQ 80220 0x0003 Seeq 80220 10/100 media interface
model xxSEEQ 84220 0x0004 Seeq 84220 10/100 media interface
/* Silicon Integrated Systems PHYs */
model xxSIS 900 0x0000 SiS 900 10/100 media interface
Add mii entry for tdk phy found on some cardbus cards.
2000-10-12 00:15:10 +00:00
/* TDK */
model TDK 78Q2120 0x0014 TDK 78Q2120 media interface
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
/* Texas Instruments PHYs */
model xxTI TLAN10T 0x0001 ThunderLAN 10baseT media interface
model xxTI 100VGPMI 0x0002 ThunderLAN 100VG-AnyLan media interface
Add entries for the XMAC II's internal PHY and the Broadcom BCM5400 1000baseTx PHY.
2000-04-22 01:54:55 +00:00
/* XaQti Corp. PHYs. */
model XAQTI XMACII 0x0000 XaQti Corp. XMAC II gigabit interface
Add Marvell PHY support for 10/100/1000 LIVENGOOD_CU Intel NIC. Parag Patel did all of the grunt work, so he gets the credit. Register definitions and actions inferred from a Linux driver, so Intel also gets some 'credit'.
2001-04-09 21:29:44 +00:00
/* Marvell Semiconductor PHYs */
Cleanup pass for mii drivers. . Make internal service routines static. . Use a consistent ordering of checks in MII_TICK. Do the work in the mii_phy_tick() subroutine if appropriate. . Call mii_phy_update() to trigger the callbacks.
2001-09-29 19:18:52 +00:00
model MARVELL E1000 0x0000 Marvell 88E1000 Gigabit PHY
Add support for SK-9521 V2.0 and 3COM 3C940. Tested at 100Mbit only, using Asus P4P800 onboard 3C940. The -stable version of this patch I have in use for ~2 weeks now, and works just fine for me. Based on: Nathan L. Binkert's patch for OpenBSD Patch submitted by and thanks to: Jung-uk Kim <jkim@niksun.com> MFC after: 2 weeks
2003-09-20 10:53:08 +00:00
model MARVELL E1011 0x0002 Marvell 88E1011 Gigabit PHY
Add a bunch of new Marvell PHY ids.
2006-12-11 10:42:04 +00:00
model MARVELL E1000_3 0x0003 Marvell 88E1000 Gigabit PHY
model MARVELL E1000S 0x0004 Marvell 88E1000S Gigabit PHY
model MARVELL E1000_5 0x0005 Marvell 88E1000 Gigabit PHY
model MARVELL E1000_6 0x0006 Marvell 88E1000 Gigabit PHY
model MARVELL E3082 0x0008 Marvell 88E3082 10/100 Fast Ethernet PHY
model MARVELL E1112 0x0009 Marvell 88E1112 Gigabit PHY
model MARVELL E1149 0x000b Marvell 88E1149 Gigabit PHY
model MARVELL E1111 0x000c Marvell 88E1111 Gigabit PHY
model MARVELL E1116 0x0021 Marvell 88E1116 Gigabit PHY
model MARVELL E1118 0x0022 Marvell 88E1118 Gigabit PHY
Cleanup pass for mii drivers. . Make internal service routines static. . Use a consistent ordering of checks in MII_TICK. Do the work in the mii_phy_tick() subroutine if appropriate. . Call mii_phy_update() to trigger the callbacks.
2001-09-29 19:18:52 +00:00
model xxMARVELL E1000 0x0005 Marvell 88E1000 Gigabit PHY
Add a bunch of new Marvell PHY ids.
2006-12-11 10:42:04 +00:00
model xxMARVELL E1011 0x0002 Marvell 88E1011 Gigabit PHY
model xxMARVELL E1000_3 0x0003 Marvell 88E1000 Gigabit PHY
model xxMARVELL E1000_5 0x0005 Marvell 88E1000 Gigabit PHY
model xxMARVELL E1111 0x000c Marvell 88E1111 Gigabit PHY
Reference in New Issue Copy Permalink