2008-10-07 21:45:18 +08:00
|
|
|
/*
|
2009-03-20 17:50:39 +08:00
|
|
|
* net/dsa/mv88e6131.c - Marvell 88e6095/6095f/6131 switch chip support
|
|
|
|
|
* Copyright (c) 2008-2009 Marvell Semiconductor
|
2008-10-07 21:45:18 +08:00
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*/
|
|
|
|
|
|
2013-01-09 00:05:54 +08:00
|
|
|
#include <linux/delay.h>
|
|
|
|
|
#include <linux/jiffies.h>
|
2008-10-07 21:45:18 +08:00
|
|
|
#include <linux/list.h>
|
2012-01-24 18:41:40 +08:00
|
|
|
#include <linux/module.h>
|
2008-10-07 21:45:18 +08:00
|
|
|
#include <linux/netdevice.h>
|
|
|
|
|
#include <linux/phy.h>
|
2011-11-28 01:06:08 +08:00
|
|
|
#include <net/dsa.h>
|
2008-10-07 21:45:18 +08:00
|
|
|
#include "mv88e6xxx.h"
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Switch product IDs */
|
2011-04-05 11:03:56 +08:00
|
|
|
#define ID_6085 0x04a0
|
|
|
|
|
#define ID_6095 0x0950
|
|
|
|
|
#define ID_6131 0x1060
|
|
|
|
|
|
2008-10-07 21:45:18 +08:00
|
|
|
static char *mv88e6131_probe(struct mii_bus *bus, int sw_addr)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
|
|
|
|
|
if (ret >= 0) {
|
|
|
|
|
ret &= 0xfff0;
|
2011-04-05 11:03:56 +08:00
|
|
|
if (ret == ID_6085)
|
|
|
|
|
return "Marvell 88E6085";
|
|
|
|
|
if (ret == ID_6095)
|
2009-03-20 17:50:39 +08:00
|
|
|
return "Marvell 88E6095/88E6095F";
|
2011-04-05 11:03:56 +08:00
|
|
|
if (ret == ID_6131)
|
2008-10-07 21:45:18 +08:00
|
|
|
return "Marvell 88E6131";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6131_switch_reset(struct dsa_switch *ds)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
int ret;
|
2013-01-09 00:05:54 +08:00
|
|
|
unsigned long timeout;
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Set all ports to the disabled state. */
|
2009-03-20 17:50:39 +08:00
|
|
|
for (i = 0; i < 11; i++) {
|
2008-10-07 21:45:18 +08:00
|
|
|
ret = REG_READ(REG_PORT(i), 0x04);
|
|
|
|
|
REG_WRITE(REG_PORT(i), 0x04, ret & 0xfffc);
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Wait for transmit queues to drain. */
|
2013-01-09 00:05:54 +08:00
|
|
|
usleep_range(2000, 4000);
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Reset the switch. */
|
2008-10-07 21:45:18 +08:00
|
|
|
REG_WRITE(REG_GLOBAL, 0x04, 0xc400);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Wait up to one second for reset to complete. */
|
2013-01-09 00:05:54 +08:00
|
|
|
timeout = jiffies + 1 * HZ;
|
|
|
|
|
while (time_before(jiffies, timeout)) {
|
2008-10-07 21:45:18 +08:00
|
|
|
ret = REG_READ(REG_GLOBAL, 0x00);
|
|
|
|
|
if ((ret & 0xc800) == 0xc800)
|
|
|
|
|
break;
|
|
|
|
|
|
2013-01-09 00:05:54 +08:00
|
|
|
usleep_range(1000, 2000);
|
2008-10-07 21:45:18 +08:00
|
|
|
}
|
2013-01-09 00:05:54 +08:00
|
|
|
if (time_after(jiffies, timeout))
|
2008-10-07 21:45:18 +08:00
|
|
|
return -ETIMEDOUT;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6131_setup_global(struct dsa_switch *ds)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
int i;
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Enable the PHY polling unit, don't discard packets with
|
2008-10-07 21:45:18 +08:00
|
|
|
* excessive collisions, use a weighted fair queueing scheme
|
|
|
|
|
* to arbitrate between packet queues, set the maximum frame
|
|
|
|
|
* size to 1632, and mask all interrupt sources.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(REG_GLOBAL, 0x04, 0x4400);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Set the default address aging time to 5 minutes, and
|
2008-10-07 21:45:18 +08:00
|
|
|
* enable address learn messages to be sent to all message
|
|
|
|
|
* ports.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(REG_GLOBAL, 0x0a, 0x0148);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Configure the priority mapping registers. */
|
2008-10-07 21:45:18 +08:00
|
|
|
ret = mv88e6xxx_config_prio(ds);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Set the VLAN ethertype to 0x8100. */
|
2008-10-07 21:45:18 +08:00
|
|
|
REG_WRITE(REG_GLOBAL, 0x19, 0x8100);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Disable ARP mirroring, and configure the upstream port as
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
* the port to which ingress and egress monitor frames are to
|
|
|
|
|
* be sent.
|
2008-10-07 21:45:18 +08:00
|
|
|
*/
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
REG_WRITE(REG_GLOBAL, 0x1a, (dsa_upstream_port(ds) * 0x1100) | 0x00f0);
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Disable cascade port functionality unless this device
|
2011-06-25 03:53:51 +08:00
|
|
|
* is used in a cascade configuration, and set the switch's
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
* DSA device number.
|
2008-10-07 21:45:18 +08:00
|
|
|
*/
|
2011-06-25 03:53:51 +08:00
|
|
|
if (ds->dst->pd->nr_chips > 1)
|
|
|
|
|
REG_WRITE(REG_GLOBAL, 0x1c, 0xf000 | (ds->index & 0x1f));
|
|
|
|
|
else
|
|
|
|
|
REG_WRITE(REG_GLOBAL, 0x1c, 0xe000 | (ds->index & 0x1f));
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Send all frames with destination addresses matching
|
2008-10-07 21:45:18 +08:00
|
|
|
* 01:80:c2:00:00:0x to the CPU port.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(REG_GLOBAL2, 0x03, 0xffff);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Ignore removed tag data on doubly tagged packets, disable
|
2008-10-07 21:45:18 +08:00
|
|
|
* flow control messages, force flow control priority to the
|
|
|
|
|
* highest, and send all special multicast frames to the CPU
|
2011-03-31 09:57:33 +08:00
|
|
|
* port at the highest priority.
|
2008-10-07 21:45:18 +08:00
|
|
|
*/
|
|
|
|
|
REG_WRITE(REG_GLOBAL2, 0x05, 0x00ff);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Program the DSA routing table. */
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
for (i = 0; i < 32; i++) {
|
|
|
|
|
int nexthop;
|
|
|
|
|
|
|
|
|
|
nexthop = 0x1f;
|
|
|
|
|
if (i != ds->index && i < ds->dst->pd->nr_chips)
|
|
|
|
|
nexthop = ds->pd->rtable[i] & 0x1f;
|
|
|
|
|
|
|
|
|
|
REG_WRITE(REG_GLOBAL2, 0x06, 0x8000 | (i << 8) | nexthop);
|
|
|
|
|
}
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Clear all trunk masks. */
|
2008-10-07 21:45:18 +08:00
|
|
|
for (i = 0; i < 8; i++)
|
2009-03-20 17:50:39 +08:00
|
|
|
REG_WRITE(REG_GLOBAL2, 0x07, 0x8000 | (i << 12) | 0x7ff);
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Clear all trunk mappings. */
|
2008-10-07 21:45:18 +08:00
|
|
|
for (i = 0; i < 16; i++)
|
|
|
|
|
REG_WRITE(REG_GLOBAL2, 0x08, 0x8000 | (i << 11));
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Force the priority of IGMP/MLD snoop frames and ARP frames
|
2008-10-07 21:45:18 +08:00
|
|
|
* to the highest setting.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(REG_GLOBAL2, 0x0f, 0x00ff);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6131_setup_port(struct dsa_switch *ds, int p)
|
|
|
|
|
{
|
2014-04-29 02:14:28 +08:00
|
|
|
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
|
2008-10-07 21:45:18 +08:00
|
|
|
int addr = REG_PORT(p);
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
u16 val;
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* MAC Forcing register: don't force link, speed, duplex
|
2009-03-20 17:50:39 +08:00
|
|
|
* or flow control state to any particular values on physical
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
* ports, but force the CPU port and all DSA ports to 1000 Mb/s
|
2011-04-05 11:03:56 +08:00
|
|
|
* (100 Mb/s on 6085) full duplex.
|
2008-10-07 21:45:18 +08:00
|
|
|
*/
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
if (dsa_is_cpu_port(ds, p) || ds->dsa_port_mask & (1 << p))
|
2011-04-05 11:03:56 +08:00
|
|
|
if (ps->id == ID_6085)
|
|
|
|
|
REG_WRITE(addr, 0x01, 0x003d); /* 100 Mb/s */
|
|
|
|
|
else
|
|
|
|
|
REG_WRITE(addr, 0x01, 0x003e); /* 1000 Mb/s */
|
2009-03-20 17:50:39 +08:00
|
|
|
else
|
|
|
|
|
REG_WRITE(addr, 0x01, 0x0003);
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Port Control: disable Core Tag, disable Drop-on-Lock,
|
2008-10-07 21:45:18 +08:00
|
|
|
* transmit frames unmodified, disable Header mode,
|
|
|
|
|
* enable IGMP/MLD snoop, disable DoubleTag, disable VLAN
|
|
|
|
|
* tunneling, determine priority by looking at 802.1p and
|
|
|
|
|
* IP priority fields (IP prio has precedence), and set STP
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
* state to Forwarding.
|
|
|
|
|
*
|
|
|
|
|
* If this is the upstream port for this switch, enable
|
|
|
|
|
* forwarding of unknown unicasts, and enable DSA tagging
|
|
|
|
|
* mode.
|
|
|
|
|
*
|
|
|
|
|
* If this is the link to another switch, use DSA tagging
|
|
|
|
|
* mode, but do not enable forwarding of unknown unicasts.
|
2008-10-07 21:45:18 +08:00
|
|
|
*/
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
val = 0x0433;
|
2011-04-26 09:45:41 +08:00
|
|
|
if (p == dsa_upstream_port(ds)) {
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
val |= 0x0104;
|
2013-01-09 00:05:53 +08:00
|
|
|
/* On 6085, unknown multicast forward is controlled
|
2011-04-26 09:45:41 +08:00
|
|
|
* here rather than in Port Control 2 register.
|
|
|
|
|
*/
|
|
|
|
|
if (ps->id == ID_6085)
|
|
|
|
|
val |= 0x0008;
|
|
|
|
|
}
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
if (ds->dsa_port_mask & (1 << p))
|
|
|
|
|
val |= 0x0100;
|
|
|
|
|
REG_WRITE(addr, 0x04, val);
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Port Control 1: disable trunking. Also, if this is the
|
2008-10-07 21:45:18 +08:00
|
|
|
* CPU port, enable learn messages to be sent to this port.
|
|
|
|
|
*/
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
REG_WRITE(addr, 0x05, dsa_is_cpu_port(ds, p) ? 0x8000 : 0x0000);
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Port based VLAN map: give each port its own address
|
2008-10-07 21:45:18 +08:00
|
|
|
* database, allow the CPU port to talk to each of the 'real'
|
|
|
|
|
* ports, and allow each of the 'real' ports to only talk to
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
* the upstream port.
|
2008-10-07 21:45:18 +08:00
|
|
|
*/
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
val = (p & 0xf) << 12;
|
|
|
|
|
if (dsa_is_cpu_port(ds, p))
|
|
|
|
|
val |= ds->phys_port_mask;
|
|
|
|
|
else
|
|
|
|
|
val |= 1 << dsa_upstream_port(ds);
|
|
|
|
|
REG_WRITE(addr, 0x06, val);
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Default VLAN ID and priority: don't set a default VLAN
|
2008-10-07 21:45:18 +08:00
|
|
|
* ID, and set the default packet priority to zero.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(addr, 0x07, 0x0000);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Port Control 2: don't force a good FCS, don't use
|
2008-10-07 21:45:18 +08:00
|
|
|
* VLAN-based, source address-based or destination
|
|
|
|
|
* address-based priority overrides, don't let the switch
|
|
|
|
|
* add or strip 802.1q tags, don't discard tagged or
|
|
|
|
|
* untagged frames on this port, do a destination address
|
|
|
|
|
* lookup on received packets as usual, don't send a copy
|
|
|
|
|
* of all transmitted/received frames on this port to the
|
dsa: add switch chip cascading support
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-20 17:52:09 +08:00
|
|
|
* CPU, and configure the upstream port number.
|
|
|
|
|
*
|
|
|
|
|
* If this is the upstream port for this switch, enable
|
|
|
|
|
* forwarding of unknown multicast addresses.
|
2008-10-07 21:45:18 +08:00
|
|
|
*/
|
2011-04-26 09:45:41 +08:00
|
|
|
if (ps->id == ID_6085)
|
2013-01-09 00:05:53 +08:00
|
|
|
/* on 6085, bits 3:0 are reserved, bit 6 control ARP
|
2011-04-26 09:45:41 +08:00
|
|
|
* mirroring, and multicast forward is handled in
|
|
|
|
|
* Port Control register.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(addr, 0x08, 0x0080);
|
|
|
|
|
else {
|
|
|
|
|
val = 0x0080 | dsa_upstream_port(ds);
|
|
|
|
|
if (p == dsa_upstream_port(ds))
|
|
|
|
|
val |= 0x0040;
|
|
|
|
|
REG_WRITE(addr, 0x08, val);
|
|
|
|
|
}
|
2008-10-07 21:45:18 +08:00
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Rate Control: disable ingress rate limiting. */
|
2008-10-07 21:45:18 +08:00
|
|
|
REG_WRITE(addr, 0x09, 0x0000);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Rate Control 2: disable egress rate limiting. */
|
2008-10-07 21:45:18 +08:00
|
|
|
REG_WRITE(addr, 0x0a, 0x0000);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Port Association Vector: when learning source addresses
|
2008-10-07 21:45:18 +08:00
|
|
|
* of packets, add the address to the address database using
|
|
|
|
|
* a port bitmap that has only the bit for this port set and
|
|
|
|
|
* the other bits clear.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(addr, 0x0b, 1 << p);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Tag Remap: use an identity 802.1p prio -> switch prio
|
2008-10-07 21:45:18 +08:00
|
|
|
* mapping.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(addr, 0x18, 0x3210);
|
|
|
|
|
|
2013-01-09 00:05:53 +08:00
|
|
|
/* Tag Remap 2: use an identity 802.1p prio -> switch prio
|
2008-10-07 21:45:18 +08:00
|
|
|
* mapping.
|
|
|
|
|
*/
|
|
|
|
|
REG_WRITE(addr, 0x19, 0x7654);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6131_setup(struct dsa_switch *ds)
|
|
|
|
|
{
|
2014-04-29 02:14:28 +08:00
|
|
|
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
|
2008-10-07 21:45:18 +08:00
|
|
|
int i;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
mutex_init(&ps->smi_mutex);
|
|
|
|
|
mv88e6xxx_ppu_state_init(ds);
|
|
|
|
|
mutex_init(&ps->stats_mutex);
|
|
|
|
|
|
2011-04-05 11:03:56 +08:00
|
|
|
ps->id = REG_READ(REG_PORT(0), 0x03) & 0xfff0;
|
|
|
|
|
|
2008-10-07 21:45:18 +08:00
|
|
|
ret = mv88e6131_switch_reset(ds);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
/* @@@ initialise vtu and atu */
|
|
|
|
|
|
|
|
|
|
ret = mv88e6131_setup_global(ds);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
2009-03-20 17:50:39 +08:00
|
|
|
for (i = 0; i < 11; i++) {
|
2008-10-07 21:45:18 +08:00
|
|
|
ret = mv88e6131_setup_port(ds, i);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6131_port_to_phy_addr(int port)
|
|
|
|
|
{
|
2009-03-20 17:50:39 +08:00
|
|
|
if (port >= 0 && port <= 11)
|
2008-10-07 21:45:18 +08:00
|
|
|
return port;
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
mv88e6131_phy_read(struct dsa_switch *ds, int port, int regnum)
|
|
|
|
|
{
|
|
|
|
|
int addr = mv88e6131_port_to_phy_addr(port);
|
|
|
|
|
return mv88e6xxx_phy_read_ppu(ds, addr, regnum);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
mv88e6131_phy_write(struct dsa_switch *ds,
|
|
|
|
|
int port, int regnum, u16 val)
|
|
|
|
|
{
|
|
|
|
|
int addr = mv88e6131_port_to_phy_addr(port);
|
|
|
|
|
return mv88e6xxx_phy_write_ppu(ds, addr, regnum, val);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct mv88e6xxx_hw_stat mv88e6131_hw_stats[] = {
|
|
|
|
|
{ "in_good_octets", 8, 0x00, },
|
|
|
|
|
{ "in_bad_octets", 4, 0x02, },
|
|
|
|
|
{ "in_unicast", 4, 0x04, },
|
|
|
|
|
{ "in_broadcasts", 4, 0x06, },
|
|
|
|
|
{ "in_multicasts", 4, 0x07, },
|
|
|
|
|
{ "in_pause", 4, 0x16, },
|
|
|
|
|
{ "in_undersize", 4, 0x18, },
|
|
|
|
|
{ "in_fragments", 4, 0x19, },
|
|
|
|
|
{ "in_oversize", 4, 0x1a, },
|
|
|
|
|
{ "in_jabber", 4, 0x1b, },
|
|
|
|
|
{ "in_rx_error", 4, 0x1c, },
|
|
|
|
|
{ "in_fcs_error", 4, 0x1d, },
|
|
|
|
|
{ "out_octets", 8, 0x0e, },
|
|
|
|
|
{ "out_unicast", 4, 0x10, },
|
|
|
|
|
{ "out_broadcasts", 4, 0x13, },
|
|
|
|
|
{ "out_multicasts", 4, 0x12, },
|
|
|
|
|
{ "out_pause", 4, 0x15, },
|
|
|
|
|
{ "excessive", 4, 0x11, },
|
|
|
|
|
{ "collisions", 4, 0x1e, },
|
|
|
|
|
{ "deferred", 4, 0x05, },
|
|
|
|
|
{ "single", 4, 0x14, },
|
|
|
|
|
{ "multiple", 4, 0x17, },
|
|
|
|
|
{ "out_fcs_error", 4, 0x03, },
|
|
|
|
|
{ "late", 4, 0x1f, },
|
|
|
|
|
{ "hist_64bytes", 4, 0x08, },
|
|
|
|
|
{ "hist_65_127bytes", 4, 0x09, },
|
|
|
|
|
{ "hist_128_255bytes", 4, 0x0a, },
|
|
|
|
|
{ "hist_256_511bytes", 4, 0x0b, },
|
|
|
|
|
{ "hist_512_1023bytes", 4, 0x0c, },
|
|
|
|
|
{ "hist_1024_max_bytes", 4, 0x0d, },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
mv88e6131_get_strings(struct dsa_switch *ds, int port, uint8_t *data)
|
|
|
|
|
{
|
|
|
|
|
mv88e6xxx_get_strings(ds, ARRAY_SIZE(mv88e6131_hw_stats),
|
|
|
|
|
mv88e6131_hw_stats, port, data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
mv88e6131_get_ethtool_stats(struct dsa_switch *ds,
|
|
|
|
|
int port, uint64_t *data)
|
|
|
|
|
{
|
|
|
|
|
mv88e6xxx_get_ethtool_stats(ds, ARRAY_SIZE(mv88e6131_hw_stats),
|
|
|
|
|
mv88e6131_hw_stats, port, data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6131_get_sset_count(struct dsa_switch *ds)
|
|
|
|
|
{
|
|
|
|
|
return ARRAY_SIZE(mv88e6131_hw_stats);
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-25 22:36:19 +08:00
|
|
|
struct dsa_switch_driver mv88e6131_switch_driver = {
|
2009-02-01 16:45:17 +08:00
|
|
|
.tag_protocol = cpu_to_be16(ETH_P_DSA),
|
2008-10-07 21:45:18 +08:00
|
|
|
.priv_size = sizeof(struct mv88e6xxx_priv_state),
|
|
|
|
|
.probe = mv88e6131_probe,
|
|
|
|
|
.setup = mv88e6131_setup,
|
|
|
|
|
.set_addr = mv88e6xxx_set_addr_direct,
|
|
|
|
|
.phy_read = mv88e6131_phy_read,
|
|
|
|
|
.phy_write = mv88e6131_phy_write,
|
|
|
|
|
.poll_link = mv88e6xxx_poll_link,
|
|
|
|
|
.get_strings = mv88e6131_get_strings,
|
|
|
|
|
.get_ethtool_stats = mv88e6131_get_ethtool_stats,
|
|
|
|
|
.get_sset_count = mv88e6131_get_sset_count,
|
|
|
|
|
};
|
2011-11-25 22:37:16 +08:00
|
|
|
|
|
|
|
|
MODULE_ALIAS("platform:mv88e6085");
|
|
|
|
|
MODULE_ALIAS("platform:mv88e6095");
|
|
|
|
|
MODULE_ALIAS("platform:mv88e6095f");
|
|
|
|
|
MODULE_ALIAS("platform:mv88e6131");
|