2019-05-27 08:55:01 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
/*
|
2016-06-21 12:28:19 -04:00
|
|
|
* Marvell 88e6xxx Ethernet switch single-chip support
|
|
|
|
|
*
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
* Copyright (c) 2008 Marvell Semiconductor
|
|
|
|
|
*
|
2016-05-10 23:27:21 +02:00
|
|
|
* Copyright (c) 2016 Andrew Lunn <andrew@lunn.ch>
|
|
|
|
|
*
|
2017-03-28 15:10:36 -04:00
|
|
|
* Copyright (c) 2016-2017 Savoir-faire Linux Inc.
|
|
|
|
|
* Vivien Didelot <vivien.didelot@savoirfairelinux.com>
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
*/
|
|
|
|
|
|
2019-08-09 18:47:55 -04:00
|
|
|
#include <linux/bitfield.h>
|
2013-01-08 16:05:54 +00:00
|
|
|
#include <linux/delay.h>
|
2015-03-26 18:36:38 -07:00
|
|
|
#include <linux/etherdevice.h>
|
2015-08-31 15:56:47 +02:00
|
|
|
#include <linux/ethtool.h>
|
2015-03-26 18:36:35 -07:00
|
|
|
#include <linux/if_bridge.h>
|
2016-10-16 19:56:49 +02:00
|
|
|
#include <linux/interrupt.h>
|
|
|
|
|
#include <linux/irq.h>
|
|
|
|
|
#include <linux/irqdomain.h>
|
2013-01-08 16:05:54 +00:00
|
|
|
#include <linux/jiffies.h>
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
#include <linux/list.h>
|
2016-05-10 23:27:21 +02:00
|
|
|
#include <linux/mdio.h>
|
2012-01-24 10:41:40 +00:00
|
|
|
#include <linux/module.h>
|
2016-06-20 13:14:09 -04:00
|
|
|
#include <linux/of_device.h>
|
2016-10-16 19:56:49 +02:00
|
|
|
#include <linux/of_irq.h>
|
2016-06-04 21:17:06 +02:00
|
|
|
#include <linux/of_mdio.h>
|
2018-05-19 22:31:34 +02:00
|
|
|
#include <linux/platform_data/mv88e6xxx.h>
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
#include <linux/netdevice.h>
|
2015-11-20 03:56:24 +01:00
|
|
|
#include <linux/gpio/consumer.h>
|
2018-05-10 13:17:35 -07:00
|
|
|
#include <linux/phylink.h>
|
2011-11-27 17:06:08 +00:00
|
|
|
#include <net/dsa.h>
|
2016-09-02 14:45:33 -04:00
|
|
|
|
2017-06-02 17:06:15 -04:00
|
|
|
#include "chip.h"
|
2020-09-18 21:11:05 +02:00
|
|
|
#include "devlink.h"
|
2016-09-29 12:21:53 -04:00
|
|
|
#include "global1.h"
|
2016-09-02 14:45:33 -04:00
|
|
|
#include "global2.h"
|
2018-02-14 01:07:50 +01:00
|
|
|
#include "hwtstamp.h"
|
2017-05-26 01:03:20 +02:00
|
|
|
#include "phy.h"
|
2016-11-04 03:23:26 +01:00
|
|
|
#include "port.h"
|
2018-02-14 01:07:45 +01:00
|
|
|
#include "ptp.h"
|
2017-05-26 01:03:21 +02:00
|
|
|
#include "serdes.h"
|
2019-05-03 19:28:22 -04:00
|
|
|
#include "smi.h"
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
static void assert_reg_lock(struct mv88e6xxx_chip *chip)
|
2015-10-30 18:56:45 -04:00
|
|
|
{
|
2016-06-21 12:28:20 -04:00
|
|
|
if (unlikely(!mutex_is_locked(&chip->reg_lock))) {
|
|
|
|
|
dev_err(chip->dev, "Switch registers lock not held!\n");
|
2015-10-30 18:56:45 -04:00
|
|
|
dump_stack();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-02 14:45:33 -04:00
|
|
|
int mv88e6xxx_read(struct mv88e6xxx_chip *chip, int addr, int reg, u16 *val)
|
2016-06-20 13:14:11 -04:00
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
assert_reg_lock(chip);
|
2016-06-20 13:14:11 -04:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
err = mv88e6xxx_smi_read(chip, addr, reg, val);
|
2016-06-20 13:14:11 -04:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
dev_dbg(chip->dev, "<- addr: 0x%.2x reg: 0x%.2x val: 0x%.4x\n",
|
2016-06-20 13:14:11 -04:00
|
|
|
addr, reg, *val);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-02 14:45:33 -04:00
|
|
|
int mv88e6xxx_write(struct mv88e6xxx_chip *chip, int addr, int reg, u16 val)
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
{
|
2016-06-20 13:14:11 -04:00
|
|
|
int err;
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
assert_reg_lock(chip);
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
err = mv88e6xxx_smi_write(chip, addr, reg, val);
|
2016-06-20 13:14:11 -04:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
dev_dbg(chip->dev, "-> addr: 0x%.2x reg: 0x%.2x val: 0x%.4x\n",
|
2015-01-23 16:10:36 -05:00
|
|
|
addr, reg, val);
|
|
|
|
|
|
2016-06-20 13:14:11 -04:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-09 18:47:54 -04:00
|
|
|
int mv88e6xxx_wait_mask(struct mv88e6xxx_chip *chip, int addr, int reg,
|
|
|
|
|
u16 mask, u16 val)
|
|
|
|
|
{
|
|
|
|
|
u16 data;
|
|
|
|
|
int err;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/* There's no bus specific operation to wait for a mask */
|
|
|
|
|
for (i = 0; i < 16; i++) {
|
|
|
|
|
err = mv88e6xxx_read(chip, addr, reg, &data);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
if ((data & mask) == val)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
usleep_range(1000, 2000);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dev_err(chip->dev, "Timeout while waiting for switch\n");
|
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-09 18:47:55 -04:00
|
|
|
int mv88e6xxx_wait_bit(struct mv88e6xxx_chip *chip, int addr, int reg,
|
|
|
|
|
int bit, int val)
|
|
|
|
|
{
|
|
|
|
|
return mv88e6xxx_wait_mask(chip, addr, reg, BIT(bit),
|
|
|
|
|
val ? BIT(bit) : 0x0000);
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 01:03:20 +02:00
|
|
|
struct mii_bus *mv88e6xxx_default_mdio_bus(struct mv88e6xxx_chip *chip)
|
2017-01-24 14:53:50 +01:00
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus;
|
|
|
|
|
|
|
|
|
|
mdio_bus = list_first_entry(&chip->mdios, struct mv88e6xxx_mdio_bus,
|
|
|
|
|
list);
|
|
|
|
|
if (!mdio_bus)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
return mdio_bus->bus;
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-16 19:56:49 +02:00
|
|
|
static void mv88e6xxx_g1_irq_mask(struct irq_data *d)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = irq_data_get_irq_chip_data(d);
|
|
|
|
|
unsigned int n = d->hwirq;
|
|
|
|
|
|
|
|
|
|
chip->g1_irq.masked |= (1 << n);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_g1_irq_unmask(struct irq_data *d)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = irq_data_get_irq_chip_data(d);
|
|
|
|
|
unsigned int n = d->hwirq;
|
|
|
|
|
|
|
|
|
|
chip->g1_irq.masked &= ~(1 << n);
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-22 22:58:32 +01:00
|
|
|
static irqreturn_t mv88e6xxx_g1_irq_thread_work(struct mv88e6xxx_chip *chip)
|
2016-10-16 19:56:49 +02:00
|
|
|
{
|
|
|
|
|
unsigned int nhandled = 0;
|
|
|
|
|
unsigned int sub_irq;
|
|
|
|
|
unsigned int n;
|
|
|
|
|
u16 reg;
|
2019-02-11 13:40:21 -05:00
|
|
|
u16 ctl1;
|
2016-10-16 19:56:49 +02:00
|
|
|
int err;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-06-15 12:13:59 -04:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_STS, ®);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
|
2019-02-11 13:40:21 -05:00
|
|
|
do {
|
|
|
|
|
for (n = 0; n < chip->g1_irq.nirqs; ++n) {
|
|
|
|
|
if (reg & (1 << n)) {
|
|
|
|
|
sub_irq = irq_find_mapping(chip->g1_irq.domain,
|
|
|
|
|
n);
|
|
|
|
|
handle_nested_irq(sub_irq);
|
|
|
|
|
++nhandled;
|
|
|
|
|
}
|
2016-10-16 19:56:49 +02:00
|
|
|
}
|
2019-02-11 13:40:21 -05:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2019-02-11 13:40:21 -05:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_CTL1, &ctl1);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_STS, ®);
|
|
|
|
|
unlock:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2019-02-11 13:40:21 -05:00
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
ctl1 &= GENMASK(chip->g1_irq.nirqs, 0);
|
|
|
|
|
} while (reg & ctl1);
|
|
|
|
|
|
2016-10-16 19:56:49 +02:00
|
|
|
out:
|
|
|
|
|
return (nhandled > 0 ? IRQ_HANDLED : IRQ_NONE);
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-22 22:58:32 +01:00
|
|
|
static irqreturn_t mv88e6xxx_g1_irq_thread_fn(int irq, void *dev_id)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = dev_id;
|
|
|
|
|
|
|
|
|
|
return mv88e6xxx_g1_irq_thread_work(chip);
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-16 19:56:49 +02:00
|
|
|
static void mv88e6xxx_g1_irq_bus_lock(struct irq_data *d)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = irq_data_get_irq_chip_data(d);
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_g1_irq_bus_sync_unlock(struct irq_data *d)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = irq_data_get_irq_chip_data(d);
|
|
|
|
|
u16 mask = GENMASK(chip->g1_irq.nirqs, 0);
|
|
|
|
|
u16 reg;
|
|
|
|
|
int err;
|
|
|
|
|
|
2017-06-15 12:14:03 -04:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_CTL1, ®);
|
2016-10-16 19:56:49 +02:00
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
reg &= ~mask;
|
|
|
|
|
reg |= (~chip->g1_irq.masked & mask);
|
|
|
|
|
|
2017-06-15 12:14:03 -04:00
|
|
|
err = mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, reg);
|
2016-10-16 19:56:49 +02:00
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
out:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
}
|
|
|
|
|
|
2017-08-19 16:25:52 +05:30
|
|
|
static const struct irq_chip mv88e6xxx_g1_irq_chip = {
|
2016-10-16 19:56:49 +02:00
|
|
|
.name = "mv88e6xxx-g1",
|
|
|
|
|
.irq_mask = mv88e6xxx_g1_irq_mask,
|
|
|
|
|
.irq_unmask = mv88e6xxx_g1_irq_unmask,
|
|
|
|
|
.irq_bus_lock = mv88e6xxx_g1_irq_bus_lock,
|
|
|
|
|
.irq_bus_sync_unlock = mv88e6xxx_g1_irq_bus_sync_unlock,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_g1_irq_domain_map(struct irq_domain *d,
|
|
|
|
|
unsigned int irq,
|
|
|
|
|
irq_hw_number_t hwirq)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = d->host_data;
|
|
|
|
|
|
|
|
|
|
irq_set_chip_data(irq, d->host_data);
|
|
|
|
|
irq_set_chip_and_handler(irq, &chip->g1_irq.chip, handle_level_irq);
|
|
|
|
|
irq_set_noprobe(irq);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct irq_domain_ops mv88e6xxx_g1_irq_domain_ops = {
|
|
|
|
|
.map = mv88e6xxx_g1_irq_domain_map,
|
|
|
|
|
.xlate = irq_domain_xlate_twocell,
|
|
|
|
|
};
|
|
|
|
|
|
2018-07-20 11:53:15 +02:00
|
|
|
/* To be called with reg_lock held */
|
2018-02-22 22:58:32 +01:00
|
|
|
static void mv88e6xxx_g1_irq_free_common(struct mv88e6xxx_chip *chip)
|
2016-10-16 19:56:49 +02:00
|
|
|
{
|
|
|
|
|
int irq, virq;
|
2016-11-20 20:14:16 +01:00
|
|
|
u16 mask;
|
|
|
|
|
|
2017-06-15 12:14:03 -04:00
|
|
|
mv88e6xxx_g1_read(chip, MV88E6XXX_G1_CTL1, &mask);
|
2017-12-07 01:05:56 +01:00
|
|
|
mask &= ~GENMASK(chip->g1_irq.nirqs, 0);
|
2017-06-15 12:14:03 -04:00
|
|
|
mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, mask);
|
2016-11-20 20:14:16 +01:00
|
|
|
|
2016-11-27 23:26:28 +01:00
|
|
|
for (irq = 0; irq < chip->g1_irq.nirqs; irq++) {
|
2016-11-20 20:14:14 +01:00
|
|
|
virq = irq_find_mapping(chip->g1_irq.domain, irq);
|
2016-10-16 19:56:49 +02:00
|
|
|
irq_dispose_mapping(virq);
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-20 20:14:14 +01:00
|
|
|
irq_domain_remove(chip->g1_irq.domain);
|
2016-10-16 19:56:49 +02:00
|
|
|
}
|
|
|
|
|
|
2018-02-22 22:58:32 +01:00
|
|
|
static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
2018-07-20 11:53:15 +02:00
|
|
|
/*
|
|
|
|
|
* free_irq must be called without reg_lock taken because the irq
|
|
|
|
|
* handler takes this lock, too.
|
|
|
|
|
*/
|
2018-02-22 22:58:32 +01:00
|
|
|
free_irq(chip->irq, chip);
|
2018-07-20 11:53:15 +02:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-07-20 11:53:15 +02:00
|
|
|
mv88e6xxx_g1_irq_free_common(chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-22 22:58:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_g1_irq_setup_common(struct mv88e6xxx_chip *chip)
|
2016-10-16 19:56:49 +02:00
|
|
|
{
|
2016-11-20 20:14:17 +01:00
|
|
|
int err, irq, virq;
|
|
|
|
|
u16 reg, mask;
|
2016-10-16 19:56:49 +02:00
|
|
|
|
|
|
|
|
chip->g1_irq.nirqs = chip->info->g1_irqs;
|
|
|
|
|
chip->g1_irq.domain = irq_domain_add_simple(
|
|
|
|
|
NULL, chip->g1_irq.nirqs, 0,
|
|
|
|
|
&mv88e6xxx_g1_irq_domain_ops, chip);
|
|
|
|
|
if (!chip->g1_irq.domain)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
for (irq = 0; irq < chip->g1_irq.nirqs; irq++)
|
|
|
|
|
irq_create_mapping(chip->g1_irq.domain, irq);
|
|
|
|
|
|
|
|
|
|
chip->g1_irq.chip = mv88e6xxx_g1_irq_chip;
|
|
|
|
|
chip->g1_irq.masked = ~0;
|
|
|
|
|
|
2017-06-15 12:14:03 -04:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_CTL1, &mask);
|
2016-10-16 19:56:49 +02:00
|
|
|
if (err)
|
2016-11-20 20:14:17 +01:00
|
|
|
goto out_mapping;
|
2016-10-16 19:56:49 +02:00
|
|
|
|
2016-11-20 20:14:17 +01:00
|
|
|
mask &= ~GENMASK(chip->g1_irq.nirqs, 0);
|
2016-10-16 19:56:49 +02:00
|
|
|
|
2017-06-15 12:14:03 -04:00
|
|
|
err = mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, mask);
|
2016-10-16 19:56:49 +02:00
|
|
|
if (err)
|
2016-11-20 20:14:17 +01:00
|
|
|
goto out_disable;
|
2016-10-16 19:56:49 +02:00
|
|
|
|
|
|
|
|
/* Reading the interrupt status clears (most of) them */
|
2017-06-15 12:13:59 -04:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_STS, ®);
|
2016-10-16 19:56:49 +02:00
|
|
|
if (err)
|
2016-11-20 20:14:17 +01:00
|
|
|
goto out_disable;
|
2016-10-16 19:56:49 +02:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
2016-11-20 20:14:17 +01:00
|
|
|
out_disable:
|
2017-12-07 01:05:56 +01:00
|
|
|
mask &= ~GENMASK(chip->g1_irq.nirqs, 0);
|
2017-06-15 12:14:03 -04:00
|
|
|
mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, mask);
|
2016-11-20 20:14:17 +01:00
|
|
|
|
|
|
|
|
out_mapping:
|
|
|
|
|
for (irq = 0; irq < 16; irq++) {
|
|
|
|
|
virq = irq_find_mapping(chip->g1_irq.domain, irq);
|
|
|
|
|
irq_dispose_mapping(virq);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
irq_domain_remove(chip->g1_irq.domain);
|
2016-10-16 19:56:49 +02:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-22 22:58:32 +01:00
|
|
|
static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
2019-02-23 17:43:56 +01:00
|
|
|
static struct lock_class_key lock_key;
|
|
|
|
|
static struct lock_class_key request_key;
|
2018-02-22 22:58:32 +01:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_g1_irq_setup_common(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2019-02-23 17:43:56 +01:00
|
|
|
/* These lock classes tells lockdep that global 1 irqs are in
|
|
|
|
|
* a different category than their parent GPIO, so it won't
|
|
|
|
|
* report false recursion.
|
|
|
|
|
*/
|
|
|
|
|
irq_set_lockdep_class(chip->irq, &lock_key, &request_key);
|
|
|
|
|
|
2020-01-06 17:13:48 +01:00
|
|
|
snprintf(chip->irq_name, sizeof(chip->irq_name),
|
|
|
|
|
"mv88e6xxx-%s", dev_name(chip->dev));
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-22 22:58:32 +01:00
|
|
|
err = request_threaded_irq(chip->irq, NULL,
|
|
|
|
|
mv88e6xxx_g1_irq_thread_fn,
|
2018-08-30 02:13:50 +02:00
|
|
|
IRQF_ONESHOT | IRQF_SHARED,
|
2020-01-06 17:13:48 +01:00
|
|
|
chip->irq_name, chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-02-22 22:58:32 +01:00
|
|
|
if (err)
|
|
|
|
|
mv88e6xxx_g1_irq_free_common(chip);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_irq_poll(struct kthread_work *work)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = container_of(work,
|
|
|
|
|
struct mv88e6xxx_chip,
|
|
|
|
|
irq_poll_work.work);
|
|
|
|
|
mv88e6xxx_g1_irq_thread_work(chip);
|
|
|
|
|
|
|
|
|
|
kthread_queue_delayed_work(chip->kworker, &chip->irq_poll_work,
|
|
|
|
|
msecs_to_jiffies(100));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_irq_poll_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_g1_irq_setup_common(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
kthread_init_delayed_work(&chip->irq_poll_work,
|
|
|
|
|
mv88e6xxx_irq_poll);
|
|
|
|
|
|
2019-02-21 20:09:27 -08:00
|
|
|
chip->kworker = kthread_create_worker(0, "%s", dev_name(chip->dev));
|
2018-02-22 22:58:32 +01:00
|
|
|
if (IS_ERR(chip->kworker))
|
|
|
|
|
return PTR_ERR(chip->kworker);
|
|
|
|
|
|
|
|
|
|
kthread_queue_delayed_work(chip->kworker, &chip->irq_poll_work,
|
|
|
|
|
msecs_to_jiffies(100));
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_irq_poll_free(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
kthread_cancel_delayed_work_sync(&chip->irq_poll_work);
|
|
|
|
|
kthread_destroy_worker(chip->kworker);
|
2018-07-20 11:53:15 +02:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-07-20 11:53:15 +02:00
|
|
|
mv88e6xxx_g1_irq_free_common(chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-22 22:58:32 +01:00
|
|
|
}
|
|
|
|
|
|
2020-03-14 10:15:38 +00:00
|
|
|
static int mv88e6xxx_port_config_interface(struct mv88e6xxx_chip *chip,
|
|
|
|
|
int port, phy_interface_t interface)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->port_set_rgmii_delay) {
|
|
|
|
|
err = chip->info->ops->port_set_rgmii_delay(chip, port,
|
|
|
|
|
interface);
|
|
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->port_set_cmode) {
|
|
|
|
|
err = chip->info->ops->port_set_cmode(chip, port,
|
|
|
|
|
interface);
|
|
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-14 10:15:43 +00:00
|
|
|
static int mv88e6xxx_port_setup_mac(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
int link, int speed, int duplex, int pause,
|
|
|
|
|
phy_interface_t mode)
|
2016-11-04 03:23:36 +01:00
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!chip->info->ops->port_set_link)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* Port's MAC control must not be changed unless the link is down */
|
2019-07-30 12:11:42 +02:00
|
|
|
err = chip->info->ops->port_set_link(chip, port, LINK_FORCED_DOWN);
|
2016-11-04 03:23:36 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2020-03-14 10:15:53 +00:00
|
|
|
if (chip->info->ops->port_set_speed_duplex) {
|
|
|
|
|
err = chip->info->ops->port_set_speed_duplex(chip, port,
|
|
|
|
|
speed, duplex);
|
2016-11-04 03:23:36 +01:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
|
goto restore_link;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-08 01:21:27 +01:00
|
|
|
if (speed == SPEED_MAX && chip->info->ops->port_max_speed_mode)
|
|
|
|
|
mode = chip->info->ops->port_max_speed_mode(port);
|
|
|
|
|
|
2018-08-09 15:38:37 +02:00
|
|
|
if (chip->info->ops->port_set_pause) {
|
|
|
|
|
err = chip->info->ops->port_set_pause(chip, port, pause);
|
|
|
|
|
if (err)
|
|
|
|
|
goto restore_link;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-14 10:15:38 +00:00
|
|
|
err = mv88e6xxx_port_config_interface(chip, port, mode);
|
2016-11-04 03:23:36 +01:00
|
|
|
restore_link:
|
|
|
|
|
if (chip->info->ops->port_set_link(chip, port, link))
|
2017-06-08 18:34:08 -04:00
|
|
|
dev_err(chip->dev, "p%d: failed to restore MAC's link\n", port);
|
2016-11-04 03:23:36 +01:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-09-12 00:15:24 +02:00
|
|
|
static int mv88e6xxx_phy_is_internal(struct dsa_switch *ds, int port)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
|
|
|
|
|
return port < chip->info->num_internal_phys;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-14 10:16:03 +00:00
|
|
|
static int mv88e6xxx_port_ppu_updates(struct mv88e6xxx_chip *chip, int port)
|
|
|
|
|
{
|
|
|
|
|
u16 reg;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_STS, ®);
|
|
|
|
|
if (err) {
|
|
|
|
|
dev_err(chip->dev,
|
|
|
|
|
"p%d: %s: failed to read port status\n",
|
|
|
|
|
port, __func__);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return !!(reg & MV88E6XXX_PORT_STS_PHY_DETECT);
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-14 10:15:43 +00:00
|
|
|
static int mv88e6xxx_serdes_pcs_get_state(struct dsa_switch *ds, int port,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2021-03-17 14:46:40 +01:00
|
|
|
int lane;
|
2020-03-14 10:15:43 +00:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
lane = mv88e6xxx_serdes_get_lane(chip, port);
|
2021-03-17 14:46:40 +01:00
|
|
|
if (lane >= 0 && chip->info->ops->serdes_pcs_get_state)
|
2020-03-14 10:15:43 +00:00
|
|
|
err = chip->info->ops->serdes_pcs_get_state(chip, port, lane,
|
|
|
|
|
state);
|
|
|
|
|
else
|
|
|
|
|
err = -EOPNOTSUPP;
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_serdes_pcs_config(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned int mode,
|
|
|
|
|
phy_interface_t interface,
|
|
|
|
|
const unsigned long *advertise)
|
|
|
|
|
{
|
|
|
|
|
const struct mv88e6xxx_ops *ops = chip->info->ops;
|
2021-03-17 14:46:40 +01:00
|
|
|
int lane;
|
2020-03-14 10:15:43 +00:00
|
|
|
|
|
|
|
|
if (ops->serdes_pcs_config) {
|
|
|
|
|
lane = mv88e6xxx_serdes_get_lane(chip, port);
|
2021-03-17 14:46:40 +01:00
|
|
|
if (lane >= 0)
|
2020-03-14 10:15:43 +00:00
|
|
|
return ops->serdes_pcs_config(chip, port, lane, mode,
|
|
|
|
|
interface, advertise);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_serdes_pcs_an_restart(struct dsa_switch *ds, int port)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
const struct mv88e6xxx_ops *ops;
|
|
|
|
|
int err = 0;
|
2021-03-17 14:46:40 +01:00
|
|
|
int lane;
|
2020-03-14 10:15:43 +00:00
|
|
|
|
|
|
|
|
ops = chip->info->ops;
|
|
|
|
|
|
|
|
|
|
if (ops->serdes_pcs_an_restart) {
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
lane = mv88e6xxx_serdes_get_lane(chip, port);
|
2021-03-17 14:46:40 +01:00
|
|
|
if (lane >= 0)
|
2020-03-14 10:15:43 +00:00
|
|
|
err = ops->serdes_pcs_an_restart(chip, port, lane);
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
dev_err(ds->dev, "p%d: failed to restart AN\n", port);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_serdes_pcs_link_up(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned int mode,
|
|
|
|
|
int speed, int duplex)
|
|
|
|
|
{
|
|
|
|
|
const struct mv88e6xxx_ops *ops = chip->info->ops;
|
2021-03-17 14:46:40 +01:00
|
|
|
int lane;
|
2020-03-14 10:15:43 +00:00
|
|
|
|
|
|
|
|
if (!phylink_autoneg_inband(mode) && ops->serdes_pcs_link_up) {
|
|
|
|
|
lane = mv88e6xxx_serdes_get_lane(chip, port);
|
2021-03-17 14:46:40 +01:00
|
|
|
if (lane >= 0)
|
2020-03-14 10:15:43 +00:00
|
|
|
return ops->serdes_pcs_link_up(chip, port, lane,
|
|
|
|
|
speed, duplex);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-09 15:38:39 +02:00
|
|
|
static void mv88e6065_phylink_validate(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned long *mask,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
if (!phy_interface_mode_is_8023z(state->interface)) {
|
|
|
|
|
/* 10M and 100M are only supported in non-802.3z mode */
|
|
|
|
|
phylink_set(mask, 10baseT_Half);
|
|
|
|
|
phylink_set(mask, 10baseT_Full);
|
|
|
|
|
phylink_set(mask, 100baseT_Half);
|
|
|
|
|
phylink_set(mask, 100baseT_Full);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6185_phylink_validate(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned long *mask,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
/* FIXME: if the port is in 1000Base-X mode, then it only supports
|
|
|
|
|
* 1000M FD speeds. In this case, CMODE will indicate 5.
|
|
|
|
|
*/
|
|
|
|
|
phylink_set(mask, 1000baseT_Full);
|
|
|
|
|
phylink_set(mask, 1000baseX_Full);
|
|
|
|
|
|
|
|
|
|
mv88e6065_phylink_validate(chip, port, mask, state);
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-25 12:39:55 +01:00
|
|
|
static void mv88e6341_phylink_validate(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned long *mask,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
if (port >= 5)
|
|
|
|
|
phylink_set(mask, 2500baseX_Full);
|
|
|
|
|
|
|
|
|
|
/* No ethtool bits for 200Mbps */
|
|
|
|
|
phylink_set(mask, 1000baseT_Full);
|
|
|
|
|
phylink_set(mask, 1000baseX_Full);
|
|
|
|
|
|
|
|
|
|
mv88e6065_phylink_validate(chip, port, mask, state);
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-09 15:38:39 +02:00
|
|
|
static void mv88e6352_phylink_validate(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned long *mask,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
/* No ethtool bits for 200Mbps */
|
|
|
|
|
phylink_set(mask, 1000baseT_Full);
|
|
|
|
|
phylink_set(mask, 1000baseX_Full);
|
|
|
|
|
|
|
|
|
|
mv88e6065_phylink_validate(chip, port, mask, state);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6390_phylink_validate(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned long *mask,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
2019-02-08 22:25:44 +01:00
|
|
|
if (port >= 9) {
|
2018-08-09 15:38:39 +02:00
|
|
|
phylink_set(mask, 2500baseX_Full);
|
2019-02-08 22:25:44 +01:00
|
|
|
phylink_set(mask, 2500baseT_Full);
|
|
|
|
|
}
|
2018-08-09 15:38:39 +02:00
|
|
|
|
|
|
|
|
/* No ethtool bits for 200Mbps */
|
|
|
|
|
phylink_set(mask, 1000baseT_Full);
|
|
|
|
|
phylink_set(mask, 1000baseX_Full);
|
|
|
|
|
|
|
|
|
|
mv88e6065_phylink_validate(chip, port, mask, state);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6390x_phylink_validate(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned long *mask,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
if (port >= 9) {
|
|
|
|
|
phylink_set(mask, 10000baseT_Full);
|
|
|
|
|
phylink_set(mask, 10000baseKR_Full);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mv88e6390_phylink_validate(chip, port, mask, state);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-17 14:46:42 +01:00
|
|
|
static void mv88e6393x_phylink_validate(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
unsigned long *mask,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
if (port == 0 || port == 9 || port == 10) {
|
|
|
|
|
phylink_set(mask, 10000baseT_Full);
|
|
|
|
|
phylink_set(mask, 10000baseKR_Full);
|
|
|
|
|
phylink_set(mask, 10000baseCR_Full);
|
|
|
|
|
phylink_set(mask, 10000baseSR_Full);
|
|
|
|
|
phylink_set(mask, 10000baseLR_Full);
|
|
|
|
|
phylink_set(mask, 10000baseLRM_Full);
|
|
|
|
|
phylink_set(mask, 10000baseER_Full);
|
|
|
|
|
phylink_set(mask, 5000baseT_Full);
|
|
|
|
|
phylink_set(mask, 2500baseX_Full);
|
|
|
|
|
phylink_set(mask, 2500baseT_Full);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
phylink_set(mask, 1000baseT_Full);
|
|
|
|
|
phylink_set(mask, 1000baseX_Full);
|
|
|
|
|
|
|
|
|
|
mv88e6065_phylink_validate(chip, port, mask, state);
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-10 13:17:35 -07:00
|
|
|
static void mv88e6xxx_validate(struct dsa_switch *ds, int port,
|
|
|
|
|
unsigned long *supported,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
2018-08-09 15:38:39 +02:00
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
|
|
|
|
|
/* Allow all the expected bits */
|
|
|
|
|
phylink_set(mask, Autoneg);
|
|
|
|
|
phylink_set(mask, Pause);
|
|
|
|
|
phylink_set_port_modes(mask);
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->phylink_validate)
|
|
|
|
|
chip->info->ops->phylink_validate(chip, port, mask, state);
|
|
|
|
|
|
|
|
|
|
bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
|
|
|
|
|
bitmap_and(state->advertising, state->advertising, mask,
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS);
|
|
|
|
|
|
|
|
|
|
/* We can only operate at 2500BaseX or 1000BaseX. If requested
|
|
|
|
|
* to advertise both, only report advertising at 2500BaseX.
|
|
|
|
|
*/
|
|
|
|
|
phylink_helper_basex_speed(state);
|
2018-05-10 13:17:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_mac_config(struct dsa_switch *ds, int port,
|
|
|
|
|
unsigned int mode,
|
|
|
|
|
const struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2020-07-19 12:00:35 +01:00
|
|
|
struct mv88e6xxx_port *p;
|
2020-03-14 10:15:38 +00:00
|
|
|
int err;
|
2018-05-10 13:17:35 -07:00
|
|
|
|
2020-07-19 12:00:35 +01:00
|
|
|
p = &chip->ports[port];
|
|
|
|
|
|
2020-03-14 10:15:38 +00:00
|
|
|
/* FIXME: is this the correct test? If we're in fixed mode on an
|
|
|
|
|
* internal port, why should we process this any different from
|
|
|
|
|
* PHY mode? On the other hand, the port may be automedia between
|
|
|
|
|
* an internal PHY and the serdes...
|
|
|
|
|
*/
|
2018-09-12 00:15:24 +02:00
|
|
|
if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds, port))
|
2018-05-10 13:17:35 -07:00
|
|
|
return;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2020-07-19 12:00:35 +01:00
|
|
|
/* In inband mode, the link may come up at any time while the link
|
|
|
|
|
* is not forced down. Force the link down while we reconfigure the
|
|
|
|
|
* interface mode.
|
2020-03-14 10:15:38 +00:00
|
|
|
*/
|
2020-07-19 12:00:35 +01:00
|
|
|
if (mode == MLO_AN_INBAND && p->interface != state->interface &&
|
|
|
|
|
chip->info->ops->port_set_link)
|
|
|
|
|
chip->info->ops->port_set_link(chip, port, LINK_FORCED_DOWN);
|
|
|
|
|
|
2020-03-14 10:15:38 +00:00
|
|
|
err = mv88e6xxx_port_config_interface(chip, port, state->interface);
|
2020-03-14 10:15:43 +00:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
|
goto err_unlock;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_serdes_pcs_config(chip, port, mode, state->interface,
|
|
|
|
|
state->advertising);
|
|
|
|
|
/* FIXME: we should restart negotiation if something changed - which
|
|
|
|
|
* is something we get if we convert to using phylinks PCS operations.
|
|
|
|
|
*/
|
|
|
|
|
if (err > 0)
|
|
|
|
|
err = 0;
|
|
|
|
|
|
2020-07-19 12:00:35 +01:00
|
|
|
/* Undo the forced down state above after completing configuration
|
|
|
|
|
* irrespective of its state on entry, which allows the link to come up.
|
|
|
|
|
*/
|
|
|
|
|
if (mode == MLO_AN_INBAND && p->interface != state->interface &&
|
|
|
|
|
chip->info->ops->port_set_link)
|
|
|
|
|
chip->info->ops->port_set_link(chip, port, LINK_UNFORCED);
|
|
|
|
|
|
|
|
|
|
p->interface = state->interface;
|
|
|
|
|
|
2020-03-14 10:15:43 +00:00
|
|
|
err_unlock:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-05-10 13:17:35 -07:00
|
|
|
|
|
|
|
|
if (err && err != -EOPNOTSUPP)
|
2020-03-14 10:15:38 +00:00
|
|
|
dev_err(ds->dev, "p%d: failed to configure MAC/PCS\n", port);
|
2018-05-10 13:17:35 -07:00
|
|
|
}
|
|
|
|
|
|
2020-02-26 10:23:51 +00:00
|
|
|
static void mv88e6xxx_mac_link_down(struct dsa_switch *ds, int port,
|
|
|
|
|
unsigned int mode,
|
|
|
|
|
phy_interface_t interface)
|
2018-05-10 13:17:35 -07:00
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2020-02-26 10:23:51 +00:00
|
|
|
const struct mv88e6xxx_ops *ops;
|
|
|
|
|
int err = 0;
|
2018-05-10 13:17:35 -07:00
|
|
|
|
2020-02-26 10:23:51 +00:00
|
|
|
ops = chip->info->ops;
|
2018-05-10 13:17:35 -07:00
|
|
|
|
2020-03-14 10:16:03 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2020-04-14 02:34:38 +02:00
|
|
|
if ((!mv88e6xxx_port_ppu_updates(chip, port) ||
|
2020-11-24 17:34:37 +13:00
|
|
|
mode == MLO_AN_FIXED) && ops->port_sync_link)
|
|
|
|
|
err = ops->port_sync_link(chip, port, mode, false);
|
2020-03-14 10:16:03 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-05-10 13:17:35 -07:00
|
|
|
|
2020-03-14 10:16:03 +00:00
|
|
|
if (err)
|
|
|
|
|
dev_err(chip->dev,
|
|
|
|
|
"p%d: failed to force MAC link down\n", port);
|
2018-05-10 13:17:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_mac_link_up(struct dsa_switch *ds, int port,
|
|
|
|
|
unsigned int mode, phy_interface_t interface,
|
2020-02-26 10:23:46 +00:00
|
|
|
struct phy_device *phydev,
|
|
|
|
|
int speed, int duplex,
|
|
|
|
|
bool tx_pause, bool rx_pause)
|
2018-05-10 13:17:35 -07:00
|
|
|
{
|
2020-02-26 10:23:51 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
const struct mv88e6xxx_ops *ops;
|
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
|
|
ops = chip->info->ops;
|
|
|
|
|
|
2020-03-14 10:16:03 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2020-04-14 02:34:38 +02:00
|
|
|
if (!mv88e6xxx_port_ppu_updates(chip, port) || mode == MLO_AN_FIXED) {
|
2020-02-26 10:23:51 +00:00
|
|
|
/* FIXME: for an automedia port, should we force the link
|
|
|
|
|
* down here - what if the link comes up due to "other" media
|
|
|
|
|
* while we're bringing the port up, how is the exclusivity
|
2020-03-14 10:15:43 +00:00
|
|
|
* handled in the Marvell hardware? E.g. port 2 on 88E6390
|
2020-02-26 10:23:51 +00:00
|
|
|
* shared between internal PHY and Serdes.
|
|
|
|
|
*/
|
2020-03-14 10:15:43 +00:00
|
|
|
err = mv88e6xxx_serdes_pcs_link_up(chip, port, mode, speed,
|
|
|
|
|
duplex);
|
|
|
|
|
if (err)
|
|
|
|
|
goto error;
|
|
|
|
|
|
2020-03-14 10:15:53 +00:00
|
|
|
if (ops->port_set_speed_duplex) {
|
|
|
|
|
err = ops->port_set_speed_duplex(chip, port,
|
|
|
|
|
speed, duplex);
|
2020-02-26 10:23:51 +00:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
|
goto error;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-24 17:34:37 +13:00
|
|
|
if (ops->port_sync_link)
|
|
|
|
|
err = ops->port_sync_link(chip, port, mode, true);
|
2020-03-14 10:16:03 +00:00
|
|
|
}
|
2020-02-26 10:23:51 +00:00
|
|
|
error:
|
2020-03-14 10:16:03 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2020-02-26 10:23:51 +00:00
|
|
|
|
2020-03-14 10:16:03 +00:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
|
dev_err(ds->dev,
|
|
|
|
|
"p%d: failed to configure MAC link up\n", port);
|
2018-05-10 13:17:35 -07:00
|
|
|
}
|
|
|
|
|
|
2016-11-21 23:26:58 +01:00
|
|
|
static int mv88e6xxx_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
{
|
2016-11-21 23:26:58 +01:00
|
|
|
if (!chip->info->ops->stats_snapshot)
|
|
|
|
|
return -EOPNOTSUPP;
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
|
2016-11-21 23:26:58 +01:00
|
|
|
return chip->info->ops->stats_snapshot(chip, port);
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
}
|
|
|
|
|
|
2015-04-02 04:06:38 +02:00
|
|
|
static struct mv88e6xxx_hw_stat mv88e6xxx_hw_stats[] = {
|
2016-11-21 23:27:02 +01:00
|
|
|
{ "in_good_octets", 8, 0x00, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_bad_octets", 4, 0x02, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_unicast", 4, 0x04, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_broadcasts", 4, 0x06, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_multicasts", 4, 0x07, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_pause", 4, 0x16, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_undersize", 4, 0x18, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_fragments", 4, 0x19, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_oversize", 4, 0x1a, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_jabber", 4, 0x1b, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_rx_error", 4, 0x1c, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "in_fcs_error", 4, 0x1d, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "out_octets", 8, 0x0e, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "out_unicast", 4, 0x10, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "out_broadcasts", 4, 0x13, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "out_multicasts", 4, 0x12, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "out_pause", 4, 0x15, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "excessive", 4, 0x11, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "collisions", 4, 0x1e, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "deferred", 4, 0x05, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "single", 4, 0x14, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "multiple", 4, 0x17, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "out_fcs_error", 4, 0x03, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "late", 4, 0x1f, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "hist_64bytes", 4, 0x08, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "hist_65_127bytes", 4, 0x09, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "hist_128_255bytes", 4, 0x0a, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "hist_256_511bytes", 4, 0x0b, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "hist_512_1023bytes", 4, 0x0c, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "hist_1024_max_bytes", 4, 0x0d, STATS_TYPE_BANK0, },
|
|
|
|
|
{ "sw_in_discards", 4, 0x10, STATS_TYPE_PORT, },
|
|
|
|
|
{ "sw_in_filtered", 2, 0x12, STATS_TYPE_PORT, },
|
|
|
|
|
{ "sw_out_filtered", 2, 0x13, STATS_TYPE_PORT, },
|
|
|
|
|
{ "in_discards", 4, 0x00, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_filtered", 4, 0x01, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_accepted", 4, 0x02, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_bad_accepted", 4, 0x03, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_good_avb_class_a", 4, 0x04, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_good_avb_class_b", 4, 0x05, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_bad_avb_class_a", 4, 0x06, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_bad_avb_class_b", 4, 0x07, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "tcam_counter_0", 4, 0x08, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "tcam_counter_1", 4, 0x09, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "tcam_counter_2", 4, 0x0a, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "tcam_counter_3", 4, 0x0b, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_da_unknown", 4, 0x0e, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "in_management", 4, 0x0f, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_queue_0", 4, 0x10, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_queue_1", 4, 0x11, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_queue_2", 4, 0x12, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_queue_3", 4, 0x13, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_queue_4", 4, 0x14, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_queue_5", 4, 0x15, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_queue_6", 4, 0x16, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_queue_7", 4, 0x17, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_cut_through", 4, 0x18, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_octets_a", 4, 0x1a, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_octets_b", 4, 0x1b, STATS_TYPE_BANK1, },
|
|
|
|
|
{ "out_management", 4, 0x1f, STATS_TYPE_BANK1, },
|
2015-04-02 04:06:38 +02:00
|
|
|
};
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
static uint64_t _mv88e6xxx_get_ethtool_stat(struct mv88e6xxx_chip *chip,
|
2015-12-23 13:23:17 +01:00
|
|
|
struct mv88e6xxx_hw_stat *s,
|
2016-11-21 23:27:04 +01:00
|
|
|
int port, u16 bank1_select,
|
|
|
|
|
u16 histogram)
|
2015-06-20 18:42:30 +02:00
|
|
|
{
|
|
|
|
|
u32 low;
|
|
|
|
|
u32 high = 0;
|
2016-11-21 23:27:02 +01:00
|
|
|
u16 reg = 0;
|
2016-09-21 01:40:31 +02:00
|
|
|
int err;
|
2015-06-20 18:42:30 +02:00
|
|
|
u64 value;
|
|
|
|
|
|
2015-12-23 13:23:17 +01:00
|
|
|
switch (s->type) {
|
2016-11-21 23:27:02 +01:00
|
|
|
case STATS_TYPE_PORT:
|
2016-09-21 01:40:31 +02:00
|
|
|
err = mv88e6xxx_port_read(chip, port, s->reg, ®);
|
|
|
|
|
if (err)
|
2018-04-27 16:18:58 +08:00
|
|
|
return U64_MAX;
|
2015-06-20 18:42:30 +02:00
|
|
|
|
2016-09-21 01:40:31 +02:00
|
|
|
low = reg;
|
2018-03-01 02:02:31 +01:00
|
|
|
if (s->size == 4) {
|
2016-09-21 01:40:31 +02:00
|
|
|
err = mv88e6xxx_port_read(chip, port, s->reg + 1, ®);
|
|
|
|
|
if (err)
|
2018-04-27 16:18:58 +08:00
|
|
|
return U64_MAX;
|
2019-05-29 07:02:11 +00:00
|
|
|
low |= ((u32)reg) << 16;
|
2015-06-20 18:42:30 +02:00
|
|
|
}
|
2015-12-23 13:23:17 +01:00
|
|
|
break;
|
2016-11-21 23:27:02 +01:00
|
|
|
case STATS_TYPE_BANK1:
|
2016-11-21 23:27:04 +01:00
|
|
|
reg = bank1_select;
|
2020-08-23 17:36:59 -05:00
|
|
|
fallthrough;
|
2016-11-21 23:27:02 +01:00
|
|
|
case STATS_TYPE_BANK0:
|
2016-11-21 23:27:04 +01:00
|
|
|
reg |= s->reg | histogram;
|
2016-11-21 23:27:05 +01:00
|
|
|
mv88e6xxx_g1_stats_read(chip, reg, &low);
|
2018-03-01 02:02:31 +01:00
|
|
|
if (s->size == 8)
|
2016-11-21 23:27:05 +01:00
|
|
|
mv88e6xxx_g1_stats_read(chip, reg + 1, &high);
|
2017-05-11 22:11:29 -05:00
|
|
|
break;
|
|
|
|
|
default:
|
2018-04-27 16:18:58 +08:00
|
|
|
return U64_MAX;
|
2015-06-20 18:42:30 +02:00
|
|
|
}
|
2019-02-28 18:14:03 +01:00
|
|
|
value = (((u64)high) << 32) | low;
|
2015-06-20 18:42:30 +02:00
|
|
|
return value;
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
static int mv88e6xxx_stats_get_strings(struct mv88e6xxx_chip *chip,
|
|
|
|
|
uint8_t *data, int types)
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
{
|
2015-12-23 13:23:17 +01:00
|
|
|
struct mv88e6xxx_hw_stat *stat;
|
|
|
|
|
int i, j;
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
|
2015-12-23 13:23:17 +01:00
|
|
|
for (i = 0, j = 0; i < ARRAY_SIZE(mv88e6xxx_hw_stats); i++) {
|
|
|
|
|
stat = &mv88e6xxx_hw_stats[i];
|
2016-11-21 23:27:02 +01:00
|
|
|
if (stat->type & types) {
|
2015-12-23 13:23:17 +01:00
|
|
|
memcpy(data + j * ETH_GSTRING_LEN, stat->string,
|
|
|
|
|
ETH_GSTRING_LEN);
|
|
|
|
|
j++;
|
|
|
|
|
}
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
}
|
2018-03-01 02:02:29 +01:00
|
|
|
|
|
|
|
|
return j;
|
2015-04-02 04:06:38 +02:00
|
|
|
}
|
|
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
static int mv88e6095_stats_get_strings(struct mv88e6xxx_chip *chip,
|
|
|
|
|
uint8_t *data)
|
2016-11-21 23:27:02 +01:00
|
|
|
{
|
2018-03-01 02:02:29 +01:00
|
|
|
return mv88e6xxx_stats_get_strings(chip, data,
|
|
|
|
|
STATS_TYPE_BANK0 | STATS_TYPE_PORT);
|
2016-11-21 23:27:02 +01:00
|
|
|
}
|
|
|
|
|
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
static int mv88e6250_stats_get_strings(struct mv88e6xxx_chip *chip,
|
|
|
|
|
uint8_t *data)
|
|
|
|
|
{
|
|
|
|
|
return mv88e6xxx_stats_get_strings(chip, data, STATS_TYPE_BANK0);
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
static int mv88e6320_stats_get_strings(struct mv88e6xxx_chip *chip,
|
|
|
|
|
uint8_t *data)
|
2016-11-21 23:27:02 +01:00
|
|
|
{
|
2018-03-01 02:02:29 +01:00
|
|
|
return mv88e6xxx_stats_get_strings(chip, data,
|
|
|
|
|
STATS_TYPE_BANK0 | STATS_TYPE_BANK1);
|
2016-11-21 23:27:02 +01:00
|
|
|
}
|
|
|
|
|
|
2018-03-28 23:50:28 +02:00
|
|
|
static const uint8_t *mv88e6xxx_atu_vtu_stats_strings[] = {
|
|
|
|
|
"atu_member_violation",
|
|
|
|
|
"atu_miss_violation",
|
|
|
|
|
"atu_full_violation",
|
|
|
|
|
"vtu_member_violation",
|
|
|
|
|
"vtu_miss_violation",
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_atu_vtu_get_strings(uint8_t *data)
|
|
|
|
|
{
|
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(mv88e6xxx_atu_vtu_stats_strings); i++)
|
|
|
|
|
strlcpy(data + i * ETH_GSTRING_LEN,
|
|
|
|
|
mv88e6xxx_atu_vtu_stats_strings[i],
|
|
|
|
|
ETH_GSTRING_LEN);
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-21 23:27:02 +01:00
|
|
|
static void mv88e6xxx_get_strings(struct dsa_switch *ds, int port,
|
2018-04-25 12:12:50 -07:00
|
|
|
u32 stringset, uint8_t *data)
|
2015-04-02 04:06:38 +02:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2018-03-01 02:02:29 +01:00
|
|
|
int count = 0;
|
2016-11-21 23:27:02 +01:00
|
|
|
|
2018-04-25 12:12:50 -07:00
|
|
|
if (stringset != ETH_SS_STATS)
|
|
|
|
|
return;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-03-01 02:02:28 +01:00
|
|
|
|
2016-11-21 23:27:02 +01:00
|
|
|
if (chip->info->ops->stats_get_strings)
|
2018-03-01 02:02:29 +01:00
|
|
|
count = chip->info->ops->stats_get_strings(chip, data);
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->serdes_get_strings) {
|
|
|
|
|
data += count * ETH_GSTRING_LEN;
|
2018-03-28 23:50:28 +02:00
|
|
|
count = chip->info->ops->serdes_get_strings(chip, port, data);
|
2018-03-01 02:02:29 +01:00
|
|
|
}
|
2018-03-01 02:02:28 +01:00
|
|
|
|
2018-03-28 23:50:28 +02:00
|
|
|
data += count * ETH_GSTRING_LEN;
|
|
|
|
|
mv88e6xxx_atu_vtu_get_strings(data);
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-11-21 23:27:02 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_stats_get_sset_count(struct mv88e6xxx_chip *chip,
|
|
|
|
|
int types)
|
|
|
|
|
{
|
2015-12-23 13:23:17 +01:00
|
|
|
struct mv88e6xxx_hw_stat *stat;
|
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
|
|
for (i = 0, j = 0; i < ARRAY_SIZE(mv88e6xxx_hw_stats); i++) {
|
|
|
|
|
stat = &mv88e6xxx_hw_stats[i];
|
2016-11-21 23:27:02 +01:00
|
|
|
if (stat->type & types)
|
2015-12-23 13:23:17 +01:00
|
|
|
j++;
|
|
|
|
|
}
|
|
|
|
|
return j;
|
2015-04-02 04:06:38 +02:00
|
|
|
}
|
|
|
|
|
|
2016-11-21 23:27:02 +01:00
|
|
|
static int mv88e6095_stats_get_sset_count(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return mv88e6xxx_stats_get_sset_count(chip, STATS_TYPE_BANK0 |
|
|
|
|
|
STATS_TYPE_PORT);
|
|
|
|
|
}
|
|
|
|
|
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
static int mv88e6250_stats_get_sset_count(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return mv88e6xxx_stats_get_sset_count(chip, STATS_TYPE_BANK0);
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-21 23:27:02 +01:00
|
|
|
static int mv88e6320_stats_get_sset_count(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return mv88e6xxx_stats_get_sset_count(chip, STATS_TYPE_BANK0 |
|
|
|
|
|
STATS_TYPE_BANK1);
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-25 12:12:50 -07:00
|
|
|
static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port, int sset)
|
2016-11-21 23:27:02 +01:00
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2018-03-01 02:02:29 +01:00
|
|
|
int serdes_count = 0;
|
|
|
|
|
int count = 0;
|
2016-11-21 23:27:02 +01:00
|
|
|
|
2018-04-25 12:12:50 -07:00
|
|
|
if (sset != ETH_SS_STATS)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-11-21 23:27:02 +01:00
|
|
|
if (chip->info->ops->stats_get_sset_count)
|
2018-03-01 02:02:29 +01:00
|
|
|
count = chip->info->ops->stats_get_sset_count(chip);
|
|
|
|
|
if (count < 0)
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->serdes_get_sset_count)
|
|
|
|
|
serdes_count = chip->info->ops->serdes_get_sset_count(chip,
|
|
|
|
|
port);
|
2018-03-28 23:50:28 +02:00
|
|
|
if (serdes_count < 0) {
|
2018-03-01 02:02:29 +01:00
|
|
|
count = serdes_count;
|
2018-03-28 23:50:28 +02:00
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
count += serdes_count;
|
|
|
|
|
count += ARRAY_SIZE(mv88e6xxx_atu_vtu_stats_strings);
|
|
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
out:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-11-21 23:27:02 +01:00
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
return count;
|
2016-11-21 23:27:02 +01:00
|
|
|
}
|
|
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
static int mv88e6xxx_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint64_t *data, int types,
|
|
|
|
|
u16 bank1_select, u16 histogram)
|
2016-11-21 23:27:03 +01:00
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_hw_stat *stat;
|
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
|
|
for (i = 0, j = 0; i < ARRAY_SIZE(mv88e6xxx_hw_stats); i++) {
|
|
|
|
|
stat = &mv88e6xxx_hw_stats[i];
|
|
|
|
|
if (stat->type & types) {
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-11-21 23:27:04 +01:00
|
|
|
data[j] = _mv88e6xxx_get_ethtool_stat(chip, stat, port,
|
|
|
|
|
bank1_select,
|
|
|
|
|
histogram);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-15 14:38:34 +01:00
|
|
|
|
2016-11-21 23:27:03 +01:00
|
|
|
j++;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-03-01 02:02:29 +01:00
|
|
|
return j;
|
2016-11-21 23:27:03 +01:00
|
|
|
}
|
|
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
static int mv88e6095_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint64_t *data)
|
2016-11-21 23:27:03 +01:00
|
|
|
{
|
|
|
|
|
return mv88e6xxx_stats_get_stats(chip, port, data,
|
2016-11-21 23:27:04 +01:00
|
|
|
STATS_TYPE_BANK0 | STATS_TYPE_PORT,
|
2017-06-15 12:14:05 -04:00
|
|
|
0, MV88E6XXX_G1_STATS_OP_HIST_RX_TX);
|
2016-11-21 23:27:03 +01:00
|
|
|
}
|
|
|
|
|
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
static int mv88e6250_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint64_t *data)
|
|
|
|
|
{
|
|
|
|
|
return mv88e6xxx_stats_get_stats(chip, port, data, STATS_TYPE_BANK0,
|
|
|
|
|
0, MV88E6XXX_G1_STATS_OP_HIST_RX_TX);
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
static int mv88e6320_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint64_t *data)
|
2016-11-21 23:27:03 +01:00
|
|
|
{
|
|
|
|
|
return mv88e6xxx_stats_get_stats(chip, port, data,
|
2016-11-21 23:27:04 +01:00
|
|
|
STATS_TYPE_BANK0 | STATS_TYPE_BANK1,
|
2017-06-15 12:14:05 -04:00
|
|
|
MV88E6XXX_G1_STATS_OP_BANK_1_BIT_9,
|
|
|
|
|
MV88E6XXX_G1_STATS_OP_HIST_RX_TX);
|
2016-11-21 23:27:04 +01:00
|
|
|
}
|
|
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
static int mv88e6390_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint64_t *data)
|
2016-11-21 23:27:04 +01:00
|
|
|
{
|
|
|
|
|
return mv88e6xxx_stats_get_stats(chip, port, data,
|
|
|
|
|
STATS_TYPE_BANK0 | STATS_TYPE_BANK1,
|
2017-06-15 12:14:05 -04:00
|
|
|
MV88E6XXX_G1_STATS_OP_BANK_1_BIT_10,
|
|
|
|
|
0);
|
2016-11-21 23:27:03 +01:00
|
|
|
}
|
|
|
|
|
|
2018-03-28 23:50:28 +02:00
|
|
|
static void mv88e6xxx_atu_vtu_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint64_t *data)
|
|
|
|
|
{
|
|
|
|
|
*data++ = chip->ports[port].atu_member_violation;
|
|
|
|
|
*data++ = chip->ports[port].atu_miss_violation;
|
|
|
|
|
*data++ = chip->ports[port].atu_full_violation;
|
|
|
|
|
*data++ = chip->ports[port].vtu_member_violation;
|
|
|
|
|
*data++ = chip->ports[port].vtu_miss_violation;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-21 23:27:03 +01:00
|
|
|
static void mv88e6xxx_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint64_t *data)
|
|
|
|
|
{
|
2018-03-01 02:02:29 +01:00
|
|
|
int count = 0;
|
|
|
|
|
|
2016-11-21 23:27:03 +01:00
|
|
|
if (chip->info->ops->stats_get_stats)
|
2018-03-01 02:02:29 +01:00
|
|
|
count = chip->info->ops->stats_get_stats(chip, port, data);
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-03-01 02:02:29 +01:00
|
|
|
if (chip->info->ops->serdes_get_stats) {
|
|
|
|
|
data += count;
|
2018-03-28 23:50:28 +02:00
|
|
|
count = chip->info->ops->serdes_get_stats(chip, port, data);
|
2018-03-01 02:02:29 +01:00
|
|
|
}
|
2018-03-28 23:50:28 +02:00
|
|
|
data += count;
|
|
|
|
|
mv88e6xxx_atu_vtu_get_stats(chip, port, data);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-11-21 23:27:03 +01:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds, int port,
|
|
|
|
|
uint64_t *data)
|
2015-04-02 04:06:38 +02:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2015-12-23 13:23:17 +01:00
|
|
|
int ret;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2015-12-23 13:23:17 +01:00
|
|
|
|
2016-11-21 23:26:58 +01:00
|
|
|
ret = mv88e6xxx_stats_snapshot(chip, port);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-15 14:38:34 +01:00
|
|
|
|
|
|
|
|
if (ret < 0)
|
2015-12-23 13:23:17 +01:00
|
|
|
return;
|
2016-11-21 23:27:03 +01:00
|
|
|
|
|
|
|
|
mv88e6xxx_get_stats(chip, port, data);
|
2015-12-23 13:23:17 +01:00
|
|
|
|
2015-04-02 04:06:38 +02:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static int mv88e6xxx_get_regs_len(struct dsa_switch *ds, int port)
|
2014-10-29 10:45:05 -07:00
|
|
|
{
|
2020-02-16 18:54:13 +01:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int len;
|
|
|
|
|
|
|
|
|
|
len = 32 * sizeof(u16);
|
|
|
|
|
if (chip->info->ops->serdes_get_regs_len)
|
|
|
|
|
len += chip->info->ops->serdes_get_regs_len(chip, port);
|
|
|
|
|
|
|
|
|
|
return len;
|
2014-10-29 10:45:05 -07:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static void mv88e6xxx_get_regs(struct dsa_switch *ds, int port,
|
|
|
|
|
struct ethtool_regs *regs, void *_p)
|
2014-10-29 10:45:05 -07:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-09-21 01:40:31 +02:00
|
|
|
int err;
|
|
|
|
|
u16 reg;
|
2014-10-29 10:45:05 -07:00
|
|
|
u16 *p = _p;
|
|
|
|
|
int i;
|
|
|
|
|
|
2018-12-17 16:05:21 -05:00
|
|
|
regs->version = chip->info->prod_num;
|
2014-10-29 10:45:05 -07:00
|
|
|
|
|
|
|
|
memset(p, 0xff, 32 * sizeof(u16));
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-05-09 13:22:45 -04:00
|
|
|
|
2014-10-29 10:45:05 -07:00
|
|
|
for (i = 0; i < 32; i++) {
|
|
|
|
|
|
2016-09-21 01:40:31 +02:00
|
|
|
err = mv88e6xxx_port_read(chip, port, i, ®);
|
|
|
|
|
if (!err)
|
|
|
|
|
p[i] = reg;
|
2014-10-29 10:45:05 -07:00
|
|
|
}
|
2016-05-09 13:22:45 -04:00
|
|
|
|
2020-02-16 18:54:13 +01:00
|
|
|
if (chip->info->ops->serdes_get_regs)
|
|
|
|
|
chip->info->ops->serdes_get_regs(chip, port, &p[i]);
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2014-10-29 10:45:05 -07:00
|
|
|
}
|
|
|
|
|
|
2017-08-01 16:32:41 -04:00
|
|
|
static int mv88e6xxx_get_mac_eee(struct dsa_switch *ds, int port,
|
|
|
|
|
struct ethtool_eee *e)
|
2017-07-17 13:03:45 -04:00
|
|
|
{
|
2017-08-01 16:32:40 -04:00
|
|
|
/* Nothing to do on the port's MAC */
|
|
|
|
|
return 0;
|
2015-03-06 22:23:51 -08:00
|
|
|
}
|
|
|
|
|
|
2017-08-01 16:32:41 -04:00
|
|
|
static int mv88e6xxx_set_mac_eee(struct dsa_switch *ds, int port,
|
|
|
|
|
struct ethtool_eee *e)
|
2015-03-06 22:23:51 -08:00
|
|
|
{
|
2017-08-01 16:32:40 -04:00
|
|
|
/* Nothing to do on the port's MAC */
|
|
|
|
|
return 0;
|
2015-03-06 22:23:51 -08:00
|
|
|
}
|
|
|
|
|
|
2019-10-21 16:51:26 -04:00
|
|
|
/* Mask of the local ports allowed to receive frames from a given fabric port */
|
2017-03-30 17:37:11 -04:00
|
|
|
static u16 mv88e6xxx_port_vlan(struct mv88e6xxx_chip *chip, int dev, int port)
|
2015-03-26 18:36:35 -07:00
|
|
|
{
|
2019-10-21 16:51:26 -04:00
|
|
|
struct dsa_switch *ds = chip->ds;
|
|
|
|
|
struct dsa_switch_tree *dst = ds->dst;
|
2017-03-30 17:37:11 -04:00
|
|
|
struct net_device *br;
|
2019-10-21 16:51:26 -04:00
|
|
|
struct dsa_port *dp;
|
|
|
|
|
bool found = false;
|
2017-03-30 17:37:11 -04:00
|
|
|
u16 pvlan;
|
2016-02-26 13:16:06 -05:00
|
|
|
|
2019-10-21 16:51:26 -04:00
|
|
|
list_for_each_entry(dp, &dst->ports, list) {
|
|
|
|
|
if (dp->ds->index == dev && dp->index == port) {
|
|
|
|
|
found = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-03-30 17:37:11 -04:00
|
|
|
|
|
|
|
|
/* Prevent frames from unknown switch or port */
|
2019-10-21 16:51:26 -04:00
|
|
|
if (!found)
|
2017-03-30 17:37:11 -04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* Frames from DSA links and CPU ports can egress any local port */
|
2019-10-21 16:51:26 -04:00
|
|
|
if (dp->type == DSA_PORT_TYPE_CPU || dp->type == DSA_PORT_TYPE_DSA)
|
2017-03-30 17:37:11 -04:00
|
|
|
return mv88e6xxx_port_mask(chip);
|
|
|
|
|
|
2019-10-21 16:51:26 -04:00
|
|
|
br = dp->bridge_dev;
|
2017-03-30 17:37:11 -04:00
|
|
|
pvlan = 0;
|
|
|
|
|
|
|
|
|
|
/* Frames from user ports can egress any local DSA links and CPU ports,
|
|
|
|
|
* as well as any local member of their bridge group.
|
|
|
|
|
*/
|
2019-10-21 16:51:26 -04:00
|
|
|
list_for_each_entry(dp, &dst->ports, list)
|
|
|
|
|
if (dp->ds == ds &&
|
|
|
|
|
(dp->type == DSA_PORT_TYPE_CPU ||
|
|
|
|
|
dp->type == DSA_PORT_TYPE_DSA ||
|
|
|
|
|
(br && dp->bridge_dev == br)))
|
|
|
|
|
pvlan |= BIT(dp->index);
|
2017-03-30 17:37:11 -04:00
|
|
|
|
|
|
|
|
return pvlan;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-30 17:37:12 -04:00
|
|
|
static int mv88e6xxx_port_vlan_map(struct mv88e6xxx_chip *chip, int port)
|
2017-03-30 17:37:11 -04:00
|
|
|
{
|
|
|
|
|
u16 output_ports = mv88e6xxx_port_vlan(chip, chip->ds->index, port);
|
2016-02-26 13:16:06 -05:00
|
|
|
|
|
|
|
|
/* prevent frames from going back out of the port they came in on */
|
|
|
|
|
output_ports &= ~BIT(port);
|
2015-03-26 18:36:35 -07:00
|
|
|
|
2016-11-04 03:23:28 +01:00
|
|
|
return mv88e6xxx_port_set_vlan_map(chip, port, output_ports);
|
2015-03-26 18:36:35 -07:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static void mv88e6xxx_port_stp_state_set(struct dsa_switch *ds, int port,
|
|
|
|
|
u8 state)
|
2015-03-26 18:36:35 -07:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-05-13 20:38:23 -04:00
|
|
|
int err;
|
2015-03-26 18:36:35 -07:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-06-08 18:34:10 -04:00
|
|
|
err = mv88e6xxx_port_set_state(chip, port, state);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-05-13 20:38:23 -04:00
|
|
|
|
|
|
|
|
if (err)
|
2017-06-08 18:34:08 -04:00
|
|
|
dev_err(ds->dev, "p%d: failed to update state\n", port);
|
2015-03-26 18:36:35 -07:00
|
|
|
}
|
|
|
|
|
|
2018-05-11 17:16:35 -04:00
|
|
|
static int mv88e6xxx_pri_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->ieee_pri_map) {
|
|
|
|
|
err = chip->info->ops->ieee_pri_map(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->ip_pri_map) {
|
|
|
|
|
err = chip->info->ops->ip_pri_map(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-26 21:56:45 -04:00
|
|
|
static int mv88e6xxx_devmap_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
2019-10-30 22:09:13 -04:00
|
|
|
struct dsa_switch *ds = chip->ds;
|
2018-04-26 21:56:45 -04:00
|
|
|
int target, port;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!chip->info->global2_addr)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* Initialize the routing port to the 32 possible target devices */
|
|
|
|
|
for (target = 0; target < 32; target++) {
|
2019-10-30 22:09:13 -04:00
|
|
|
port = dsa_routing_port(ds, target);
|
|
|
|
|
if (port == ds->num_ports)
|
|
|
|
|
port = 0x1f;
|
2018-04-26 21:56:45 -04:00
|
|
|
|
|
|
|
|
err = mv88e6xxx_g2_device_mapping_write(chip, target, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-09 11:38:49 -04:00
|
|
|
if (chip->info->ops->set_cascade_port) {
|
|
|
|
|
port = MV88E6XXX_CASCADE_PORT_MULTIPLE;
|
|
|
|
|
err = chip->info->ops->set_cascade_port(chip, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-09 11:38:50 -04:00
|
|
|
err = mv88e6xxx_g1_set_device_number(chip, chip->ds->index);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2018-04-26 21:56:45 -04:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-26 21:56:44 -04:00
|
|
|
static int mv88e6xxx_trunk_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
/* Clear all trunk masks and mapping */
|
|
|
|
|
if (chip->info->global2_addr)
|
|
|
|
|
return mv88e6xxx_g2_trunk_clear(chip);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-09 11:38:51 -04:00
|
|
|
static int mv88e6xxx_rmu_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
if (chip->info->ops->rmu_disable)
|
|
|
|
|
return chip->info->ops->rmu_disable(chip);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-17 13:03:43 -04:00
|
|
|
static int mv88e6xxx_pot_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
if (chip->info->ops->pot_clear)
|
|
|
|
|
return chip->info->ops->pot_clear(chip);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-17 13:03:41 -04:00
|
|
|
static int mv88e6xxx_rsvd2cpu_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
if (chip->info->ops->mgmt_rsvd2cpu)
|
|
|
|
|
return chip->info->ops->mgmt_rsvd2cpu(chip);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-11 16:12:49 -05:00
|
|
|
static int mv88e6xxx_atu_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
2017-03-11 16:12:51 -05:00
|
|
|
int err;
|
|
|
|
|
|
2017-03-11 16:12:54 -05:00
|
|
|
err = mv88e6xxx_g1_atu_flush(chip, 0, true);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2020-12-10 12:06:44 +01:00
|
|
|
/* The chips that have a "learn2all" bit in Global1, ATU
|
|
|
|
|
* Control are precisely those whose port registers have a
|
|
|
|
|
* Message Port bit in Port Control 1 and hence implement
|
|
|
|
|
* ->port_setup_message_port.
|
|
|
|
|
*/
|
|
|
|
|
if (chip->info->ops->port_setup_message_port) {
|
|
|
|
|
err = mv88e6xxx_g1_atu_set_learn2all(chip, true);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
2017-03-11 16:12:51 -05:00
|
|
|
|
2017-03-11 16:12:49 -05:00
|
|
|
return mv88e6xxx_g1_atu_set_age_time(chip, 300000);
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-19 10:55:36 -04:00
|
|
|
static int mv88e6xxx_irl_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
int port;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!chip->info->ops->irl_init_all)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
for (port = 0; port < mv88e6xxx_num_ports(chip); port++) {
|
|
|
|
|
/* Disable ingress rate limiting by resetting all per port
|
|
|
|
|
* ingress rate limit resources to their initial state.
|
|
|
|
|
*/
|
|
|
|
|
err = chip->info->ops->irl_init_all(chip, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-13 14:18:05 -04:00
|
|
|
static int mv88e6xxx_mac_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
if (chip->info->ops->set_switch_mac) {
|
|
|
|
|
u8 addr[ETH_ALEN];
|
|
|
|
|
|
|
|
|
|
eth_random_addr(addr);
|
|
|
|
|
|
|
|
|
|
return chip->info->ops->set_switch_mac(chip, addr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-30 17:37:09 -04:00
|
|
|
static int mv88e6xxx_pvt_map(struct mv88e6xxx_chip *chip, int dev, int port)
|
|
|
|
|
{
|
2021-01-13 09:42:54 +01:00
|
|
|
struct dsa_switch_tree *dst = chip->ds->dst;
|
|
|
|
|
struct dsa_switch *ds;
|
|
|
|
|
struct dsa_port *dp;
|
2017-03-30 17:37:09 -04:00
|
|
|
u16 pvlan = 0;
|
|
|
|
|
|
|
|
|
|
if (!mv88e6xxx_has_pvt(chip))
|
2019-10-21 16:51:25 -04:00
|
|
|
return 0;
|
2017-03-30 17:37:09 -04:00
|
|
|
|
|
|
|
|
/* Skip the local source device, which uses in-chip port VLAN */
|
2021-01-13 09:42:54 +01:00
|
|
|
if (dev != chip->ds->index) {
|
2017-03-30 17:37:15 -04:00
|
|
|
pvlan = mv88e6xxx_port_vlan(chip, dev, port);
|
2017-03-30 17:37:09 -04:00
|
|
|
|
2021-01-13 09:42:54 +01:00
|
|
|
ds = dsa_switch_find(dst->index, dev);
|
|
|
|
|
dp = ds ? dsa_to_port(ds, port) : NULL;
|
|
|
|
|
if (dp && dp->lag_dev) {
|
|
|
|
|
/* As the PVT is used to limit flooding of
|
|
|
|
|
* FORWARD frames, which use the LAG ID as the
|
|
|
|
|
* source port, we must translate dev/port to
|
|
|
|
|
* the special "LAG device" in the PVT, using
|
|
|
|
|
* the LAG ID as the port number.
|
|
|
|
|
*/
|
|
|
|
|
dev = MV88E6XXX_G2_PVT_ADRR_DEV_TRUNK;
|
|
|
|
|
port = dsa_lag_id(dst, dp->lag_dev);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-30 17:37:09 -04:00
|
|
|
return mv88e6xxx_g2_pvt_write(chip, dev, port, pvlan);
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-30 17:37:08 -04:00
|
|
|
static int mv88e6xxx_pvt_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
2017-03-30 17:37:09 -04:00
|
|
|
int dev, port;
|
|
|
|
|
int err;
|
|
|
|
|
|
2017-03-30 17:37:08 -04:00
|
|
|
if (!mv88e6xxx_has_pvt(chip))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* Clear 5 Bit Port for usage with Marvell Link Street devices:
|
|
|
|
|
* use 4 bits for the Src_Port/Src_Trunk and 5 bits for the Src_Dev.
|
|
|
|
|
*/
|
2017-03-30 17:37:09 -04:00
|
|
|
err = mv88e6xxx_g2_misc_4_bit_port(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
for (dev = 0; dev < MV88E6XXX_MAX_PVT_SWITCHES; ++dev) {
|
|
|
|
|
for (port = 0; port < MV88E6XXX_MAX_PVT_PORTS; ++port) {
|
|
|
|
|
err = mv88e6xxx_pvt_map(chip, dev, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
2017-03-30 17:37:08 -04:00
|
|
|
}
|
|
|
|
|
|
2016-09-22 16:49:24 -04:00
|
|
|
static void mv88e6xxx_port_fast_age(struct dsa_switch *ds, int port)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err;
|
|
|
|
|
|
2021-03-18 20:25:34 +01:00
|
|
|
if (dsa_to_port(ds, port)->lag_dev)
|
|
|
|
|
/* Hardware is incapable of fast-aging a LAG through a
|
|
|
|
|
* regular ATU move operation. Until we have something
|
|
|
|
|
* more fancy in place this is a no-op.
|
|
|
|
|
*/
|
|
|
|
|
return;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-03-11 16:12:55 -05:00
|
|
|
err = mv88e6xxx_g1_atu_remove(chip, 0, port, false);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-09-22 16:49:24 -04:00
|
|
|
|
|
|
|
|
if (err)
|
2017-06-08 18:34:08 -04:00
|
|
|
dev_err(ds->dev, "p%d: failed to flush ATU\n", port);
|
2016-09-22 16:49:24 -04:00
|
|
|
}
|
|
|
|
|
|
2017-05-01 14:05:13 -04:00
|
|
|
static int mv88e6xxx_vtu_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
2020-11-10 19:57:20 +01:00
|
|
|
if (!mv88e6xxx_max_vid(chip))
|
2017-05-01 14:05:13 -04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
return mv88e6xxx_g1_vtu_flush(chip);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-18 20:25:36 +01:00
|
|
|
static int mv88e6xxx_vtu_get(struct mv88e6xxx_chip *chip, u16 vid,
|
|
|
|
|
struct mv88e6xxx_vtu_entry *entry)
|
2017-05-01 14:05:22 -04:00
|
|
|
{
|
2021-03-18 20:25:36 +01:00
|
|
|
int err;
|
|
|
|
|
|
2017-05-01 14:05:22 -04:00
|
|
|
if (!chip->info->ops->vtu_getnext)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2021-03-18 20:25:36 +01:00
|
|
|
entry->vid = vid ? vid - 1 : mv88e6xxx_max_vid(chip);
|
|
|
|
|
entry->valid = false;
|
|
|
|
|
|
|
|
|
|
err = chip->info->ops->vtu_getnext(chip, entry);
|
|
|
|
|
|
|
|
|
|
if (entry->vid != vid)
|
|
|
|
|
entry->valid = false;
|
|
|
|
|
|
|
|
|
|
return err;
|
2017-05-01 14:05:22 -04:00
|
|
|
}
|
|
|
|
|
|
2021-03-18 20:25:35 +01:00
|
|
|
static int mv88e6xxx_vtu_walk(struct mv88e6xxx_chip *chip,
|
|
|
|
|
int (*cb)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
const struct mv88e6xxx_vtu_entry *entry,
|
|
|
|
|
void *priv),
|
|
|
|
|
void *priv)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_vtu_entry entry = {
|
|
|
|
|
.vid = mv88e6xxx_max_vid(chip),
|
|
|
|
|
.valid = false,
|
|
|
|
|
};
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!chip->info->ops->vtu_getnext)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
do {
|
|
|
|
|
err = chip->info->ops->vtu_getnext(chip, &entry);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
if (!entry.valid)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
err = cb(chip, &entry, priv);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
} while (entry.vid < mv88e6xxx_max_vid(chip));
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-01 14:05:23 -04:00
|
|
|
static int mv88e6xxx_vtu_loadpurge(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mv88e6xxx_vtu_entry *entry)
|
|
|
|
|
{
|
|
|
|
|
if (!chip->info->ops->vtu_loadpurge)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
return chip->info->ops->vtu_loadpurge(chip, entry);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-18 20:25:35 +01:00
|
|
|
static int mv88e6xxx_fid_map_vlan(struct mv88e6xxx_chip *chip,
|
|
|
|
|
const struct mv88e6xxx_vtu_entry *entry,
|
|
|
|
|
void *_fid_bitmap)
|
|
|
|
|
{
|
|
|
|
|
unsigned long *fid_bitmap = _fid_bitmap;
|
|
|
|
|
|
|
|
|
|
set_bit(entry->fid, fid_bitmap);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-18 21:11:06 +02:00
|
|
|
int mv88e6xxx_fid_map(struct mv88e6xxx_chip *chip, unsigned long *fid_bitmap)
|
2016-02-26 13:16:03 -05:00
|
|
|
{
|
2016-02-26 13:16:04 -05:00
|
|
|
int i, err;
|
2020-09-18 21:11:06 +02:00
|
|
|
u16 fid;
|
2016-02-26 13:16:03 -05:00
|
|
|
|
|
|
|
|
bitmap_zero(fid_bitmap, MV88E6XXX_N_FID);
|
|
|
|
|
|
2016-02-26 13:16:04 -05:00
|
|
|
/* Set every FID bit used by the (un)bridged ports */
|
2016-09-29 12:21:57 -04:00
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i) {
|
2020-09-18 21:11:06 +02:00
|
|
|
err = mv88e6xxx_port_get_fid(chip, i, &fid);
|
2016-02-26 13:16:04 -05:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2020-09-18 21:11:06 +02:00
|
|
|
set_bit(fid, fid_bitmap);
|
2016-02-26 13:16:04 -05:00
|
|
|
}
|
|
|
|
|
|
2016-02-26 13:16:03 -05:00
|
|
|
/* Set every FID bit used by the VLAN entries */
|
2021-03-18 20:25:35 +01:00
|
|
|
return mv88e6xxx_vtu_walk(chip, mv88e6xxx_fid_map_vlan, fid_bitmap);
|
2020-09-18 21:11:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_atu_new(struct mv88e6xxx_chip *chip, u16 *fid)
|
|
|
|
|
{
|
|
|
|
|
DECLARE_BITMAP(fid_bitmap, MV88E6XXX_N_FID);
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_fid_map(chip, fid_bitmap);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2016-02-26 13:16:03 -05:00
|
|
|
/* The reset value 0x000 is used to indicate that multiple address
|
|
|
|
|
* databases are not needed. Return the next positive available.
|
|
|
|
|
*/
|
|
|
|
|
*fid = find_next_zero_bit(fid_bitmap, MV88E6XXX_N_FID, 1);
|
2016-06-21 12:28:20 -04:00
|
|
|
if (unlikely(*fid >= mv88e6xxx_num_databases(chip)))
|
2016-02-26 13:16:03 -05:00
|
|
|
return -ENOSPC;
|
|
|
|
|
|
|
|
|
|
/* Clear the database */
|
2017-03-11 16:12:54 -05:00
|
|
|
return mv88e6xxx_g1_atu_flush(chip, *fid, true);
|
2016-02-26 13:16:03 -05:00
|
|
|
}
|
|
|
|
|
|
2016-02-12 12:09:40 -05:00
|
|
|
static int mv88e6xxx_port_check_hw_vlan(struct dsa_switch *ds, int port,
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
u16 vid)
|
2016-02-12 12:09:40 -05:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2019-08-01 14:36:34 -04:00
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
2016-02-12 12:09:40 -05:00
|
|
|
int i, err;
|
|
|
|
|
|
net: dsa: mv88e6xxx: deny vid 0 on the CPU port and DSA links too
mv88e6xxx apparently has a problem offloading VID 0, which the 8021q
module tries to install as part of commit ad1afb003939 ("vlan_dev: VLAN
0 should be treated as "no vlan tag" (802.1p packet)"). That mv88e6xxx
restriction seems to have been introduced by the "VTU GetNext VID-1
trick to retrieve a single entry" - see commit 2fb5ef09de7c ("net: dsa:
mv88e6xxx: extract single VLAN retrieval").
There is one more problem. The mv88e6xxx CPU port and DSA links do not
report properly in the prepare phase what are the VLANs that they can
offload. They'll say they can offload everything:
mv88e6xxx_port_vlan_prepare
-> mv88e6xxx_port_check_hw_vlan:
/* DSA and CPU ports have to be members of multiple vlans */
if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port))
return 0;
Except that if you actually try to commit to it, they'll error out and
print this message:
[ 32.802438] mv88e6085 d0032004.mdio-mii:12: p9: failed to add VLAN 0t
which comes from:
mv88e6xxx_port_vlan_add
-> mv88e6xxx_port_vlan_join:
if (!vid)
return -EOPNOTSUPP;
What prevents this condition from triggering in real life? The fact that
when a DSA_NOTIFIER_VLAN_ADD is emitted, it never targets a DSA link
directly. Instead, the notifier will always target either a user port or
a CPU port. DSA links just happen to get dragged in by:
static bool dsa_switch_vlan_match(struct dsa_switch *ds, int port,
struct dsa_notifier_vlan_info *info)
{
...
if (dsa_is_dsa_port(ds, port))
return true;
...
}
So for every DSA VLAN notifier, during the prepare phase, it will just
so happen that there will be somebody to say "no, don't do that".
This will become a problem when the switchdev prepare/commit transactional
model goes away. Every port needs to think on its own. DSA links can no
longer bluff and rely on the fact that the prepare phase will not go
through to the end, because there will be no prepare phase any longer.
Fix this issue before it becomes a problem, by having the "vid == 0"
check earlier than the check whether we are a CPU port / DSA link or not.
Also, the "vid == 0" check becomes unnecessary in the .port_vlan_add
callback, so we can remove it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:47 +02:00
|
|
|
if (!vid)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2017-09-25 23:32:20 +02:00
|
|
|
/* DSA and CPU ports have to be members of multiple vlans */
|
|
|
|
|
if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port))
|
|
|
|
|
return 0;
|
|
|
|
|
|
2021-03-18 20:25:36 +01:00
|
|
|
err = mv88e6xxx_vtu_get(chip, vid, &vlan);
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2016-02-12 12:09:40 -05:00
|
|
|
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
if (!vlan.valid)
|
|
|
|
|
return 0;
|
2016-02-12 12:09:40 -05:00
|
|
|
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i) {
|
|
|
|
|
if (dsa_is_dsa_port(ds, i) || dsa_is_cpu_port(ds, i))
|
|
|
|
|
continue;
|
2016-02-12 12:09:40 -05:00
|
|
|
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
if (!dsa_to_port(ds, i)->slave)
|
|
|
|
|
continue;
|
2016-12-11 21:07:19 +01:00
|
|
|
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
if (vlan.member[i] ==
|
|
|
|
|
MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER)
|
|
|
|
|
continue;
|
2016-02-12 12:09:40 -05:00
|
|
|
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
if (dsa_to_port(ds, i)->bridge_dev ==
|
|
|
|
|
dsa_to_port(ds, port)->bridge_dev)
|
|
|
|
|
break; /* same bridge, check next VLAN */
|
2016-02-12 12:09:40 -05:00
|
|
|
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
if (!dsa_to_port(ds, i)->bridge_dev)
|
|
|
|
|
continue;
|
2016-12-11 21:07:19 +01:00
|
|
|
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
dev_err(ds->dev, "p%d: hw VLAN %d already used by port %d in %s\n",
|
|
|
|
|
port, vlan.vid, i,
|
|
|
|
|
netdev_name(dsa_to_port(ds, i)->bridge_dev));
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
}
|
2016-02-12 12:09:40 -05:00
|
|
|
|
2019-08-01 14:36:33 -04:00
|
|
|
return 0;
|
2016-02-12 12:09:40 -05:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static int mv88e6xxx_port_vlan_filtering(struct dsa_switch *ds, int port,
|
2021-02-13 22:43:19 +02:00
|
|
|
bool vlan_filtering,
|
|
|
|
|
struct netlink_ext_ack *extack)
|
2016-02-26 13:16:08 -05:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2017-06-12 12:37:41 -04:00
|
|
|
u16 mode = vlan_filtering ? MV88E6XXX_PORT_CTL2_8021Q_MODE_SECURE :
|
|
|
|
|
MV88E6XXX_PORT_CTL2_8021Q_MODE_DISABLED;
|
2016-09-21 01:40:31 +02:00
|
|
|
int err;
|
2016-02-26 13:16:08 -05:00
|
|
|
|
net: switchdev: remove the transaction structure from port attributes
Since the introduction of the switchdev API, port attributes were
transmitted to drivers for offloading using a two-step transactional
model, with a prepare phase that was supposed to catch all errors, and a
commit phase that was supposed to never fail.
Some classes of failures can never be avoided, like hardware access, or
memory allocation. In the latter case, merely attempting to move the
memory allocation to the preparation phase makes it impossible to avoid
memory leaks, since commit 91cf8eceffc1 ("switchdev: Remove unused
transaction item queue") which has removed the unused mechanism of
passing on the allocated memory between one phase and another.
It is time we admit that separating the preparation from the commit
phase is something that is best left for the driver to decide, and not
something that should be baked into the API, especially since there are
no switchdev callers that depend on this.
This patch removes the struct switchdev_trans member from switchdev port
attribute notifier structures, and converts drivers to not look at this
member.
In part, this patch contains a revert of my previous commit 2e554a7a5d8a
("net: dsa: propagate switchdev vlan_filtering prepare phase to
drivers").
For the most part, the conversion was trivial except for:
- Rocker's world implementation based on Broadcom OF-DPA had an odd
implementation of ofdpa_port_attr_bridge_flags_set. The conversion was
done mechanically, by pasting the implementation twice, then only
keeping the code that would get executed during prepare phase on top,
then only keeping the code that gets executed during the commit phase
on bottom, then simplifying the resulting code until this was obtained.
- DSA's offloading of STP state, bridge flags, VLAN filtering and
multicast router could be converted right away. But the ageing time
could not, so a shim was introduced and this was left for a further
commit.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> # RTL8366RB
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:50 +02:00
|
|
|
if (!mv88e6xxx_max_vid(chip))
|
|
|
|
|
return -EOPNOTSUPP;
|
2016-05-09 13:22:47 -04:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-11-04 03:23:31 +01:00
|
|
|
err = mv88e6xxx_port_set_8021q_mode(chip, port, mode);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-02-26 13:16:08 -05:00
|
|
|
|
2016-09-21 01:40:31 +02:00
|
|
|
return err;
|
2016-02-26 13:16:08 -05:00
|
|
|
}
|
|
|
|
|
|
2016-06-20 13:13:58 -04:00
|
|
|
static int
|
|
|
|
|
mv88e6xxx_port_vlan_prepare(struct dsa_switch *ds, int port,
|
2017-11-30 11:23:57 -05:00
|
|
|
const struct switchdev_obj_port_vlan *vlan)
|
2015-11-01 12:33:55 -05:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-02-12 12:09:40 -05:00
|
|
|
int err;
|
|
|
|
|
|
2020-11-10 19:57:20 +01:00
|
|
|
if (!mv88e6xxx_max_vid(chip))
|
2016-05-09 13:22:47 -04:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2016-02-12 12:09:40 -05:00
|
|
|
/* If the requested port doesn't belong to the same bridge as the VLAN
|
|
|
|
|
* members, do not support it (yet) and fallback to software VLAN.
|
|
|
|
|
*/
|
2019-08-01 14:36:33 -04:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
err = mv88e6xxx_port_check_hw_vlan(ds, port, vlan->vid);
|
2019-08-01 14:36:33 -04:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-02-12 12:09:40 -05:00
|
|
|
|
2019-08-01 14:36:33 -04:00
|
|
|
return err;
|
2015-11-01 12:33:55 -05:00
|
|
|
}
|
|
|
|
|
|
2017-11-09 22:29:55 +01:00
|
|
|
static int mv88e6xxx_port_db_load_purge(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
const unsigned char *addr, u16 vid,
|
|
|
|
|
u8 state)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_atu_entry entry;
|
2019-08-01 14:36:35 -04:00
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
|
|
|
|
u16 fid;
|
2017-11-09 22:29:55 +01:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/* Null VLAN ID corresponds to the port private database */
|
2019-08-01 14:36:35 -04:00
|
|
|
if (vid == 0) {
|
|
|
|
|
err = mv88e6xxx_port_get_fid(chip, port, &fid);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
} else {
|
2021-03-18 20:25:36 +01:00
|
|
|
err = mv88e6xxx_vtu_get(chip, vid, &vlan);
|
2019-08-01 14:36:35 -04:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
/* switchdev expects -EOPNOTSUPP to honor software VLANs */
|
2021-03-18 20:25:36 +01:00
|
|
|
if (!vlan.valid)
|
2019-08-01 14:36:35 -04:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
fid = vlan.fid;
|
|
|
|
|
}
|
2017-11-09 22:29:55 +01:00
|
|
|
|
2019-09-07 16:00:47 -04:00
|
|
|
entry.state = 0;
|
2017-11-09 22:29:55 +01:00
|
|
|
ether_addr_copy(entry.mac, addr);
|
|
|
|
|
eth_addr_dec(entry.mac);
|
|
|
|
|
|
2019-08-01 14:36:35 -04:00
|
|
|
err = mv88e6xxx_g1_atu_getnext(chip, fid, &entry);
|
2017-11-09 22:29:55 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
/* Initialize a fresh ATU entry if it isn't found */
|
2019-09-07 16:00:47 -04:00
|
|
|
if (!entry.state || !ether_addr_equal(entry.mac, addr)) {
|
2017-11-09 22:29:55 +01:00
|
|
|
memset(&entry, 0, sizeof(entry));
|
|
|
|
|
ether_addr_copy(entry.mac, addr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Purge the ATU entry only if no port is using it anymore */
|
2019-09-07 16:00:47 -04:00
|
|
|
if (!state) {
|
2017-11-09 22:29:55 +01:00
|
|
|
entry.portvec &= ~BIT(port);
|
|
|
|
|
if (!entry.portvec)
|
2019-09-07 16:00:47 -04:00
|
|
|
entry.state = 0;
|
2017-11-09 22:29:55 +01:00
|
|
|
} else {
|
2021-01-30 21:43:34 +08:00
|
|
|
if (state == MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC)
|
|
|
|
|
entry.portvec = BIT(port);
|
|
|
|
|
else
|
|
|
|
|
entry.portvec |= BIT(port);
|
|
|
|
|
|
2017-11-09 22:29:55 +01:00
|
|
|
entry.state = state;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-01 14:36:35 -04:00
|
|
|
return mv88e6xxx_g1_atu_loadpurge(chip, fid, &entry);
|
2017-11-09 22:29:55 +01:00
|
|
|
}
|
|
|
|
|
|
2019-09-07 16:00:49 -04:00
|
|
|
static int mv88e6xxx_policy_apply(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
const struct mv88e6xxx_policy *policy)
|
|
|
|
|
{
|
|
|
|
|
enum mv88e6xxx_policy_mapping mapping = policy->mapping;
|
|
|
|
|
enum mv88e6xxx_policy_action action = policy->action;
|
|
|
|
|
const u8 *addr = policy->addr;
|
|
|
|
|
u16 vid = policy->vid;
|
|
|
|
|
u8 state;
|
|
|
|
|
int err;
|
|
|
|
|
int id;
|
|
|
|
|
|
|
|
|
|
if (!chip->info->ops->port_set_policy)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
switch (mapping) {
|
|
|
|
|
case MV88E6XXX_POLICY_MAPPING_DA:
|
|
|
|
|
case MV88E6XXX_POLICY_MAPPING_SA:
|
|
|
|
|
if (action == MV88E6XXX_POLICY_ACTION_NORMAL)
|
|
|
|
|
state = 0; /* Dissociate the port and address */
|
|
|
|
|
else if (action == MV88E6XXX_POLICY_ACTION_DISCARD &&
|
|
|
|
|
is_multicast_ether_addr(addr))
|
|
|
|
|
state = MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC_POLICY;
|
|
|
|
|
else if (action == MV88E6XXX_POLICY_ACTION_DISCARD &&
|
|
|
|
|
is_unicast_ether_addr(addr))
|
|
|
|
|
state = MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC_POLICY;
|
|
|
|
|
else
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_db_load_purge(chip, port, addr, vid,
|
|
|
|
|
state);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Skip the port's policy clearing if the mapping is still in use */
|
|
|
|
|
if (action == MV88E6XXX_POLICY_ACTION_NORMAL)
|
|
|
|
|
idr_for_each_entry(&chip->policies, policy, id)
|
|
|
|
|
if (policy->port == port &&
|
|
|
|
|
policy->mapping == mapping &&
|
|
|
|
|
policy->action != action)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
return chip->info->ops->port_set_policy(chip, port, mapping, action);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_policy_insert(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
struct ethtool_rx_flow_spec *fs)
|
|
|
|
|
{
|
|
|
|
|
struct ethhdr *mac_entry = &fs->h_u.ether_spec;
|
|
|
|
|
struct ethhdr *mac_mask = &fs->m_u.ether_spec;
|
|
|
|
|
enum mv88e6xxx_policy_mapping mapping;
|
|
|
|
|
enum mv88e6xxx_policy_action action;
|
|
|
|
|
struct mv88e6xxx_policy *policy;
|
|
|
|
|
u16 vid = 0;
|
|
|
|
|
u8 *addr;
|
|
|
|
|
int err;
|
|
|
|
|
int id;
|
|
|
|
|
|
|
|
|
|
if (fs->location != RX_CLS_LOC_ANY)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
if (fs->ring_cookie == RX_CLS_FLOW_DISC)
|
|
|
|
|
action = MV88E6XXX_POLICY_ACTION_DISCARD;
|
|
|
|
|
else
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
switch (fs->flow_type & ~FLOW_EXT) {
|
|
|
|
|
case ETHER_FLOW:
|
|
|
|
|
if (!is_zero_ether_addr(mac_mask->h_dest) &&
|
|
|
|
|
is_zero_ether_addr(mac_mask->h_source)) {
|
|
|
|
|
mapping = MV88E6XXX_POLICY_MAPPING_DA;
|
|
|
|
|
addr = mac_entry->h_dest;
|
|
|
|
|
} else if (is_zero_ether_addr(mac_mask->h_dest) &&
|
|
|
|
|
!is_zero_ether_addr(mac_mask->h_source)) {
|
|
|
|
|
mapping = MV88E6XXX_POLICY_MAPPING_SA;
|
|
|
|
|
addr = mac_entry->h_source;
|
|
|
|
|
} else {
|
|
|
|
|
/* Cannot support DA and SA mapping in the same rule */
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ((fs->flow_type & FLOW_EXT) && fs->m_ext.vlan_tci) {
|
2020-07-05 21:38:08 +02:00
|
|
|
if (fs->m_ext.vlan_tci != htons(0xffff))
|
2019-09-07 16:00:49 -04:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
vid = be16_to_cpu(fs->h_ext.vlan_tci) & VLAN_VID_MASK;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
idr_for_each_entry(&chip->policies, policy, id) {
|
|
|
|
|
if (policy->port == port && policy->mapping == mapping &&
|
|
|
|
|
policy->action == action && policy->vid == vid &&
|
|
|
|
|
ether_addr_equal(policy->addr, addr))
|
|
|
|
|
return -EEXIST;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
policy = devm_kzalloc(chip->dev, sizeof(*policy), GFP_KERNEL);
|
|
|
|
|
if (!policy)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
fs->location = 0;
|
|
|
|
|
err = idr_alloc_u32(&chip->policies, policy, &fs->location, 0xffffffff,
|
|
|
|
|
GFP_KERNEL);
|
|
|
|
|
if (err) {
|
|
|
|
|
devm_kfree(chip->dev, policy);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
memcpy(&policy->fs, fs, sizeof(*fs));
|
|
|
|
|
ether_addr_copy(policy->addr, addr);
|
|
|
|
|
policy->mapping = mapping;
|
|
|
|
|
policy->action = action;
|
|
|
|
|
policy->port = port;
|
|
|
|
|
policy->vid = vid;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_policy_apply(chip, port, policy);
|
|
|
|
|
if (err) {
|
|
|
|
|
idr_remove(&chip->policies, fs->location);
|
|
|
|
|
devm_kfree(chip->dev, policy);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_get_rxnfc(struct dsa_switch *ds, int port,
|
|
|
|
|
struct ethtool_rxnfc *rxnfc, u32 *rule_locs)
|
|
|
|
|
{
|
|
|
|
|
struct ethtool_rx_flow_spec *fs = &rxnfc->fs;
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
struct mv88e6xxx_policy *policy;
|
|
|
|
|
int err;
|
|
|
|
|
int id;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
|
|
switch (rxnfc->cmd) {
|
|
|
|
|
case ETHTOOL_GRXCLSRLCNT:
|
|
|
|
|
rxnfc->data = 0;
|
|
|
|
|
rxnfc->data |= RX_CLS_LOC_SPECIAL;
|
|
|
|
|
rxnfc->rule_cnt = 0;
|
|
|
|
|
idr_for_each_entry(&chip->policies, policy, id)
|
|
|
|
|
if (policy->port == port)
|
|
|
|
|
rxnfc->rule_cnt++;
|
|
|
|
|
err = 0;
|
|
|
|
|
break;
|
|
|
|
|
case ETHTOOL_GRXCLSRULE:
|
|
|
|
|
err = -ENOENT;
|
|
|
|
|
policy = idr_find(&chip->policies, fs->location);
|
|
|
|
|
if (policy) {
|
|
|
|
|
memcpy(fs, &policy->fs, sizeof(*fs));
|
|
|
|
|
err = 0;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case ETHTOOL_GRXCLSRLALL:
|
|
|
|
|
rxnfc->data = 0;
|
|
|
|
|
rxnfc->rule_cnt = 0;
|
|
|
|
|
idr_for_each_entry(&chip->policies, policy, id)
|
|
|
|
|
if (policy->port == port)
|
|
|
|
|
rule_locs[rxnfc->rule_cnt++] = id;
|
|
|
|
|
err = 0;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
err = -EOPNOTSUPP;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_set_rxnfc(struct dsa_switch *ds, int port,
|
|
|
|
|
struct ethtool_rxnfc *rxnfc)
|
|
|
|
|
{
|
|
|
|
|
struct ethtool_rx_flow_spec *fs = &rxnfc->fs;
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
struct mv88e6xxx_policy *policy;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
|
|
switch (rxnfc->cmd) {
|
|
|
|
|
case ETHTOOL_SRXCLSRLINS:
|
|
|
|
|
err = mv88e6xxx_policy_insert(chip, port, fs);
|
|
|
|
|
break;
|
|
|
|
|
case ETHTOOL_SRXCLSRLDEL:
|
|
|
|
|
err = -ENOENT;
|
|
|
|
|
policy = idr_remove(&chip->policies, fs->location);
|
|
|
|
|
if (policy) {
|
|
|
|
|
policy->action = MV88E6XXX_POLICY_ACTION_NORMAL;
|
|
|
|
|
err = mv88e6xxx_policy_apply(chip, port, policy);
|
|
|
|
|
devm_kfree(chip->dev, policy);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
err = -EOPNOTSUPP;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-09 22:29:56 +01:00
|
|
|
static int mv88e6xxx_port_add_broadcast(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
u16 vid)
|
|
|
|
|
{
|
|
|
|
|
u8 state = MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC;
|
2021-03-18 20:25:37 +01:00
|
|
|
u8 broadcast[ETH_ALEN];
|
|
|
|
|
|
|
|
|
|
eth_broadcast_addr(broadcast);
|
2017-11-09 22:29:56 +01:00
|
|
|
|
|
|
|
|
return mv88e6xxx_port_db_load_purge(chip, port, broadcast, vid, state);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_broadcast_setup(struct mv88e6xxx_chip *chip, u16 vid)
|
|
|
|
|
{
|
|
|
|
|
int port;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
for (port = 0; port < mv88e6xxx_num_ports(chip); port++) {
|
2021-03-18 20:25:40 +01:00
|
|
|
struct dsa_port *dp = dsa_to_port(chip->ds, port);
|
|
|
|
|
struct net_device *brport;
|
|
|
|
|
|
|
|
|
|
if (dsa_is_unused_port(chip->ds, port))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
brport = dsa_port_to_bridge_port(dp);
|
|
|
|
|
if (brport && !br_port_flag_is_set(brport, BR_BCAST_FLOOD))
|
|
|
|
|
/* Skip bridged user ports where broadcast
|
|
|
|
|
* flooding is disabled.
|
|
|
|
|
*/
|
|
|
|
|
continue;
|
|
|
|
|
|
2017-11-09 22:29:56 +01:00
|
|
|
err = mv88e6xxx_port_add_broadcast(chip, port, vid);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-18 20:25:40 +01:00
|
|
|
struct mv88e6xxx_port_broadcast_sync_ctx {
|
|
|
|
|
int port;
|
|
|
|
|
bool flood;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
mv88e6xxx_port_broadcast_sync_vlan(struct mv88e6xxx_chip *chip,
|
|
|
|
|
const struct mv88e6xxx_vtu_entry *vlan,
|
|
|
|
|
void *_ctx)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_port_broadcast_sync_ctx *ctx = _ctx;
|
|
|
|
|
u8 broadcast[ETH_ALEN];
|
|
|
|
|
u8 state;
|
|
|
|
|
|
|
|
|
|
if (ctx->flood)
|
|
|
|
|
state = MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC;
|
|
|
|
|
else
|
|
|
|
|
state = MV88E6XXX_G1_ATU_DATA_STATE_MC_UNUSED;
|
|
|
|
|
|
|
|
|
|
eth_broadcast_addr(broadcast);
|
|
|
|
|
|
|
|
|
|
return mv88e6xxx_port_db_load_purge(chip, ctx->port, broadcast,
|
|
|
|
|
vlan->vid, state);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_broadcast_sync(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
bool flood)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_port_broadcast_sync_ctx ctx = {
|
|
|
|
|
.port = port,
|
|
|
|
|
.flood = flood,
|
|
|
|
|
};
|
|
|
|
|
struct mv88e6xxx_vtu_entry vid0 = {
|
|
|
|
|
.vid = 0,
|
|
|
|
|
};
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/* Update the port's private database... */
|
|
|
|
|
err = mv88e6xxx_port_broadcast_sync_vlan(chip, &vid0, &ctx);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
/* ...and the database for all VLANs. */
|
|
|
|
|
return mv88e6xxx_vtu_walk(chip, mv88e6xxx_port_broadcast_sync_vlan,
|
|
|
|
|
&ctx);
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-01 14:36:37 -04:00
|
|
|
static int mv88e6xxx_port_vlan_join(struct mv88e6xxx_chip *chip, int port,
|
2020-02-26 17:14:26 +00:00
|
|
|
u16 vid, u8 member, bool warn)
|
2015-08-13 12:52:22 -04:00
|
|
|
{
|
2019-08-01 14:36:37 -04:00
|
|
|
const u8 non_member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER;
|
2016-09-29 12:21:58 -04:00
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
2019-08-01 14:36:37 -04:00
|
|
|
int i, err;
|
2015-08-13 12:52:22 -04:00
|
|
|
|
2021-03-18 20:25:36 +01:00
|
|
|
err = mv88e6xxx_vtu_get(chip, vid, &vlan);
|
2017-11-09 22:29:56 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2021-03-18 20:25:36 +01:00
|
|
|
if (!vlan.valid) {
|
2019-08-01 14:36:37 -04:00
|
|
|
memset(&vlan, 0, sizeof(vlan));
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_atu_new(chip, &vlan.fid);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i)
|
|
|
|
|
if (i == port)
|
|
|
|
|
vlan.member[i] = member;
|
|
|
|
|
else
|
|
|
|
|
vlan.member[i] = non_member;
|
|
|
|
|
|
|
|
|
|
vlan.vid = vid;
|
|
|
|
|
vlan.valid = true;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_vtu_loadpurge(chip, &vlan);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_broadcast_setup(chip, vlan.vid);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
} else if (vlan.member[port] != member) {
|
|
|
|
|
vlan.member[port] = member;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_vtu_loadpurge(chip, &vlan);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
2020-02-26 17:14:26 +00:00
|
|
|
} else if (warn) {
|
2019-08-01 14:36:37 -04:00
|
|
|
dev_info(chip->dev, "p%d: already a member of VLAN %d\n",
|
|
|
|
|
port, vid);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
2015-11-01 12:33:55 -05:00
|
|
|
}
|
|
|
|
|
|
2021-01-09 02:01:53 +02:00
|
|
|
static int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
|
2021-02-13 22:43:18 +02:00
|
|
|
const struct switchdev_obj_port_vlan *vlan,
|
|
|
|
|
struct netlink_ext_ack *extack)
|
2015-11-01 12:33:55 -05:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2015-11-01 12:33:55 -05:00
|
|
|
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
|
|
|
|
|
bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
|
2020-02-26 17:14:26 +00:00
|
|
|
bool warn;
|
2017-06-07 18:12:13 -04:00
|
|
|
u8 member;
|
2021-01-09 02:01:53 +02:00
|
|
|
int err;
|
2015-11-01 12:33:55 -05:00
|
|
|
|
2021-01-09 02:01:53 +02:00
|
|
|
err = mv88e6xxx_port_vlan_prepare(ds, port, vlan);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
2016-05-09 13:22:47 -04:00
|
|
|
|
2017-06-07 18:12:13 -04:00
|
|
|
if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port))
|
2017-06-15 12:14:02 -04:00
|
|
|
member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNMODIFIED;
|
2017-06-07 18:12:13 -04:00
|
|
|
else if (untagged)
|
2017-06-15 12:14:02 -04:00
|
|
|
member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNTAGGED;
|
2017-06-07 18:12:13 -04:00
|
|
|
else
|
2017-06-15 12:14:02 -04:00
|
|
|
member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_TAGGED;
|
2017-06-07 18:12:13 -04:00
|
|
|
|
2020-02-26 17:14:26 +00:00
|
|
|
/* net/dsa/slave.c will call dsa_port_vlan_add() for the affected port
|
|
|
|
|
* and then the CPU port. Do not warn for duplicates for the CPU port.
|
|
|
|
|
*/
|
|
|
|
|
warn = !dsa_is_cpu_port(ds, port) && !dsa_is_dsa_port(ds, port);
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2015-11-01 12:33:55 -05:00
|
|
|
|
2021-01-09 02:01:53 +02:00
|
|
|
err = mv88e6xxx_port_vlan_join(chip, port, vlan->vid, member, warn);
|
|
|
|
|
if (err) {
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
dev_err(ds->dev, "p%d: failed to add VLAN %d%c\n", port,
|
|
|
|
|
vlan->vid, untagged ? 'u' : 't');
|
2021-01-09 02:01:53 +02:00
|
|
|
goto out;
|
|
|
|
|
}
|
2015-11-01 12:33:55 -05:00
|
|
|
|
2021-01-09 02:01:53 +02:00
|
|
|
if (pvid) {
|
|
|
|
|
err = mv88e6xxx_port_set_pvid(chip, port, vlan->vid);
|
|
|
|
|
if (err) {
|
|
|
|
|
dev_err(ds->dev, "p%d: failed to set PVID %d\n",
|
|
|
|
|
port, vlan->vid);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
out:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2021-01-09 02:01:53 +02:00
|
|
|
|
|
|
|
|
return err;
|
2015-08-13 12:52:22 -04:00
|
|
|
}
|
|
|
|
|
|
2019-08-01 14:36:36 -04:00
|
|
|
static int mv88e6xxx_port_vlan_leave(struct mv88e6xxx_chip *chip,
|
|
|
|
|
int port, u16 vid)
|
2015-08-13 12:52:21 -04:00
|
|
|
{
|
2016-09-29 12:21:58 -04:00
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
2015-08-13 12:52:21 -04:00
|
|
|
int i, err;
|
|
|
|
|
|
2019-08-01 14:36:36 -04:00
|
|
|
if (!vid)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2021-03-18 20:25:36 +01:00
|
|
|
err = mv88e6xxx_vtu_get(chip, vid, &vlan);
|
2015-08-13 12:52:21 -04:00
|
|
|
if (err)
|
2015-11-01 12:33:55 -05:00
|
|
|
return err;
|
2015-08-13 12:52:21 -04:00
|
|
|
|
2019-08-01 14:36:36 -04:00
|
|
|
/* If the VLAN doesn't exist in hardware or the port isn't a member,
|
|
|
|
|
* tell switchdev that this VLAN is likely handled in software.
|
|
|
|
|
*/
|
2021-03-18 20:25:36 +01:00
|
|
|
if (!vlan.valid ||
|
2019-08-01 14:36:36 -04:00
|
|
|
vlan.member[port] == MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER)
|
2016-02-05 14:04:39 -05:00
|
|
|
return -EOPNOTSUPP;
|
2015-08-13 12:52:21 -04:00
|
|
|
|
2017-06-15 12:14:02 -04:00
|
|
|
vlan.member[port] = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER;
|
2015-08-13 12:52:21 -04:00
|
|
|
|
|
|
|
|
/* keep the VLAN unless all ports are excluded */
|
2015-10-11 18:08:36 -04:00
|
|
|
vlan.valid = false;
|
2016-09-29 12:21:57 -04:00
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i) {
|
2017-06-15 12:14:02 -04:00
|
|
|
if (vlan.member[i] !=
|
|
|
|
|
MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER) {
|
2015-10-11 18:08:36 -04:00
|
|
|
vlan.valid = true;
|
2015-08-13 12:52:21 -04:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-01 14:05:23 -04:00
|
|
|
err = mv88e6xxx_vtu_loadpurge(chip, &vlan);
|
2015-11-01 12:33:55 -05:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2017-03-11 16:12:55 -05:00
|
|
|
return mv88e6xxx_g1_atu_remove(chip, vlan.fid, port, false);
|
2015-11-01 12:33:55 -05:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static int mv88e6xxx_port_vlan_del(struct dsa_switch *ds, int port,
|
|
|
|
|
const struct switchdev_obj_port_vlan *vlan)
|
2015-11-01 12:33:55 -05:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2015-11-01 12:33:55 -05:00
|
|
|
int err = 0;
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
u16 pvid;
|
2015-11-01 12:33:55 -05:00
|
|
|
|
2020-11-10 19:57:20 +01:00
|
|
|
if (!mv88e6xxx_max_vid(chip))
|
2016-05-09 13:22:47 -04:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2015-11-01 12:33:55 -05:00
|
|
|
|
2016-11-04 03:23:30 +01:00
|
|
|
err = mv88e6xxx_port_get_pvid(chip, port, &pvid);
|
2015-08-13 12:52:21 -04:00
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
net: switchdev: remove vid_begin -> vid_end range from VLAN objects
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| | br_afspec |
| | | |
| | v |
| | br_process_vlan_info |
| | | |
| | v |
| | br_vlan_info |
| | / \ /
| | / \ /
| | / \ /
| | / \ /
v v v v v
nbp_vlan_add br_vlan_add ------+
| ^ ^ | |
| / | | |
| / / / |
\ br_vlan_get_master/ / v
\ ^ / / br_vlan_add_existing
\ | / / |
\ | / / /
\ | / / /
\ | / / /
\ | / / /
v | | v /
__vlan_add /
/ | /
/ | /
v | /
__vlan_vid_add | /
\ | /
v v v
br_switchdev_port_vlan_add
The ranges UAPI was introduced to the bridge in commit bdced7ef7838
("bridge: support for multiple vlans and vlan ranges in setlink and
dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec)
have always been passed one by one, through struct bridge_vlan_info
tmp_vinfo, to br_vlan_info. So the range never went too far in depth.
Then Scott Feldman introduced the switchdev_port_bridge_setlink function
in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink").
That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made
full use of the range. But switchdev_port_bridge_setlink was called like
this:
br_setlink
-> br_afspec
-> switchdev_port_bridge_setlink
Basically, the switchdev and the bridge code were not tightly integrated.
Then commit 41c498b9359e ("bridge: restore br_setlink back to original")
came, and switchdev drivers were required to implement
.ndo_bridge_setlink = switchdev_port_bridge_setlink for a while.
In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op
first in __vlan_vid_add/del") finally made switchdev penetrate the
br_vlan_info() barrier and start to develop the call path we have today.
But remember, br_vlan_info() still receives VLANs one by one.
Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev") so that drivers would not implement .ndo_bridge_setlink any
longer. The switchdev_port_bridge_setlink also got deleted.
This refactoring removed the parallel bridge_setlink implementation from
switchdev, and left the only switchdev VLAN objects to be the ones
offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add
(the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about
bridge VLANs")).
That is to say, today the switchdev VLAN object ranges are not used in
the kernel. Refactoring the above call path is a bit complicated, when
the bridge VLAN call path is already a bit complicated.
Let's go off and finish the job of commit 29ab586c3d83 by deleting the
bogus iteration through the VLAN ranges from the drivers. Some aspects
of this feature never made too much sense in the first place. For
example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
flag supposed to mean, when a port can obviously have a single pvid?
This particular configuration _is_ denied as of commit 6623c60dc28e
("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API
perspective, the driver still has to play pretend, and only offload the
vlan->vid_end as pvid. And the addition of a switchdev VLAN object can
modify the flags of another, completely unrelated, switchdev VLAN
object! (a VLAN that is PVID will invalidate the PVID flag from whatever
other VLAN had previously been offloaded with switchdev and had that
flag. Yet switchdev never notifies about that change, drivers are
supposed to guess).
Nonetheless, having a VLAN range in the API makes error handling look
scarier than it really is - unwinding on errors and all of that.
When in reality, no one really calls this API with more than one VLAN.
It is all unnecessary complexity.
And despite appearing pretentious (two-phase transactional model and
all), the switchdev API is really sloppy because the VLAN addition and
removal operations are not paired with one another (you can add a VLAN
100 times and delete it just once). The bridge notifies through
switchdev of a VLAN addition not only when the flags of an existing VLAN
change, but also when nothing changes. There are switchdev drivers out
there who don't like adding a VLAN that has already been added, and
those checks don't really belong at driver level. But the fact that the
API contains ranges is yet another factor that prevents this from being
addressed in the future.
Of the existing switchdev pieces of hardware, it appears that only
Mellanox Spectrum supports offloading more than one VLAN at a time,
through mlxsw_sp_port_vlan_set. I have kept that code internal to the
driver, because there is some more bookkeeping that makes use of it, but
I deleted it from the switchdev API. But since the switchdev support for
ranges has already been de facto deleted by a Mellanox employee and
nobody noticed for 4 years, I'm going to assume it's not a biggie.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09 02:01:46 +02:00
|
|
|
err = mv88e6xxx_port_vlan_leave(chip, port, vlan->vid);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
|
|
if (vlan->vid == pvid) {
|
|
|
|
|
err = mv88e6xxx_port_set_pvid(chip, port, 0);
|
2015-11-01 12:33:55 -05:00
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-13 12:52:21 -04:00
|
|
|
unlock:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2015-08-13 12:52:21 -04:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-06 16:15:40 +03:00
|
|
|
static int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
|
|
|
|
|
const unsigned char *addr, u16 vid)
|
2015-08-06 01:44:08 -04:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2017-08-06 16:15:40 +03:00
|
|
|
int err;
|
2015-08-06 01:44:08 -04:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-08-06 16:15:40 +03:00
|
|
|
err = mv88e6xxx_port_db_load_purge(chip, port, addr, vid,
|
|
|
|
|
MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2017-08-06 16:15:40 +03:00
|
|
|
|
|
|
|
|
return err;
|
2015-08-06 01:44:08 -04:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static int mv88e6xxx_port_fdb_del(struct dsa_switch *ds, int port,
|
2017-08-06 16:15:39 +03:00
|
|
|
const unsigned char *addr, u16 vid)
|
2015-08-06 01:44:08 -04:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-08-31 11:50:04 -04:00
|
|
|
int err;
|
2015-08-06 01:44:08 -04:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2019-09-07 16:00:47 -04:00
|
|
|
err = mv88e6xxx_port_db_load_purge(chip, port, addr, vid, 0);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2015-08-06 01:44:08 -04:00
|
|
|
|
2016-08-31 11:50:04 -04:00
|
|
|
return err;
|
2015-08-06 01:44:08 -04:00
|
|
|
}
|
|
|
|
|
|
2016-08-31 11:50:04 -04:00
|
|
|
static int mv88e6xxx_port_db_dump_fid(struct mv88e6xxx_chip *chip,
|
|
|
|
|
u16 fid, u16 vid, int port,
|
2017-08-06 16:15:49 +03:00
|
|
|
dsa_fdb_dump_cb_t *cb, void *data)
|
2016-02-26 13:16:02 -05:00
|
|
|
{
|
2017-03-11 16:12:53 -05:00
|
|
|
struct mv88e6xxx_atu_entry addr;
|
2017-08-06 16:15:49 +03:00
|
|
|
bool is_static;
|
2016-02-26 13:16:02 -05:00
|
|
|
int err;
|
|
|
|
|
|
2019-09-07 16:00:47 -04:00
|
|
|
addr.state = 0;
|
2017-03-11 16:12:53 -05:00
|
|
|
eth_broadcast_addr(addr.mac);
|
2016-02-26 13:16:02 -05:00
|
|
|
|
|
|
|
|
do {
|
2017-03-11 16:12:53 -05:00
|
|
|
err = mv88e6xxx_g1_atu_getnext(chip, fid, &addr);
|
2016-02-26 13:16:02 -05:00
|
|
|
if (err)
|
2016-08-31 11:50:04 -04:00
|
|
|
return err;
|
2016-02-26 13:16:02 -05:00
|
|
|
|
2019-09-07 16:00:47 -04:00
|
|
|
if (!addr.state)
|
2016-02-26 13:16:02 -05:00
|
|
|
break;
|
|
|
|
|
|
2017-03-11 16:12:57 -05:00
|
|
|
if (addr.trunk || (addr.portvec & BIT(port)) == 0)
|
2016-08-31 11:50:04 -04:00
|
|
|
continue;
|
|
|
|
|
|
2017-08-06 16:15:49 +03:00
|
|
|
if (!is_unicast_ether_addr(addr.mac))
|
|
|
|
|
continue;
|
2016-08-31 11:50:04 -04:00
|
|
|
|
2017-08-06 16:15:49 +03:00
|
|
|
is_static = (addr.state ==
|
|
|
|
|
MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC);
|
|
|
|
|
err = cb(addr.mac, vid, is_static, data);
|
2016-08-31 11:50:04 -04:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2016-02-26 13:16:02 -05:00
|
|
|
} while (!is_broadcast_ether_addr(addr.mac));
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-18 20:25:35 +01:00
|
|
|
struct mv88e6xxx_port_db_dump_vlan_ctx {
|
|
|
|
|
int port;
|
|
|
|
|
dsa_fdb_dump_cb_t *cb;
|
|
|
|
|
void *data;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_db_dump_vlan(struct mv88e6xxx_chip *chip,
|
|
|
|
|
const struct mv88e6xxx_vtu_entry *entry,
|
|
|
|
|
void *_data)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_port_db_dump_vlan_ctx *ctx = _data;
|
|
|
|
|
|
|
|
|
|
return mv88e6xxx_port_db_dump_fid(chip, entry->fid, entry->vid,
|
|
|
|
|
ctx->port, ctx->cb, ctx->data);
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-31 11:50:04 -04:00
|
|
|
static int mv88e6xxx_port_db_dump(struct mv88e6xxx_chip *chip, int port,
|
2017-08-06 16:15:49 +03:00
|
|
|
dsa_fdb_dump_cb_t *cb, void *data)
|
2015-10-22 09:34:41 -04:00
|
|
|
{
|
2021-03-18 20:25:35 +01:00
|
|
|
struct mv88e6xxx_port_db_dump_vlan_ctx ctx = {
|
|
|
|
|
.port = port,
|
|
|
|
|
.cb = cb,
|
|
|
|
|
.data = data,
|
|
|
|
|
};
|
2016-02-26 13:16:04 -05:00
|
|
|
u16 fid;
|
2015-10-22 09:34:41 -04:00
|
|
|
int err;
|
|
|
|
|
|
2016-02-26 13:16:04 -05:00
|
|
|
/* Dump port's default Filtering Information Database (VLAN ID 0) */
|
2016-11-04 03:23:29 +01:00
|
|
|
err = mv88e6xxx_port_get_fid(chip, port, &fid);
|
2016-02-26 13:16:04 -05:00
|
|
|
if (err)
|
2016-08-31 11:50:04 -04:00
|
|
|
return err;
|
2016-02-26 13:16:04 -05:00
|
|
|
|
2017-08-06 16:15:49 +03:00
|
|
|
err = mv88e6xxx_port_db_dump_fid(chip, fid, 0, port, cb, data);
|
2016-02-26 13:16:04 -05:00
|
|
|
if (err)
|
2016-08-31 11:50:04 -04:00
|
|
|
return err;
|
2016-02-26 13:16:04 -05:00
|
|
|
|
2021-03-18 20:25:35 +01:00
|
|
|
return mv88e6xxx_vtu_walk(chip, mv88e6xxx_port_db_dump_vlan, &ctx);
|
2016-08-31 11:50:04 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_fdb_dump(struct dsa_switch *ds, int port,
|
2017-08-06 16:15:49 +03:00
|
|
|
dsa_fdb_dump_cb_t *cb, void *data)
|
2016-08-31 11:50:04 -04:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2019-06-12 12:42:47 -04:00
|
|
|
int err;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2019-06-12 12:42:47 -04:00
|
|
|
err = mv88e6xxx_port_db_dump(chip, port, cb, data);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-08-31 11:50:04 -04:00
|
|
|
|
2019-06-12 12:42:47 -04:00
|
|
|
return err;
|
2015-10-22 09:34:41 -04:00
|
|
|
}
|
|
|
|
|
|
2017-03-30 17:37:12 -04:00
|
|
|
static int mv88e6xxx_bridge_map(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct net_device *br)
|
2015-11-04 17:23:40 -05:00
|
|
|
{
|
2019-10-21 16:51:27 -04:00
|
|
|
struct dsa_switch *ds = chip->ds;
|
|
|
|
|
struct dsa_switch_tree *dst = ds->dst;
|
|
|
|
|
struct dsa_port *dp;
|
2017-03-30 17:37:12 -04:00
|
|
|
int err;
|
2016-02-26 13:16:05 -05:00
|
|
|
|
2019-10-21 16:51:27 -04:00
|
|
|
list_for_each_entry(dp, &dst->ports, list) {
|
|
|
|
|
if (dp->bridge_dev == br) {
|
|
|
|
|
if (dp->ds == ds) {
|
|
|
|
|
/* This is a local bridge group member,
|
|
|
|
|
* remap its Port VLAN Map.
|
|
|
|
|
*/
|
|
|
|
|
err = mv88e6xxx_port_vlan_map(chip, dp->index);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
} else {
|
|
|
|
|
/* This is an external bridge group member,
|
|
|
|
|
* remap its cross-chip Port VLAN Table entry.
|
|
|
|
|
*/
|
|
|
|
|
err = mv88e6xxx_pvt_map(chip, dp->ds->index,
|
|
|
|
|
dp->index);
|
2017-03-30 17:37:13 -04:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-30 17:37:12 -04:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_bridge_join(struct dsa_switch *ds, int port,
|
|
|
|
|
struct net_device *br)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-03-30 17:37:12 -04:00
|
|
|
err = mv88e6xxx_bridge_map(chip, br);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-02-12 12:09:39 -05:00
|
|
|
|
2016-02-26 13:16:05 -05:00
|
|
|
return err;
|
2015-11-04 17:23:40 -05:00
|
|
|
}
|
|
|
|
|
|
2017-01-27 15:29:41 -05:00
|
|
|
static void mv88e6xxx_port_bridge_leave(struct dsa_switch *ds, int port,
|
|
|
|
|
struct net_device *br)
|
2016-02-05 14:07:14 -05:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-02-26 13:16:05 -05:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-03-30 17:37:12 -04:00
|
|
|
if (mv88e6xxx_bridge_map(chip, br) ||
|
|
|
|
|
mv88e6xxx_port_vlan_map(chip, port))
|
|
|
|
|
dev_err(ds->dev, "failed to remap in-chip Port VLAN\n");
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-02-05 14:07:14 -05:00
|
|
|
}
|
|
|
|
|
|
net: dsa: permit cross-chip bridging between all trees in the system
One way of utilizing DSA is by cascading switches which do not all have
compatible taggers. Consider the following real-life topology:
+---------------------------------------------------------------+
| LS1028A |
| +------------------------------+ |
| | DSA master for Felix | |
| |(internal ENETC port 2: eno2))| |
| +------------+------------------------------+-------------+ |
| | Felix embedded L2 switch | |
| | | |
| | +--------------+ +--------------+ +--------------+ | |
| | |DSA master for| |DSA master for| |DSA master for| | |
| | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | |
| | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | |
+--+-+--------------+---+--------------+---+--------------+--+--+
+-----------------------+ +-----------------------+ +-----------------------+
| SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
The above can be described in the device tree as follows (obviously not
complete):
mscc_felix {
dsa,member = <0 0>;
ports {
port@4 {
ethernet = <&enetc_port2>;
};
};
};
sja1105_switch1 {
dsa,member = <1 1>;
ports {
port@4 {
ethernet = <&mscc_felix_port1>;
};
};
};
sja1105_switch2 {
dsa,member = <2 2>;
ports {
port@4 {
ethernet = <&mscc_felix_port2>;
};
};
};
sja1105_switch3 {
dsa,member = <3 3>;
ports {
port@4 {
ethernet = <&mscc_felix_port3>;
};
};
};
Basically we instantiate one DSA switch tree for every hardware switch
in the system, but we still give them globally unique switch IDs (will
come back to that later). Having 3 disjoint switch trees makes the
tagger drivers "just work", because net devices are registered for the
3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
port. So packets received on the ENETC port are stripped of their
stacked DSA tags one by one.
Currently, hardware bridging between ports on the same sja1105 chip is
possible, but switching between sja1105 ports on different chips is
handled by the software bridge. This is fine, but we can do better.
In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
In other words, a sja1105 switch can correctly parse and route a packet
containing a dsa_8021q tag. So if we could enable hardware bridging on
the Felix DSA master ports, cross-chip bridging could be completely
offloaded.
Such as system would be used as follows:
ip link add dev br0 type bridge && ip link set dev br0 up
for port in sw0p0 sw0p1 sw0p2 sw0p3 \
sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2 sw2p3; do
ip link set dev $port master br0
done
The above makes switching between ports on the same row be performed in
hardware, and between ports on different rows in software. Now assume
the Felix switch ports are called swp0, swp1, swp2. By running the
following extra commands:
ip link add dev br1 type bridge && ip link set dev br1 up
for port in swp0 swp1 swp2; do
ip link set dev $port master br1
done
the CPU no longer sees packets which traverse sja1105 switch boundaries
and can be forwarded directly by Felix. The br1 bridge would not be used
for any sort of traffic termination.
For this to work, we need to give drivers an opportunity to listen for
bridging events on DSA trees other than their own, and pass that other
tree index as argument. I have made the assumption, for the moment, that
the other existing DSA notifiers don't need to be broadcast to other
trees. That assumption might turn out to be incorrect. But in the
meantime, introduce a dsa_broadcast function, similar in purpose to
dsa_port_notify, which is used only by the bridging notifiers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-05-10 19:37:41 +03:00
|
|
|
static int mv88e6xxx_crosschip_bridge_join(struct dsa_switch *ds,
|
|
|
|
|
int tree_index, int sw_index,
|
2017-03-30 17:37:15 -04:00
|
|
|
int port, struct net_device *br)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err;
|
|
|
|
|
|
net: dsa: permit cross-chip bridging between all trees in the system
One way of utilizing DSA is by cascading switches which do not all have
compatible taggers. Consider the following real-life topology:
+---------------------------------------------------------------+
| LS1028A |
| +------------------------------+ |
| | DSA master for Felix | |
| |(internal ENETC port 2: eno2))| |
| +------------+------------------------------+-------------+ |
| | Felix embedded L2 switch | |
| | | |
| | +--------------+ +--------------+ +--------------+ | |
| | |DSA master for| |DSA master for| |DSA master for| | |
| | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | |
| | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | |
+--+-+--------------+---+--------------+---+--------------+--+--+
+-----------------------+ +-----------------------+ +-----------------------+
| SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
The above can be described in the device tree as follows (obviously not
complete):
mscc_felix {
dsa,member = <0 0>;
ports {
port@4 {
ethernet = <&enetc_port2>;
};
};
};
sja1105_switch1 {
dsa,member = <1 1>;
ports {
port@4 {
ethernet = <&mscc_felix_port1>;
};
};
};
sja1105_switch2 {
dsa,member = <2 2>;
ports {
port@4 {
ethernet = <&mscc_felix_port2>;
};
};
};
sja1105_switch3 {
dsa,member = <3 3>;
ports {
port@4 {
ethernet = <&mscc_felix_port3>;
};
};
};
Basically we instantiate one DSA switch tree for every hardware switch
in the system, but we still give them globally unique switch IDs (will
come back to that later). Having 3 disjoint switch trees makes the
tagger drivers "just work", because net devices are registered for the
3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
port. So packets received on the ENETC port are stripped of their
stacked DSA tags one by one.
Currently, hardware bridging between ports on the same sja1105 chip is
possible, but switching between sja1105 ports on different chips is
handled by the software bridge. This is fine, but we can do better.
In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
In other words, a sja1105 switch can correctly parse and route a packet
containing a dsa_8021q tag. So if we could enable hardware bridging on
the Felix DSA master ports, cross-chip bridging could be completely
offloaded.
Such as system would be used as follows:
ip link add dev br0 type bridge && ip link set dev br0 up
for port in sw0p0 sw0p1 sw0p2 sw0p3 \
sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2 sw2p3; do
ip link set dev $port master br0
done
The above makes switching between ports on the same row be performed in
hardware, and between ports on different rows in software. Now assume
the Felix switch ports are called swp0, swp1, swp2. By running the
following extra commands:
ip link add dev br1 type bridge && ip link set dev br1 up
for port in swp0 swp1 swp2; do
ip link set dev $port master br1
done
the CPU no longer sees packets which traverse sja1105 switch boundaries
and can be forwarded directly by Felix. The br1 bridge would not be used
for any sort of traffic termination.
For this to work, we need to give drivers an opportunity to listen for
bridging events on DSA trees other than their own, and pass that other
tree index as argument. I have made the assumption, for the moment, that
the other existing DSA notifiers don't need to be broadcast to other
trees. That assumption might turn out to be incorrect. But in the
meantime, introduce a dsa_broadcast function, similar in purpose to
dsa_port_notify, which is used only by the bridging notifiers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-05-10 19:37:41 +03:00
|
|
|
if (tree_index != ds->dst->index)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
net: dsa: permit cross-chip bridging between all trees in the system
One way of utilizing DSA is by cascading switches which do not all have
compatible taggers. Consider the following real-life topology:
+---------------------------------------------------------------+
| LS1028A |
| +------------------------------+ |
| | DSA master for Felix | |
| |(internal ENETC port 2: eno2))| |
| +------------+------------------------------+-------------+ |
| | Felix embedded L2 switch | |
| | | |
| | +--------------+ +--------------+ +--------------+ | |
| | |DSA master for| |DSA master for| |DSA master for| | |
| | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | |
| | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | |
+--+-+--------------+---+--------------+---+--------------+--+--+
+-----------------------+ +-----------------------+ +-----------------------+
| SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
The above can be described in the device tree as follows (obviously not
complete):
mscc_felix {
dsa,member = <0 0>;
ports {
port@4 {
ethernet = <&enetc_port2>;
};
};
};
sja1105_switch1 {
dsa,member = <1 1>;
ports {
port@4 {
ethernet = <&mscc_felix_port1>;
};
};
};
sja1105_switch2 {
dsa,member = <2 2>;
ports {
port@4 {
ethernet = <&mscc_felix_port2>;
};
};
};
sja1105_switch3 {
dsa,member = <3 3>;
ports {
port@4 {
ethernet = <&mscc_felix_port3>;
};
};
};
Basically we instantiate one DSA switch tree for every hardware switch
in the system, but we still give them globally unique switch IDs (will
come back to that later). Having 3 disjoint switch trees makes the
tagger drivers "just work", because net devices are registered for the
3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
port. So packets received on the ENETC port are stripped of their
stacked DSA tags one by one.
Currently, hardware bridging between ports on the same sja1105 chip is
possible, but switching between sja1105 ports on different chips is
handled by the software bridge. This is fine, but we can do better.
In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
In other words, a sja1105 switch can correctly parse and route a packet
containing a dsa_8021q tag. So if we could enable hardware bridging on
the Felix DSA master ports, cross-chip bridging could be completely
offloaded.
Such as system would be used as follows:
ip link add dev br0 type bridge && ip link set dev br0 up
for port in sw0p0 sw0p1 sw0p2 sw0p3 \
sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2 sw2p3; do
ip link set dev $port master br0
done
The above makes switching between ports on the same row be performed in
hardware, and between ports on different rows in software. Now assume
the Felix switch ports are called swp0, swp1, swp2. By running the
following extra commands:
ip link add dev br1 type bridge && ip link set dev br1 up
for port in swp0 swp1 swp2; do
ip link set dev $port master br1
done
the CPU no longer sees packets which traverse sja1105 switch boundaries
and can be forwarded directly by Felix. The br1 bridge would not be used
for any sort of traffic termination.
For this to work, we need to give drivers an opportunity to listen for
bridging events on DSA trees other than their own, and pass that other
tree index as argument. I have made the assumption, for the moment, that
the other existing DSA notifiers don't need to be broadcast to other
trees. That assumption might turn out to be incorrect. But in the
meantime, introduce a dsa_broadcast function, similar in purpose to
dsa_port_notify, which is used only by the bridging notifiers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-05-10 19:37:41 +03:00
|
|
|
err = mv88e6xxx_pvt_map(chip, sw_index, port);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2017-03-30 17:37:15 -04:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
net: dsa: permit cross-chip bridging between all trees in the system
One way of utilizing DSA is by cascading switches which do not all have
compatible taggers. Consider the following real-life topology:
+---------------------------------------------------------------+
| LS1028A |
| +------------------------------+ |
| | DSA master for Felix | |
| |(internal ENETC port 2: eno2))| |
| +------------+------------------------------+-------------+ |
| | Felix embedded L2 switch | |
| | | |
| | +--------------+ +--------------+ +--------------+ | |
| | |DSA master for| |DSA master for| |DSA master for| | |
| | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | |
| | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | |
+--+-+--------------+---+--------------+---+--------------+--+--+
+-----------------------+ +-----------------------+ +-----------------------+
| SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
The above can be described in the device tree as follows (obviously not
complete):
mscc_felix {
dsa,member = <0 0>;
ports {
port@4 {
ethernet = <&enetc_port2>;
};
};
};
sja1105_switch1 {
dsa,member = <1 1>;
ports {
port@4 {
ethernet = <&mscc_felix_port1>;
};
};
};
sja1105_switch2 {
dsa,member = <2 2>;
ports {
port@4 {
ethernet = <&mscc_felix_port2>;
};
};
};
sja1105_switch3 {
dsa,member = <3 3>;
ports {
port@4 {
ethernet = <&mscc_felix_port3>;
};
};
};
Basically we instantiate one DSA switch tree for every hardware switch
in the system, but we still give them globally unique switch IDs (will
come back to that later). Having 3 disjoint switch trees makes the
tagger drivers "just work", because net devices are registered for the
3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
port. So packets received on the ENETC port are stripped of their
stacked DSA tags one by one.
Currently, hardware bridging between ports on the same sja1105 chip is
possible, but switching between sja1105 ports on different chips is
handled by the software bridge. This is fine, but we can do better.
In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
In other words, a sja1105 switch can correctly parse and route a packet
containing a dsa_8021q tag. So if we could enable hardware bridging on
the Felix DSA master ports, cross-chip bridging could be completely
offloaded.
Such as system would be used as follows:
ip link add dev br0 type bridge && ip link set dev br0 up
for port in sw0p0 sw0p1 sw0p2 sw0p3 \
sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2 sw2p3; do
ip link set dev $port master br0
done
The above makes switching between ports on the same row be performed in
hardware, and between ports on different rows in software. Now assume
the Felix switch ports are called swp0, swp1, swp2. By running the
following extra commands:
ip link add dev br1 type bridge && ip link set dev br1 up
for port in swp0 swp1 swp2; do
ip link set dev $port master br1
done
the CPU no longer sees packets which traverse sja1105 switch boundaries
and can be forwarded directly by Felix. The br1 bridge would not be used
for any sort of traffic termination.
For this to work, we need to give drivers an opportunity to listen for
bridging events on DSA trees other than their own, and pass that other
tree index as argument. I have made the assumption, for the moment, that
the other existing DSA notifiers don't need to be broadcast to other
trees. That assumption might turn out to be incorrect. But in the
meantime, introduce a dsa_broadcast function, similar in purpose to
dsa_port_notify, which is used only by the bridging notifiers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-05-10 19:37:41 +03:00
|
|
|
static void mv88e6xxx_crosschip_bridge_leave(struct dsa_switch *ds,
|
|
|
|
|
int tree_index, int sw_index,
|
2017-03-30 17:37:15 -04:00
|
|
|
int port, struct net_device *br)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
|
net: dsa: permit cross-chip bridging between all trees in the system
One way of utilizing DSA is by cascading switches which do not all have
compatible taggers. Consider the following real-life topology:
+---------------------------------------------------------------+
| LS1028A |
| +------------------------------+ |
| | DSA master for Felix | |
| |(internal ENETC port 2: eno2))| |
| +------------+------------------------------+-------------+ |
| | Felix embedded L2 switch | |
| | | |
| | +--------------+ +--------------+ +--------------+ | |
| | |DSA master for| |DSA master for| |DSA master for| | |
| | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | |
| | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | |
+--+-+--------------+---+--------------+---+--------------+--+--+
+-----------------------+ +-----------------------+ +-----------------------+
| SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
The above can be described in the device tree as follows (obviously not
complete):
mscc_felix {
dsa,member = <0 0>;
ports {
port@4 {
ethernet = <&enetc_port2>;
};
};
};
sja1105_switch1 {
dsa,member = <1 1>;
ports {
port@4 {
ethernet = <&mscc_felix_port1>;
};
};
};
sja1105_switch2 {
dsa,member = <2 2>;
ports {
port@4 {
ethernet = <&mscc_felix_port2>;
};
};
};
sja1105_switch3 {
dsa,member = <3 3>;
ports {
port@4 {
ethernet = <&mscc_felix_port3>;
};
};
};
Basically we instantiate one DSA switch tree for every hardware switch
in the system, but we still give them globally unique switch IDs (will
come back to that later). Having 3 disjoint switch trees makes the
tagger drivers "just work", because net devices are registered for the
3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
port. So packets received on the ENETC port are stripped of their
stacked DSA tags one by one.
Currently, hardware bridging between ports on the same sja1105 chip is
possible, but switching between sja1105 ports on different chips is
handled by the software bridge. This is fine, but we can do better.
In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
In other words, a sja1105 switch can correctly parse and route a packet
containing a dsa_8021q tag. So if we could enable hardware bridging on
the Felix DSA master ports, cross-chip bridging could be completely
offloaded.
Such as system would be used as follows:
ip link add dev br0 type bridge && ip link set dev br0 up
for port in sw0p0 sw0p1 sw0p2 sw0p3 \
sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2 sw2p3; do
ip link set dev $port master br0
done
The above makes switching between ports on the same row be performed in
hardware, and between ports on different rows in software. Now assume
the Felix switch ports are called swp0, swp1, swp2. By running the
following extra commands:
ip link add dev br1 type bridge && ip link set dev br1 up
for port in swp0 swp1 swp2; do
ip link set dev $port master br1
done
the CPU no longer sees packets which traverse sja1105 switch boundaries
and can be forwarded directly by Felix. The br1 bridge would not be used
for any sort of traffic termination.
For this to work, we need to give drivers an opportunity to listen for
bridging events on DSA trees other than their own, and pass that other
tree index as argument. I have made the assumption, for the moment, that
the other existing DSA notifiers don't need to be broadcast to other
trees. That assumption might turn out to be incorrect. But in the
meantime, introduce a dsa_broadcast function, similar in purpose to
dsa_port_notify, which is used only by the bridging notifiers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-05-10 19:37:41 +03:00
|
|
|
if (tree_index != ds->dst->index)
|
|
|
|
|
return;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
net: dsa: permit cross-chip bridging between all trees in the system
One way of utilizing DSA is by cascading switches which do not all have
compatible taggers. Consider the following real-life topology:
+---------------------------------------------------------------+
| LS1028A |
| +------------------------------+ |
| | DSA master for Felix | |
| |(internal ENETC port 2: eno2))| |
| +------------+------------------------------+-------------+ |
| | Felix embedded L2 switch | |
| | | |
| | +--------------+ +--------------+ +--------------+ | |
| | |DSA master for| |DSA master for| |DSA master for| | |
| | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | |
| | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | |
+--+-+--------------+---+--------------+---+--------------+--+--+
+-----------------------+ +-----------------------+ +-----------------------+
| SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
The above can be described in the device tree as follows (obviously not
complete):
mscc_felix {
dsa,member = <0 0>;
ports {
port@4 {
ethernet = <&enetc_port2>;
};
};
};
sja1105_switch1 {
dsa,member = <1 1>;
ports {
port@4 {
ethernet = <&mscc_felix_port1>;
};
};
};
sja1105_switch2 {
dsa,member = <2 2>;
ports {
port@4 {
ethernet = <&mscc_felix_port2>;
};
};
};
sja1105_switch3 {
dsa,member = <3 3>;
ports {
port@4 {
ethernet = <&mscc_felix_port3>;
};
};
};
Basically we instantiate one DSA switch tree for every hardware switch
in the system, but we still give them globally unique switch IDs (will
come back to that later). Having 3 disjoint switch trees makes the
tagger drivers "just work", because net devices are registered for the
3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
port. So packets received on the ENETC port are stripped of their
stacked DSA tags one by one.
Currently, hardware bridging between ports on the same sja1105 chip is
possible, but switching between sja1105 ports on different chips is
handled by the software bridge. This is fine, but we can do better.
In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
In other words, a sja1105 switch can correctly parse and route a packet
containing a dsa_8021q tag. So if we could enable hardware bridging on
the Felix DSA master ports, cross-chip bridging could be completely
offloaded.
Such as system would be used as follows:
ip link add dev br0 type bridge && ip link set dev br0 up
for port in sw0p0 sw0p1 sw0p2 sw0p3 \
sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2 sw2p3; do
ip link set dev $port master br0
done
The above makes switching between ports on the same row be performed in
hardware, and between ports on different rows in software. Now assume
the Felix switch ports are called swp0, swp1, swp2. By running the
following extra commands:
ip link add dev br1 type bridge && ip link set dev br1 up
for port in swp0 swp1 swp2; do
ip link set dev $port master br1
done
the CPU no longer sees packets which traverse sja1105 switch boundaries
and can be forwarded directly by Felix. The br1 bridge would not be used
for any sort of traffic termination.
For this to work, we need to give drivers an opportunity to listen for
bridging events on DSA trees other than their own, and pass that other
tree index as argument. I have made the assumption, for the moment, that
the other existing DSA notifiers don't need to be broadcast to other
trees. That assumption might turn out to be incorrect. But in the
meantime, introduce a dsa_broadcast function, similar in purpose to
dsa_port_notify, which is used only by the bridging notifiers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-05-10 19:37:41 +03:00
|
|
|
if (mv88e6xxx_pvt_map(chip, sw_index, port))
|
2017-03-30 17:37:15 -04:00
|
|
|
dev_err(ds->dev, "failed to remap cross-chip Port VLAN\n");
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2017-03-30 17:37:15 -04:00
|
|
|
}
|
|
|
|
|
|
2016-12-05 17:30:27 -05:00
|
|
|
static int mv88e6xxx_software_reset(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
if (chip->info->ops->reset)
|
|
|
|
|
return chip->info->ops->reset(chip);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-05 17:30:26 -05:00
|
|
|
static void mv88e6xxx_hardware_reset(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
struct gpio_desc *gpiod = chip->reset;
|
|
|
|
|
|
|
|
|
|
/* If there is a GPIO connected to the reset pin, toggle it */
|
|
|
|
|
if (gpiod) {
|
|
|
|
|
gpiod_set_value_cansleep(gpiod, 1);
|
|
|
|
|
usleep_range(10000, 20000);
|
|
|
|
|
gpiod_set_value_cansleep(gpiod, 0);
|
|
|
|
|
usleep_range(10000, 20000);
|
2020-11-16 08:43:01 -08:00
|
|
|
|
|
|
|
|
mv88e6xxx_g1_wait_eeprom_done(chip);
|
2016-12-05 17:30:26 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-05 17:30:25 -05:00
|
|
|
static int mv88e6xxx_disable_ports(struct mv88e6xxx_chip *chip)
|
2016-05-09 13:22:49 -04:00
|
|
|
{
|
2016-12-05 17:30:25 -05:00
|
|
|
int i, err;
|
2016-05-09 13:22:49 -04:00
|
|
|
|
2016-12-05 17:30:25 -05:00
|
|
|
/* Set all ports to the Disabled state */
|
2016-09-29 12:21:57 -04:00
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
|
2017-06-08 18:34:10 -04:00
|
|
|
err = mv88e6xxx_port_set_state(chip, i, BR_STATE_DISABLED);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2016-05-09 13:22:49 -04:00
|
|
|
}
|
|
|
|
|
|
2016-12-05 17:30:25 -05:00
|
|
|
/* Wait for transmit queues to drain,
|
|
|
|
|
* i.e. 2ms for a maximum frame to be transmitted at 10 Mbps.
|
|
|
|
|
*/
|
2016-05-09 13:22:49 -04:00
|
|
|
usleep_range(2000, 4000);
|
|
|
|
|
|
2016-12-05 17:30:25 -05:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_switch_reset(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_disable_ports(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2016-12-05 17:30:26 -05:00
|
|
|
mv88e6xxx_hardware_reset(chip);
|
2016-05-09 13:22:49 -04:00
|
|
|
|
2016-12-05 17:30:27 -05:00
|
|
|
return mv88e6xxx_software_reset(chip);
|
2016-05-09 13:22:49 -04:00
|
|
|
}
|
|
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
static int mv88e6xxx_set_port_mode(struct mv88e6xxx_chip *chip, int port,
|
2017-06-08 18:34:09 -04:00
|
|
|
enum mv88e6xxx_frame_mode frame,
|
|
|
|
|
enum mv88e6xxx_egress_mode egress, u16 etype)
|
2016-12-03 04:35:19 +01:00
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
if (!chip->info->ops->port_set_frame_mode)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_set_egress_mode(chip, port, egress);
|
2016-12-03 04:35:19 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
err = chip->info->ops->port_set_frame_mode(chip, port, frame);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->port_set_ether_type)
|
|
|
|
|
return chip->info->ops->port_set_ether_type(chip, port, etype);
|
|
|
|
|
|
|
|
|
|
return 0;
|
2016-12-03 04:35:19 +01:00
|
|
|
}
|
|
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
static int mv88e6xxx_set_port_mode_normal(struct mv88e6xxx_chip *chip, int port)
|
2016-12-03 04:35:19 +01:00
|
|
|
{
|
2017-03-11 16:12:59 -05:00
|
|
|
return mv88e6xxx_set_port_mode(chip, port, MV88E6XXX_FRAME_MODE_NORMAL,
|
2017-06-08 18:34:09 -04:00
|
|
|
MV88E6XXX_EGRESS_MODE_UNMODIFIED,
|
2017-06-12 12:37:45 -04:00
|
|
|
MV88E6XXX_PORT_ETH_TYPE_DEFAULT);
|
2017-03-11 16:12:59 -05:00
|
|
|
}
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
static int mv88e6xxx_set_port_mode_dsa(struct mv88e6xxx_chip *chip, int port)
|
|
|
|
|
{
|
|
|
|
|
return mv88e6xxx_set_port_mode(chip, port, MV88E6XXX_FRAME_MODE_DSA,
|
2017-06-08 18:34:09 -04:00
|
|
|
MV88E6XXX_EGRESS_MODE_UNMODIFIED,
|
2017-06-12 12:37:45 -04:00
|
|
|
MV88E6XXX_PORT_ETH_TYPE_DEFAULT);
|
2017-03-11 16:12:59 -05:00
|
|
|
}
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
static int mv88e6xxx_set_port_mode_edsa(struct mv88e6xxx_chip *chip, int port)
|
|
|
|
|
{
|
|
|
|
|
return mv88e6xxx_set_port_mode(chip, port,
|
|
|
|
|
MV88E6XXX_FRAME_MODE_ETHERTYPE,
|
2017-06-08 18:34:09 -04:00
|
|
|
MV88E6XXX_EGRESS_MODE_ETHERTYPE,
|
|
|
|
|
ETH_P_EDSA);
|
2017-03-11 16:12:59 -05:00
|
|
|
}
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
static int mv88e6xxx_setup_port_mode(struct mv88e6xxx_chip *chip, int port)
|
|
|
|
|
{
|
|
|
|
|
if (dsa_is_dsa_port(chip->ds, port))
|
|
|
|
|
return mv88e6xxx_set_port_mode_dsa(chip, port);
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-10-26 11:22:54 -04:00
|
|
|
if (dsa_is_user_port(chip->ds, port))
|
2017-03-11 16:12:59 -05:00
|
|
|
return mv88e6xxx_set_port_mode_normal(chip, port);
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
/* Setup CPU port mode depending on its supported tag format */
|
|
|
|
|
if (chip->info->tag_protocol == DSA_TAG_PROTO_DSA)
|
|
|
|
|
return mv88e6xxx_set_port_mode_dsa(chip, port);
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
if (chip->info->tag_protocol == DSA_TAG_PROTO_EDSA)
|
|
|
|
|
return mv88e6xxx_set_port_mode_edsa(chip, port);
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-03-11 16:12:59 -05:00
|
|
|
return -EINVAL;
|
2016-12-03 04:35:19 +01:00
|
|
|
}
|
|
|
|
|
|
2017-03-11 16:13:00 -05:00
|
|
|
static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port)
|
2016-12-03 04:35:19 +01:00
|
|
|
{
|
2017-03-11 16:13:00 -05:00
|
|
|
bool message = dsa_is_dsa_port(chip->ds, port);
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-03-11 16:13:00 -05:00
|
|
|
return mv88e6xxx_port_set_message_port(chip, port, message);
|
2017-03-11 16:12:59 -05:00
|
|
|
}
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2017-03-11 16:13:00 -05:00
|
|
|
static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port)
|
2017-03-11 16:12:59 -05:00
|
|
|
{
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
int err;
|
2016-12-03 04:35:19 +01:00
|
|
|
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
if (chip->info->ops->port_set_ucast_flood) {
|
2021-03-18 20:25:38 +01:00
|
|
|
err = chip->info->ops->port_set_ucast_flood(chip, port, true);
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
if (chip->info->ops->port_set_mcast_flood) {
|
2021-03-18 20:25:38 +01:00
|
|
|
err = chip->info->ops->port_set_mcast_flood(chip, port, true);
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
2017-03-11 16:12:50 -05:00
|
|
|
|
2019-06-15 13:35:29 -07:00
|
|
|
return 0;
|
2017-03-11 16:12:50 -05:00
|
|
|
}
|
|
|
|
|
|
2019-08-31 16:18:36 -04:00
|
|
|
static irqreturn_t mv88e6xxx_serdes_irq_thread_fn(int irq, void *dev_id)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_port *mvp = dev_id;
|
|
|
|
|
struct mv88e6xxx_chip *chip = mvp->chip;
|
|
|
|
|
irqreturn_t ret = IRQ_NONE;
|
|
|
|
|
int port = mvp->port;
|
2021-03-17 14:46:40 +01:00
|
|
|
int lane;
|
2019-08-31 16:18:36 -04:00
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
lane = mv88e6xxx_serdes_get_lane(chip, port);
|
2021-03-17 14:46:40 +01:00
|
|
|
if (lane >= 0)
|
2019-08-31 16:18:36 -04:00
|
|
|
ret = mv88e6xxx_serdes_irq_status(chip, port, lane);
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_serdes_irq_request(struct mv88e6xxx_chip *chip, int port,
|
2021-03-17 14:46:40 +01:00
|
|
|
int lane)
|
2019-08-31 16:18:36 -04:00
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_port *dev_id = &chip->ports[port];
|
|
|
|
|
unsigned int irq;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/* Nothing to request if this SERDES port has no IRQ */
|
|
|
|
|
irq = mv88e6xxx_serdes_irq_mapping(chip, port);
|
|
|
|
|
if (!irq)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2020-01-06 17:13:49 +01:00
|
|
|
snprintf(dev_id->serdes_irq_name, sizeof(dev_id->serdes_irq_name),
|
|
|
|
|
"mv88e6xxx-%s-serdes-%d", dev_name(chip->dev), port);
|
|
|
|
|
|
2019-08-31 16:18:36 -04:00
|
|
|
/* Requesting the IRQ will trigger IRQ callbacks, so release the lock */
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
err = request_threaded_irq(irq, NULL, mv88e6xxx_serdes_irq_thread_fn,
|
2020-01-06 17:13:49 +01:00
|
|
|
IRQF_ONESHOT, dev_id->serdes_irq_name,
|
|
|
|
|
dev_id);
|
2019-08-31 16:18:36 -04:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
dev_id->serdes_irq = irq;
|
|
|
|
|
|
|
|
|
|
return mv88e6xxx_serdes_irq_enable(chip, port, lane);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_serdes_irq_free(struct mv88e6xxx_chip *chip, int port,
|
2021-03-17 14:46:40 +01:00
|
|
|
int lane)
|
2019-08-31 16:18:36 -04:00
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_port *dev_id = &chip->ports[port];
|
|
|
|
|
unsigned int irq = dev_id->serdes_irq;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/* Nothing to free if no IRQ has been requested */
|
|
|
|
|
if (!irq)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_serdes_irq_disable(chip, port, lane);
|
|
|
|
|
|
|
|
|
|
/* Freeing the IRQ will trigger IRQ callbacks, so release the lock */
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
free_irq(irq, dev_id);
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
|
|
dev_id->serdes_irq = 0;
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 01:03:21 +02:00
|
|
|
static int mv88e6xxx_serdes_power(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
bool on)
|
|
|
|
|
{
|
2021-03-17 14:46:40 +01:00
|
|
|
int lane;
|
2019-08-19 16:00:53 -04:00
|
|
|
int err;
|
2017-05-26 01:03:24 +02:00
|
|
|
|
2019-08-31 16:18:33 -04:00
|
|
|
lane = mv88e6xxx_serdes_get_lane(chip, port);
|
2021-03-17 14:46:40 +01:00
|
|
|
if (lane < 0)
|
2019-08-19 16:00:53 -04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
if (on) {
|
2019-08-31 16:18:33 -04:00
|
|
|
err = mv88e6xxx_serdes_power_up(chip, port, lane);
|
2019-08-19 16:00:53 -04:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2019-08-31 16:18:36 -04:00
|
|
|
err = mv88e6xxx_serdes_irq_request(chip, port, lane);
|
2019-08-19 16:00:53 -04:00
|
|
|
} else {
|
2019-08-31 16:18:36 -04:00
|
|
|
err = mv88e6xxx_serdes_irq_free(chip, port, lane);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
2019-08-19 16:00:53 -04:00
|
|
|
|
2019-08-31 16:18:33 -04:00
|
|
|
err = mv88e6xxx_serdes_power_down(chip, port, lane);
|
2019-08-19 16:00:53 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return err;
|
2017-05-26 01:03:21 +02:00
|
|
|
}
|
|
|
|
|
|
2021-03-17 14:46:41 +01:00
|
|
|
static int mv88e6xxx_set_egress_port(struct mv88e6xxx_chip *chip,
|
|
|
|
|
enum mv88e6xxx_egress_direction direction,
|
|
|
|
|
int port)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!chip->info->ops->set_egress_port)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
err = chip->info->ops->set_egress_port(chip, direction, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
if (direction == MV88E6XXX_EGRESS_DIR_INGRESS)
|
|
|
|
|
chip->ingress_dest_port = port;
|
|
|
|
|
else
|
|
|
|
|
chip->egress_dest_port = port;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-05 15:34:10 -05:00
|
|
|
static int mv88e6xxx_setup_upstream_port(struct mv88e6xxx_chip *chip, int port)
|
|
|
|
|
{
|
|
|
|
|
struct dsa_switch *ds = chip->ds;
|
|
|
|
|
int upstream_port;
|
|
|
|
|
int err;
|
|
|
|
|
|
2017-12-05 15:34:13 -05:00
|
|
|
upstream_port = dsa_upstream_port(ds, port);
|
2017-12-05 15:34:10 -05:00
|
|
|
if (chip->info->ops->port_set_upstream_port) {
|
|
|
|
|
err = chip->info->ops->port_set_upstream_port(chip, port,
|
|
|
|
|
upstream_port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-05 15:34:11 -05:00
|
|
|
if (port == upstream_port) {
|
|
|
|
|
if (chip->info->ops->set_cpu_port) {
|
|
|
|
|
err = chip->info->ops->set_cpu_port(chip,
|
|
|
|
|
upstream_port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-17 14:46:41 +01:00
|
|
|
err = mv88e6xxx_set_egress_port(chip,
|
2019-11-07 22:11:13 +01:00
|
|
|
MV88E6XXX_EGRESS_DIR_INGRESS,
|
|
|
|
|
upstream_port);
|
2021-03-17 14:46:41 +01:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
|
return err;
|
2019-11-07 22:11:13 +01:00
|
|
|
|
2021-03-17 14:46:41 +01:00
|
|
|
err = mv88e6xxx_set_egress_port(chip,
|
2019-11-07 22:11:13 +01:00
|
|
|
MV88E6XXX_EGRESS_DIR_EGRESS,
|
|
|
|
|
upstream_port);
|
2021-03-17 14:46:41 +01:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
|
return err;
|
2017-12-05 15:34:11 -05:00
|
|
|
}
|
|
|
|
|
|
2017-12-05 15:34:10 -05:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
|
2015-03-26 18:36:29 -07:00
|
|
|
{
|
2016-06-21 12:28:20 -04:00
|
|
|
struct dsa_switch *ds = chip->ds;
|
2016-09-21 01:40:31 +02:00
|
|
|
int err;
|
2015-05-06 01:09:47 +02:00
|
|
|
u16 reg;
|
2015-03-26 18:36:29 -07:00
|
|
|
|
2018-08-09 15:38:47 +02:00
|
|
|
chip->ports[port].chip = chip;
|
|
|
|
|
chip->ports[port].port = port;
|
|
|
|
|
|
2016-11-04 03:23:36 +01:00
|
|
|
/* MAC Forcing register: don't force link, speed, duplex or flow control
|
|
|
|
|
* state to any particular values on physical ports, but force the CPU
|
|
|
|
|
* port and all DSA ports to their maximum bandwidth and full duplex.
|
|
|
|
|
*/
|
|
|
|
|
if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
|
|
|
|
|
err = mv88e6xxx_port_setup_mac(chip, port, LINK_FORCED_UP,
|
|
|
|
|
SPEED_MAX, DUPLEX_FULL,
|
2018-08-09 15:38:37 +02:00
|
|
|
PAUSE_OFF,
|
2016-11-04 03:23:36 +01:00
|
|
|
PHY_INTERFACE_MODE_NA);
|
|
|
|
|
else
|
|
|
|
|
err = mv88e6xxx_port_setup_mac(chip, port, LINK_UNFORCED,
|
|
|
|
|
SPEED_UNFORCED, DUPLEX_UNFORCED,
|
2018-08-09 15:38:37 +02:00
|
|
|
PAUSE_ON,
|
2016-11-04 03:23:36 +01:00
|
|
|
PHY_INTERFACE_MODE_NA);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-05-06 01:09:47 +02:00
|
|
|
|
|
|
|
|
/* Port Control: disable Drop-on-Unlock, disable Drop-on-Lock,
|
|
|
|
|
* disable Header mode, enable IGMP/MLD snooping, disable VLAN
|
|
|
|
|
* tunneling, determine priority by looking at 802.1p and IP
|
|
|
|
|
* priority fields (IP prio has precedence), and set STP state
|
|
|
|
|
* to Forwarding.
|
|
|
|
|
*
|
|
|
|
|
* If this is the CPU link, use DSA or EDSA tagging depending
|
|
|
|
|
* on which tagging mode was configured.
|
|
|
|
|
*
|
|
|
|
|
* If this is a link to another switch, use DSA tagging mode.
|
|
|
|
|
*
|
|
|
|
|
* If this is the upstream port for this switch, enable
|
|
|
|
|
* forwarding of unknown unicasts and multicasts.
|
|
|
|
|
*/
|
2017-06-12 12:37:37 -04:00
|
|
|
reg = MV88E6XXX_PORT_CTL0_IGMP_MLD_SNOOP |
|
|
|
|
|
MV88E6185_PORT_CTL0_USE_TAG | MV88E6185_PORT_CTL0_USE_IP |
|
|
|
|
|
MV88E6XXX_PORT_CTL0_STATE_FORWARDING;
|
|
|
|
|
err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_CTL0, reg);
|
2016-12-03 04:35:19 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-08-17 23:52:52 +02:00
|
|
|
|
2017-03-11 16:13:00 -05:00
|
|
|
err = mv88e6xxx_setup_port_mode(chip, port);
|
2016-12-03 04:35:19 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-05-06 01:09:47 +02:00
|
|
|
|
2017-03-11 16:13:00 -05:00
|
|
|
err = mv88e6xxx_setup_egress_floods(chip, port);
|
2017-03-11 16:12:59 -05:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2015-08-13 12:52:23 -04:00
|
|
|
/* Port Control 2: don't force a good FCS, set the maximum frame size to
|
2016-02-26 13:16:07 -05:00
|
|
|
* 10240 bytes, disable 802.1q tags checking, don't discard tagged or
|
2015-08-13 12:52:23 -04:00
|
|
|
* untagged frames on this port, do a destination address lookup on all
|
|
|
|
|
* received packets as usual, disable ARP mirroring and don't send a
|
|
|
|
|
* copy of all transmitted/received frames on this port to the CPU.
|
2015-05-06 01:09:47 +02:00
|
|
|
*/
|
2017-02-04 20:15:28 +01:00
|
|
|
err = mv88e6xxx_port_set_map_da(chip, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-08-13 12:52:23 -04:00
|
|
|
|
2017-12-05 15:34:10 -05:00
|
|
|
err = mv88e6xxx_setup_upstream_port(chip, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-05-06 01:09:47 +02:00
|
|
|
|
2017-02-04 20:15:28 +01:00
|
|
|
err = mv88e6xxx_port_set_8021q_mode(chip, port,
|
2017-06-12 12:37:41 -04:00
|
|
|
MV88E6XXX_PORT_CTL2_8021Q_MODE_DISABLED);
|
2017-02-04 20:15:28 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
2017-06-08 18:34:13 -04:00
|
|
|
if (chip->info->ops->port_set_jumbo_size) {
|
|
|
|
|
err = chip->info->ops->port_set_jumbo_size(chip, port, 10240);
|
2016-12-03 04:45:17 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-18 20:25:39 +01:00
|
|
|
/* Port Association Vector: disable automatic address learning
|
|
|
|
|
* on all user ports since they start out in standalone
|
|
|
|
|
* mode. When joining a bridge, learning will be configured to
|
|
|
|
|
* match the bridge port settings. Enable learning on all
|
|
|
|
|
* DSA/CPU ports. NOTE: FROM_CPU frames always bypass the
|
|
|
|
|
* learning process.
|
|
|
|
|
*
|
|
|
|
|
* Disable HoldAt1, IntOnAgeOut, LockedPort, IgnoreWrongData,
|
|
|
|
|
* and RefreshLocked. I.e. setup standard automatic learning.
|
2015-05-06 01:09:47 +02:00
|
|
|
*/
|
2021-03-18 20:25:39 +01:00
|
|
|
if (dsa_is_user_port(ds, port))
|
2016-04-14 14:42:07 -04:00
|
|
|
reg = 0;
|
2021-03-18 20:25:39 +01:00
|
|
|
else
|
|
|
|
|
reg = 1 << port;
|
2015-11-03 10:52:36 -05:00
|
|
|
|
2017-06-12 12:37:43 -04:00
|
|
|
err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_ASSOC_VECTOR,
|
|
|
|
|
reg);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-05-06 01:09:47 +02:00
|
|
|
|
|
|
|
|
/* Egress rate control 2: disable egress rate control. */
|
2017-06-12 12:37:42 -04:00
|
|
|
err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_EGRESS_RATE_CTL2,
|
|
|
|
|
0x0000);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-05-06 01:09:47 +02:00
|
|
|
|
2017-06-08 18:34:12 -04:00
|
|
|
if (chip->info->ops->port_pause_limit) {
|
|
|
|
|
err = chip->info->ops->port_pause_limit(chip, port, 0, 0);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2016-12-03 04:45:19 +01:00
|
|
|
}
|
2015-05-06 01:09:47 +02:00
|
|
|
|
2017-03-11 16:13:01 -05:00
|
|
|
if (chip->info->ops->port_disable_learn_limit) {
|
|
|
|
|
err = chip->info->ops->port_disable_learn_limit(chip, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-11 16:13:02 -05:00
|
|
|
if (chip->info->ops->port_disable_pri_override) {
|
|
|
|
|
err = chip->info->ops->port_disable_pri_override(chip, port);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2016-12-03 04:35:16 +01:00
|
|
|
}
|
2016-08-22 16:01:02 +02:00
|
|
|
|
2016-12-03 04:35:16 +01:00
|
|
|
if (chip->info->ops->port_tag_remap) {
|
|
|
|
|
err = chip->info->ops->port_tag_remap(chip, port);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-05-06 01:09:47 +02:00
|
|
|
}
|
|
|
|
|
|
2016-12-03 04:45:18 +01:00
|
|
|
if (chip->info->ops->port_egress_rate_limiting) {
|
|
|
|
|
err = chip->info->ops->port_egress_rate_limiting(chip, port);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-05-06 01:09:47 +02:00
|
|
|
}
|
|
|
|
|
|
2019-07-31 10:23:49 +02:00
|
|
|
if (chip->info->ops->port_setup_message_port) {
|
|
|
|
|
err = chip->info->ops->port_setup_message_port(chip, port);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
2015-03-26 18:36:29 -07:00
|
|
|
|
net: dsa: mv88e6xxx: share the same default FDB
For hardware cross-chip bridging to work, user ports *and* DSA ports
need to share a common address database, in order to switch a frame to
the correct interconnected device.
This is currently working for VLAN filtering aware systems, since Linux
will implement a bridge group as a 802.1Q VLAN, which has its own FDB,
including DSA and CPU links as members.
However when the system doesn't support VLAN filtering, Linux only
relies on the port-based VLAN to implement a bridge group.
To fix hardware cross-chip bridging for such systems, set the same
default address database 0 for user and DSA ports, instead of giving
them all a different default database.
Note that the bridging code prevents frames to egress between unbridged
ports, and flushes FDB entries of a port when changing its STP state.
Also note that the FID 0 is special and means "all" for ATU operations,
but it's OK since it is used as a default forwarding address database.
Fixes: 2db9ce1fd9a3 ("net: dsa: mv88e6xxx: assign default FDB to ports")
Fixes: 466dfa077022 ("net: dsa: mv88e6xxx: assign dynamic FDB to bridges")
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-14 14:42:09 -04:00
|
|
|
/* Port based VLAN map: give each port the same default address
|
2016-02-26 13:16:06 -05:00
|
|
|
* database, and allow bidirectional communication between the
|
|
|
|
|
* CPU and DSA port(s), and the other ports.
|
2015-03-26 18:36:29 -07:00
|
|
|
*/
|
2016-11-04 03:23:29 +01:00
|
|
|
err = mv88e6xxx_port_set_fid(chip, port, 0);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2016-02-26 13:16:04 -05:00
|
|
|
|
2017-03-30 17:37:12 -04:00
|
|
|
err = mv88e6xxx_port_vlan_map(chip, port);
|
2016-09-21 01:40:31 +02:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2015-03-26 18:36:29 -07:00
|
|
|
|
|
|
|
|
/* Default VLAN ID and priority: don't set a default VLAN
|
|
|
|
|
* ID, and set the default packet priority to zero.
|
|
|
|
|
*/
|
2017-06-12 12:37:40 -04:00
|
|
|
return mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_DEFAULT_VLAN, 0);
|
2015-05-06 01:09:48 +02:00
|
|
|
}
|
|
|
|
|
|
2020-07-11 22:32:05 +02:00
|
|
|
static int mv88e6xxx_get_max_mtu(struct dsa_switch *ds, int port)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
|
|
|
|
|
if (chip->info->ops->port_set_jumbo_size)
|
|
|
|
|
return 10240;
|
2020-07-24 11:21:22 +12:00
|
|
|
else if (chip->info->ops->set_max_frame_size)
|
|
|
|
|
return 1632;
|
2020-07-11 22:32:05 +02:00
|
|
|
return 1522;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_change_mtu(struct dsa_switch *ds, int port, int new_mtu)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
if (chip->info->ops->port_set_jumbo_size)
|
|
|
|
|
ret = chip->info->ops->port_set_jumbo_size(chip, port, new_mtu);
|
2020-07-24 11:21:22 +12:00
|
|
|
else if (chip->info->ops->set_max_frame_size)
|
|
|
|
|
ret = chip->info->ops->set_max_frame_size(chip, new_mtu);
|
2020-07-11 22:32:05 +02:00
|
|
|
else
|
|
|
|
|
if (new_mtu > 1522)
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 01:03:24 +02:00
|
|
|
static int mv88e6xxx_port_enable(struct dsa_switch *ds, int port,
|
|
|
|
|
struct phy_device *phydev)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2017-05-26 18:02:42 -04:00
|
|
|
int err;
|
2017-05-26 01:03:24 +02:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-05-26 18:02:42 -04:00
|
|
|
err = mv88e6xxx_serdes_power(chip, port, true);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2017-05-26 01:03:24 +02:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-24 20:44:43 +01:00
|
|
|
static void mv88e6xxx_port_disable(struct dsa_switch *ds, int port)
|
2017-05-26 01:03:24 +02:00
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-05-26 18:02:42 -04:00
|
|
|
if (mv88e6xxx_serdes_power(chip, port, false))
|
|
|
|
|
dev_err(chip->dev, "failed to power off SERDES\n");
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2017-05-26 01:03:24 +02:00
|
|
|
}
|
|
|
|
|
|
2016-07-18 20:45:40 -04:00
|
|
|
static int mv88e6xxx_set_ageing_time(struct dsa_switch *ds,
|
|
|
|
|
unsigned int ageing_time)
|
|
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-07-18 20:45:40 -04:00
|
|
|
int err;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-03-11 16:12:48 -05:00
|
|
|
err = mv88e6xxx_g1_atu_set_age_time(chip, ageing_time);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-07-18 20:45:40 -04:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-11 17:16:36 -04:00
|
|
|
static int mv88e6xxx_stats_setup(struct mv88e6xxx_chip *chip)
|
2015-03-26 18:36:28 -07:00
|
|
|
{
|
2016-05-09 13:22:49 -04:00
|
|
|
int err;
|
2015-05-06 01:09:47 +02:00
|
|
|
|
2016-11-21 23:27:01 +01:00
|
|
|
/* Initialize the statistics unit */
|
2018-05-11 17:16:36 -04:00
|
|
|
if (chip->info->ops->stats_set_histogram) {
|
|
|
|
|
err = chip->info->ops->stats_set_histogram(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
2016-11-21 23:27:01 +01:00
|
|
|
|
2017-11-10 00:36:41 +01:00
|
|
|
return mv88e6xxx_g1_stats_clear(chip);
|
2016-07-18 20:45:30 -04:00
|
|
|
}
|
|
|
|
|
|
2019-01-09 00:24:03 +01:00
|
|
|
/* Check if the errata has already been applied. */
|
|
|
|
|
static bool mv88e6390_setup_errata_applied(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
int port;
|
|
|
|
|
int err;
|
|
|
|
|
u16 val;
|
|
|
|
|
|
|
|
|
|
for (port = 0; port < mv88e6xxx_num_ports(chip); port++) {
|
2019-08-26 23:31:51 +02:00
|
|
|
err = mv88e6xxx_port_hidden_read(chip, 0xf, port, 0, &val);
|
2019-01-09 00:24:03 +01:00
|
|
|
if (err) {
|
|
|
|
|
dev_err(chip->dev,
|
|
|
|
|
"Error reading hidden register: %d\n", err);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
if (val != 0x01c0)
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The 6390 copper ports have an errata which require poking magic
|
|
|
|
|
* values into undocumented hidden registers and then performing a
|
|
|
|
|
* software reset.
|
|
|
|
|
*/
|
|
|
|
|
static int mv88e6390_setup_errata(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
int port;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (mv88e6390_setup_errata_applied(chip))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* Set the ports into blocking mode */
|
|
|
|
|
for (port = 0; port < mv88e6xxx_num_ports(chip); port++) {
|
|
|
|
|
err = mv88e6xxx_port_set_state(chip, port, BR_STATE_DISABLED);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (port = 0; port < mv88e6xxx_num_ports(chip); port++) {
|
2019-08-26 23:31:51 +02:00
|
|
|
err = mv88e6xxx_port_hidden_write(chip, 0xf, port, 0, 0x01c0);
|
2019-01-09 00:24:03 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return mv88e6xxx_software_reset(chip);
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-25 01:03:52 +02:00
|
|
|
static void mv88e6xxx_teardown(struct dsa_switch *ds)
|
|
|
|
|
{
|
|
|
|
|
mv88e6xxx_teardown_devlink_params(ds);
|
2019-11-05 01:13:01 +01:00
|
|
|
dsa_devlink_resources_unregister(ds);
|
2020-09-18 21:11:07 +02:00
|
|
|
mv88e6xxx_teardown_devlink_regions(ds);
|
2019-10-25 01:03:52 +02:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static int mv88e6xxx_setup(struct dsa_switch *ds)
|
2016-05-09 13:22:50 -04:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2018-08-09 15:38:45 +02:00
|
|
|
u8 cmode;
|
2016-05-09 13:22:50 -04:00
|
|
|
int err;
|
2016-05-09 13:22:56 -04:00
|
|
|
int i;
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
chip->ds = ds;
|
2017-01-24 14:53:50 +01:00
|
|
|
ds->slave_mii_bus = mv88e6xxx_default_mdio_bus(chip);
|
2016-05-09 13:22:50 -04:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-05-09 13:22:50 -04:00
|
|
|
|
2019-01-09 00:24:03 +01:00
|
|
|
if (chip->info->ops->setup_errata) {
|
|
|
|
|
err = chip->info->ops->setup_errata(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-09 15:38:45 +02:00
|
|
|
/* Cache the cmode of each port. */
|
|
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
|
|
|
|
|
if (chip->info->ops->port_get_cmode) {
|
|
|
|
|
err = chip->info->ops->port_get_cmode(chip, i, &cmode);
|
|
|
|
|
if (err)
|
2018-08-14 12:09:05 +03:00
|
|
|
goto unlock;
|
2018-08-09 15:38:45 +02:00
|
|
|
|
|
|
|
|
chip->ports[i].cmode = cmode;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-18 20:45:30 -04:00
|
|
|
/* Setup Switch Port Registers */
|
2016-09-29 12:21:57 -04:00
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
|
2019-08-19 16:00:52 -04:00
|
|
|
if (dsa_is_unused_port(ds, i))
|
|
|
|
|
continue;
|
|
|
|
|
|
2019-07-31 10:23:48 +02:00
|
|
|
/* Prevent the use of an invalid port. */
|
2019-08-19 16:00:52 -04:00
|
|
|
if (mv88e6xxx_is_invalid_port(chip, i)) {
|
2019-07-31 10:23:48 +02:00
|
|
|
dev_err(chip->dev, "port %d is invalid\n", i);
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
goto unlock;
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-18 20:45:30 -04:00
|
|
|
err = mv88e6xxx_setup_port(chip, i);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-19 10:55:36 -04:00
|
|
|
err = mv88e6xxx_irl_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2017-10-13 14:18:05 -04:00
|
|
|
err = mv88e6xxx_mac_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2017-05-26 18:03:05 -04:00
|
|
|
err = mv88e6xxx_phy_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2017-05-01 14:05:13 -04:00
|
|
|
err = mv88e6xxx_vtu_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2017-03-30 17:37:08 -04:00
|
|
|
err = mv88e6xxx_pvt_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2017-03-11 16:12:49 -05:00
|
|
|
err = mv88e6xxx_atu_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2017-11-09 22:29:56 +01:00
|
|
|
err = mv88e6xxx_broadcast_setup(chip, 0);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2017-07-17 13:03:43 -04:00
|
|
|
err = mv88e6xxx_pot_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2018-05-09 11:38:51 -04:00
|
|
|
err = mv88e6xxx_rmu_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2017-07-17 13:03:41 -04:00
|
|
|
err = mv88e6xxx_rsvd2cpu_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
2016-12-03 04:45:16 +01:00
|
|
|
|
2018-04-26 21:56:44 -04:00
|
|
|
err = mv88e6xxx_trunk_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2018-04-26 21:56:45 -04:00
|
|
|
err = mv88e6xxx_devmap_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2018-05-11 17:16:35 -04:00
|
|
|
err = mv88e6xxx_pri_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2018-02-14 01:07:50 +01:00
|
|
|
/* Setup PTP Hardware Clock and timestamping */
|
2018-02-14 01:07:45 +01:00
|
|
|
if (chip->info->ptp_support) {
|
|
|
|
|
err = mv88e6xxx_ptp_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
2018-02-14 01:07:50 +01:00
|
|
|
|
|
|
|
|
err = mv88e6xxx_hwtstamp_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
2018-02-14 01:07:45 +01:00
|
|
|
}
|
|
|
|
|
|
2018-05-11 17:16:36 -04:00
|
|
|
err = mv88e6xxx_stats_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
2015-08-13 12:52:18 -04:00
|
|
|
unlock:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2015-06-20 21:31:29 +02:00
|
|
|
|
2019-11-05 01:13:01 +01:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
/* Have to be called without holding the register lock, since
|
|
|
|
|
* they take the devlink lock, and we later take the locks in
|
|
|
|
|
* the reverse order when getting/setting parameters or
|
|
|
|
|
* resource occupancy.
|
2019-10-25 01:03:52 +02:00
|
|
|
*/
|
2019-11-05 01:13:01 +01:00
|
|
|
err = mv88e6xxx_setup_devlink_resources(ds);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_setup_devlink_params(ds);
|
|
|
|
|
if (err)
|
2020-09-18 21:11:07 +02:00
|
|
|
goto out_resources;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_setup_devlink_regions(ds);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_params;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
out_params:
|
|
|
|
|
mv88e6xxx_teardown_devlink_params(ds);
|
|
|
|
|
out_resources:
|
|
|
|
|
dsa_devlink_resources_unregister(ds);
|
2019-11-05 01:13:01 +01:00
|
|
|
|
|
|
|
|
return err;
|
2015-05-06 01:09:47 +02:00
|
|
|
}
|
|
|
|
|
|
2016-08-15 17:19:00 -04:00
|
|
|
static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
|
2015-04-02 04:06:36 +02:00
|
|
|
{
|
2017-01-24 14:53:49 +01:00
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
|
|
|
|
|
struct mv88e6xxx_chip *chip = mdio_bus->chip;
|
2016-08-15 17:19:00 -04:00
|
|
|
u16 val;
|
|
|
|
|
int err;
|
2015-04-02 04:06:36 +02:00
|
|
|
|
2017-01-24 14:53:48 +01:00
|
|
|
if (!chip->info->ops->phy_read)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-01-24 14:53:48 +01:00
|
|
|
err = chip->info->ops->phy_read(chip, bus, phy, reg, &val);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-08-15 17:19:00 -04:00
|
|
|
|
2017-02-01 03:40:05 +01:00
|
|
|
if (reg == MII_PHYSID2) {
|
2018-11-12 18:51:01 +01:00
|
|
|
/* Some internal PHYs don't have a model number. */
|
|
|
|
|
if (chip->info->family != MV88E6XXX_FAMILY_6165)
|
|
|
|
|
/* Then there is the 6165 family. It gets is
|
|
|
|
|
* PHYs correct. But it can also have two
|
|
|
|
|
* SERDES interfaces in the PHY address
|
|
|
|
|
* space. And these don't have a model
|
|
|
|
|
* number. But they are not PHYs, so we don't
|
|
|
|
|
* want to give them something a PHY driver
|
|
|
|
|
* will recognise.
|
|
|
|
|
*
|
|
|
|
|
* Use the mv88e6390 family model number
|
|
|
|
|
* instead, for anything which really could be
|
|
|
|
|
* a PHY,
|
|
|
|
|
*/
|
|
|
|
|
if (!(val & 0x3f0))
|
|
|
|
|
val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
|
2017-02-01 03:40:05 +01:00
|
|
|
}
|
|
|
|
|
|
2016-08-15 17:19:00 -04:00
|
|
|
return err ? err : val;
|
2015-04-02 04:06:36 +02:00
|
|
|
}
|
|
|
|
|
|
2016-08-15 17:19:00 -04:00
|
|
|
static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
|
2015-04-02 04:06:36 +02:00
|
|
|
{
|
2017-01-24 14:53:49 +01:00
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
|
|
|
|
|
struct mv88e6xxx_chip *chip = mdio_bus->chip;
|
2016-08-15 17:19:00 -04:00
|
|
|
int err;
|
2015-04-02 04:06:36 +02:00
|
|
|
|
2017-01-24 14:53:48 +01:00
|
|
|
if (!chip->info->ops->phy_write)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-01-24 14:53:48 +01:00
|
|
|
err = chip->info->ops->phy_write(chip, bus, phy, reg, val);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-08-15 17:19:00 -04:00
|
|
|
|
|
|
|
|
return err;
|
2015-04-02 04:06:36 +02:00
|
|
|
}
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip *chip,
|
2017-01-24 14:53:50 +01:00
|
|
|
struct device_node *np,
|
|
|
|
|
bool external)
|
2016-06-04 21:17:06 +02:00
|
|
|
{
|
|
|
|
|
static int index;
|
2017-01-24 14:53:49 +01:00
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus;
|
2016-06-04 21:17:06 +02:00
|
|
|
struct mii_bus *bus;
|
|
|
|
|
int err;
|
|
|
|
|
|
2018-02-22 01:51:49 +01:00
|
|
|
if (external) {
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-02-22 01:51:49 +01:00
|
|
|
err = mv88e6xxx_g2_scratch_gpio_set_smi(chip, true);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-22 01:51:49 +01:00
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-24 14:53:49 +01:00
|
|
|
bus = devm_mdiobus_alloc_size(chip->dev, sizeof(*mdio_bus));
|
2016-06-04 21:17:06 +02:00
|
|
|
if (!bus)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2017-01-24 14:53:49 +01:00
|
|
|
mdio_bus = bus->priv;
|
2017-01-24 14:53:50 +01:00
|
|
|
mdio_bus->bus = bus;
|
2017-01-24 14:53:49 +01:00
|
|
|
mdio_bus->chip = chip;
|
2017-01-24 14:53:50 +01:00
|
|
|
INIT_LIST_HEAD(&mdio_bus->list);
|
|
|
|
|
mdio_bus->external = external;
|
2017-01-24 14:53:49 +01:00
|
|
|
|
2016-06-04 21:17:06 +02:00
|
|
|
if (np) {
|
|
|
|
|
bus->name = np->full_name;
|
2017-07-18 16:43:19 -05:00
|
|
|
snprintf(bus->id, MII_BUS_ID_SIZE, "%pOF", np);
|
2016-06-04 21:17:06 +02:00
|
|
|
} else {
|
|
|
|
|
bus->name = "mv88e6xxx SMI";
|
|
|
|
|
snprintf(bus->id, MII_BUS_ID_SIZE, "mv88e6xxx-%d", index++);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bus->read = mv88e6xxx_mdio_read;
|
|
|
|
|
bus->write = mv88e6xxx_mdio_write;
|
2016-06-21 12:28:20 -04:00
|
|
|
bus->parent = chip->dev;
|
2016-06-04 21:17:06 +02:00
|
|
|
|
2018-03-17 20:32:05 +01:00
|
|
|
if (!external) {
|
|
|
|
|
err = mv88e6xxx_g2_irq_mdio_setup(chip, bus);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-15 16:56:19 -07:00
|
|
|
err = of_mdiobus_register(bus, np);
|
2016-06-04 21:17:06 +02:00
|
|
|
if (err) {
|
2016-06-21 12:28:20 -04:00
|
|
|
dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
|
2018-03-17 20:32:05 +01:00
|
|
|
mv88e6xxx_g2_irq_mdio_free(chip, bus);
|
2017-01-24 14:53:50 +01:00
|
|
|
return err;
|
2016-06-04 21:17:06 +02:00
|
|
|
}
|
2017-01-24 14:53:50 +01:00
|
|
|
|
|
|
|
|
if (external)
|
|
|
|
|
list_add_tail(&mdio_bus->list, &chip->mdios);
|
|
|
|
|
else
|
|
|
|
|
list_add(&mdio_bus->list, &chip->mdios);
|
2016-06-04 21:17:06 +02:00
|
|
|
|
|
|
|
|
return 0;
|
2017-01-24 14:53:50 +01:00
|
|
|
}
|
2016-06-04 21:17:06 +02:00
|
|
|
|
2017-12-07 01:05:57 +01:00
|
|
|
static void mv88e6xxx_mdios_unregister(struct mv88e6xxx_chip *chip)
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus;
|
|
|
|
|
struct mii_bus *bus;
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(mdio_bus, &chip->mdios, list) {
|
|
|
|
|
bus = mdio_bus->bus;
|
|
|
|
|
|
2018-03-17 20:32:05 +01:00
|
|
|
if (!mdio_bus->external)
|
|
|
|
|
mv88e6xxx_g2_irq_mdio_free(chip, bus);
|
|
|
|
|
|
2017-12-07 01:05:57 +01:00
|
|
|
mdiobus_unregister(bus);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-24 14:53:50 +01:00
|
|
|
static int mv88e6xxx_mdios_register(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct device_node *np)
|
|
|
|
|
{
|
|
|
|
|
struct device_node *child;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/* Always register one mdio bus for the internal/default mdio
|
|
|
|
|
* bus. This maybe represented in the device tree, but is
|
|
|
|
|
* optional.
|
|
|
|
|
*/
|
|
|
|
|
child = of_get_child_by_name(np, "mdio");
|
|
|
|
|
err = mv88e6xxx_mdio_register(chip, child, false);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
/* Walk the device tree, and see if there are any other nodes
|
|
|
|
|
* which say they are compatible with the external mdio
|
|
|
|
|
* bus.
|
|
|
|
|
*/
|
|
|
|
|
for_each_available_child_of_node(np, child) {
|
2020-09-01 04:32:57 +02:00
|
|
|
if (of_device_is_compatible(
|
|
|
|
|
child, "marvell,mv88e6xxx-mdio-external")) {
|
2017-01-24 14:53:50 +01:00
|
|
|
err = mv88e6xxx_mdio_register(chip, child, true);
|
2017-12-07 01:05:57 +01:00
|
|
|
if (err) {
|
|
|
|
|
mv88e6xxx_mdios_unregister(chip);
|
2019-07-23 16:13:07 +05:30
|
|
|
of_node_put(child);
|
2017-01-24 14:53:50 +01:00
|
|
|
return err;
|
2017-12-07 01:05:57 +01:00
|
|
|
}
|
2017-01-24 14:53:50 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
2016-06-04 21:17:06 +02:00
|
|
|
}
|
|
|
|
|
|
2016-07-20 18:18:35 -04:00
|
|
|
static int mv88e6xxx_get_eeprom_len(struct dsa_switch *ds)
|
|
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-07-20 18:18:35 -04:00
|
|
|
|
|
|
|
|
return chip->eeprom_len;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_get_eeprom(struct dsa_switch *ds,
|
|
|
|
|
struct ethtool_eeprom *eeprom, u8 *data)
|
|
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-07-20 18:18:35 -04:00
|
|
|
int err;
|
|
|
|
|
|
2016-09-29 12:22:02 -04:00
|
|
|
if (!chip->info->ops->get_eeprom)
|
|
|
|
|
return -EOPNOTSUPP;
|
2016-07-20 18:18:35 -04:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-09-29 12:22:02 -04:00
|
|
|
err = chip->info->ops->get_eeprom(chip, eeprom, data);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-07-20 18:18:35 -04:00
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
eeprom->magic = 0xc3ec4951;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_set_eeprom(struct dsa_switch *ds,
|
|
|
|
|
struct ethtool_eeprom *eeprom, u8 *data)
|
|
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-07-20 18:18:35 -04:00
|
|
|
int err;
|
|
|
|
|
|
2016-09-29 12:22:02 -04:00
|
|
|
if (!chip->info->ops->set_eeprom)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2016-07-20 18:18:35 -04:00
|
|
|
if (eeprom->magic != 0xc3ec4951)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-09-29 12:22:02 -04:00
|
|
|
err = chip->info->ops->set_eeprom(chip, eeprom, data);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-07-20 18:18:35 -04:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-29 12:22:00 -04:00
|
|
|
static const struct mv88e6xxx_ops mv88e6085_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6097 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
|
2017-05-26 18:03:06 -04:00
|
|
|
.phy_read = mv88e6185_phy_ppu_read,
|
|
|
|
|
.phy_write = mv88e6185_phy_ppu_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:28 -05:00
|
|
|
.ppu_enable = mv88e6185_g1_ppu_enable,
|
|
|
|
|
.ppu_disable = mv88e6185_g1_ppu_disable,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6185_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6085_g1_rmu_disable,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2020-07-24 11:21:22 +12:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6095_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6095 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
|
2017-05-26 18:03:06 -04:00
|
|
|
.phy_read = mv88e6185_phy_ppu_read,
|
|
|
|
|
.phy_write = mv88e6185_phy_ppu_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6185_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6085_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6185_port_set_forward_unknown,
|
|
|
|
|
.port_set_mcast_flood = mv88e6185_port_set_default_forward,
|
2017-02-04 20:15:28 +01:00
|
|
|
.port_set_upstream_port = mv88e6095_port_set_upstream_port,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
|
2020-11-24 17:34:38 +13:00
|
|
|
.serdes_power = mv88e6185_serdes_power,
|
|
|
|
|
.serdes_get_lane = mv88e6185_serdes_get_lane,
|
|
|
|
|
.serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
|
2016-12-05 17:30:28 -05:00
|
|
|
.ppu_enable = mv88e6185_g1_ppu_enable,
|
|
|
|
|
.ppu_disable = mv88e6185_g1_ppu_disable,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6185_g1_reset,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2020-07-24 11:21:22 +12:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
2016-11-22 17:47:21 +01:00
|
|
|
static const struct mv88e6xxx_ops mv88e6097_ops = {
|
2016-11-25 09:41:30 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6097 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-11-22 17:47:21 +01:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6185_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6095_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-22 17:47:21 +01:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-22 17:47:21 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
|
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-14 11:29:30 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2020-11-24 17:34:38 +13:00
|
|
|
.serdes_power = mv88e6185_serdes_power,
|
|
|
|
|
.serdes_get_lane = mv88e6185_serdes_get_lane,
|
|
|
|
|
.serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
|
2020-11-24 17:34:39 +13:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
|
|
|
|
.serdes_irq_enable = mv88e6097_serdes_irq_enable,
|
|
|
|
|
.serdes_irq_status = mv88e6097_serdes_irq_status,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6085_g1_rmu_disable,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2020-07-24 11:21:22 +12:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-11-22 17:47:21 +01:00
|
|
|
};
|
|
|
|
|
|
2016-09-29 12:22:00 -04:00
|
|
|
static const struct mv88e6xxx_ops mv88e6123_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6165 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2017-06-02 23:22:45 +02:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6085_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2017-06-02 23:22:46 +02:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2020-07-24 11:21:22 +12:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6131_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6185 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
|
2017-05-26 18:03:06 -04:00
|
|
|
.phy_read = mv88e6185_phy_ppu_read,
|
|
|
|
|
.phy_write = mv88e6185_phy_ppu_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6185_port_set_forward_unknown,
|
|
|
|
|
.port_set_mcast_flood = mv88e6185_port_set_default_forward,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-02-04 20:15:28 +01:00
|
|
|
.port_set_upstream_port = mv88e6095_port_set_upstream_port,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2018-08-09 15:38:37 +02:00
|
|
|
.port_set_pause = mv88e6185_port_set_pause,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
|
2016-12-05 17:30:28 -05:00
|
|
|
.ppu_enable = mv88e6185_g1_ppu_enable,
|
2018-05-09 11:38:49 -04:00
|
|
|
.set_cascade_port = mv88e6185_g1_set_cascade_port,
|
2016-12-05 17:30:28 -05:00
|
|
|
.ppu_disable = mv88e6185_g1_ppu_disable,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6185_g1_reset,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
2017-03-28 13:50:32 -04:00
|
|
|
static const struct mv88e6xxx_ops mv88e6141_ops = {
|
|
|
|
|
/* MV88E6XXX_FAMILY_6341 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2017-03-28 13:50:32 -04:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
|
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2017-03-28 13:50:32 -04:00
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6341_port_set_speed_duplex,
|
2019-03-08 01:21:27 +01:00
|
|
|
.port_max_speed_mode = mv88e6341_port_max_speed_mode,
|
2017-03-28 13:50:32 -04:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
|
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2017-03-28 13:50:32 -04:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2017-03-28 13:50:32 -04:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-28 13:50:32 -04:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
|
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-08-26 23:31:55 +02:00
|
|
|
.port_set_cmode = mv88e6341_port_set_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2017-03-28 13:50:32 -04:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2017-03-28 13:50:32 -04:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
|
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-03-28 13:50:32 -04:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
|
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2017-03-28 13:50:32 -04:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2019-08-26 23:31:53 +02:00
|
|
|
.serdes_power = mv88e6390_serdes_power,
|
|
|
|
|
.serdes_get_lane = mv88e6341_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
/* Check status register pause & lpa register */
|
|
|
|
|
.serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6390_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6390_serdes_irq_status,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2019-02-25 12:39:55 +01:00
|
|
|
.phylink_validate = mv88e6341_phylink_validate,
|
2017-03-28 13:50:32 -04:00
|
|
|
};
|
|
|
|
|
|
2016-09-29 12:22:00 -04:00
|
|
|
static const struct mv88e6xxx_ops mv88e6161_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6165 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2017-06-02 23:22:45 +02:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2019-03-01 23:43:39 +01:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-07-18 22:38:21 +02:00
|
|
|
.avb_ops = &mv88e6165_avb_ops,
|
2018-07-18 22:38:22 +02:00
|
|
|
.ptp_ops = &mv88e6165_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6165_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6165 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2017-01-24 14:53:47 +01:00
|
|
|
.phy_read = mv88e6165_phy_read,
|
|
|
|
|
.phy_write = mv88e6165_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-07-18 22:38:21 +02:00
|
|
|
.avb_ops = &mv88e6165_avb_ops,
|
2018-07-18 22:38:22 +02:00
|
|
|
.ptp_ops = &mv88e6165_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6171_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6351 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-10 15:44:01 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6172_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6352 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:02 -04:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-04 03:23:34 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6352_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6352_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2019-08-31 16:18:31 -04:00
|
|
|
.serdes_get_lane = mv88e6352_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
.serdes_pcs_get_state = mv88e6352_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6352_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6352_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6352_serdes_pcs_link_up,
|
2017-05-26 01:03:21 +02:00
|
|
|
.serdes_power = mv88e6352_serdes_power,
|
2020-02-16 18:54:14 +01:00
|
|
|
.serdes_get_regs_len = mv88e6352_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6352_serdes_get_regs,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6352_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6175_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6351 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-10 15:44:01 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6176_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6352 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:02 -04:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-04 03:23:34 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6352_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6352_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2019-08-31 16:18:31 -04:00
|
|
|
.serdes_get_lane = mv88e6352_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
.serdes_pcs_get_state = mv88e6352_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6352_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6352_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6352_serdes_pcs_link_up,
|
2017-05-26 01:03:21 +02:00
|
|
|
.serdes_power = mv88e6352_serdes_power,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6352_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6352_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6352_serdes_irq_status,
|
2020-02-16 18:54:14 +01:00
|
|
|
.serdes_get_regs_len = mv88e6352_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6352_serdes_get_regs,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6352_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6185_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6185 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
|
2017-05-26 18:03:06 -04:00
|
|
|
.phy_read = mv88e6185_phy_ppu_read,
|
|
|
|
|
.phy_write = mv88e6185_phy_ppu_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6185_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6085_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6185_port_set_forward_unknown,
|
|
|
|
|
.port_set_mcast_flood = mv88e6185_port_set_default_forward,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6095_port_egress_rate_limiting,
|
2017-02-04 20:15:28 +01:00
|
|
|
.port_set_upstream_port = mv88e6095_port_set_upstream_port,
|
2018-08-09 15:38:37 +02:00
|
|
|
.port_set_pause = mv88e6185_port_set_pause,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
|
2020-11-24 17:34:38 +13:00
|
|
|
.serdes_power = mv88e6185_serdes_power,
|
|
|
|
|
.serdes_get_lane = mv88e6185_serdes_get_lane,
|
|
|
|
|
.serdes_pcs_get_state = mv88e6185_serdes_pcs_get_state,
|
2018-05-09 11:38:49 -04:00
|
|
|
.set_cascade_port = mv88e6185_g1_set_cascade_port,
|
2016-12-05 17:30:28 -05:00
|
|
|
.ppu_enable = mv88e6185_g1_ppu_enable,
|
|
|
|
|
.ppu_disable = mv88e6185_g1_ppu_disable,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6185_g1_reset,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2020-07-24 11:21:22 +12:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
2016-11-21 23:26:57 +01:00
|
|
|
static const struct mv88e6xxx_ops mv88e6190_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-09 00:24:03 +01:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 18:07:16 -05:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 23:26:57 +01:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6390_port_set_speed_duplex,
|
2019-03-08 01:21:27 +01:00
|
|
|
.port_max_speed_mode = mv88e6390_port_max_speed_mode,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2020-07-24 11:21:21 +12:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-11 00:32:15 +01:00
|
|
|
.port_set_cmode = mv88e6390_port_set_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:27:00 +01:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 23:27:01 +01:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2016-11-21 23:27:04 +01:00
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-09 00:03:43 +01:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 04:45:16 +01:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:27 -04:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2017-05-26 01:03:23 +02:00
|
|
|
.serdes_power = mv88e6390_serdes_power,
|
2019-08-26 23:31:52 +02:00
|
|
|
.serdes_get_lane = mv88e6390_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
/* Check status register pause & lpa register */
|
|
|
|
|
.serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6390_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6390_serdes_irq_status,
|
2020-01-18 19:40:56 +01:00
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 18:54:15 +01:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6390_phylink_validate,
|
2016-11-21 23:26:57 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6190x_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-09 00:24:03 +01:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 18:07:16 -05:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 23:26:57 +01:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6390x_port_set_speed_duplex,
|
2019-03-08 01:21:27 +01:00
|
|
|
.port_max_speed_mode = mv88e6390x_port_max_speed_mode,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2020-07-24 11:21:21 +12:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-11 00:32:15 +01:00
|
|
|
.port_set_cmode = mv88e6390x_port_set_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:27:00 +01:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 23:27:01 +01:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2016-11-21 23:27:04 +01:00
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-09 00:03:43 +01:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 04:45:16 +01:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:27 -04:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2019-08-26 23:31:53 +02:00
|
|
|
.serdes_power = mv88e6390_serdes_power,
|
2019-08-26 23:31:52 +02:00
|
|
|
.serdes_get_lane = mv88e6390x_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
/* Check status register pause & lpa register */
|
|
|
|
|
.serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6390_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6390_serdes_irq_status,
|
2020-01-18 19:40:56 +01:00
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 18:54:15 +01:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6390x_phylink_validate,
|
2016-11-21 23:26:57 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6191_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-09 00:24:03 +01:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 18:07:16 -05:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 23:26:57 +01:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6390_port_set_speed_duplex,
|
2019-03-08 01:21:27 +01:00
|
|
|
.port_max_speed_mode = mv88e6390_port_max_speed_mode,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-11 00:32:15 +01:00
|
|
|
.port_set_cmode = mv88e6390_port_set_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:27:00 +01:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 23:27:01 +01:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2016-11-21 23:27:04 +01:00
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-09 00:03:43 +01:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 04:45:16 +01:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:27 -04:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2017-05-26 01:03:23 +02:00
|
|
|
.serdes_power = mv88e6390_serdes_power,
|
2019-08-26 23:31:52 +02:00
|
|
|
.serdes_get_lane = mv88e6390_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
/* Check status register pause & lpa register */
|
|
|
|
|
.serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6390_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6390_serdes_irq_status,
|
2020-01-18 19:40:56 +01:00
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 18:54:15 +01:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-07-18 22:38:20 +02:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
|
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6390_phylink_validate,
|
2016-11-21 23:26:57 +01:00
|
|
|
};
|
|
|
|
|
|
2016-09-29 12:22:00 -04:00
|
|
|
static const struct mv88e6xxx_ops mv88e6240_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6352 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:02 -04:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-04 03:23:34 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6352_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6352_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2019-08-31 16:18:31 -04:00
|
|
|
.serdes_get_lane = mv88e6352_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
.serdes_pcs_get_state = mv88e6352_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6352_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6352_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6352_serdes_pcs_link_up,
|
2017-05-26 01:03:21 +02:00
|
|
|
.serdes_power = mv88e6352_serdes_power,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6352_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6352_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6352_serdes_irq_status,
|
2020-02-16 18:54:14 +01:00
|
|
|
.serdes_get_regs_len = mv88e6352_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6352_serdes_get_regs,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6352_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6250_ops = {
|
|
|
|
|
/* MV88E6XXX_FAMILY_6250 */
|
|
|
|
|
.ieee_pri_map = mv88e6250_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
|
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
|
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
|
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6250_port_set_speed_duplex,
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
|
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
|
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
|
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
|
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
|
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
|
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
|
|
|
|
.stats_get_sset_count = mv88e6250_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6250_stats_get_strings,
|
|
|
|
|
.stats_get_stats = mv88e6250_stats_get_stats,
|
|
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
|
|
|
|
.watchdog_ops = &mv88e6250_watchdog_ops,
|
|
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
|
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
|
|
|
|
.reset = mv88e6250_g1_reset,
|
2021-01-25 16:04:48 +01:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2021-01-25 16:04:49 +01:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2019-07-31 10:23:51 +02:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
|
|
|
|
.ptp_ops = &mv88e6250_ptp_ops,
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
.phylink_validate = mv88e6065_phylink_validate,
|
|
|
|
|
};
|
|
|
|
|
|
2016-11-21 23:26:57 +01:00
|
|
|
static const struct mv88e6xxx_ops mv88e6290_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-09 00:24:03 +01:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 18:07:16 -05:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 23:26:57 +01:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6390_port_set_speed_duplex,
|
2019-03-08 01:21:27 +01:00
|
|
|
.port_max_speed_mode = mv88e6390_port_max_speed_mode,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-11 00:32:15 +01:00
|
|
|
.port_set_cmode = mv88e6390_port_set_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:27:00 +01:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 23:27:01 +01:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2016-11-21 23:27:04 +01:00
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-09 00:03:43 +01:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 04:45:16 +01:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:27 -04:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2017-05-26 01:03:23 +02:00
|
|
|
.serdes_power = mv88e6390_serdes_power,
|
2019-08-26 23:31:52 +02:00
|
|
|
.serdes_get_lane = mv88e6390_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
/* Check status register pause & lpa register */
|
|
|
|
|
.serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6390_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6390_serdes_irq_status,
|
2020-01-18 19:40:56 +01:00
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 18:54:15 +01:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6390_phylink_validate,
|
2016-11-21 23:26:57 +01:00
|
|
|
};
|
|
|
|
|
|
2016-09-29 12:22:00 -04:00
|
|
|
static const struct mv88e6xxx_ops mv88e6320_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6320 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:02 -04:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6320_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2018-12-19 18:28:54 +01:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6321_ops = {
|
2017-07-17 13:03:37 -04:00
|
|
|
/* MV88E6XXX_FAMILY_6320 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:02 -04:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6320_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2018-12-19 18:28:54 +01:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
2017-03-28 13:50:33 -04:00
|
|
|
static const struct mv88e6xxx_ops mv88e6341_ops = {
|
|
|
|
|
/* MV88E6XXX_FAMILY_6341 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2017-03-28 13:50:33 -04:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
|
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2017-03-28 13:50:33 -04:00
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6341_port_set_speed_duplex,
|
2019-03-08 01:21:27 +01:00
|
|
|
.port_max_speed_mode = mv88e6341_port_max_speed_mode,
|
2017-03-28 13:50:33 -04:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
|
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2017-03-28 13:50:33 -04:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2017-03-28 13:50:33 -04:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-28 13:50:33 -04:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
|
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-08-26 23:31:55 +02:00
|
|
|
.port_set_cmode = mv88e6341_port_set_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2017-03-28 13:50:33 -04:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2017-03-28 13:50:33 -04:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
|
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-03-28 13:50:33 -04:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
|
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2017-03-28 13:50:33 -04:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2019-08-26 23:31:53 +02:00
|
|
|
.serdes_power = mv88e6390_serdes_power,
|
|
|
|
|
.serdes_get_lane = mv88e6341_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
/* Check status register pause & lpa register */
|
|
|
|
|
.serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6390_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6390_serdes_irq_status,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2019-02-25 12:39:55 +01:00
|
|
|
.phylink_validate = mv88e6341_phylink_validate,
|
2017-03-28 13:50:33 -04:00
|
|
|
};
|
|
|
|
|
|
2016-09-29 12:22:00 -04:00
|
|
|
static const struct mv88e6xxx_ops mv88e6350_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6351 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-10 15:44:01 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6351_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6351 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-10 15:44:01 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6185_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6352_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6352 */
|
2018-05-11 17:16:35 -04:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 12:22:02 -04:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 12:22:01 -04:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2016-09-29 12:22:00 -04:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
2016-11-04 03:23:32 +01:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-04 03:23:34 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6352_port_set_speed_duplex,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:26:58 +01:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-10 00:36:41 +01:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2016-11-21 23:27:03 +01:00
|
|
|
.stats_get_stats = mv88e6095_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-09 00:03:42 +01:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 13:03:41 -04:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6352_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:22 -04:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 14:05:23 -04:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2019-08-31 16:18:31 -04:00
|
|
|
.serdes_get_lane = mv88e6352_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
.serdes_pcs_get_state = mv88e6352_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6352_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6352_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6352_serdes_pcs_link_up,
|
2017-05-26 01:03:21 +02:00
|
|
|
.serdes_power = mv88e6352_serdes_power,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6352_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6352_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6352_serdes_irq_status,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-03-01 02:02:31 +01:00
|
|
|
.serdes_get_sset_count = mv88e6352_serdes_get_sset_count,
|
|
|
|
|
.serdes_get_strings = mv88e6352_serdes_get_strings,
|
|
|
|
|
.serdes_get_stats = mv88e6352_serdes_get_stats,
|
2020-02-16 18:54:14 +01:00
|
|
|
.serdes_get_regs_len = mv88e6352_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6352_serdes_get_regs,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6352_phylink_validate,
|
2016-09-29 12:22:00 -04:00
|
|
|
};
|
|
|
|
|
|
2016-11-21 23:26:57 +01:00
|
|
|
static const struct mv88e6xxx_ops mv88e6390_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-09 00:24:03 +01:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 18:07:16 -05:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 23:26:57 +01:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6390_port_set_speed_duplex,
|
2019-03-08 01:21:27 +01:00
|
|
|
.port_max_speed_mode = mv88e6390_port_max_speed_mode,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-11 00:32:15 +01:00
|
|
|
.port_set_cmode = mv88e6390_port_set_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:27:00 +01:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 23:27:01 +01:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2016-11-21 23:27:04 +01:00
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-09 00:03:43 +01:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 04:45:16 +01:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:27 -04:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2017-05-26 01:03:23 +02:00
|
|
|
.serdes_power = mv88e6390_serdes_power,
|
2019-08-26 23:31:52 +02:00
|
|
|
.serdes_get_lane = mv88e6390_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
/* Check status register pause & lpa register */
|
|
|
|
|
.serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6390_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6390_serdes_irq_status,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2019-12-25 08:22:38 +03:00
|
|
|
.serdes_get_sset_count = mv88e6390_serdes_get_sset_count,
|
|
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 18:54:15 +01:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6390_phylink_validate,
|
2016-11-21 23:26:57 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6390x_ops = {
|
2016-11-21 23:26:59 +01:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-09 00:24:03 +01:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 10:55:36 -04:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 18:07:16 -05:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 23:26:57 +01:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 17:34:37 +13:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6390x_port_set_speed_duplex,
|
2019-03-08 01:21:27 +01:00
|
|
|
.port_max_speed_mode = mv88e6390x_port_max_speed_mode,
|
2016-12-03 04:35:16 +01:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 16:00:48 -04:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 04:35:19 +01:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 18:34:13 -04:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 04:45:18 +01:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 18:34:12 -04:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 16:13:01 -05:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 16:13:02 -05:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 15:38:45 +02:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-11 00:32:14 +01:00
|
|
|
.port_set_cmode = mv88e6390x_port_set_cmode,
|
2019-07-31 10:23:49 +02:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 23:27:00 +01:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 23:27:01 +01:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 23:27:02 +01:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2016-11-21 23:27:04 +01:00
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
2017-06-08 18:34:11 -04:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-09 00:03:43 +01:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 04:45:16 +01:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 13:03:43 -04:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 17:30:27 -05:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 11:38:51 -04:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-25 01:03:52 +02:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 14:05:27 -04:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2019-08-26 23:31:53 +02:00
|
|
|
.serdes_power = mv88e6390_serdes_power,
|
2019-08-26 23:31:52 +02:00
|
|
|
.serdes_get_lane = mv88e6390x_serdes_get_lane,
|
2020-03-14 10:15:43 +00:00
|
|
|
.serdes_pcs_get_state = mv88e6390_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
2019-08-31 16:18:29 -04:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2019-08-31 16:18:34 -04:00
|
|
|
.serdes_irq_enable = mv88e6390_serdes_irq_enable,
|
2019-08-31 16:18:35 -04:00
|
|
|
.serdes_irq_status = mv88e6390_serdes_irq_status,
|
2020-01-18 19:40:56 +01:00
|
|
|
.serdes_get_sset_count = mv88e6390_serdes_get_sset_count,
|
|
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 18:54:15 +01:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-02-14 01:07:46 +01:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 01:07:44 +01:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
2018-07-18 22:38:20 +02:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-08-09 15:38:39 +02:00
|
|
|
.phylink_validate = mv88e6390x_phylink_validate,
|
2016-11-21 23:26:57 +01:00
|
|
|
};
|
|
|
|
|
|
2021-03-17 14:46:42 +01:00
|
|
|
static const struct mv88e6xxx_ops mv88e6393x_ops = {
|
|
|
|
|
/* MV88E6XXX_FAMILY_6393 */
|
|
|
|
|
.setup_errata = mv88e6393x_serdes_setup_errata,
|
|
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
|
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
|
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
|
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read,
|
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write,
|
|
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
|
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
|
|
|
|
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
|
|
|
|
|
.port_set_speed_duplex = mv88e6393x_port_set_speed_duplex,
|
|
|
|
|
.port_max_speed_mode = mv88e6393x_port_max_speed_mode,
|
|
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2021-03-17 14:46:43 +01:00
|
|
|
.port_set_policy = mv88e6393x_port_set_policy,
|
2021-03-17 14:46:42 +01:00
|
|
|
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
|
|
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
|
|
|
|
.port_set_ether_type = mv88e6393x_port_set_ether_type,
|
|
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
|
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
|
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
|
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
|
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
|
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
|
|
|
|
.port_set_cmode = mv88e6393x_port_set_cmode,
|
|
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
|
|
|
|
.port_set_upstream_port = mv88e6393x_port_set_upstream_port,
|
|
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
|
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
|
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
|
|
|
|
.stats_get_stats = mv88e6390_stats_get_stats,
|
|
|
|
|
/* .set_cpu_port is missing because this family does not support a global
|
|
|
|
|
* CPU port, only per port CPU port which is set via
|
|
|
|
|
* .port_set_upstream_port method.
|
|
|
|
|
*/
|
|
|
|
|
.set_egress_port = mv88e6393x_set_egress_port,
|
|
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
|
|
|
|
.mgmt_rsvd2cpu = mv88e6393x_port_mgmt_rsvd2cpu,
|
|
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
|
|
|
|
.reset = mv88e6352_g1_reset,
|
|
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
|
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
|
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
|
|
|
|
.serdes_power = mv88e6393x_serdes_power,
|
|
|
|
|
.serdes_get_lane = mv88e6393x_serdes_get_lane,
|
|
|
|
|
.serdes_pcs_get_state = mv88e6393x_serdes_pcs_get_state,
|
|
|
|
|
.serdes_pcs_config = mv88e6390_serdes_pcs_config,
|
|
|
|
|
.serdes_pcs_an_restart = mv88e6390_serdes_pcs_an_restart,
|
|
|
|
|
.serdes_pcs_link_up = mv88e6390_serdes_pcs_link_up,
|
|
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
|
|
|
|
.serdes_irq_enable = mv88e6393x_serdes_irq_enable,
|
|
|
|
|
.serdes_irq_status = mv88e6393x_serdes_irq_status,
|
|
|
|
|
/* TODO: serdes stats */
|
|
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
|
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
|
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
|
|
|
|
.phylink_validate = mv88e6393x_phylink_validate,
|
|
|
|
|
};
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
static const struct mv88e6xxx_info mv88e6xxx_table[] = {
|
|
|
|
|
[MV88E6085] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6085,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6097,
|
|
|
|
|
.name = "Marvell 88E6085",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 10,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 8,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6085_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6095] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6095,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6095,
|
|
|
|
|
.name = "Marvell 88E6095/88E6095F",
|
|
|
|
|
.num_databases = 256,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 11,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 0,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 8,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6095_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
2016-11-22 17:47:21 +01:00
|
|
|
[MV88E6097] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6097,
|
2016-11-22 17:47:21 +01:00
|
|
|
.family = MV88E6XXX_FAMILY_6097,
|
|
|
|
|
.name = "Marvell 88E6097/88E6097F",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-11-22 17:47:21 +01:00
|
|
|
.num_ports = 11,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 8,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-11-22 17:47:21 +01:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-22 17:47:21 +01:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-11-22 17:47:21 +01:00
|
|
|
.age_time_coeff = 15000,
|
2016-11-25 09:41:29 +01:00
|
|
|
.g1_irqs = 8,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-05 14:12:42 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-11-22 17:47:21 +01:00
|
|
|
.ops = &mv88e6097_ops,
|
|
|
|
|
},
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
[MV88E6123] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6123,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6165,
|
|
|
|
|
.name = "Marvell 88E6123",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 1024,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 3,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2017-06-07 15:06:19 +02:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6123_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6131] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6131,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6185,
|
|
|
|
|
.name = "Marvell 88E6131",
|
|
|
|
|
.num_databases = 256,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 8,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 0,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6131_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
2017-03-28 13:50:32 -04:00
|
|
|
[MV88E6141] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6141,
|
2017-03-28 13:50:32 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6341,
|
2018-03-20 10:44:40 +01:00
|
|
|
.name = "Marvell 88E6141",
|
2017-03-28 13:50:32 -04:00
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 2048,
|
2017-03-28 13:50:32 -04:00
|
|
|
.num_ports = 6,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 11,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2017-03-28 13:50:32 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x10,
|
2017-03-28 13:50:32 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2017-03-28 13:50:32 -04:00
|
|
|
.age_time_coeff = 3750,
|
|
|
|
|
.atu_move_port_mask = 0x1f,
|
2018-03-17 20:32:03 +01:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2017-03-28 13:50:32 -04:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
|
|
|
|
.ops = &mv88e6141_ops,
|
|
|
|
|
},
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
[MV88E6161] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6161,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6165,
|
|
|
|
|
.name = "Marvell 88E6161",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 1024,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 6,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2017-06-07 15:06:19 +02:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2018-07-18 22:38:22 +02:00
|
|
|
.ptp_support = true,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6161_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6165] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6165,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6165,
|
|
|
|
|
.name = "Marvell 88E6165",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 6,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 0,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2018-07-18 22:38:22 +02:00
|
|
|
.ptp_support = true,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6165_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6171] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6171,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6351,
|
|
|
|
|
.name = "Marvell 88E6171",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6171_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6172] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6172,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6352,
|
|
|
|
|
.name = "Marvell 88E6172",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 15,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6172_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6175] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6175,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6351,
|
|
|
|
|
.name = "Marvell 88E6175",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6175_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6176] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6176,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6352,
|
|
|
|
|
.name = "Marvell 88E6176",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 15,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6176_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6185] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6185,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6185,
|
|
|
|
|
.name = "Marvell 88E6185",
|
|
|
|
|
.num_databases = 256,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 10,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 0,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 8,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6185_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
2016-11-21 23:26:57 +01:00
|
|
|
[MV88E6190] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6190,
|
2016-11-21 23:26:57 +01:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
|
.name = "Marvell 88E6190",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 16384,
|
2016-11-21 23:26:57 +01:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 10:06:05 +01:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 16,
|
2017-05-01 14:05:27 -04:00
|
|
|
.max_vid = 8191,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 23:26:57 +01:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2017-02-02 00:46:15 +01:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 23:26:57 +01:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 14,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2016-11-21 23:26:57 +01:00
|
|
|
.ops = &mv88e6190_ops,
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6190X] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6190X,
|
2016-11-21 23:26:57 +01:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
|
.name = "Marvell 88E6190X",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 16384,
|
2016-11-21 23:26:57 +01:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 10:06:05 +01:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 16,
|
2017-05-01 14:05:27 -04:00
|
|
|
.max_vid = 8191,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 23:26:57 +01:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-02 00:46:15 +01:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 23:26:57 +01:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2016-11-21 23:26:57 +01:00
|
|
|
.ops = &mv88e6190x_ops,
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6191] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6191,
|
2016-11-21 23:26:57 +01:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
|
.name = "Marvell 88E6191",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 16384,
|
2016-11-21 23:26:57 +01:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 10:06:05 +01:00
|
|
|
.num_internal_phys = 9,
|
2017-05-01 14:05:27 -04:00
|
|
|
.max_vid = 8191,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 23:26:57 +01:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-02 00:46:15 +01:00
|
|
|
.age_time_coeff = 3750,
|
2016-12-03 04:35:18 +01:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2017-03-28 13:50:34 -04:00
|
|
|
.ops = &mv88e6191_ops,
|
2016-11-21 23:26:57 +01:00
|
|
|
},
|
|
|
|
|
|
2021-03-17 14:46:42 +01:00
|
|
|
[MV88E6191X] = {
|
|
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6191X,
|
|
|
|
|
.family = MV88E6XXX_FAMILY_6393,
|
|
|
|
|
.name = "Marvell 88E6191X",
|
|
|
|
|
.num_databases = 4096,
|
|
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
|
|
|
|
.num_internal_phys = 9,
|
|
|
|
|
.max_vid = 8191,
|
|
|
|
|
.port_base_addr = 0x0,
|
|
|
|
|
.phy_base_addr = 0x0,
|
|
|
|
|
.global1_addr = 0x1b,
|
|
|
|
|
.global2_addr = 0x1c,
|
|
|
|
|
.age_time_coeff = 3750,
|
|
|
|
|
.g1_irqs = 10,
|
|
|
|
|
.g2_irqs = 14,
|
|
|
|
|
.atu_move_port_mask = 0x1f,
|
|
|
|
|
.pvt = true,
|
|
|
|
|
.multi_chip = true,
|
|
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
|
|
|
|
.ptp_support = true,
|
|
|
|
|
.ops = &mv88e6393x_ops,
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6193X] = {
|
|
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6193X,
|
|
|
|
|
.family = MV88E6XXX_FAMILY_6393,
|
|
|
|
|
.name = "Marvell 88E6193X",
|
|
|
|
|
.num_databases = 4096,
|
|
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
|
|
|
|
.num_internal_phys = 9,
|
|
|
|
|
.max_vid = 8191,
|
|
|
|
|
.port_base_addr = 0x0,
|
|
|
|
|
.phy_base_addr = 0x0,
|
|
|
|
|
.global1_addr = 0x1b,
|
|
|
|
|
.global2_addr = 0x1c,
|
|
|
|
|
.age_time_coeff = 3750,
|
|
|
|
|
.g1_irqs = 10,
|
|
|
|
|
.g2_irqs = 14,
|
|
|
|
|
.atu_move_port_mask = 0x1f,
|
|
|
|
|
.pvt = true,
|
|
|
|
|
.multi_chip = true,
|
|
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
|
|
|
|
.ptp_support = true,
|
|
|
|
|
.ops = &mv88e6393x_ops,
|
|
|
|
|
},
|
|
|
|
|
|
2019-07-31 10:23:46 +02:00
|
|
|
[MV88E6220] = {
|
|
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6220,
|
|
|
|
|
.family = MV88E6XXX_FAMILY_6250,
|
|
|
|
|
.name = "Marvell 88E6220",
|
|
|
|
|
.num_databases = 64,
|
|
|
|
|
|
|
|
|
|
/* Ports 2-4 are not routed to pins
|
|
|
|
|
* => usable ports 0, 1, 5, 6
|
|
|
|
|
*/
|
|
|
|
|
.num_ports = 7,
|
|
|
|
|
.num_internal_phys = 2,
|
2019-07-31 10:23:48 +02:00
|
|
|
.invalid_port_mask = BIT(2) | BIT(3) | BIT(4),
|
2019-07-31 10:23:46 +02:00
|
|
|
.max_vid = 4095,
|
|
|
|
|
.port_base_addr = 0x08,
|
|
|
|
|
.phy_base_addr = 0x00,
|
|
|
|
|
.global1_addr = 0x0f,
|
|
|
|
|
.global2_addr = 0x07,
|
|
|
|
|
.age_time_coeff = 15000,
|
|
|
|
|
.g1_irqs = 9,
|
|
|
|
|
.g2_irqs = 10,
|
|
|
|
|
.atu_move_port_mask = 0xf,
|
|
|
|
|
.dual_chip = true,
|
|
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2019-07-31 10:23:51 +02:00
|
|
|
.ptp_support = true,
|
2019-07-31 10:23:46 +02:00
|
|
|
.ops = &mv88e6250_ops,
|
|
|
|
|
},
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
[MV88E6240] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6240,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6352,
|
|
|
|
|
.name = "Marvell 88E6240",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 15,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6240_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
[MV88E6250] = {
|
|
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6250,
|
|
|
|
|
.family = MV88E6XXX_FAMILY_6250,
|
|
|
|
|
.name = "Marvell 88E6250",
|
|
|
|
|
.num_databases = 64,
|
|
|
|
|
.num_ports = 7,
|
|
|
|
|
.num_internal_phys = 5,
|
|
|
|
|
.max_vid = 4095,
|
|
|
|
|
.port_base_addr = 0x08,
|
|
|
|
|
.phy_base_addr = 0x00,
|
|
|
|
|
.global1_addr = 0x0f,
|
|
|
|
|
.global2_addr = 0x07,
|
|
|
|
|
.age_time_coeff = 15000,
|
|
|
|
|
.g1_irqs = 9,
|
|
|
|
|
.g2_irqs = 10,
|
|
|
|
|
.atu_move_port_mask = 0xf,
|
|
|
|
|
.dual_chip = true,
|
|
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2019-07-31 10:23:51 +02:00
|
|
|
.ptp_support = true,
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
.ops = &mv88e6250_ops,
|
|
|
|
|
},
|
|
|
|
|
|
2016-11-21 23:26:57 +01:00
|
|
|
[MV88E6290] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6290,
|
2016-11-21 23:26:57 +01:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
|
.name = "Marvell 88E6290",
|
|
|
|
|
.num_databases = 4096,
|
|
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 10:06:05 +01:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 16,
|
2017-05-01 14:05:27 -04:00
|
|
|
.max_vid = 8191,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 23:26:57 +01:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-02 00:46:15 +01:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 23:26:57 +01:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2016-11-21 23:26:57 +01:00
|
|
|
.ops = &mv88e6290_ops,
|
|
|
|
|
},
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
[MV88E6320] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6320,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6320,
|
|
|
|
|
.name = "Marvell 88E6320",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 15,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 8,
|
2018-03-17 20:32:04 +01:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6320_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6321] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6321,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6320,
|
|
|
|
|
.name = "Marvell 88E6321",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 15,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 8,
|
2018-03-17 20:32:04 +01:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6321_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
2017-01-30 20:29:34 +01:00
|
|
|
[MV88E6341] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6341,
|
2017-01-30 20:29:34 +01:00
|
|
|
.family = MV88E6XXX_FAMILY_6341,
|
|
|
|
|
.name = "Marvell 88E6341",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 2048,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2017-01-30 20:29:34 +01:00
|
|
|
.num_ports = 6,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 11,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2017-01-30 20:29:34 +01:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x10,
|
2017-01-30 20:29:34 +01:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2017-01-30 20:29:34 +01:00
|
|
|
.age_time_coeff = 3750,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2018-03-17 20:32:03 +01:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2017-01-30 20:29:34 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2017-01-30 20:29:34 +01:00
|
|
|
.ops = &mv88e6341_ops,
|
|
|
|
|
},
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
[MV88E6350] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6350,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6351,
|
|
|
|
|
.name = "Marvell 88E6350",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6350_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6351] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6351,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6351,
|
|
|
|
|
.name = "Marvell 88E6351",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6351_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
|
|
|
|
|
|
|
|
|
[MV88E6352] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6352,
|
2016-05-09 13:22:58 -04:00
|
|
|
.family = MV88E6XXX_FAMILY_6352,
|
|
|
|
|
.name = "Marvell 88E6352",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 8192,
|
2016-05-09 13:22:58 -04:00
|
|
|
.num_ports = 7,
|
2018-03-17 20:32:04 +01:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 15,
|
2017-05-01 14:05:10 -04:00
|
|
|
.max_vid = 4095,
|
2016-06-20 13:14:10 -04:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 12:21:53 -04:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-18 20:45:39 -04:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 19:56:49 +02:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_EDSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2016-09-29 12:22:00 -04:00
|
|
|
.ops = &mv88e6352_ops,
|
2016-05-09 13:22:58 -04:00
|
|
|
},
|
2016-11-21 23:26:57 +01:00
|
|
|
[MV88E6390] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6390,
|
2016-11-21 23:26:57 +01:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
|
.name = "Marvell 88E6390",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 16384,
|
2016-11-21 23:26:57 +01:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 10:06:05 +01:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 16,
|
2017-05-01 14:05:27 -04:00
|
|
|
.max_vid = 8191,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 23:26:57 +01:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-02 00:46:15 +01:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 23:26:57 +01:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2016-11-21 23:26:57 +01:00
|
|
|
.ops = &mv88e6390_ops,
|
|
|
|
|
},
|
|
|
|
|
[MV88E6390X] = {
|
2017-06-12 12:37:36 -04:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6390X,
|
2016-11-21 23:26:57 +01:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
|
.name = "Marvell 88E6390X",
|
|
|
|
|
.num_databases = 4096,
|
2019-11-05 01:12:58 +01:00
|
|
|
.num_macs = 16384,
|
2016-11-21 23:26:57 +01:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 10:06:05 +01:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 01:07:46 +01:00
|
|
|
.num_gpio = 16,
|
2017-05-01 14:05:27 -04:00
|
|
|
.max_vid = 8191,
|
2016-11-21 23:26:57 +01:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 20:58:22 +02:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 23:26:57 +01:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 13:03:44 -04:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-02 00:46:15 +01:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 23:26:57 +01:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 13:03:40 -04:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 16:12:55 -05:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 17:37:07 -04:00
|
|
|
.pvt = true,
|
2017-07-17 13:03:46 -04:00
|
|
|
.multi_chip = true,
|
2016-12-03 04:35:18 +01:00
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
2018-02-14 01:07:45 +01:00
|
|
|
.ptp_support = true,
|
2016-11-21 23:26:57 +01:00
|
|
|
.ops = &mv88e6390x_ops,
|
|
|
|
|
},
|
2021-03-17 14:46:42 +01:00
|
|
|
|
|
|
|
|
[MV88E6393X] = {
|
|
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6393X,
|
|
|
|
|
.family = MV88E6XXX_FAMILY_6393,
|
|
|
|
|
.name = "Marvell 88E6393X",
|
|
|
|
|
.num_databases = 4096,
|
|
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
|
|
|
|
.num_internal_phys = 9,
|
|
|
|
|
.max_vid = 8191,
|
|
|
|
|
.port_base_addr = 0x0,
|
|
|
|
|
.phy_base_addr = 0x0,
|
|
|
|
|
.global1_addr = 0x1b,
|
|
|
|
|
.global2_addr = 0x1c,
|
|
|
|
|
.age_time_coeff = 3750,
|
|
|
|
|
.g1_irqs = 10,
|
|
|
|
|
.g2_irqs = 14,
|
|
|
|
|
.atu_move_port_mask = 0x1f,
|
|
|
|
|
.pvt = true,
|
|
|
|
|
.multi_chip = true,
|
|
|
|
|
.tag_protocol = DSA_TAG_PROTO_DSA,
|
|
|
|
|
.ptp_support = true,
|
|
|
|
|
.ops = &mv88e6393x_ops,
|
|
|
|
|
},
|
2016-05-09 13:22:58 -04:00
|
|
|
};
|
|
|
|
|
|
2016-06-20 13:14:04 -04:00
|
|
|
static const struct mv88e6xxx_info *mv88e6xxx_lookup_info(unsigned int prod_num)
|
2015-10-30 19:39:48 -04:00
|
|
|
{
|
2016-04-17 13:23:58 -04:00
|
|
|
int i;
|
2015-10-30 19:39:48 -04:00
|
|
|
|
2016-06-20 13:14:04 -04:00
|
|
|
for (i = 0; i < ARRAY_SIZE(mv88e6xxx_table); ++i)
|
|
|
|
|
if (mv88e6xxx_table[i].prod_num == prod_num)
|
|
|
|
|
return &mv88e6xxx_table[i];
|
2015-10-30 19:39:48 -04:00
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
static int mv88e6xxx_detect(struct mv88e6xxx_chip *chip)
|
2016-06-20 13:14:08 -04:00
|
|
|
{
|
|
|
|
|
const struct mv88e6xxx_info *info;
|
2016-07-20 18:18:36 -04:00
|
|
|
unsigned int prod_num, rev;
|
|
|
|
|
u16 id;
|
|
|
|
|
int err;
|
2016-06-20 13:14:08 -04:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-06-12 12:37:36 -04:00
|
|
|
err = mv88e6xxx_port_read(chip, 0, MV88E6XXX_PORT_SWITCH_ID, &id);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-07-20 18:18:36 -04:00
|
|
|
if (err)
|
|
|
|
|
return err;
|
2016-06-20 13:14:08 -04:00
|
|
|
|
2017-06-12 12:37:36 -04:00
|
|
|
prod_num = id & MV88E6XXX_PORT_SWITCH_ID_PROD_MASK;
|
|
|
|
|
rev = id & MV88E6XXX_PORT_SWITCH_ID_REV_MASK;
|
2016-06-20 13:14:08 -04:00
|
|
|
|
|
|
|
|
info = mv88e6xxx_lookup_info(prod_num);
|
|
|
|
|
if (!info)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
2016-06-20 13:14:09 -04:00
|
|
|
/* Update the compatible info with the probed one */
|
2016-06-21 12:28:20 -04:00
|
|
|
chip->info = info;
|
2016-06-20 13:14:08 -04:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
dev_info(chip->dev, "switch 0x%x detected: %s, revision %u\n",
|
|
|
|
|
chip->info->prod_num, chip->info->name, rev);
|
2016-06-20 13:14:08 -04:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
static struct mv88e6xxx_chip *mv88e6xxx_alloc_chip(struct device *dev)
|
2016-06-20 13:14:06 -04:00
|
|
|
{
|
2016-06-21 12:28:20 -04:00
|
|
|
struct mv88e6xxx_chip *chip;
|
2016-06-20 13:14:06 -04:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
|
|
|
|
|
if (!chip)
|
2016-06-20 13:14:06 -04:00
|
|
|
return NULL;
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
chip->dev = dev;
|
2016-06-20 13:14:06 -04:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
mutex_init(&chip->reg_lock);
|
2017-01-24 14:53:50 +01:00
|
|
|
INIT_LIST_HEAD(&chip->mdios);
|
2019-09-07 16:00:49 -04:00
|
|
|
idr_init(&chip->policies);
|
2016-06-20 13:14:06 -04:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
return chip;
|
2016-06-20 13:14:06 -04:00
|
|
|
}
|
|
|
|
|
|
2017-11-10 15:22:52 -08:00
|
|
|
static enum dsa_tag_protocol mv88e6xxx_get_tag_protocol(struct dsa_switch *ds,
|
2020-01-07 21:06:05 -08:00
|
|
|
int port,
|
|
|
|
|
enum dsa_tag_protocol m)
|
2016-08-22 16:01:01 +02:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-08-22 16:01:02 +02:00
|
|
|
|
2016-12-03 04:35:18 +01:00
|
|
|
return chip->info->tag_protocol;
|
2016-08-22 16:01:01 +02:00
|
|
|
}
|
|
|
|
|
|
2021-01-09 02:01:52 +02:00
|
|
|
static int mv88e6xxx_port_mdb_add(struct dsa_switch *ds, int port,
|
|
|
|
|
const struct switchdev_obj_port_mdb *mdb)
|
2016-08-31 11:50:05 -04:00
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2021-01-09 02:01:52 +02:00
|
|
|
int err;
|
2016-08-31 11:50:05 -04:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2021-01-09 02:01:52 +02:00
|
|
|
err = mv88e6xxx_port_db_load_purge(chip, port, mdb->addr, mdb->vid,
|
|
|
|
|
MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2021-01-09 02:01:52 +02:00
|
|
|
|
|
|
|
|
return err;
|
2016-08-31 11:50:05 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_mdb_del(struct dsa_switch *ds, int port,
|
|
|
|
|
const struct switchdev_obj_port_mdb *mdb)
|
|
|
|
|
{
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-08-31 11:50:05 -04:00
|
|
|
int err;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2019-09-07 16:00:47 -04:00
|
|
|
err = mv88e6xxx_port_db_load_purge(chip, port, mdb->addr, mdb->vid, 0);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-08-31 11:50:05 -04:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-07 22:11:14 +01:00
|
|
|
static int mv88e6xxx_port_mirror_add(struct dsa_switch *ds, int port,
|
|
|
|
|
struct dsa_mall_mirror_tc_entry *mirror,
|
|
|
|
|
bool ingress)
|
|
|
|
|
{
|
|
|
|
|
enum mv88e6xxx_egress_direction direction = ingress ?
|
|
|
|
|
MV88E6XXX_EGRESS_DIR_INGRESS :
|
|
|
|
|
MV88E6XXX_EGRESS_DIR_EGRESS;
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
bool other_mirrors = false;
|
|
|
|
|
int i;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&chip->reg_lock);
|
|
|
|
|
if ((ingress ? chip->ingress_dest_port : chip->egress_dest_port) !=
|
|
|
|
|
mirror->to_local_port) {
|
|
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); i++)
|
|
|
|
|
other_mirrors |= ingress ?
|
|
|
|
|
chip->ports[i].mirror_ingress :
|
|
|
|
|
chip->ports[i].mirror_egress;
|
|
|
|
|
|
|
|
|
|
/* Can't change egress port when other mirror is active */
|
|
|
|
|
if (other_mirrors) {
|
|
|
|
|
err = -EBUSY;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-17 14:46:41 +01:00
|
|
|
err = mv88e6xxx_set_egress_port(chip, direction,
|
|
|
|
|
mirror->to_local_port);
|
2019-11-07 22:11:14 +01:00
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_set_mirror(chip, port, direction, true);
|
|
|
|
|
out:
|
|
|
|
|
mutex_unlock(&chip->reg_lock);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_port_mirror_del(struct dsa_switch *ds, int port,
|
|
|
|
|
struct dsa_mall_mirror_tc_entry *mirror)
|
|
|
|
|
{
|
|
|
|
|
enum mv88e6xxx_egress_direction direction = mirror->ingress ?
|
|
|
|
|
MV88E6XXX_EGRESS_DIR_INGRESS :
|
|
|
|
|
MV88E6XXX_EGRESS_DIR_EGRESS;
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
bool other_mirrors = false;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&chip->reg_lock);
|
|
|
|
|
if (mv88e6xxx_port_set_mirror(chip, port, direction, false))
|
|
|
|
|
dev_err(ds->dev, "p%d: failed to disable mirroring\n", port);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); i++)
|
|
|
|
|
other_mirrors |= mirror->ingress ?
|
|
|
|
|
chip->ports[i].mirror_ingress :
|
|
|
|
|
chip->ports[i].mirror_egress;
|
|
|
|
|
|
|
|
|
|
/* Reset egress port when no other mirror is active */
|
|
|
|
|
if (!other_mirrors) {
|
2021-03-17 14:46:41 +01:00
|
|
|
if (mv88e6xxx_set_egress_port(chip, direction,
|
|
|
|
|
dsa_upstream_port(ds, port)))
|
2019-11-07 22:11:14 +01:00
|
|
|
dev_err(ds->dev, "failed to set egress port\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mutex_unlock(&chip->reg_lock);
|
|
|
|
|
}
|
|
|
|
|
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
static int mv88e6xxx_port_pre_bridge_flags(struct dsa_switch *ds, int port,
|
|
|
|
|
struct switchdev_brport_flags flags,
|
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
const struct mv88e6xxx_ops *ops;
|
|
|
|
|
|
2021-03-18 20:25:40 +01:00
|
|
|
if (flags.mask & ~(BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD |
|
|
|
|
|
BR_BCAST_FLOOD))
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
ops = chip->info->ops;
|
|
|
|
|
|
|
|
|
|
if ((flags.mask & BR_FLOOD) && !ops->port_set_ucast_flood)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
if ((flags.mask & BR_MCAST_FLOOD) && !ops->port_set_mcast_flood)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_bridge_flags(struct dsa_switch *ds, int port,
|
|
|
|
|
struct switchdev_brport_flags flags,
|
|
|
|
|
struct netlink_ext_ack *extack)
|
2019-02-20 15:35:05 -08:00
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2021-03-18 20:25:39 +01:00
|
|
|
bool do_fast_age = false;
|
2019-02-20 15:35:05 -08:00
|
|
|
int err = -EOPNOTSUPP;
|
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
|
2021-03-18 20:25:39 +01:00
|
|
|
if (flags.mask & BR_LEARNING) {
|
|
|
|
|
bool learning = !!(flags.val & BR_LEARNING);
|
|
|
|
|
u16 pav = learning ? (1 << port) : 0;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_set_assoc_vector(chip, port, pav);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
if (!learning)
|
|
|
|
|
do_fast_age = true;
|
|
|
|
|
}
|
|
|
|
|
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
if (flags.mask & BR_FLOOD) {
|
|
|
|
|
bool unicast = !!(flags.val & BR_FLOOD);
|
|
|
|
|
|
|
|
|
|
err = chip->info->ops->port_set_ucast_flood(chip, port,
|
|
|
|
|
unicast);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (flags.mask & BR_MCAST_FLOOD) {
|
|
|
|
|
bool multicast = !!(flags.val & BR_MCAST_FLOOD);
|
|
|
|
|
|
|
|
|
|
err = chip->info->ops->port_set_mcast_flood(chip, port,
|
|
|
|
|
multicast);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-18 20:25:40 +01:00
|
|
|
if (flags.mask & BR_BCAST_FLOOD) {
|
|
|
|
|
bool broadcast = !!(flags.val & BR_BCAST_FLOOD);
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_broadcast_sync(chip, port, broadcast);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
out:
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
2021-03-18 20:25:39 +01:00
|
|
|
if (do_fast_age)
|
|
|
|
|
mv88e6xxx_port_fast_age(ds, port);
|
|
|
|
|
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_set_mrouter(struct dsa_switch *ds, int port,
|
|
|
|
|
bool mrouter,
|
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!chip->info->ops->port_set_mcast_flood)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
err = chip->info->ops->port_set_mcast_flood(chip, port, mrouter);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2019-02-20 15:35:05 -08:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-13 09:42:54 +01:00
|
|
|
static bool mv88e6xxx_lag_can_offload(struct dsa_switch *ds,
|
|
|
|
|
struct net_device *lag,
|
|
|
|
|
struct netdev_lag_upper_info *info)
|
|
|
|
|
{
|
2021-01-15 13:52:59 +01:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2021-01-13 09:42:54 +01:00
|
|
|
struct dsa_port *dp;
|
|
|
|
|
int id, members = 0;
|
|
|
|
|
|
2021-01-15 13:52:59 +01:00
|
|
|
if (!mv88e6xxx_has_lag(chip))
|
|
|
|
|
return false;
|
|
|
|
|
|
2021-01-13 09:42:54 +01:00
|
|
|
id = dsa_lag_id(ds->dst, lag);
|
|
|
|
|
if (id < 0 || id >= ds->num_lag_ids)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
dsa_lag_foreach_port(dp, ds->dst, lag)
|
|
|
|
|
/* Includes the port joining the LAG */
|
|
|
|
|
members++;
|
|
|
|
|
|
|
|
|
|
if (members > 8)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
/* We could potentially relax this to include active
|
|
|
|
|
* backup in the future.
|
|
|
|
|
*/
|
|
|
|
|
if (info->tx_type != NETDEV_LAG_TX_TYPE_HASH)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
/* Ideally we would also validate that the hash type matches
|
|
|
|
|
* the hardware. Alas, this is always set to unknown on team
|
|
|
|
|
* interfaces.
|
|
|
|
|
*/
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_lag_sync_map(struct dsa_switch *ds, struct net_device *lag)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
struct dsa_port *dp;
|
|
|
|
|
u16 map = 0;
|
|
|
|
|
int id;
|
|
|
|
|
|
|
|
|
|
id = dsa_lag_id(ds->dst, lag);
|
|
|
|
|
|
|
|
|
|
/* Build the map of all ports to distribute flows destined for
|
|
|
|
|
* this LAG. This can be either a local user port, or a DSA
|
|
|
|
|
* port if the LAG port is on a remote chip.
|
|
|
|
|
*/
|
|
|
|
|
dsa_lag_foreach_port(dp, ds->dst, lag)
|
|
|
|
|
map |= BIT(dsa_towards_port(ds, dp->ds->index, dp->index));
|
|
|
|
|
|
|
|
|
|
return mv88e6xxx_g2_trunk_mapping_write(chip, id, map);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const u8 mv88e6xxx_lag_mask_table[8][8] = {
|
|
|
|
|
/* Row number corresponds to the number of active members in a
|
|
|
|
|
* LAG. Each column states which of the eight hash buckets are
|
|
|
|
|
* mapped to the column:th port in the LAG.
|
|
|
|
|
*
|
|
|
|
|
* Example: In a LAG with three active ports, the second port
|
|
|
|
|
* ([2][1]) would be selected for traffic mapped to buckets
|
|
|
|
|
* 3,4,5 (0x38).
|
|
|
|
|
*/
|
|
|
|
|
{ 0xff, 0, 0, 0, 0, 0, 0, 0 },
|
|
|
|
|
{ 0x0f, 0xf0, 0, 0, 0, 0, 0, 0 },
|
|
|
|
|
{ 0x07, 0x38, 0xc0, 0, 0, 0, 0, 0 },
|
|
|
|
|
{ 0x03, 0x0c, 0x30, 0xc0, 0, 0, 0, 0 },
|
|
|
|
|
{ 0x03, 0x0c, 0x30, 0x40, 0x80, 0, 0, 0 },
|
|
|
|
|
{ 0x03, 0x0c, 0x10, 0x20, 0x40, 0x80, 0, 0 },
|
|
|
|
|
{ 0x03, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0 },
|
|
|
|
|
{ 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void mv88e6xxx_lag_set_port_mask(u16 *mask, int port,
|
|
|
|
|
int num_tx, int nth)
|
|
|
|
|
{
|
|
|
|
|
u8 active = 0;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
num_tx = num_tx <= 8 ? num_tx : 8;
|
|
|
|
|
if (nth < num_tx)
|
|
|
|
|
active = mv88e6xxx_lag_mask_table[num_tx - 1][nth];
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < 8; i++) {
|
|
|
|
|
if (BIT(i) & active)
|
|
|
|
|
mask[i] |= BIT(port);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_lag_sync_masks(struct dsa_switch *ds)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
unsigned int id, num_tx;
|
|
|
|
|
struct net_device *lag;
|
|
|
|
|
struct dsa_port *dp;
|
|
|
|
|
int i, err, nth;
|
|
|
|
|
u16 mask[8];
|
|
|
|
|
u16 ivec;
|
|
|
|
|
|
|
|
|
|
/* Assume no port is a member of any LAG. */
|
|
|
|
|
ivec = BIT(mv88e6xxx_num_ports(chip)) - 1;
|
|
|
|
|
|
|
|
|
|
/* Disable all masks for ports that _are_ members of a LAG. */
|
|
|
|
|
list_for_each_entry(dp, &ds->dst->ports, list) {
|
|
|
|
|
if (!dp->lag_dev || dp->ds != ds)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
ivec &= ~BIT(dp->index);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < 8; i++)
|
|
|
|
|
mask[i] = ivec;
|
|
|
|
|
|
|
|
|
|
/* Enable the correct subset of masks for all LAG ports that
|
|
|
|
|
* are in the Tx set.
|
|
|
|
|
*/
|
|
|
|
|
dsa_lags_foreach_id(id, ds->dst) {
|
|
|
|
|
lag = dsa_lag_dev(ds->dst, id);
|
|
|
|
|
if (!lag)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
num_tx = 0;
|
|
|
|
|
dsa_lag_foreach_port(dp, ds->dst, lag) {
|
|
|
|
|
if (dp->lag_tx_enabled)
|
|
|
|
|
num_tx++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!num_tx)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
nth = 0;
|
|
|
|
|
dsa_lag_foreach_port(dp, ds->dst, lag) {
|
|
|
|
|
if (!dp->lag_tx_enabled)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (dp->ds == ds)
|
|
|
|
|
mv88e6xxx_lag_set_port_mask(mask, dp->index,
|
|
|
|
|
num_tx, nth);
|
|
|
|
|
|
|
|
|
|
nth++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < 8; i++) {
|
|
|
|
|
err = mv88e6xxx_g2_trunk_mask_write(chip, i, true, mask[i]);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_lag_sync_masks_map(struct dsa_switch *ds,
|
|
|
|
|
struct net_device *lag)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_lag_sync_masks(ds);
|
|
|
|
|
|
|
|
|
|
if (!err)
|
|
|
|
|
err = mv88e6xxx_lag_sync_map(ds, lag);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_lag_change(struct dsa_switch *ds, int port)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
err = mv88e6xxx_lag_sync_masks(ds);
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_lag_join(struct dsa_switch *ds, int port,
|
|
|
|
|
struct net_device *lag,
|
|
|
|
|
struct netdev_lag_upper_info *info)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err, id;
|
|
|
|
|
|
|
|
|
|
if (!mv88e6xxx_lag_can_offload(ds, lag, info))
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
id = dsa_lag_id(ds->dst, lag);
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_set_trunk(chip, port, true, id);
|
|
|
|
|
if (err)
|
|
|
|
|
goto err_unlock;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_lag_sync_masks_map(ds, lag);
|
|
|
|
|
if (err)
|
|
|
|
|
goto err_clear_trunk;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
err_clear_trunk:
|
|
|
|
|
mv88e6xxx_port_set_trunk(chip, port, false, 0);
|
|
|
|
|
err_unlock:
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_lag_leave(struct dsa_switch *ds, int port,
|
|
|
|
|
struct net_device *lag)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err_sync, err_trunk;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
err_sync = mv88e6xxx_lag_sync_masks_map(ds, lag);
|
|
|
|
|
err_trunk = mv88e6xxx_port_set_trunk(chip, port, false, 0);
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
return err_sync ? : err_trunk;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_crosschip_lag_change(struct dsa_switch *ds, int sw_index,
|
|
|
|
|
int port)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
err = mv88e6xxx_lag_sync_masks(ds);
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_crosschip_lag_join(struct dsa_switch *ds, int sw_index,
|
|
|
|
|
int port, struct net_device *lag,
|
|
|
|
|
struct netdev_lag_upper_info *info)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!mv88e6xxx_lag_can_offload(ds, lag, info))
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_lag_sync_masks_map(ds, lag);
|
|
|
|
|
if (err)
|
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_pvt_map(chip, sw_index, port);
|
|
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mv88e6xxx_crosschip_lag_leave(struct dsa_switch *ds, int sw_index,
|
|
|
|
|
int port, struct net_device *lag)
|
|
|
|
|
{
|
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
int err_sync, err_pvt;
|
|
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
err_sync = mv88e6xxx_lag_sync_masks_map(ds, lag);
|
|
|
|
|
err_pvt = mv88e6xxx_pvt_map(chip, sw_index, port);
|
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
return err_sync ? : err_pvt;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-08 14:52:08 -08:00
|
|
|
static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
|
2016-08-22 16:01:01 +02:00
|
|
|
.get_tag_protocol = mv88e6xxx_get_tag_protocol,
|
2016-05-09 13:22:58 -04:00
|
|
|
.setup = mv88e6xxx_setup,
|
2019-10-25 01:03:52 +02:00
|
|
|
.teardown = mv88e6xxx_teardown,
|
2018-05-10 13:17:35 -07:00
|
|
|
.phylink_validate = mv88e6xxx_validate,
|
2020-03-14 10:15:43 +00:00
|
|
|
.phylink_mac_link_state = mv88e6xxx_serdes_pcs_get_state,
|
2018-05-10 13:17:35 -07:00
|
|
|
.phylink_mac_config = mv88e6xxx_mac_config,
|
2020-03-14 10:15:43 +00:00
|
|
|
.phylink_mac_an_restart = mv88e6xxx_serdes_pcs_an_restart,
|
2018-05-10 13:17:35 -07:00
|
|
|
.phylink_mac_link_down = mv88e6xxx_mac_link_down,
|
|
|
|
|
.phylink_mac_link_up = mv88e6xxx_mac_link_up,
|
2016-05-09 13:22:58 -04:00
|
|
|
.get_strings = mv88e6xxx_get_strings,
|
|
|
|
|
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
|
|
|
|
|
.get_sset_count = mv88e6xxx_get_sset_count,
|
2017-05-26 01:03:24 +02:00
|
|
|
.port_enable = mv88e6xxx_port_enable,
|
|
|
|
|
.port_disable = mv88e6xxx_port_disable,
|
2020-07-11 22:32:05 +02:00
|
|
|
.port_max_mtu = mv88e6xxx_get_max_mtu,
|
|
|
|
|
.port_change_mtu = mv88e6xxx_change_mtu,
|
2017-08-01 16:32:41 -04:00
|
|
|
.get_mac_eee = mv88e6xxx_get_mac_eee,
|
|
|
|
|
.set_mac_eee = mv88e6xxx_set_mac_eee,
|
2016-05-10 23:27:25 +02:00
|
|
|
.get_eeprom_len = mv88e6xxx_get_eeprom_len,
|
2016-05-09 13:22:58 -04:00
|
|
|
.get_eeprom = mv88e6xxx_get_eeprom,
|
|
|
|
|
.set_eeprom = mv88e6xxx_set_eeprom,
|
|
|
|
|
.get_regs_len = mv88e6xxx_get_regs_len,
|
|
|
|
|
.get_regs = mv88e6xxx_get_regs,
|
2019-09-07 16:00:49 -04:00
|
|
|
.get_rxnfc = mv88e6xxx_get_rxnfc,
|
|
|
|
|
.set_rxnfc = mv88e6xxx_set_rxnfc,
|
2016-07-18 20:45:40 -04:00
|
|
|
.set_ageing_time = mv88e6xxx_set_ageing_time,
|
2016-05-09 13:22:58 -04:00
|
|
|
.port_bridge_join = mv88e6xxx_port_bridge_join,
|
|
|
|
|
.port_bridge_leave = mv88e6xxx_port_bridge_leave,
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
.port_pre_bridge_flags = mv88e6xxx_port_pre_bridge_flags,
|
|
|
|
|
.port_bridge_flags = mv88e6xxx_port_bridge_flags,
|
|
|
|
|
.port_set_mrouter = mv88e6xxx_port_set_mrouter,
|
2016-05-09 13:22:58 -04:00
|
|
|
.port_stp_state_set = mv88e6xxx_port_stp_state_set,
|
2016-09-22 16:49:24 -04:00
|
|
|
.port_fast_age = mv88e6xxx_port_fast_age,
|
2016-05-09 13:22:58 -04:00
|
|
|
.port_vlan_filtering = mv88e6xxx_port_vlan_filtering,
|
|
|
|
|
.port_vlan_add = mv88e6xxx_port_vlan_add,
|
|
|
|
|
.port_vlan_del = mv88e6xxx_port_vlan_del,
|
|
|
|
|
.port_fdb_add = mv88e6xxx_port_fdb_add,
|
|
|
|
|
.port_fdb_del = mv88e6xxx_port_fdb_del,
|
|
|
|
|
.port_fdb_dump = mv88e6xxx_port_fdb_dump,
|
2016-08-31 11:50:05 -04:00
|
|
|
.port_mdb_add = mv88e6xxx_port_mdb_add,
|
|
|
|
|
.port_mdb_del = mv88e6xxx_port_mdb_del,
|
2019-11-07 22:11:14 +01:00
|
|
|
.port_mirror_add = mv88e6xxx_port_mirror_add,
|
|
|
|
|
.port_mirror_del = mv88e6xxx_port_mirror_del,
|
2017-03-30 17:37:15 -04:00
|
|
|
.crosschip_bridge_join = mv88e6xxx_crosschip_bridge_join,
|
|
|
|
|
.crosschip_bridge_leave = mv88e6xxx_crosschip_bridge_leave,
|
2018-02-14 01:07:50 +01:00
|
|
|
.port_hwtstamp_set = mv88e6xxx_port_hwtstamp_set,
|
|
|
|
|
.port_hwtstamp_get = mv88e6xxx_port_hwtstamp_get,
|
|
|
|
|
.port_txtstamp = mv88e6xxx_port_txtstamp,
|
|
|
|
|
.port_rxtstamp = mv88e6xxx_port_rxtstamp,
|
|
|
|
|
.get_ts_info = mv88e6xxx_get_ts_info,
|
2019-10-25 01:03:52 +02:00
|
|
|
.devlink_param_get = mv88e6xxx_devlink_param_get,
|
|
|
|
|
.devlink_param_set = mv88e6xxx_devlink_param_set,
|
2020-09-18 21:11:09 +02:00
|
|
|
.devlink_info_get = mv88e6xxx_devlink_info_get,
|
2021-01-13 09:42:54 +01:00
|
|
|
.port_lag_change = mv88e6xxx_port_lag_change,
|
|
|
|
|
.port_lag_join = mv88e6xxx_port_lag_join,
|
|
|
|
|
.port_lag_leave = mv88e6xxx_port_lag_leave,
|
|
|
|
|
.crosschip_lag_change = mv88e6xxx_crosschip_lag_change,
|
|
|
|
|
.crosschip_lag_join = mv88e6xxx_crosschip_lag_join,
|
|
|
|
|
.crosschip_lag_leave = mv88e6xxx_crosschip_lag_leave,
|
2016-05-09 13:22:58 -04:00
|
|
|
};
|
|
|
|
|
|
2017-01-26 10:45:51 -08:00
|
|
|
static int mv88e6xxx_register_switch(struct mv88e6xxx_chip *chip)
|
2016-06-20 13:14:02 -04:00
|
|
|
{
|
2016-06-21 12:28:20 -04:00
|
|
|
struct device *dev = chip->dev;
|
2016-06-20 13:14:02 -04:00
|
|
|
struct dsa_switch *ds;
|
|
|
|
|
|
2019-10-21 16:51:30 -04:00
|
|
|
ds = devm_kzalloc(dev, sizeof(*ds), GFP_KERNEL);
|
2016-06-20 13:14:02 -04:00
|
|
|
if (!ds)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2019-10-21 16:51:30 -04:00
|
|
|
ds->dev = dev;
|
|
|
|
|
ds->num_ports = mv88e6xxx_num_ports(chip);
|
2016-06-21 12:28:20 -04:00
|
|
|
ds->priv = chip;
|
2018-05-19 22:31:34 +02:00
|
|
|
ds->dev = dev;
|
2016-08-23 12:38:56 -04:00
|
|
|
ds->ops = &mv88e6xxx_switch_ops;
|
2017-03-15 15:53:50 -04:00
|
|
|
ds->ageing_time_min = chip->info->age_time_coeff;
|
|
|
|
|
ds->ageing_time_max = chip->info->age_time_coeff * U8_MAX;
|
2016-06-20 13:14:02 -04:00
|
|
|
|
2021-01-13 09:42:54 +01:00
|
|
|
/* Some chips support up to 32, but that requires enabling the
|
|
|
|
|
* 5-bit port mode, which we do not support. 640k^W16 ought to
|
|
|
|
|
* be enough for anyone.
|
|
|
|
|
*/
|
2021-01-15 13:52:59 +01:00
|
|
|
ds->num_lag_ids = mv88e6xxx_has_lag(chip) ? 16 : 0;
|
2021-01-13 09:42:54 +01:00
|
|
|
|
2016-06-20 13:14:02 -04:00
|
|
|
dev_set_drvdata(dev, ds);
|
|
|
|
|
|
2017-05-26 18:12:51 -04:00
|
|
|
return dsa_register_switch(ds);
|
2016-06-20 13:14:02 -04:00
|
|
|
}
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
static void mv88e6xxx_unregister_switch(struct mv88e6xxx_chip *chip)
|
2016-06-20 13:14:02 -04:00
|
|
|
{
|
2016-06-21 12:28:20 -04:00
|
|
|
dsa_unregister_switch(chip->ds);
|
2016-06-20 13:14:02 -04:00
|
|
|
}
|
|
|
|
|
|
2018-05-19 22:31:34 +02:00
|
|
|
static const void *pdata_device_get_match_data(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
const struct of_device_id *matches = dev->driver->of_match_table;
|
|
|
|
|
const struct dsa_mv88e6xxx_pdata *pdata = dev->platform_data;
|
|
|
|
|
|
|
|
|
|
for (; matches->name[0] || matches->type[0] || matches->compatible[0];
|
|
|
|
|
matches++) {
|
|
|
|
|
if (!strcmp(pdata->compatible, matches->compatible))
|
|
|
|
|
return matches->data;
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-05 12:07:28 +01:00
|
|
|
/* There is no suspend to RAM support at DSA level yet, the switch configuration
|
|
|
|
|
* would be lost after a power cycle so prevent it to be suspended.
|
|
|
|
|
*/
|
|
|
|
|
static int __maybe_unused mv88e6xxx_suspend(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int __maybe_unused mv88e6xxx_resume(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SIMPLE_DEV_PM_OPS(mv88e6xxx_pm_ops, mv88e6xxx_suspend, mv88e6xxx_resume);
|
|
|
|
|
|
2016-06-20 13:13:58 -04:00
|
|
|
static int mv88e6xxx_probe(struct mdio_device *mdiodev)
|
2011-11-25 14:36:19 +00:00
|
|
|
{
|
2018-05-19 22:31:34 +02:00
|
|
|
struct dsa_mv88e6xxx_pdata *pdata = mdiodev->dev.platform_data;
|
2018-05-20 19:04:24 -04:00
|
|
|
const struct mv88e6xxx_info *compat_info = NULL;
|
2016-05-10 23:27:21 +02:00
|
|
|
struct device *dev = &mdiodev->dev;
|
2016-05-10 23:27:25 +02:00
|
|
|
struct device_node *np = dev->of_node;
|
2016-06-21 12:28:20 -04:00
|
|
|
struct mv88e6xxx_chip *chip;
|
2018-05-19 22:31:34 +02:00
|
|
|
int port;
|
2016-05-10 23:27:22 +02:00
|
|
|
int err;
|
2016-05-10 23:27:21 +02:00
|
|
|
|
2018-05-31 00:15:42 +02:00
|
|
|
if (!np && !pdata)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2018-05-19 22:31:34 +02:00
|
|
|
if (np)
|
|
|
|
|
compat_info = of_device_get_match_data(dev);
|
|
|
|
|
|
|
|
|
|
if (pdata) {
|
|
|
|
|
compat_info = pdata_device_get_match_data(dev);
|
|
|
|
|
|
|
|
|
|
if (!pdata->netdev)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
for (port = 0; port < DSA_MAX_PORTS; port++) {
|
|
|
|
|
if (!(pdata->enabled_ports & (1 << port)))
|
|
|
|
|
continue;
|
|
|
|
|
if (strcmp(pdata->cd.port_names[port], "cpu"))
|
|
|
|
|
continue;
|
|
|
|
|
pdata->cd.netdev[port] = &pdata->netdev->dev;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-20 13:14:09 -04:00
|
|
|
if (!compat_info)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
chip = mv88e6xxx_alloc_chip(dev);
|
2018-05-19 22:31:34 +02:00
|
|
|
if (!chip) {
|
|
|
|
|
err = -ENOMEM;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2016-05-10 23:27:21 +02:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
chip->info = compat_info;
|
2016-06-20 13:14:09 -04:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
err = mv88e6xxx_smi_init(chip, mdiodev->bus, mdiodev->addr);
|
2016-06-20 13:14:07 -04:00
|
|
|
if (err)
|
2018-05-19 22:31:34 +02:00
|
|
|
goto out;
|
2016-05-10 23:27:21 +02:00
|
|
|
|
2016-11-21 23:26:55 +01:00
|
|
|
chip->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
|
2018-05-19 22:31:34 +02:00
|
|
|
if (IS_ERR(chip->reset)) {
|
|
|
|
|
err = PTR_ERR(chip->reset);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2019-06-27 21:17:39 +03:00
|
|
|
if (chip->reset)
|
|
|
|
|
usleep_range(1000, 2000);
|
2016-11-21 23:26:55 +01:00
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
err = mv88e6xxx_detect(chip);
|
2016-06-20 13:14:08 -04:00
|
|
|
if (err)
|
2018-05-19 22:31:34 +02:00
|
|
|
goto out;
|
2016-05-10 23:27:21 +02:00
|
|
|
|
2016-08-15 17:19:00 -04:00
|
|
|
mv88e6xxx_phy_init(chip);
|
|
|
|
|
|
2018-05-19 22:31:35 +02:00
|
|
|
if (chip->info->ops->get_eeprom) {
|
|
|
|
|
if (np)
|
|
|
|
|
of_property_read_u32(np, "eeprom-length",
|
|
|
|
|
&chip->eeprom_len);
|
|
|
|
|
else
|
|
|
|
|
chip->eeprom_len = pdata->eeprom_len;
|
|
|
|
|
}
|
2016-05-10 23:27:25 +02:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
err = mv88e6xxx_switch_reset(chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
if (err)
|
|
|
|
|
goto out;
|
|
|
|
|
|
2019-05-01 00:10:50 +02:00
|
|
|
if (np) {
|
|
|
|
|
chip->irq = of_irq_get(np, 0);
|
|
|
|
|
if (chip->irq == -EPROBE_DEFER) {
|
|
|
|
|
err = chip->irq;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2016-10-16 19:56:49 +02:00
|
|
|
}
|
|
|
|
|
|
2019-05-01 00:10:50 +02:00
|
|
|
if (pdata)
|
|
|
|
|
chip->irq = pdata->irq;
|
|
|
|
|
|
2018-02-22 22:58:32 +01:00
|
|
|
/* Has to be performed before the MDIO bus is created, because
|
2018-03-20 10:44:41 +01:00
|
|
|
* the PHYs will link their interrupts to these interrupt
|
2018-02-22 22:58:32 +01:00
|
|
|
* controllers
|
|
|
|
|
*/
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-02-22 22:58:32 +01:00
|
|
|
if (chip->irq > 0)
|
2016-10-16 19:56:49 +02:00
|
|
|
err = mv88e6xxx_g1_irq_setup(chip);
|
2018-02-22 22:58:32 +01:00
|
|
|
else
|
|
|
|
|
err = mv88e6xxx_irq_poll_setup(chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-01-14 02:32:44 +01:00
|
|
|
|
2018-02-22 22:58:32 +01:00
|
|
|
if (err)
|
|
|
|
|
goto out;
|
2018-01-14 02:32:45 +01:00
|
|
|
|
2018-02-22 22:58:32 +01:00
|
|
|
if (chip->info->g2_irqs > 0) {
|
|
|
|
|
err = mv88e6xxx_g2_irq_setup(chip);
|
2018-01-14 02:32:45 +01:00
|
|
|
if (err)
|
2018-02-22 22:58:32 +01:00
|
|
|
goto out_g1_irq;
|
2016-10-16 19:56:49 +02:00
|
|
|
}
|
|
|
|
|
|
2018-02-22 22:58:32 +01:00
|
|
|
err = mv88e6xxx_g1_atu_prob_irq_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_g2_irq;
|
|
|
|
|
|
|
|
|
|
err = mv88e6xxx_g1_vtu_prob_irq_setup(chip);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_g1_atu_prob_irq;
|
|
|
|
|
|
2017-01-24 14:53:50 +01:00
|
|
|
err = mv88e6xxx_mdios_register(chip, np);
|
2016-06-04 21:17:06 +02:00
|
|
|
if (err)
|
2018-01-14 02:32:45 +01:00
|
|
|
goto out_g1_vtu_prob_irq;
|
2016-06-04 21:17:06 +02:00
|
|
|
|
2017-01-26 10:45:51 -08:00
|
|
|
err = mv88e6xxx_register_switch(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
if (err)
|
|
|
|
|
goto out_mdio;
|
2016-06-04 21:17:07 +02:00
|
|
|
|
2011-11-25 14:36:19 +00:00
|
|
|
return 0;
|
2016-10-16 19:56:49 +02:00
|
|
|
|
|
|
|
|
out_mdio:
|
2017-01-24 14:53:50 +01:00
|
|
|
mv88e6xxx_mdios_unregister(chip);
|
2018-01-14 02:32:45 +01:00
|
|
|
out_g1_vtu_prob_irq:
|
2018-02-22 22:58:32 +01:00
|
|
|
mv88e6xxx_g1_vtu_prob_irq_free(chip);
|
2018-01-14 02:32:44 +01:00
|
|
|
out_g1_atu_prob_irq:
|
2018-02-22 22:58:32 +01:00
|
|
|
mv88e6xxx_g1_atu_prob_irq_free(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
out_g2_irq:
|
2018-02-22 22:58:32 +01:00
|
|
|
if (chip->info->g2_irqs > 0)
|
2016-10-16 19:56:49 +02:00
|
|
|
mv88e6xxx_g2_irq_free(chip);
|
|
|
|
|
out_g1_irq:
|
2018-02-22 22:58:32 +01:00
|
|
|
if (chip->irq > 0)
|
2016-11-20 20:14:15 +01:00
|
|
|
mv88e6xxx_g1_irq_free(chip);
|
2018-02-22 22:58:32 +01:00
|
|
|
else
|
|
|
|
|
mv88e6xxx_irq_poll_free(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
out:
|
2018-05-19 22:31:34 +02:00
|
|
|
if (pdata)
|
|
|
|
|
dev_put(pdata->netdev);
|
|
|
|
|
|
2016-10-16 19:56:49 +02:00
|
|
|
return err;
|
2011-11-25 14:36:19 +00:00
|
|
|
}
|
2016-05-10 23:27:21 +02:00
|
|
|
|
|
|
|
|
static void mv88e6xxx_remove(struct mdio_device *mdiodev)
|
|
|
|
|
{
|
|
|
|
|
struct dsa_switch *ds = dev_get_drvdata(&mdiodev->dev);
|
2016-08-31 18:06:13 -04:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-05-10 23:27:21 +02:00
|
|
|
|
2018-02-14 01:07:50 +01:00
|
|
|
if (chip->info->ptp_support) {
|
|
|
|
|
mv88e6xxx_hwtstamp_free(chip);
|
2018-02-14 01:07:45 +01:00
|
|
|
mv88e6xxx_ptp_free(chip);
|
2018-02-14 01:07:50 +01:00
|
|
|
}
|
2018-02-14 01:07:45 +01:00
|
|
|
|
2016-08-22 16:01:03 +02:00
|
|
|
mv88e6xxx_phy_destroy(chip);
|
2016-06-21 12:28:20 -04:00
|
|
|
mv88e6xxx_unregister_switch(chip);
|
2017-01-24 14:53:50 +01:00
|
|
|
mv88e6xxx_mdios_unregister(chip);
|
2016-10-16 19:56:49 +02:00
|
|
|
|
2018-03-17 20:21:09 +01:00
|
|
|
mv88e6xxx_g1_vtu_prob_irq_free(chip);
|
|
|
|
|
mv88e6xxx_g1_atu_prob_irq_free(chip);
|
|
|
|
|
|
|
|
|
|
if (chip->info->g2_irqs > 0)
|
|
|
|
|
mv88e6xxx_g2_irq_free(chip);
|
|
|
|
|
|
|
|
|
|
if (chip->irq > 0)
|
2016-11-20 20:14:15 +01:00
|
|
|
mv88e6xxx_g1_irq_free(chip);
|
2018-03-17 20:21:09 +01:00
|
|
|
else
|
|
|
|
|
mv88e6xxx_irq_poll_free(chip);
|
2016-05-10 23:27:21 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct of_device_id mv88e6xxx_of_match[] = {
|
2016-06-20 13:14:09 -04:00
|
|
|
{
|
|
|
|
|
.compatible = "marvell,mv88e6085",
|
|
|
|
|
.data = &mv88e6xxx_table[MV88E6085],
|
|
|
|
|
},
|
2016-11-21 23:26:57 +01:00
|
|
|
{
|
|
|
|
|
.compatible = "marvell,mv88e6190",
|
|
|
|
|
.data = &mv88e6xxx_table[MV88E6190],
|
|
|
|
|
},
|
net: dsa: mv88e6xxx: add support for mv88e6250
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
introduce a new compatible string in order for the auto-identification
in mv88e6xxx_detect() to work.
The chip has four per port 16-bits statistics registers, two of which
correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
this be easy...). Wiring up those four statistics seems to require
introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
The chip does have ptp support, and the existing
mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
out-of-the-box, but for simplicity (and lack of testing) I'm eliding
this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-04 07:34:32 +00:00
|
|
|
{
|
|
|
|
|
.compatible = "marvell,mv88e6250",
|
|
|
|
|
.data = &mv88e6xxx_table[MV88E6250],
|
|
|
|
|
},
|
2016-05-10 23:27:21 +02:00
|
|
|
{ /* sentinel */ },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
MODULE_DEVICE_TABLE(of, mv88e6xxx_of_match);
|
|
|
|
|
|
|
|
|
|
static struct mdio_driver mv88e6xxx_driver = {
|
|
|
|
|
.probe = mv88e6xxx_probe,
|
|
|
|
|
.remove = mv88e6xxx_remove,
|
|
|
|
|
.mdiodrv.driver = {
|
|
|
|
|
.name = "mv88e6085",
|
|
|
|
|
.of_match_table = mv88e6xxx_of_match,
|
2019-02-05 12:07:28 +01:00
|
|
|
.pm = &mv88e6xxx_pm_ops,
|
2016-05-10 23:27:21 +02:00
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
|
2019-04-27 19:19:10 +02:00
|
|
|
mdio_module_driver(mv88e6xxx_driver);
|
2011-11-25 14:37:16 +00:00
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Lennert Buytenhek <buytenh@wantstofly.org>");
|
|
|
|
|
MODULE_DESCRIPTION("Driver for Marvell 88E6XXX ethernet switch chips");
|
|
|
|
|
MODULE_LICENSE("GPL");
|