d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
19af62e535
freebsd-skq/sys/dev/mii/nsphy.c

409 lines
12 KiB
C
Raw Normal View History

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: nsphy.c,v 1.18 1999/07/14 23:57:36 thorpej Exp $ */
/*-
* Copyright (c) 1998, 1999 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
* NASA Ames Research Center.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the NetBSD
* Foundation, Inc. and its contributors.
* 4. Neither the name of The NetBSD Foundation nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
Start each of the license/copyright comments with /*-, minor shuffle of lines
2005-01-06 01:43:34 +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
* Copyright (c) 1997 Manuel Bouyer. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by Manuel Bouyer.
* 4. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
Remove double __FBSDID and move the remaining one into a common place after the license(s) and before the driver comment (the latter only in drivers not having __FBSDID at that location).
2004-05-29 18:09:10 +00:00
#include <sys/cdefs.h>
__FBSDID("$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
/*
* driver for National Semiconductor's DP83840A ethernet 10/100 PHY
* Data Sheet available from www.national.com
*/
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/kernel.h>
#include <sys/socket.h>
#include <sys/errno.h>
#include <sys/module.h>
#include <sys/bus.h>
#include <net/if.h>
#include <net/if_media.h>
#include <dev/mii/mii.h>
#include <dev/mii/miivar.h>
Remove miidevs.h and generate it from miidevs at compile time. The devlist2h.awk tool to do this has been repocopied to sys/tools/.
2003-01-19 02:59:34 +00:00
#include "miidevs.h"
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
#include <dev/mii/nsphyreg.h>
#include "miibus_if.h"
Put function return types on a line by themselves. Cleanup my earlier de-__P sweep and remove whitespace between function names and paramters.
2002-10-14 22:31:52 +00:00
static int nsphy_probe(device_t);
static int nsphy_attach(device_t);
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
static device_method_t nsphy_methods[] = {
/* device interface */
DEVMETHOD(device_probe, nsphy_probe),
DEVMETHOD(device_attach, nsphy_attach),
Make one generic mii_phy_detach() to replace 19 slightly different ones. Rename mii_phy_auto_stop() mii_phy_down(). Introduce mii_down(), use it from nge. Do not indirect it to 19 identical case's in 19 switchstatements like NetBSD did.
2002-04-29 13:07:38 +00:00
DEVMETHOD(device_detach, mii_phy_detach),
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
DEVMETHOD(device_shutdown, bus_generic_shutdown),
{ 0, 0 }
};
static devclass_t nsphy_devclass;
static driver_t nsphy_driver = {
"nsphy",
nsphy_methods,
sizeof(struct mii_softc)
};
DRIVER_MODULE(nsphy, miibus, nsphy_driver, nsphy_devclass, 0, 0);
Remove __P.
2002-03-20 02:08:01 +00:00
static int nsphy_service(struct mii_softc *, struct mii_data *, int);
static void nsphy_status(struct mii_softc *);
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
static void nsphy_reset(struct mii_softc *);
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 17:40:53 +00:00
Add a helper function mii_phy_dev_probe(), which wraps around the mii_phy_match() API and takes care of the PHY device probe based on the struct mii_phydesc array and the match return value provided. Convert PHY drivers to take advantage of mii_phy_dev_probe(), converting drivers to provide a mii_phydesc table in the first place where necessary. Reviewed by: yongari MFC after: 2 weeks
2006-12-02 15:32:34 +00:00
static const struct mii_phydesc nsphys[] = {
MII_PHY_DESC(NATSEMI, DP83840),
MII_PHY_END
};
Put function return types on a line by themselves. Cleanup my earlier de-__P sweep and remove whitespace between function names and paramters.
2002-10-14 22:31:52 +00:00
static int
Use ansi function definitions in preference to K&R to reduce diffs with NetBSD (and cause it looks cooler).
2005-09-30 19:39:27 +00:00
nsphy_probe(device_t dev)
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 17:40:53 +00:00
{
Add a helper function mii_phy_dev_probe(), which wraps around the mii_phy_match() API and takes care of the PHY device probe based on the struct mii_phydesc array and the match return value provided. Convert PHY drivers to take advantage of mii_phy_dev_probe(), converting drivers to provide a mii_phydesc table in the first place where necessary. Reviewed by: yongari MFC after: 2 weeks
2006-12-02 15:32:34 +00:00
return (mii_phy_dev_probe(dev, nsphys, BUS_PROBE_DEFAULT));
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
}
Put function return types on a line by themselves. Cleanup my earlier de-__P sweep and remove whitespace between function names and paramters.
2002-10-14 22:31:52 +00:00
static int
Use ansi function definitions in preference to K&R to reduce diffs with NetBSD (and cause it looks cooler).
2005-09-30 19:39:27 +00:00
nsphy_attach(device_t dev)
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
{
struct mii_softc *sc;
struct mii_attach_args *ma;
struct mii_data *mii;
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
const char *nic;
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
sc = device_get_softc(dev);
ma = device_get_ivars(dev);
sc->mii_dev = device_get_parent(dev);
mii = device_get_softc(sc->mii_dev);
LIST_INSERT_HEAD(&mii->mii_phys, sc, mii_list);
sc->mii_inst = mii->mii_instance;
sc->mii_phy = ma->mii_phyno;
sc->mii_service = nsphy_service;
sc->mii_pdata = mii;
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
mii->mii_instance++;
nic = device_get_name(device_get_parent(sc->mii_dev));
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
/*
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
* Am79C971 and i82557 wedge when isolating all of their
* (external) PHYs.
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
*/
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
if (strcmp(nic, "fxp") == 0 || strcmp(nic, "pcn") == 0)
sc->mii_flags |= MIIF_NOISOLATE;
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
- Fix a typo in a comment. - Fix whitespace according to style(9). - Sync the comment describing why we have to wait in nsphy_reset() with nsphyter_reset(). It's true that the manual tells to not do a reset within 500us of applying power but that's unlikely the cause of problems seen here. Generally having to wait 500us after a reset however is.
2008-01-27 01:30:02 +00:00
/*
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
* DP83840A used with HME chips don't advertise their media
* capabilities themselves properly so force writing the ANAR
* according to the BMSR in mii_phy_setmedia().
- Fix a typo in a comment. - Fix whitespace according to style(9). - Sync the comment describing why we have to wait in nsphy_reset() with nsphyter_reset(). It's true that the manual tells to not do a reset within 500us of applying power but that's unlikely the cause of problems seen here. Generally having to wait 500us after a reset however is.
2008-01-27 01:30:02 +00:00
*/
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
if (strcmp(nic, "hme") == 0)
sc->mii_flags |= MIIF_FORCEANEG;
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 17:40:53 +00:00
#define ADD(m, c) ifmedia_add(&mii->mii_media, (m), (c), NULL)
- Fix a typo in a comment. - Fix whitespace according to style(9). - Sync the comment describing why we have to wait in nsphy_reset() with nsphyter_reset(). It's true that the manual tells to not do a reset within 500us of applying power but that's unlikely the cause of problems seen here. Generally having to wait 500us after a reset however is.
2008-01-27 01:30:02 +00:00
/*
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
* In order for MII loopback to work Am79C971 and greater PCnet
* chips additionally need to be placed into external loopback
* mode which pcn(4) doesn't do so far.
- Fix a typo in a comment. - Fix whitespace according to style(9). - Sync the comment describing why we have to wait in nsphy_reset() with nsphyter_reset(). It's true that the manual tells to not do a reset within 500us of applying power but that's unlikely the cause of problems seen here. Generally having to wait 500us after a reset however is.
2008-01-27 01:30:02 +00:00
*/
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
if (strcmp(nic, "pcn") != 0)
#if 1
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_100_TX, IFM_LOOP,
Use mii_phy_add_media()/mii_phy_setmedia()-compatible media table indices when manually adding media. Some of these I've missed while converting drivers to take advantage of said fuctions recently, others where longstanding bugs.
2007-01-12 22:27:46 +00:00
sc->mii_inst), MII_MEDIA_100_TX);
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
#else
if (strcmp(nic, "pcn") == 0)
sc->mii_flags |= MIIF_NOLOOP;
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 17:40:53 +00:00
#endif
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
nsphy_reset(sc);
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
sc->mii_capabilities =
PHY_READ(sc, MII_BMSR) & ma->mii_capmask;
device_printf(dev, " ");
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
mii_phy_add_media(sc);
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
printf("\n");
#undef ADD
MIIBUS_MEDIAINIT(sc->mii_dev);
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
return (0);
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
}
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
static int
Use ansi function definitions in preference to K&R to reduce diffs with NetBSD (and cause it looks cooler).
2005-09-30 19:39:27 +00:00
nsphy_service(struct mii_softc *sc, struct mii_data *mii, int cmd)
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
{
struct ifmedia_entry *ife = mii->mii_media.ifm_cur;
int reg;
switch (cmd) {
case MII_POLLSTAT:
/*
* If we're not polling our PHY instance, just return.
*/
if (IFM_INST(ife->ifm_media) != sc->mii_inst)
return (0);
break;
case MII_MEDIACHG:
/*
* If the media indicates a different PHY instance,
* isolate ourselves.
*/
if (IFM_INST(ife->ifm_media) != sc->mii_inst) {
reg = PHY_READ(sc, MII_BMCR);
PHY_WRITE(sc, MII_BMCR, reg | BMCR_ISO);
return (0);
}
/*
* If the interface is not up, don't do anything.
*/
if ((mii->mii_ifp->if_flags & IFF_UP) == 0)
break;
reg = PHY_READ(sc, MII_NSPHY_PCR);
/*
* Set up the PCR to use LED4 to indicate full-duplex
* in both 10baseT and 100baseTX modes.
*/
reg |= PCR_LED4MODE;
/*
Spelling fix in a comment.
2004-05-29 16:54:59 +00:00
* Make sure Carrier Integrity Monitor function is
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
* disabled (normal for Node operation, but sometimes
* it's not set?!)
*/
reg |= PCR_CIMDIS;
/*
* Make sure "force link good" is set to normal mode.
* It's only intended for debugging.
*/
reg |= PCR_FLINK100;
/*
* Mystery bits which are supposedly `reserved',
* but we seem to need to set them when the PHY
Enable some undocumented bits in the DP83840 PHY, which is needed when using it with the Intel fxp driver. Tested by: peter, Ollivier Robert <roberto@eurocontrol.fr>, Peter Schultz <pete@jocose.org>
2001-03-16 14:17:02 +00:00
* is connected to some interfaces:
*
* 0x0400 is needed for fxp
* (Intel EtherExpress Pro 10+/100B, 82557 chip)
* (nsphy with a DP83840 chip)
* 0x0100 may be needed for some other card
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
*/
reg |= 0x0100 | 0x0400;
Enable some undocumented bits in the DP83840 PHY, which is needed when using it with the Intel fxp driver. Tested by: peter, Ollivier Robert <roberto@eurocontrol.fr>, Peter Schultz <pete@jocose.org>
2001-03-16 14:17:02 +00:00
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
if (strcmp(mii->mii_ifp->if_dname, "fxp") == 0)
Only touch the PCR register in order to set bits for the fxp driver. The 3C509-TX card apparently had a slightly different version of the chip, and has problems when this register is set. The problem does not appear on the 3C509{BC} cards, but since only the fxp driver needs specific bits set, conditionalize on that.
2001-06-02 19:51:02 +00:00
PHY_WRITE(sc, MII_NSPHY_PCR, reg);
Enable some undocumented bits in the DP83840 PHY, which is needed when using it with the Intel fxp driver. Tested by: peter, Ollivier Robert <roberto@eurocontrol.fr>, Peter Schultz <pete@jocose.org>
2001-03-16 14:17:02 +00:00
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
mii_phy_setmedia(sc);
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
break;
case MII_TICK:
/*
* If we're not currently selected, just return.
*/
if (IFM_INST(ife->ifm_media) != sc->mii_inst)
return (0);
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
if (mii_phy_tick(sc) == EJUSTRETURN)
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
return (0);
break;
}
/* Update the media status. */
nsphy_status(sc);
/* Callback if something changed. */
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
mii_phy_update(sc, cmd);
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
return (0);
}
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
static void
Use ansi function definitions in preference to K&R to reduce diffs with NetBSD (and cause it looks cooler).
2005-09-30 19:39:27 +00:00
nsphy_status(struct mii_softc *sc)
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
{
struct mii_data *mii = sc->mii_pdata;
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
struct ifmedia_entry *ife = mii->mii_media.ifm_cur;
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
int bmsr, bmcr, par, anlpar;
mii->mii_media_status = IFM_AVALID;
mii->mii_media_active = IFM_ETHER;
bmsr = PHY_READ(sc, MII_BMSR) |
PHY_READ(sc, MII_BMSR);
if (bmsr & BMSR_LINK)
mii->mii_media_status |= IFM_ACTIVE;
bmcr = PHY_READ(sc, MII_BMCR);
if (bmcr & BMCR_ISO) {
mii->mii_media_active |= IFM_NONE;
mii->mii_media_status = 0;
return;
}
if (bmcr & BMCR_LOOP)
mii->mii_media_active |= IFM_LOOP;
if (bmcr & BMCR_AUTOEN) {
/*
- Fix a typo in a comment. - Fix whitespace according to style(9). - Sync the comment describing why we have to wait in nsphy_reset() with nsphyter_reset(). It's true that the manual tells to not do a reset within 500us of applying power but that's unlikely the cause of problems seen here. Generally having to wait 500us after a reset however is.
2008-01-27 01:30:02 +00:00
* The PAR status bits are only valid if autonegotiation
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
* has completed (or it's disabled).
*/
if ((bmsr & BMSR_ACOMP) == 0) {
/* Erg, still trying, I guess... */
mii->mii_media_active |= IFM_NONE;
return;
}
/*
* Argh. The PAR doesn't seem to indicate duplex mode
* properly! Determine media based on link partner's
* advertised capabilities.
*/
if (PHY_READ(sc, MII_ANER) & ANER_LPAN) {
anlpar = PHY_READ(sc, MII_ANAR) &
PHY_READ(sc, MII_ANLPAR);
IEEE 802.3 Annex 28B.3 explicitly specifies the following relative priorities of the technologies supported by 802.3 Selector Field value. 1000BASE-T full duplex 1000BASE-T 100BASE-T2 full duplex 100BASE-TX full duplex 100BASE-T2 100BASE-T4 100BASE-TX 10BASE-T full duplex 10BAST-T However PHY drivers didn't honor the order such that 100BASE-T4 had higher priority than 100BASE-TX full duplex. Fix that long standing bugs such that have PHY drivers choose the highest common denominator ability. Fix a bug in dcphy which inadvertently aceepts 100BASE-T4. PR: 92599
2007-11-16 10:25:36 +00:00
if (anlpar & ANLPAR_TX_FD)
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
mii->mii_media_active |= IFM_100_TX|IFM_FDX;
IEEE 802.3 Annex 28B.3 explicitly specifies the following relative priorities of the technologies supported by 802.3 Selector Field value. 1000BASE-T full duplex 1000BASE-T 100BASE-T2 full duplex 100BASE-TX full duplex 100BASE-T2 100BASE-T4 100BASE-TX 10BASE-T full duplex 10BAST-T However PHY drivers didn't honor the order such that 100BASE-T4 had higher priority than 100BASE-TX full duplex. Fix that long standing bugs such that have PHY drivers choose the highest common denominator ability. Fix a bug in dcphy which inadvertently aceepts 100BASE-T4. PR: 92599
2007-11-16 10:25:36 +00:00
else if (anlpar & ANLPAR_T4)
mii->mii_media_active |= IFM_100_T4;
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
else if (anlpar & ANLPAR_TX)
mii->mii_media_active |= IFM_100_TX;
else if (anlpar & ANLPAR_10_FD)
mii->mii_media_active |= IFM_10_T|IFM_FDX;
else if (anlpar & ANLPAR_10)
mii->mii_media_active |= IFM_10_T;
else
mii->mii_media_active |= IFM_NONE;
return;
}
/*
* Link partner is not capable of autonegotiation.
* We will never be in full-duplex mode if this is
* the case, so reading the PAR is OK.
*/
par = PHY_READ(sc, MII_NSPHY_PAR);
if (par & PAR_10)
mii->mii_media_active |= IFM_10_T;
else
mii->mii_media_active |= IFM_100_TX;
#if 0
if (par & PAR_FDX)
mii->mii_media_active |= IFM_FDX;
#endif
} else
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
mii->mii_media_active = ife->ifm_media;
}
static void
nsphy_reset(struct mii_softc *sc)
{
struct ifmedia_entry *ife = sc->mii_pdata->mii_media.ifm_cur;
int reg, i;
if (sc->mii_flags & MIIF_NOISOLATE)
reg = BMCR_RESET;
else
reg = BMCR_RESET | BMCR_ISO;
PHY_WRITE(sc, MII_BMCR, reg);
/*
- Fix a typo in a comment. - Fix whitespace according to style(9). - Sync the comment describing why we have to wait in nsphy_reset() with nsphyter_reset(). It's true that the manual tells to not do a reset within 500us of applying power but that's unlikely the cause of problems seen here. Generally having to wait 500us after a reset however is.
2008-01-27 01:30:02 +00:00
* It is best to allow a little time for the reset to settle
* in before we start polling the BMCR again. Notably, the
* DP83840A manuals state that there should be a 500us delay
* between asserting software reset and attempting MII serial
* operations. Be conservative.
- Don't add IFM_NONE when used in combination with pcn(4) as for MII loopback to work PCnet chips additionally need to be placed into external loopback mode which pcn(4) doesn't do so far. - In nsphy_service() just use if_dname instead of determining the name of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)). - Don't set MIIF_NOISOLATE, except for when used in combination with a NIC that wedges when isolating the PHYs, so nsphy(4) can be used in configurations with multiple PHYs. - Use mii_phy_add_media() instead of mii_add_media() so the latter can be eventually retired. - Take advantage of mii_phy_setmedia() (requires the MIIF_FORCEANEG added in sys/dev/mii/mii_physubr.c 1.26, sys/dev/mii/miivar.h 1.19). - Implement a separate nsphy_reset(). There are two reasons for this: 1) This PHY can take an inordinate amount of time to reset if media is attached; under fairly normal circumstances up to nearly one second. This is because it appears to go through an implicit auto- negotiation cycle as part of the reset. 2) During reset and auto-negotiation, the BMCR will clear the reset bit before the process is complete. It will return 0 until the process is complete and it's safe to access the PHY again. This is the first of two changes required to make the combination of Am79c971 and DP83840A found on certain HP cards and on-board in IBM machines work. - Fix some whitespace nits. Based on: NetBSD (except for the first and second item) MFC after: 2 weeks
2006-11-28 01:01:02 +00:00
*/
DELAY(1000);
/*
* Wait another 2s for it to complete.
* This is only a little overkill as under normal circumstances
* the PHY can take up to 1s to complete reset.
* This is also a bit odd because after a reset, the BMCR will
* clear the reset bit and simply reports 0 even though the reset
* is not yet complete.
*/
for (i = 0; i < 1000; i++) {
reg = PHY_READ(sc, MII_BMCR);
if (reg != 0 && (reg & BMCR_RESET) == 0)
break;
DELAY(2000);
}
if ((sc->mii_flags & MIIF_NOISOLATE) == 0) {
if ((ife == NULL && sc->mii_inst != 0) ||
(ife != NULL && IFM_INST(ife->ifm_media) != sc->mii_inst))
PHY_WRITE(sc, MII_BMCR, reg | BMCR_ISO);
}
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
}
Reference in New Issue Copy Permalink