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

262 lines
11 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.
*
* 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.
*/
Add et(4), a port of DragonFly's Agere ET1310 10/100/Gigabit Ethernet device driver, written by sephe@ Obtained from: DragonFly Sponsored by: iXsystems MFC after: 2 weeks
2008-06-20 19:28:33 +00:00
oui AGERE 0x00a0bc Agere Systems
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
Add PHY entry for the ASIX 88x90 internal PHYs.
2009-03-30 01:47:32 +00:00
oui ASIX 0x00602e Asix Semiconductor
Add Attansic/Atheros F1 PHY driver.
2008-05-19 01:12:10 +00:00
oui ATHEROS 0x001374 Atheros Communications
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 support for the BCM5906[M] adapters. These adapters only support 10/100 operation and place the mailbox registers at a different offset. They also do not have an EEPROM, so the MAC address must be read from NVRAM instead. MFC after: 1 month PR: kern/118975 Submitted by: benjsc, Thomas Nyström thn at saeab dot se Submitted by: sephe (original patch for DragonflyBSD)
2008-04-29 19:47:13 +00:00
oui BROADCOM2 0x000af7 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
Add JMicron JMP202/JMP211 PHY driver.
2008-05-27 01:16:40 +00:00
oui JMICRON 0x001b8c JMicron 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
This is a rewritten driver for the SMSC LAN91C111. It's based in part on the sn(4) driver and also looking at newer drivers. The reason for the rewrite is to support MII and to try and resolve some performance issues found when trying to use the sn(4) driver on the Gumstix network boards. For reference, the SMSC LAN91C111 is a non-PCI ethernet part whose lineage dates back to Ye Olde Days of ISA. It seems to get some use in the embedded space these days on parts lacking on-board MACs or on-board PCI controllers, such as the XScale PXA line of ARM CPUs. This also includes a driver for the SMSC LAN83C183 10/100 PHY. Man page to follow.
2008-06-06 05:00:49 +00:00
oui SMSC 0x0005be SMSC
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
Add BCM5717C 10/100/1000TX PHY id.
2010-10-27 17:16:40 +00:00
oui xxBROADCOM_ALT2 0x00d897 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.
*/
Add et(4), a port of DragonFly's Agere ET1310 10/100/Gigabit Ethernet device driver, written by sephe@ Obtained from: DragonFly Sponsored by: iXsystems MFC after: 2 weeks
2008-06-20 19:28:33 +00:00
/* Agere Systems PHYs */
Add Agere ET1011 PHY which is found on Belkin F5D5055 USB controller. Unlike Agere ET1011C, Agere ET1011 does not seem to need special DSP programming to workaround silicon bug.
2010-04-13 20:07:52 +00:00
model AGERE ET1011 0x0001 ET1011 10/100/1000baseT PHY
Add et(4), a port of DragonFly's Agere ET1310 10/100/Gigabit Ethernet device driver, written by sephe@ Obtained from: DragonFly Sponsored by: iXsystems MFC after: 2 weeks
2008-06-20 19:28:33 +00:00
model AGERE ET1011C 0x0004 ET1011C 10/100/1000baseT PHY
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
Add PHY entry for the ASIX 88x90 internal PHYs.
2009-03-30 01:47:32 +00:00
/* Asix semiconductor PHYs. */
model ASIX AX88X9X 0x0031 Ax88x9x internal PHY
Add Attansic/Atheros F1 PHY driver.
2008-05-19 01:12:10 +00:00
/* Atheros Communications/Attansic PHYs. */
model ATHEROS F1 0x0001 Atheros F1 10/100/1000 PHY
- Add driver for Attansic L2 FastEthernet controller found on Asus EeePC and some Asus mainboards. Reviewed by: yongari, rpaulo, jhb Tested by: many Approved by: kib (mentor) MFC after: 1 week
2008-10-03 10:31:31 +00:00
model ATHEROS F2 0x0002 Atheros F2 10/100 PHY
Add F1 PHY found on Atheros AR8151 v2.0 PCIe gigabit ethernet controller.
2010-08-09 17:22:14 +00:00
model ATHEROS F1_7 0x0007 Atheros F1 10/100/1000 PHY
Add Attansic/Atheros F1 PHY driver.
2008-05-19 01:12:10 +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
- Also probe BCM5214 and BCM5222. - Add some DSP init code for BCM5221. The values derived from Apple's GMAC driver and the same init code also exists in Linux's sungem_phy driver. - Only read media status bits when they are valid. Obtained from: NetBSD, OpenBSD
2010-11-22 22:03:11 +00:00
model BROADCOM BCM5214 0x0028 BCM5214 Quad 10/100 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 BCM5221 0x001e BCM5221 10/100baseTX PHY
- Also probe BCM5214 and BCM5222. - Add some DSP init code for BCM5221. The values derived from Apple's GMAC driver and the same init code also exists in Linux's sungem_phy driver. - Only read media status bits when they are valid. Obtained from: NetBSD, OpenBSD
2010-11-22 22:03:11 +00:00
model BROADCOM BCM5222 0x0032 BCM5222 Dual 10/100 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
Add support for BCM54K2 found in combination with Apple K2 GMAC. Submitted by: Andreas Tobler Obtained from: OpenBSD MFC after: 1 week
2010-02-20 22:01:24 +00:00
model xxBROADCOM BCM54K2 0x002e BCM54K2 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
Recognize the BCM5482S.
2010-11-08 21:23:28 +00:00
model xxBROADCOM_ALT1 BCM5482S 0x000b BCM5482S Dual-Port 10/100/1000baseX/FX 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
- Add PHY ID for BCM5709C 1000Base-T controllers. MFC after: 1 week
2008-03-05 22:58:02 +00:00
model xxBROADCOM_ALT1 BCM5709CAX 0x002c BCM5709C(AX) 10/100/1000baseTX PHY
Flesh out support for the BCM5722 by recognizing the phy on the 5722 and the specific ASIC revision. MFC after: 1 week Obtained from: OpenBSD (mii/phy bits)
2008-03-06 21:42:48 +00:00
model xxBROADCOM_ALT1 BCM5722 0x002d BCM5722 10/100/1000baseTX PHY
Add BCM5754 PHY id that is found on Dell Studio XPS 16. Tested by: scf MFC after: 1 week
2010-01-14 00:36:49 +00:00
model xxBROADCOM_ALT1 BCM5784 0x003a BCM5784 10/100/1000baseTX PHY
- Add PHY ID for BCM5709C 1000Base-T controllers. MFC after: 1 week
2008-03-05 22:58:02 +00:00
model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/100/1000baseTX PHY
Add BCM5761 PHY id.
2009-11-02 18:15:11 +00:00
model xxBROADCOM_ALT1 BCM5761 0x003d BCM5761 10/100/1000baseTX PHY
- Added support for 5709S/5716S PHYs. Submitted by: pyunyh MFC after: 2 weeks
2010-03-18 20:57:57 +00:00
model xxBROADCOM_ALT1 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY
Add BCM5717C 10/100/1000TX PHY id.
2010-10-27 17:16:40 +00:00
model xxBROADCOM_ALT2 BCM5717C 0x0020 BCM5717C 10/100/1000baseTX PHY
Add support for the BCM5906[M] adapters. These adapters only support 10/100 operation and place the mailbox registers at a different offset. They also do not have an EEPROM, so the MAC address must be read from NVRAM instead. MFC after: 1 month PR: kern/118975 Submitted by: benjsc, Thomas Nyström thn at saeab dot se Submitted by: sephe (original patch for DragonflyBSD)
2008-04-29 19:47:13 +00:00
model BROADCOM2 BCM5906 0x0004 BCM5906 10/100baseTX 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
Recognize the quad-port Cicada (Vitesse) CS8204 10/100/1000TX PHY. This PHY is found on many embedded development boards: among others MPC8555CDS evaluation systems use it. Approved by: cognet (mentor) MFp4: e500
2008-03-03 18:44:33 +00:00
model CICADA CS8204 0x0004 Cicada CS8204 10/100/1000TX PHY
Correct PHY description and OUI of VSC8211. Previously VSC8211 was not recognized by ciphy(4) due to the incorrect OUI. Reported by: nork Tested by: nork
2008-10-23 01:27:15 +00:00
model CICADA VSC8211 0x000b Cicada VSC8211 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
model CICADA CS8201A 0x0020 Cicada CS8201 10/100/1000TX PHY
model CICADA CS8201B 0x0021 Cicada CS8201 10/100/1000TX PHY
Recognize Cicada CS8244 phy chip (among others, can be found on MPC8572DS development systems). Obtained from: Freescale, Semihalf
2008-04-26 18:07:24 +00:00
model CICADA CS8244 0x002c Cicada CS8244 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
Add support for IC Plus IP1001 PHY. Tested by: Stuart Fraser < stuart AT stuartfraser DOT net >
2008-04-05 00:52:07 +00:00
model ICPLUS IP1001 0x0019 IC Plus IP1001 10/100/1000 media interface
Add IC Plus IP1000A integrated PHY id.
2006-07-25 00:14:00 +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
/* 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
Add JMicron JMP202/JMP211 PHY driver.
2008-05-27 01:16:40 +00:00
/* JMicron Technologies PHYs */
model JMICRON JMP211 0x0021 JMP211 10/100/1000 media interface
model JMICRON JMP202 0x0022 JMP202 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
/* 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 a driver for the National Semiconductor DP83815, DP83843 and DP83847 PHYs. The main reason for using a specific driver for these PHYs are reset quirks similar to the nsphy(4) driven DP83840A. PR: 112654 Obtained from: NetBSD MFC after: 2 weeks Thanks to: mlaier for testing w/ DP83815
2008-01-27 01:10:41 +00:00
model NATSEMI DP83815 0x0002 DP83815 10/100 media interface
model NATSEMI DP83847 0x0003 DP83847 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
- Also probe DP83865, which is an is an ultra low power version of the DP83861 and DP83891. - Reset the PHY during attach so it's in a known state. - Add a comment describing why we hardwire 10baseT support in the BMSR. - Always explicitly set IFM_HDX for half-duplex. [1] Obtained from: OpenBSD [1] MFC after: 2 weeks
2009-06-13 23:27:04 +00:00
model NATSEMI DP83865 0x0007 DP83865 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
This is a rewritten driver for the SMSC LAN91C111. It's based in part on the sn(4) driver and also looking at newer drivers. The reason for the rewrite is to support MII and to try and resolve some performance issues found when trying to use the sn(4) driver on the Gumstix network boards. For reference, the SMSC LAN91C111 is a non-PCI ethernet part whose lineage dates back to Ye Olde Days of ISA. It seems to get some use in the embedded space these days on parts lacking on-board MACs or on-board PCI controllers, such as the XScale PXA line of ARM CPUs. This also includes a driver for the SMSC LAN83C183 10/100 PHY. Man page to follow.
2008-06-06 05:00:49 +00:00
/* SMSC PHYs */
model SMSC LAN83C183 0x0004 SMSC LAN83C183 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
Marvell model number 0x06 is 88E1101 PHY.
2010-08-07 23:16:21 +00:00
model MARVELL E1101 0x0006 Marvell 88E1101 Gigabit PHY
Add a bunch of new Marvell PHY ids.
2006-12-11 10:42:04 +00:00
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
Recognize 88E1116R phy variation. This part is found on some embedded devices. Obtained from: Semihalf
2008-09-04 11:09:40 +00:00
model MARVELL E1116R 0x0024 Marvell 88E1116R Gigabit PHY
Add a bunch of new Marvell PHY ids.
2006-12-11 10:42:04 +00:00
model MARVELL E1118 0x0022 Marvell 88E1118 Gigabit PHY
Add driver support for 88E3016 PHY which is found on Marvell Yukon FE+ controller. Due to the severe silicon bugs for Yukon FE+, 88E3016 seems to require more workarounds. However I'm not sure whether the workaround is PHY specific or only applicable to Yukon FE+. The datasheet for the PHY is publicly available but it lacks several details for the workaround used in this change. The workaround information was obtained from Linux. Many thanks to Yukon FE+ users who helped me add 88E3016 support. Tested by: bz, Tanguy Bouzeloc ( the.zauron <> gmail dot com ) Bruce Cran ( bruce <> cran dot org dot uk ) Michael Reifenberger ( mike <> reifenberger dot com ) Stephen Montgomery-Smith ( stephen <> missouri dot edu )
2009-05-25 02:36:29 +00:00
model MARVELL E3016 0x0026 Marvell 88E3016 10/100 Fast Ethernet PHY
Add Marvell PHYG65G Gigabit PHY which is found on 88E8059 Yukon Optima. Tested by: James LaLagna < jameslalagna <> gmail dot com > MFC after: 5 days
2010-04-30 19:01:55 +00:00
model MARVELL PHYG65G 0x0027 Marvell PHYG65G 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