freebsd-skq/sys/dev/mii/mii.c

549 lines
13 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: mii.c,v 1.12 1999/08/03 19:41:49 drochner Exp $ */
/*-
* Copyright (c) 1998 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
* NASA Ames Research Center.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#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
/*
* MII bus layer, glues MII-capable network interface drivers to sharable
* PHY drivers. This exports an interface compatible with BSD/OS 3.0's,
* plus some NetBSD extensions.
*/
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/socket.h>
#include <sys/malloc.h>
#include <sys/module.h>
#include <sys/bus.h>
#include <net/if.h>
#include <net/if_media.h>
#include <net/route.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/mii.h>
#include <dev/mii/miivar.h>
MODULE_VERSION(miibus, 1);
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 17:40:53 +00:00
#include "miibus_if.h"
static int miibus_print_child(device_t dev, device_t child);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
static int miibus_read_ivar(device_t dev, device_t child, int which,
uintptr_t *result);
static int miibus_child_location_str(device_t bus, device_t child, char *buf,
size_t buflen);
static int miibus_child_pnpinfo_str(device_t bus, device_t child, char *buf,
size_t buflen);
static int miibus_readreg(device_t, int, int);
static int miibus_writereg(device_t, int, int, int);
static void miibus_statchg(device_t);
static void miibus_linkchg(device_t);
static void miibus_mediainit(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 miibus_methods[] = {
/* device interface */
DEVMETHOD(device_probe, miibus_probe),
DEVMETHOD(device_attach, miibus_attach),
DEVMETHOD(device_detach, miibus_detach),
DEVMETHOD(device_shutdown, bus_generic_shutdown),
/* bus interface */
DEVMETHOD(bus_print_child, miibus_print_child),
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
DEVMETHOD(bus_read_ivar, miibus_read_ivar),
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(bus_driver_added, bus_generic_driver_added),
DEVMETHOD(bus_child_pnpinfo_str, miibus_child_pnpinfo_str),
DEVMETHOD(bus_child_location_str, miibus_child_location_str),
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 interface */
DEVMETHOD(miibus_readreg, miibus_readreg),
DEVMETHOD(miibus_writereg, miibus_writereg),
DEVMETHOD(miibus_statchg, miibus_statchg),
DEVMETHOD(miibus_linkchg, miibus_linkchg),
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(miibus_mediainit, miibus_mediainit),
{ 0, 0 }
};
devclass_t miibus_devclass;
driver_t miibus_driver = {
"miibus",
miibus_methods,
sizeof(struct mii_data)
};
struct miibus_ivars {
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
struct ifnet *ifp;
ifm_change_cb_t ifmedia_upd;
ifm_stat_cb_t ifmedia_sts;
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
int mii_flags;
};
int
miibus_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
{
device_set_desc(dev, "MII bus");
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
return (BUS_PROBE_SPECIFIC);
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
miibus_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 miibus_ivars *ivars;
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
struct mii_attach_args *ma;
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;
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
device_t *children;
int i, nchildren;
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 = device_get_softc(dev);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
nchildren = 0;
if (device_get_children(dev, &children, &nchildren) == 0) {
for (i = 0; i < nchildren; i++) {
ma = device_get_ivars(children[i]);
ma->mii_data = mii;
}
free(children, M_TEMP);
}
if (nchildren == 0) {
device_printf(dev, "cannot get children\n");
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
return (ENXIO);
}
ivars = device_get_ivars(dev);
ifmedia_init(&mii->mii_media, IFM_IMASK, ivars->ifmedia_upd,
ivars->ifmedia_sts);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
mii->mii_ifp = ivars->ifp;
mii->mii_ifp->if_capabilities |= IFCAP_LINKSTATE;
mii->mii_ifp->if_capenable |= IFCAP_LINKSTATE;
LIST_INIT(&mii->mii_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
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
return (bus_generic_attach(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
}
int
miibus_detach(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_data *mii;
bus_generic_detach(dev);
mii = device_get_softc(dev);
ifmedia_removeall(&mii->mii_media);
mii->mii_ifp = NULL;
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
}
static int
miibus_print_child(device_t dev, device_t child)
{
struct mii_attach_args *ma;
int retval;
ma = device_get_ivars(child);
retval = bus_print_child_header(dev, child);
retval += printf(" PHY %d", ma->mii_phyno);
retval += bus_print_child_footer(dev, child);
return (retval);
}
static int
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
miibus_read_ivar(device_t dev, device_t child __unused, int which,
uintptr_t *result)
{
struct miibus_ivars *ivars;
/*
* NB: this uses the instance variables of the miibus rather than
* its PHY children.
*/
ivars = device_get_ivars(dev);
switch (which) {
case MIIBUS_IVAR_FLAGS:
*result = ivars->mii_flags;
break;
default:
return (ENOENT);
}
return (0);
}
static int
miibus_child_pnpinfo_str(device_t bus __unused, device_t child, char *buf,
size_t buflen)
{
struct mii_attach_args *ma;
ma = device_get_ivars(child);
snprintf(buf, buflen, "oui=0x%x model=0x%x rev=0x%x",
MII_OUI(ma->mii_id1, ma->mii_id2),
MII_MODEL(ma->mii_id2), MII_REV(ma->mii_id2));
return (0);
}
static int
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
miibus_child_location_str(device_t bus __unused, device_t child, char *buf,
size_t buflen)
{
struct mii_attach_args *ma;
ma = device_get_ivars(child);
snprintf(buf, buflen, "phyno=%d", ma->mii_phyno);
return (0);
}
static int
miibus_readreg(device_t dev, int phy, int reg)
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
{
device_t parent;
parent = device_get_parent(dev);
return (MIIBUS_READREG(parent, phy, reg));
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 int
miibus_writereg(device_t dev, int phy, int reg, int data)
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
{
device_t parent;
parent = device_get_parent(dev);
return (MIIBUS_WRITEREG(parent, phy, reg, data));
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 void
miibus_statchg(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
{
device_t parent;
struct mii_data *mii;
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
parent = device_get_parent(dev);
MIIBUS_STATCHG(parent);
mii = device_get_softc(dev);
mii->mii_ifp->if_baudrate = ifmedia_baudrate(mii->mii_media_active);
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 void
miibus_linkchg(device_t dev)
{
struct mii_data *mii;
device_t parent;
int link_state;
parent = device_get_parent(dev);
MIIBUS_LINKCHG(parent);
mii = device_get_softc(dev);
if (mii->mii_media_status & IFM_AVALID) {
if (mii->mii_media_status & IFM_ACTIVE)
link_state = LINK_STATE_UP;
else
link_state = LINK_STATE_DOWN;
} else
link_state = LINK_STATE_UNKNOWN;
if_link_state_change(mii->mii_ifp, link_state);
}
static void
miibus_mediainit(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_data *mii;
struct ifmedia_entry *m;
int media = 0;
/* Poke the parent in case it has any media of its own to add. */
MIIBUS_MEDIAINIT(device_get_parent(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
mii = device_get_softc(dev);
LIST_FOREACH(m, &mii->mii_media.ifm_list, ifm_list) {
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
media = m->ifm_media;
if (media == (IFM_ETHER | IFM_AUTO))
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;
}
ifmedia_set(&mii->mii_media, media);
}
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
/*
* Helper function used by network interface drivers, attaches the miibus and
* the PHYs to the network interface driver parent.
*/
int
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
mii_attach(device_t dev, device_t *miibus, struct ifnet *ifp,
ifm_change_cb_t ifmedia_upd, ifm_stat_cb_t ifmedia_sts, int capmask,
int phyloc, int offloc, int flags)
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 17:40:53 +00:00
{
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
struct miibus_ivars *ivars;
struct mii_attach_args ma, *args;
device_t *children, phy;
int bmsr, first, i, nchildren, offset, phymax, phymin, rv;
if (phyloc != MII_PHY_ANY && offloc != MII_OFFSET_ANY) {
printf("%s: phyloc and offloc specified\n", __func__);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
return (EINVAL);
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 17:40:53 +00:00
}
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
if (offloc != MII_OFFSET_ANY && (offloc < 0 || offloc >= MII_NPHY)) {
printf("%s: ivalid offloc %d\n", __func__, offloc);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
return (EINVAL);
}
if (phyloc == MII_PHY_ANY) {
phymin = 0;
phymax = MII_NPHY - 1;
} else {
if (phyloc < 0 || phyloc >= MII_NPHY) {
printf("%s: ivalid phyloc %d\n", __func__, phyloc);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
return (EINVAL);
}
phymin = phymax = phyloc;
This commit adds support for the NetBSD MII abstraction layer and MII-compliant PHY drivers. Many 10/100 ethernet NICs available today either use an MII transceiver or have built-in transceivers that can be programmed using an MII interface. It makes sense then to separate this support out into common code instead of duplicating it in all of the NIC drivers. The mii code also handles all of the media detection, selection and reporting via the ifmedia interface. This is basically the same code from NetBSD's /sys/dev/mii, except it's been adapted to FreeBSD's bus architecture. The advantage to this is that it automatically allows everything to be turned into a loadable module. There are some common functions for use in drivers once an miibus has been attached (mii_mediachg(), mii_pollstat(), mii_tick()) as well as individual PHY drivers. There is also a generic driver for all PHYs that aren't handled by a specific driver. It's possible to do this because all 10/100 PHYs implement the same general register set in addition to their vendor-specific register sets, so for the most part you can use one driver for pretty much any PHY. There are a couple of oddball exceptions though, hence the need to have specific drivers. There are two layers: the generic "miibus" layer and the PHY driver layer. The drivers are child devices of "miibus" and the "miibus" is a child of a given NIC driver. The "miibus" code and the PHY drivers can actually be compiled and kldoaded as completely separate modules or compiled together into one module. For the moment I'm using the latter approach since the code is relatively small. Currently there are only three PHY drivers here: the generic driver, the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding others later as I convert various NIC drivers to use this code. I realize that I'm cvs adding this stuff instead of importing it onto a separate vendor branch, but in my opinion the import approach doesn't really offer any significant advantage: I'm going to be maintaining this stuff and writing my own PHY drivers one way or the other.
1999-08-21 17:40:53 +00:00
}
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
first = 0;
if (*miibus == NULL) {
first = 1;
ivars = malloc(sizeof(*ivars), M_DEVBUF, M_NOWAIT);
if (ivars == NULL)
return (ENOMEM);
ivars->ifp = ifp;
ivars->ifmedia_upd = ifmedia_upd;
ivars->ifmedia_sts = ifmedia_sts;
ivars->mii_flags = flags;
*miibus = device_add_child(dev, "miibus", -1);
if (*miibus == NULL) {
rv = ENXIO;
goto fail;
}
device_set_ivars(*miibus, ivars);
} else {
ivars = device_get_ivars(*miibus);
if (ivars->ifp != ifp || ivars->ifmedia_upd != ifmedia_upd ||
ivars->ifmedia_sts != ifmedia_sts ||
ivars->mii_flags != flags) {
printf("%s: non-matching invariant\n", __func__);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
return (EINVAL);
}
/*
* Assignment of the attach arguments mii_data for the first
* pass is done in miibus_attach(), i.e. once the miibus softc
* has been allocated.
*/
ma.mii_data = device_get_softc(*miibus);
}
ma.mii_capmask = capmask;
phy = NULL;
offset = 0;
for (ma.mii_phyno = phymin; ma.mii_phyno <= phymax; ma.mii_phyno++) {
/*
* Make sure we haven't already configured a PHY at this
* address. This allows mii_attach() to be called
* multiple times.
*/
if (device_get_children(*miibus, &children, &nchildren) == 0) {
for (i = 0; i < nchildren; i++) {
args = device_get_ivars(children[i]);
if (args->mii_phyno == ma.mii_phyno) {
/*
* Yes, there is already something
* configured at this address.
*/
free(children, M_TEMP);
goto skip;
}
}
free(children, M_TEMP);
}
/*
* Check to see if there is a PHY at this address. Note,
* many braindead PHYs report 0/0 in their ID registers,
* so we test for media in the BMSR.
*/
bmsr = MIIBUS_READREG(dev, ma.mii_phyno, MII_BMSR);
if (bmsr == 0 || bmsr == 0xffff ||
(bmsr & (BMSR_EXTSTAT | BMSR_MEDIAMASK)) == 0) {
/* Assume no PHY at this address. */
continue;
}
/*
* There is a PHY at this address. If we were given an
* `offset' locator, skip this PHY if it doesn't match.
*/
if (offloc != MII_OFFSET_ANY && offloc != offset)
goto skip;
/*
* Extract the IDs. Braindead PHYs will be handled by
* the `ukphy' driver, as we have no ID information to
* match on.
*/
ma.mii_id1 = MIIBUS_READREG(dev, ma.mii_phyno, MII_PHYIDR1);
ma.mii_id2 = MIIBUS_READREG(dev, ma.mii_phyno, MII_PHYIDR2);
args = malloc(sizeof(struct mii_attach_args), M_DEVBUF,
M_NOWAIT);
if (args == NULL)
goto skip;
bcopy((char *)&ma, (char *)args, sizeof(ma));
phy = device_add_child(*miibus, NULL, -1);
if (phy == NULL) {
free(args, M_DEVBUF);
goto skip;
}
device_set_ivars(phy, args);
skip:
offset++;
}
if (first != 0) {
if (phy == NULL) {
rv = ENXIO;
goto fail;
}
rv = bus_generic_attach(dev);
if (rv != 0)
goto fail;
/* Attaching of the PHY drivers is done in miibus_attach(). */
return (0);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
}
rv = bus_generic_attach(*miibus);
if (rv != 0)
goto fail;
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);
Add a NetBSD-compatible mii_attach(), which is intended to eventually replace mii_phy_probe() altogether. Compared to the latter the advantages of mii_attach() are: - intended to be called multiple times in order to attach PHYs in multiple passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1 range) - being able to pass along the capability mask from the NIC to the PHY drivers - being able to specify at which address (phyloc) to probe for a PHY (instead of always probing at all addresses from 0 to MII_NPHY - 1) - being able to specify which PHY instance (offloc) to attach - being able to pass along MIIF_* flags from the NIC to the PHY drivers (f.e. as required to indicated to the PHY drivers that flow control is supported by the NIC driver, which actually is the motivation for this change). While at it, I used the opportunity to get rid of some hacks in mii(4) like miibus_probe() generally doing work besides sheer probing and the "EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by passing the struct ifnet pointer via an argument of mii_attach() as well as to fix some resource leaks in mii(4) in case something fails. Commits which will update the PHY drivers to honor the MII flags passed down from the NIC drivers and take advantage of mii_attach() to get rid of certain types of hacks in NIC and PHY drivers as well as a conversion of the remaining uses of mii_phy_probe() will follow shortly. Reviewed by: jhb, yongari Obtained from: NetBSD (partially)
2010-10-14 22:01:40 +00:00
fail:
if (*miibus != NULL)
device_delete_child(dev, *miibus);
free(ivars, M_DEVBUF);
if (first != 0)
*miibus = NULL;
return (rv);
}
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
/*
* Media changed; notify all PHYs.
*/
int
mii_mediachg(struct mii_data *mii)
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 *child;
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 rv;
mii->mii_media_status = 0;
mii->mii_media_active = IFM_NONE;
LIST_FOREACH(child, &mii->mii_phys, mii_list) {
/*
* If the media indicates a different PHY instance,
* isolate this one.
*/
if (IFM_INST(ife->ifm_media) != child->mii_inst) {
if ((child->mii_flags & MIIF_NOISOLATE) != 0) {
device_printf(child->mii_dev, "%s: "
"can't handle non-zero PHY instance %d\n",
__func__, child->mii_inst);
continue;
}
PHY_WRITE(child, MII_BMCR, PHY_READ(child, MII_BMCR) |
BMCR_ISO);
continue;
}
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
rv = (*child->mii_service)(child, mii, MII_MEDIACHG);
if (rv)
return (rv);
}
return (0);
}
/*
* Call the PHY tick routines, used during autonegotiation.
*/
void
mii_tick(struct mii_data *mii)
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 *child;
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
LIST_FOREACH(child, &mii->mii_phys, mii_list) {
/*
* If this PHY instance isn't currently selected, just skip
* it.
*/
if (IFM_INST(ife->ifm_media) != child->mii_inst)
continue;
(void)(*child->mii_service)(child, mii, MII_TICK);
}
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
}
/*
* Get media status from PHYs.
*/
void
mii_pollstat(struct mii_data *mii)
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 *child;
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
mii->mii_media_status = 0;
mii->mii_media_active = IFM_NONE;
LIST_FOREACH(child, &mii->mii_phys, mii_list) {
/*
* If we're not polling this PHY instance, just skip it.
*/
if (IFM_INST(ife->ifm_media) != child->mii_inst)
continue;
(void)(*child->mii_service)(child, mii, MII_POLLSTAT);
}
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
}
/*
* Inform the PHYs that the interface is down.
*/
void
mii_down(struct mii_data *mii)
{
struct mii_softc *child;
LIST_FOREACH(child, &mii->mii_phys, mii_list)
mii_phy_down(child);
}