Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 2011-2012 Stefan Bethke.
|
|
|
|
* Copyright (c) 2012 Adrian Chadd.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR 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.
|
|
|
|
*
|
|
|
|
* $FreeBSD$
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/bus.h>
|
|
|
|
#include <sys/errno.h>
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
#include <sys/module.h>
|
|
|
|
#include <sys/socket.h>
|
|
|
|
#include <sys/sockio.h>
|
|
|
|
#include <sys/sysctl.h>
|
|
|
|
#include <sys/systm.h>
|
|
|
|
|
|
|
|
#include <net/if.h>
|
|
|
|
#include <net/if_arp.h>
|
|
|
|
#include <net/ethernet.h>
|
|
|
|
#include <net/if_dl.h>
|
|
|
|
#include <net/if_media.h>
|
|
|
|
#include <net/if_types.h>
|
|
|
|
|
|
|
|
#include <machine/bus.h>
|
|
|
|
#include <dev/iicbus/iic.h>
|
|
|
|
#include <dev/iicbus/iiconf.h>
|
|
|
|
#include <dev/iicbus/iicbus.h>
|
|
|
|
#include <dev/mii/mii.h>
|
|
|
|
#include <dev/mii/miivar.h>
|
|
|
|
#include <dev/etherswitch/mdio.h>
|
|
|
|
|
|
|
|
#include <dev/etherswitch/etherswitch.h>
|
|
|
|
|
|
|
|
#include <dev/etherswitch/arswitch/arswitchreg.h>
|
|
|
|
#include <dev/etherswitch/arswitch/arswitchvar.h>
|
|
|
|
|
|
|
|
#include <dev/etherswitch/arswitch/arswitch_reg.h>
|
|
|
|
#include <dev/etherswitch/arswitch/arswitch_phy.h>
|
|
|
|
|
|
|
|
#include "mdio_if.h"
|
|
|
|
#include "miibus_if.h"
|
|
|
|
#include "etherswitch_if.h"
|
|
|
|
|
|
|
|
#if defined(DEBUG)
|
|
|
|
static SYSCTL_NODE(_debug, OID_AUTO, arswitch, CTLFLAG_RD, 0, "arswitch");
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* access PHYs integrated into the switch chip through the switch's MDIO
|
|
|
|
* control register.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
arswitch_readphy(device_t dev, int phy, int reg)
|
|
|
|
{
|
2012-10-15 12:20:40 +00:00
|
|
|
struct arswitch_softc *sc;
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
uint32_t data = 0, ctrl;
|
|
|
|
int err, timeout;
|
|
|
|
|
2012-10-15 12:20:40 +00:00
|
|
|
sc = device_get_softc(dev);
|
|
|
|
ARSWITCH_LOCK_ASSERT(sc, MA_NOTOWNED);
|
|
|
|
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
if (phy < 0 || phy >= 32)
|
|
|
|
return (ENXIO);
|
|
|
|
if (reg < 0 || reg >= 32)
|
|
|
|
return (ENXIO);
|
2012-10-15 12:20:40 +00:00
|
|
|
|
|
|
|
ARSWITCH_LOCK(sc);
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
err = arswitch_writereg_msb(dev, AR8X16_REG_MDIO_CTRL,
|
|
|
|
AR8X16_MDIO_CTRL_BUSY | AR8X16_MDIO_CTRL_MASTER_EN |
|
|
|
|
AR8X16_MDIO_CTRL_CMD_READ |
|
|
|
|
(phy << AR8X16_MDIO_CTRL_PHY_ADDR_SHIFT) |
|
|
|
|
(reg << AR8X16_MDIO_CTRL_REG_ADDR_SHIFT));
|
|
|
|
DEVERR(dev, err, "arswitch_readphy()=%d: phy=%d.%02x\n", phy, reg);
|
|
|
|
if (err != 0)
|
2012-10-15 12:20:40 +00:00
|
|
|
goto fail;
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
for (timeout = 100; timeout--; ) {
|
|
|
|
ctrl = arswitch_readreg_msb(dev, AR8X16_REG_MDIO_CTRL);
|
|
|
|
if ((ctrl & AR8X16_MDIO_CTRL_BUSY) == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (timeout < 0)
|
2012-10-15 12:20:40 +00:00
|
|
|
goto fail;
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
data = arswitch_readreg_lsb(dev, AR8X16_REG_MDIO_CTRL) &
|
|
|
|
AR8X16_MDIO_CTRL_DATA_MASK;
|
2012-10-15 12:20:40 +00:00
|
|
|
ARSWITCH_UNLOCK(sc);
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
return (data);
|
2012-10-15 12:20:40 +00:00
|
|
|
|
|
|
|
fail:
|
|
|
|
ARSWITCH_UNLOCK(sc);
|
|
|
|
return (-1);
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
arswitch_writephy(device_t dev, int phy, int reg, int data)
|
|
|
|
{
|
2012-10-15 12:20:40 +00:00
|
|
|
struct arswitch_softc *sc;
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
uint32_t ctrl;
|
|
|
|
int err, timeout;
|
2012-10-15 12:20:40 +00:00
|
|
|
|
|
|
|
sc = device_get_softc(dev);
|
|
|
|
ARSWITCH_LOCK_ASSERT(sc, MA_NOTOWNED);
|
|
|
|
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
if (reg < 0 || reg >= 32)
|
|
|
|
return (ENXIO);
|
2012-10-15 12:20:40 +00:00
|
|
|
|
|
|
|
ARSWITCH_LOCK(sc);
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
err = arswitch_writereg_lsb(dev, AR8X16_REG_MDIO_CTRL,
|
|
|
|
(data & AR8X16_MDIO_CTRL_DATA_MASK));
|
|
|
|
if (err != 0)
|
2012-10-15 12:20:40 +00:00
|
|
|
goto out;
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
err = arswitch_writereg_msb(dev, AR8X16_REG_MDIO_CTRL,
|
|
|
|
AR8X16_MDIO_CTRL_BUSY |
|
|
|
|
AR8X16_MDIO_CTRL_MASTER_EN |
|
|
|
|
AR8X16_MDIO_CTRL_CMD_WRITE |
|
|
|
|
(phy << AR8X16_MDIO_CTRL_PHY_ADDR_SHIFT) |
|
|
|
|
(reg << AR8X16_MDIO_CTRL_REG_ADDR_SHIFT));
|
|
|
|
if (err != 0)
|
2012-10-15 12:20:40 +00:00
|
|
|
goto out;
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
for (timeout = 100; timeout--; ) {
|
|
|
|
ctrl = arswitch_readreg(dev, AR8X16_REG_MDIO_CTRL);
|
|
|
|
if ((ctrl & AR8X16_MDIO_CTRL_BUSY) == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (timeout < 0)
|
|
|
|
err = EIO;
|
2012-10-15 12:20:40 +00:00
|
|
|
out:
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
DEVERR(dev, err, "arswitch_writephy()=%d: phy=%d.%02x\n", phy, reg);
|
2012-10-15 12:20:40 +00:00
|
|
|
ARSWITCH_UNLOCK(sc);
|
Commit the first pass of the etherswitch support.
This is designed to support the very basic ethernet switch chip behaviour,
specifically:
* accessing switch register space;
* accessing per-PHY registers (for switches that actually expose PHYs);
* basic vlan group support, which applies for the rtl8366 driver but not
for the atheros switches.
This also includes initial support for:
* rtl8366rb support - which is a 10/100/1000 switch which supports
vlan groups;
* Initial Atheros AR8316 switch support - which is a 10/100/1000 switch
which supports an alternate vlan configuration (so the vlan group
methods are stubbed.)
The general idea here is that the switch driver may speak to a variety of
backend busses (mdio, i2c, spi, whatever) and expose:
* If applicable, one or more MDIO busses which ethernet interfaces can
then attach PHYs to via miiproxy/mdioproxy;
* exposes miibusses, one for each port at the moment, so ..
* .. a PHY can be exposed on each miibus, for each switch port, with all
of the existing MII/ifnet framework.
However:
* The ifnet is manually created for now, and it isn't linked into the
interface list, nor can you (currently) send/receive frames on this ifnet.
At some point in the future there may be _some_ support for this, for
switches with a multi-port, isolated mode.
* I'm still in the process of sorting out correct(er) locking.
TODO:
* ray's switch code in zrouter (zrouter.org) includes a much more developed
newbus API that covers the various switch methods, as well as a
capability API so drivers, the switch layer and the userland utility
can properly control the subset of supported features.
The plan is to sort that out later, once the rest of ray's switch drivers
are brought over and extended to export MII busses and PHYs.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
2012-05-11 20:53:20 +00:00
|
|
|
return (err);
|
|
|
|
}
|