2019-05-27 06:55:01 +00: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 16:28:19 +00: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 21:27:21 +00:00
|
|
|
* Copyright (c) 2016 Andrew Lunn <andrew@lunn.ch>
|
|
|
|
*
|
2017-03-28 19:10:36 +00: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 22:47:55 +00:00
|
|
|
#include <linux/bitfield.h>
|
2013-01-08 16:05:54 +00:00
|
|
|
#include <linux/delay.h>
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
#include <linux/dsa/mv88e6xxx.h>
|
2015-03-27 01:36:38 +00:00
|
|
|
#include <linux/etherdevice.h>
|
2015-08-31 13:56:47 +00:00
|
|
|
#include <linux/ethtool.h>
|
2015-03-27 01:36:35 +00:00
|
|
|
#include <linux/if_bridge.h>
|
2016-10-16 17:56:49 +00: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 21:27:21 +00:00
|
|
|
#include <linux/mdio.h>
|
2012-01-24 10:41:40 +00:00
|
|
|
#include <linux/module.h>
|
2023-07-24 21:18:58 +00:00
|
|
|
#include <linux/of.h>
|
2016-10-16 17:56:49 +00:00
|
|
|
#include <linux/of_irq.h>
|
2016-06-04 19:17:06 +00:00
|
|
|
#include <linux/of_mdio.h>
|
2018-05-19 20:31:34 +00: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 02:56:24 +00:00
|
|
|
#include <linux/gpio/consumer.h>
|
2018-05-10 20:17:35 +00:00
|
|
|
#include <linux/phylink.h>
|
2011-11-27 17:06:08 +00:00
|
|
|
#include <net/dsa.h>
|
2016-09-02 18:45:33 +00:00
|
|
|
|
2017-06-02 21:06:15 +00:00
|
|
|
#include "chip.h"
|
2020-09-18 19:11:05 +00:00
|
|
|
#include "devlink.h"
|
2016-09-29 16:21:53 +00:00
|
|
|
#include "global1.h"
|
2016-09-02 18:45:33 +00:00
|
|
|
#include "global2.h"
|
2018-02-14 00:07:50 +00:00
|
|
|
#include "hwtstamp.h"
|
2017-05-25 23:03:20 +00:00
|
|
|
#include "phy.h"
|
2016-11-04 02:23:26 +00:00
|
|
|
#include "port.h"
|
2018-02-14 00:07:45 +00:00
|
|
|
#include "ptp.h"
|
2017-05-25 23:03:21 +00:00
|
|
|
#include "serdes.h"
|
2019-05-03 23:28:22 +00: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 16:28:20 +00:00
|
|
|
static void assert_reg_lock(struct mv88e6xxx_chip *chip)
|
2015-10-30 22:56:45 +00:00
|
|
|
{
|
2016-06-21 16:28:20 +00:00
|
|
|
if (unlikely(!mutex_is_locked(&chip->reg_lock))) {
|
|
|
|
dev_err(chip->dev, "Switch registers lock not held!\n");
|
2015-10-30 22:56:45 +00:00
|
|
|
dump_stack();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-02 18:45:33 +00:00
|
|
|
int mv88e6xxx_read(struct mv88e6xxx_chip *chip, int addr, int reg, u16 *val)
|
2016-06-20 17:14:11 +00:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
assert_reg_lock(chip);
|
2016-06-20 17:14:11 +00:00
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
err = mv88e6xxx_smi_read(chip, addr, reg, val);
|
2016-06-20 17:14:11 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
dev_dbg(chip->dev, "<- addr: 0x%.2x reg: 0x%.2x val: 0x%.4x\n",
|
2016-06-20 17:14:11 +00:00
|
|
|
addr, reg, *val);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-02 18:45:33 +00: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 17:14:11 +00:00
|
|
|
int err;
|
|
|
|
|
2016-06-21 16:28:20 +00: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 16:28:20 +00:00
|
|
|
err = mv88e6xxx_smi_write(chip, addr, reg, val);
|
2016-06-20 17:14:11 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
dev_dbg(chip->dev, "-> addr: 0x%.2x reg: 0x%.2x val: 0x%.4x\n",
|
2015-01-23 21:10:36 +00:00
|
|
|
addr, reg, val);
|
|
|
|
|
2016-06-20 17:14:11 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-08-09 22:47:54 +00:00
|
|
|
int mv88e6xxx_wait_mask(struct mv88e6xxx_chip *chip, int addr, int reg,
|
|
|
|
u16 mask, u16 val)
|
|
|
|
{
|
2022-01-28 16:26:49 +00:00
|
|
|
const unsigned long timeout = jiffies + msecs_to_jiffies(50);
|
2019-08-09 22:47:54 +00:00
|
|
|
u16 data;
|
|
|
|
int err;
|
|
|
|
int i;
|
|
|
|
|
2022-01-28 16:26:49 +00:00
|
|
|
/* There's no bus specific operation to wait for a mask. Even
|
|
|
|
* if the initial poll takes longer than 50ms, always do at
|
|
|
|
* least one more attempt.
|
|
|
|
*/
|
|
|
|
for (i = 0; time_before(jiffies, timeout) || (i < 2); i++) {
|
2019-08-09 22:47:54 +00:00
|
|
|
err = mv88e6xxx_read(chip, addr, reg, &data);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if ((data & mask) == val)
|
|
|
|
return 0;
|
|
|
|
|
2022-01-28 16:26:49 +00:00
|
|
|
if (i < 2)
|
|
|
|
cpu_relax();
|
|
|
|
else
|
|
|
|
usleep_range(1000, 2000);
|
2019-08-09 22:47:54 +00:00
|
|
|
}
|
|
|
|
|
dsa: mv88e6xxx: Do a final check before timing out
I get sporadic timeouts from the driver when using the
MV88E6352. Reading the status again after the loop fixes the
problem: the operation is successful but goes undetected.
Some added prints show things like this:
[ 58.356209] mv88e6085 mdio_mux-0.1:00: Timeout while waiting
for switch, addr 1b reg 0b, mask 8000, val 0000, data c000
[ 58.367487] mv88e6085 mdio_mux-0.1:00: Timeout waiting for
ATU op 4000, fid 0001
(...)
[ 61.826293] mv88e6085 mdio_mux-0.1:00: Timeout while waiting
for switch, addr 1c reg 18, mask 8000, val 0000, data 9860
[ 61.837560] mv88e6085 mdio_mux-0.1:00: Timeout waiting
for PHY command 1860 to complete
The reason is probably not the commands: I think those are
mostly fine with the 50+50ms timeout, but the problem
appears when OpenWrt brings up several interfaces in
parallel on a system with 7 populated ports: if one of
them take more than 50 ms and waits one or more of the
others can get stuck on the mutex for the switch and then
this can easily multiply.
As we sleep and wait, the function loop needs a final
check after exiting the loop if we were successful.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Cc: Tobias Waldekranz <tobias@waldekranz.com>
Fixes: 35da1dfd9484 ("net: dsa: mv88e6xxx: Improve performance of busy bit polling")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230712223405.861899-1-linus.walleij@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-12 22:34:05 +00:00
|
|
|
err = mv88e6xxx_read(chip, addr, reg, &data);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if ((data & mask) == val)
|
|
|
|
return 0;
|
|
|
|
|
2019-08-09 22:47:54 +00:00
|
|
|
dev_err(chip->dev, "Timeout while waiting for switch\n");
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
|
|
|
|
2019-08-09 22:47:55 +00: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-25 23:03:20 +00:00
|
|
|
struct mii_bus *mv88e6xxx_default_mdio_bus(struct mv88e6xxx_chip *chip)
|
2017-01-24 13:53:50 +00: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 17:56:49 +00: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 21:58:32 +00:00
|
|
|
static irqreturn_t mv88e6xxx_g1_irq_thread_work(struct mv88e6xxx_chip *chip)
|
2016-10-16 17:56:49 +00:00
|
|
|
{
|
|
|
|
unsigned int nhandled = 0;
|
|
|
|
unsigned int sub_irq;
|
|
|
|
unsigned int n;
|
|
|
|
u16 reg;
|
2019-02-11 18:40:21 +00:00
|
|
|
u16 ctl1;
|
2016-10-16 17:56:49 +00:00
|
|
|
int err;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-06-15 16:13:59 +00:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_STS, ®);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-10-16 17:56:49 +00:00
|
|
|
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
2019-02-11 18:40:21 +00: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 17:56:49 +00:00
|
|
|
}
|
2019-02-11 18:40:21 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2019-02-11 18:40:21 +00: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 18:40:21 +00:00
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
ctl1 &= GENMASK(chip->g1_irq.nirqs, 0);
|
|
|
|
} while (reg & ctl1);
|
|
|
|
|
2016-10-16 17:56:49 +00:00
|
|
|
out:
|
|
|
|
return (nhandled > 0 ? IRQ_HANDLED : IRQ_NONE);
|
|
|
|
}
|
|
|
|
|
2018-02-22 21:58:32 +00: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 17:56:49 +00: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 17:56:49 +00: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 16:14:03 +00:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_CTL1, ®);
|
2016-10-16 17:56:49 +00:00
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
reg &= ~mask;
|
|
|
|
reg |= (~chip->g1_irq.masked & mask);
|
|
|
|
|
2017-06-15 16:14:03 +00:00
|
|
|
err = mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, reg);
|
2016-10-16 17:56:49 +00:00
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
out:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-10-16 17:56:49 +00:00
|
|
|
}
|
|
|
|
|
2017-08-19 10:55:52 +00:00
|
|
|
static const struct irq_chip mv88e6xxx_g1_irq_chip = {
|
2016-10-16 17:56:49 +00: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 09:53:15 +00:00
|
|
|
/* To be called with reg_lock held */
|
2018-02-22 21:58:32 +00:00
|
|
|
static void mv88e6xxx_g1_irq_free_common(struct mv88e6xxx_chip *chip)
|
2016-10-16 17:56:49 +00:00
|
|
|
{
|
|
|
|
int irq, virq;
|
2016-11-20 19:14:16 +00:00
|
|
|
u16 mask;
|
|
|
|
|
2017-06-15 16:14:03 +00:00
|
|
|
mv88e6xxx_g1_read(chip, MV88E6XXX_G1_CTL1, &mask);
|
2017-12-07 00:05:56 +00:00
|
|
|
mask &= ~GENMASK(chip->g1_irq.nirqs, 0);
|
2017-06-15 16:14:03 +00:00
|
|
|
mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, mask);
|
2016-11-20 19:14:16 +00:00
|
|
|
|
2016-11-27 22:26:28 +00:00
|
|
|
for (irq = 0; irq < chip->g1_irq.nirqs; irq++) {
|
2016-11-20 19:14:14 +00:00
|
|
|
virq = irq_find_mapping(chip->g1_irq.domain, irq);
|
2016-10-16 17:56:49 +00:00
|
|
|
irq_dispose_mapping(virq);
|
|
|
|
}
|
|
|
|
|
2016-11-20 19:14:14 +00:00
|
|
|
irq_domain_remove(chip->g1_irq.domain);
|
2016-10-16 17:56:49 +00:00
|
|
|
}
|
|
|
|
|
2018-02-22 21:58:32 +00:00
|
|
|
static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip *chip)
|
|
|
|
{
|
2018-07-20 09:53:15 +00:00
|
|
|
/*
|
|
|
|
* free_irq must be called without reg_lock taken because the irq
|
|
|
|
* handler takes this lock, too.
|
|
|
|
*/
|
2018-02-22 21:58:32 +00:00
|
|
|
free_irq(chip->irq, chip);
|
2018-07-20 09:53:15 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-07-20 09:53:15 +00:00
|
|
|
mv88e6xxx_g1_irq_free_common(chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-22 21:58:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_g1_irq_setup_common(struct mv88e6xxx_chip *chip)
|
2016-10-16 17:56:49 +00:00
|
|
|
{
|
2016-11-20 19:14:17 +00:00
|
|
|
int err, irq, virq;
|
|
|
|
u16 reg, mask;
|
2016-10-16 17:56:49 +00: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 16:14:03 +00:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_CTL1, &mask);
|
2016-10-16 17:56:49 +00:00
|
|
|
if (err)
|
2016-11-20 19:14:17 +00:00
|
|
|
goto out_mapping;
|
2016-10-16 17:56:49 +00:00
|
|
|
|
2016-11-20 19:14:17 +00:00
|
|
|
mask &= ~GENMASK(chip->g1_irq.nirqs, 0);
|
2016-10-16 17:56:49 +00:00
|
|
|
|
2017-06-15 16:14:03 +00:00
|
|
|
err = mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, mask);
|
2016-10-16 17:56:49 +00:00
|
|
|
if (err)
|
2016-11-20 19:14:17 +00:00
|
|
|
goto out_disable;
|
2016-10-16 17:56:49 +00:00
|
|
|
|
|
|
|
/* Reading the interrupt status clears (most of) them */
|
2017-06-15 16:13:59 +00:00
|
|
|
err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_STS, ®);
|
2016-10-16 17:56:49 +00:00
|
|
|
if (err)
|
2016-11-20 19:14:17 +00:00
|
|
|
goto out_disable;
|
2016-10-16 17:56:49 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2016-11-20 19:14:17 +00:00
|
|
|
out_disable:
|
2017-12-07 00:05:56 +00:00
|
|
|
mask &= ~GENMASK(chip->g1_irq.nirqs, 0);
|
2017-06-15 16:14:03 +00:00
|
|
|
mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, mask);
|
2016-11-20 19:14:17 +00: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 17:56:49 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-02-22 21:58:32 +00:00
|
|
|
static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
{
|
2019-02-23 16:43:56 +00:00
|
|
|
static struct lock_class_key lock_key;
|
|
|
|
static struct lock_class_key request_key;
|
2018-02-22 21:58:32 +00:00
|
|
|
int err;
|
|
|
|
|
|
|
|
err = mv88e6xxx_g1_irq_setup_common(chip);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2019-02-23 16:43:56 +00: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 16:13:48 +00: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 21:58:32 +00:00
|
|
|
err = request_threaded_irq(chip->irq, NULL,
|
|
|
|
mv88e6xxx_g1_irq_thread_fn,
|
2018-08-30 00:13:50 +00:00
|
|
|
IRQF_ONESHOT | IRQF_SHARED,
|
2020-01-06 16:13:48 +00:00
|
|
|
chip->irq_name, chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-02-22 21:58:32 +00: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-22 04:09:27 +00:00
|
|
|
chip->kworker = kthread_create_worker(0, "%s", dev_name(chip->dev));
|
2018-02-22 21:58:32 +00: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 09:53:15 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-07-20 09:53:15 +00:00
|
|
|
mv88e6xxx_g1_irq_free_common(chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-22 21:58:32 +00: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 02:23:36 +00: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 10:11:42 +00:00
|
|
|
err = chip->info->ops->port_set_link(chip, port, LINK_FORCED_DOWN);
|
2016-11-04 02:23:36 +00: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 02:23:36 +00:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
goto restore_link;
|
|
|
|
}
|
|
|
|
|
2018-08-09 13:38:37 +00: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 02:23:36 +00:00
|
|
|
restore_link:
|
|
|
|
if (chip->info->ops->port_set_link(chip, port, link))
|
2017-06-08 22:34:08 +00:00
|
|
|
dev_err(chip->dev, "p%d: failed to restore MAC's link\n", port);
|
2016-11-04 02:23:36 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2023-05-29 08:02:41 +00:00
|
|
|
static int mv88e6xxx_phy_is_internal(struct mv88e6xxx_chip *chip, int port)
|
2018-09-11 22:15:24 +00:00
|
|
|
{
|
2023-05-29 08:02:43 +00:00
|
|
|
return port >= chip->info->internal_phys_offset &&
|
|
|
|
port < chip->info->num_internal_phys +
|
|
|
|
chip->info->internal_phys_offset;
|
2018-09-11 22:15:24 +00:00
|
|
|
}
|
|
|
|
|
2020-03-14 10:16:03 +00:00
|
|
|
static int mv88e6xxx_port_ppu_updates(struct mv88e6xxx_chip *chip, int port)
|
|
|
|
{
|
|
|
|
u16 reg;
|
|
|
|
int err;
|
|
|
|
|
net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's"
This commit fixes a misunderstanding in commit 4a3e0aeddf09 ("net: dsa:
mv88e6xxx: don't use PHY_DETECT on internal PHY's").
For Marvell DSA switches with the PHY_DETECT bit (for non-6250 family
devices), controls whether the PPU polls the PHY to retrieve the link,
speed, duplex and pause status to update the port configuration. This
applies for both internal and external PHYs.
For some switches such as 88E6352 and 88E6390X, PHY_DETECT has an
additional function of enabling auto-media mode between the internal
PHY and SERDES blocks depending on which first gains link.
The original intention of commit 5d5b231da7ac (net: dsa: mv88e6xxx: use
PHY_DETECT in mac_link_up/mac_link_down) was to allow this bit to be
used to detect when this propagation is enabled, and allow software to
update the port configuration. This has found to be necessary for some
switches which do not automatically propagate status from the SERDES to
the port, which includes the 88E6390. However, commit 4a3e0aeddf09
("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's") breaks
this assumption.
Maarten Zanders has confirmed that the issue he was addressing was for
an 88E6250 switch, which does not have a PHY_DETECT bit in bit 12, but
instead a link status bit. Therefore, mv88e6xxx_port_ppu_updates() does
not report correctly.
This patch resolves the above issues by reverting Maarten's change and
instead making mv88e6xxx_port_ppu_updates() indicate whether the port
is internal for the 88E6250 family of switches.
Yes, you're right, I'm targeting the 6250 family. And yes, your
suggestion would solve my case and is a better implementation for
the other devices (as far as I can see).
Fixes: 4a3e0aeddf09 ("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Maarten Zanders <maarten.zanders@mind.be>
Link: https://lore.kernel.org/r/E1muXm7-00EwJB-7n@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-07 10:32:43 +00:00
|
|
|
/* The 88e6250 family does not have the PHY detect bit. Instead,
|
|
|
|
* report whether the port is internal.
|
|
|
|
*/
|
|
|
|
if (chip->info->family == MV88E6XXX_FAMILY_6250)
|
2023-05-29 08:02:42 +00:00
|
|
|
return mv88e6xxx_phy_is_internal(chip, port);
|
net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's"
This commit fixes a misunderstanding in commit 4a3e0aeddf09 ("net: dsa:
mv88e6xxx: don't use PHY_DETECT on internal PHY's").
For Marvell DSA switches with the PHY_DETECT bit (for non-6250 family
devices), controls whether the PPU polls the PHY to retrieve the link,
speed, duplex and pause status to update the port configuration. This
applies for both internal and external PHYs.
For some switches such as 88E6352 and 88E6390X, PHY_DETECT has an
additional function of enabling auto-media mode between the internal
PHY and SERDES blocks depending on which first gains link.
The original intention of commit 5d5b231da7ac (net: dsa: mv88e6xxx: use
PHY_DETECT in mac_link_up/mac_link_down) was to allow this bit to be
used to detect when this propagation is enabled, and allow software to
update the port configuration. This has found to be necessary for some
switches which do not automatically propagate status from the SERDES to
the port, which includes the 88E6390. However, commit 4a3e0aeddf09
("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's") breaks
this assumption.
Maarten Zanders has confirmed that the issue he was addressing was for
an 88E6250 switch, which does not have a PHY_DETECT bit in bit 12, but
instead a link status bit. Therefore, mv88e6xxx_port_ppu_updates() does
not report correctly.
This patch resolves the above issues by reverting Maarten's change and
instead making mv88e6xxx_port_ppu_updates() indicate whether the port
is internal for the 88E6250 family of switches.
Yes, you're right, I'm targeting the 6250 family. And yes, your
suggestion would solve my case and is a better implementation for
the other devices (as far as I can see).
Fixes: 4a3e0aeddf09 ("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Maarten Zanders <maarten.zanders@mind.be>
Link: https://lore.kernel.org/r/E1muXm7-00EwJB-7n@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-07 10:32:43 +00:00
|
|
|
|
2020-03-14 10:16:03 +00:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2022-02-03 13:30:42 +00:00
|
|
|
static const u8 mv88e6185_phy_interface_modes[] = {
|
|
|
|
[MV88E6185_PORT_STS_CMODE_GMII_FD] = PHY_INTERFACE_MODE_GMII,
|
|
|
|
[MV88E6185_PORT_STS_CMODE_MII_100_FD_PS] = PHY_INTERFACE_MODE_MII,
|
|
|
|
[MV88E6185_PORT_STS_CMODE_MII_100] = PHY_INTERFACE_MODE_MII,
|
|
|
|
[MV88E6185_PORT_STS_CMODE_MII_10] = PHY_INTERFACE_MODE_MII,
|
|
|
|
[MV88E6185_PORT_STS_CMODE_SERDES] = PHY_INTERFACE_MODE_1000BASEX,
|
|
|
|
[MV88E6185_PORT_STS_CMODE_1000BASE_X] = PHY_INTERFACE_MODE_1000BASEX,
|
|
|
|
[MV88E6185_PORT_STS_CMODE_PHY] = PHY_INTERFACE_MODE_SGMII,
|
|
|
|
};
|
|
|
|
|
2022-02-13 18:51:54 +00:00
|
|
|
static void mv88e6095_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
u8 cmode = chip->ports[port].cmode;
|
|
|
|
|
|
|
|
config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100;
|
|
|
|
|
2023-05-29 08:02:41 +00:00
|
|
|
if (mv88e6xxx_phy_is_internal(chip, port)) {
|
2022-02-13 18:51:54 +00:00
|
|
|
__set_bit(PHY_INTERFACE_MODE_MII, config->supported_interfaces);
|
|
|
|
} else {
|
|
|
|
if (cmode < ARRAY_SIZE(mv88e6185_phy_interface_modes) &&
|
|
|
|
mv88e6185_phy_interface_modes[cmode])
|
|
|
|
__set_bit(mv88e6185_phy_interface_modes[cmode],
|
|
|
|
config->supported_interfaces);
|
|
|
|
|
|
|
|
config->mac_capabilities |= MAC_1000FD;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-02-03 13:30:42 +00:00
|
|
|
static void mv88e6185_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
u8 cmode = chip->ports[port].cmode;
|
|
|
|
|
2022-02-07 08:22:53 +00:00
|
|
|
if (cmode < ARRAY_SIZE(mv88e6185_phy_interface_modes) &&
|
2022-02-03 13:30:42 +00:00
|
|
|
mv88e6185_phy_interface_modes[cmode])
|
|
|
|
__set_bit(mv88e6185_phy_interface_modes[cmode],
|
|
|
|
config->supported_interfaces);
|
2018-08-09 13:38:39 +00:00
|
|
|
|
2022-02-03 13:30:42 +00:00
|
|
|
config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100 |
|
|
|
|
MAC_1000FD;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const u8 mv88e6xxx_phy_interface_modes[] = {
|
2023-04-11 02:35:41 +00:00
|
|
|
[MV88E6XXX_PORT_STS_CMODE_MII_PHY] = PHY_INTERFACE_MODE_REVMII,
|
2022-02-03 13:30:42 +00:00
|
|
|
[MV88E6XXX_PORT_STS_CMODE_MII] = PHY_INTERFACE_MODE_MII,
|
|
|
|
[MV88E6XXX_PORT_STS_CMODE_GMII] = PHY_INTERFACE_MODE_GMII,
|
2023-04-11 02:35:41 +00:00
|
|
|
[MV88E6XXX_PORT_STS_CMODE_RMII_PHY] = PHY_INTERFACE_MODE_REVRMII,
|
2022-02-03 13:30:42 +00:00
|
|
|
[MV88E6XXX_PORT_STS_CMODE_RMII] = PHY_INTERFACE_MODE_RMII,
|
|
|
|
[MV88E6XXX_PORT_STS_CMODE_100BASEX] = PHY_INTERFACE_MODE_100BASEX,
|
|
|
|
[MV88E6XXX_PORT_STS_CMODE_1000BASEX] = PHY_INTERFACE_MODE_1000BASEX,
|
|
|
|
[MV88E6XXX_PORT_STS_CMODE_SGMII] = PHY_INTERFACE_MODE_SGMII,
|
|
|
|
/* higher interface modes are not needed here, since ports supporting
|
|
|
|
* them are writable, and so the supported interfaces are filled in the
|
|
|
|
* corresponding .phylink_set_interfaces() implementation below
|
2018-08-09 13:38:39 +00:00
|
|
|
*/
|
2022-02-03 13:30:42 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void mv88e6xxx_translate_cmode(u8 cmode, unsigned long *supported)
|
|
|
|
{
|
|
|
|
if (cmode < ARRAY_SIZE(mv88e6xxx_phy_interface_modes) &&
|
|
|
|
mv88e6xxx_phy_interface_modes[cmode])
|
|
|
|
__set_bit(mv88e6xxx_phy_interface_modes[cmode], supported);
|
|
|
|
else if (cmode == MV88E6XXX_PORT_STS_CMODE_RGMII)
|
|
|
|
phy_interface_set_rgmii(supported);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6250_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
unsigned long *supported = config->supported_interfaces;
|
|
|
|
|
|
|
|
/* Translate the default cmode */
|
|
|
|
mv88e6xxx_translate_cmode(chip->ports[port].cmode, supported);
|
|
|
|
|
|
|
|
config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100;
|
|
|
|
}
|
|
|
|
|
2023-11-24 04:15:28 +00:00
|
|
|
static void mv88e6351_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
unsigned long *supported = config->supported_interfaces;
|
|
|
|
|
|
|
|
/* Translate the default cmode */
|
|
|
|
mv88e6xxx_translate_cmode(chip->ports[port].cmode, supported);
|
|
|
|
|
|
|
|
config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100 |
|
|
|
|
MAC_1000FD;
|
|
|
|
}
|
|
|
|
|
2022-02-03 13:30:42 +00:00
|
|
|
static int mv88e6352_get_port4_serdes_cmode(struct mv88e6xxx_chip *chip)
|
|
|
|
{
|
|
|
|
u16 reg, val;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_read(chip, 4, MV88E6XXX_PORT_STS, ®);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* If PHY_DETECT is zero, then we are not in auto-media mode */
|
|
|
|
if (!(reg & MV88E6XXX_PORT_STS_PHY_DETECT))
|
|
|
|
return 0xf;
|
|
|
|
|
|
|
|
val = reg & ~MV88E6XXX_PORT_STS_PHY_DETECT;
|
|
|
|
err = mv88e6xxx_port_write(chip, 4, MV88E6XXX_PORT_STS, val);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_read(chip, 4, MV88E6XXX_PORT_STS, &val);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* Restore PHY_DETECT value */
|
|
|
|
err = mv88e6xxx_port_write(chip, 4, MV88E6XXX_PORT_STS, reg);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
return val & MV88E6XXX_PORT_STS_CMODE_MASK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6352_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
unsigned long *supported = config->supported_interfaces;
|
|
|
|
int err, cmode;
|
|
|
|
|
|
|
|
/* Translate the default cmode */
|
|
|
|
mv88e6xxx_translate_cmode(chip->ports[port].cmode, supported);
|
|
|
|
|
|
|
|
config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100 |
|
|
|
|
MAC_1000FD;
|
|
|
|
|
|
|
|
/* Port 4 supports automedia if the serdes is associated with it. */
|
|
|
|
if (port == 4) {
|
|
|
|
err = mv88e6352_g2_scratch_port_has_serdes(chip, port);
|
|
|
|
if (err < 0)
|
|
|
|
dev_err(chip->dev, "p%d: failed to read scratch\n",
|
|
|
|
port);
|
|
|
|
if (err <= 0)
|
net: dsa: mv88e6xxx: avoid reg_lock deadlock in mv88e6xxx_setup_port()
In the blamed commit, it was not noticed that one implementation of
chip->info->ops->phylink_get_caps(), called by mv88e6xxx_get_caps(),
may access hardware registers, and in doing so, it takes the
mv88e6xxx_reg_lock(). Namely, this is mv88e6352_phylink_get_caps().
This is a problem because mv88e6xxx_get_caps(), apart from being
a top-level function (method invoked by dsa_switch_ops), is now also
directly called from mv88e6xxx_setup_port(), which runs under the
mv88e6xxx_reg_lock() taken by mv88e6xxx_setup(). Therefore, when running
on mv88e6352, the reg_lock would be acquired a second time and the
system would deadlock on driver probe.
The things that mv88e6xxx_setup() can compete with in terms of register
access with are the IRQ handlers and MDIO bus operations registered by
mv88e6xxx_probe(). So there is a real need to acquire the register lock.
The register lock can, in principle, be dropped and re-acquired pretty
much at will within the driver, as long as no operations that involve
waiting for indirect access to complete (essentially, callers of
mv88e6xxx_smi_direct_wait() and mv88e6xxx_wait_mask()) are interrupted
with the lock released. However, I would guess that in mv88e6xxx_setup(),
the critical section is kept open for such a long time just in order to
optimize away multiple lock/unlock operations on the registers.
We could, in principle, drop the reg_lock right before the
mv88e6xxx_setup_port() -> mv88e6xxx_get_caps() call, and
re-acquire it immediately afterwards. But this would look ugly, because
mv88e6xxx_setup_port() would release a lock which it didn't acquire, but
the caller did.
A cleaner solution to this issue comes from the observation that struct
mv88e6xxxx_ops methods generally assume they are called with the
reg_lock already acquired. Whereas mv88e6352_phylink_get_caps() is more
the exception rather than the norm, in that it acquires the lock itself.
Let's enforce the same locking pattern/convention for
chip->info->ops->phylink_get_caps() as well, and make
mv88e6xxx_get_caps(), the top-level function, acquire the register lock
explicitly, for this one implementation that will access registers for
port 4 to work properly.
This means that mv88e6xxx_setup_port() will no longer call the top-level
function, but the low-level mv88e6xxx_ops method which expects the
correct calling context (register lock held).
Compared to chip->info->ops->phylink_get_caps(), mv88e6xxx_get_caps()
also fixes up the supported_interfaces bitmap for internal ports, since
that can be done generically and does not require per-switch knowledge.
That's code which will no longer execute, however mv88e6xxx_setup_port()
doesn't need that. It just needs to look at the mac_capabilities bitmap.
Fixes: cc1049ccee20 ("net: dsa: mv88e6xxx: fix speed setting for CPU/DSA ports")
Reported-by: Maksim Kiselev <bigunclemax@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Maksim Kiselev <bigunclemax@gmail.com>
Link: https://lore.kernel.org/r/20221214110120.3368472-1-vladimir.oltean@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-14 11:01:20 +00:00
|
|
|
return;
|
2022-02-03 13:30:42 +00:00
|
|
|
|
|
|
|
cmode = mv88e6352_get_port4_serdes_cmode(chip);
|
|
|
|
if (cmode < 0)
|
|
|
|
dev_err(chip->dev, "p%d: failed to read serdes cmode\n",
|
|
|
|
port);
|
|
|
|
else
|
|
|
|
mv88e6xxx_translate_cmode(cmode, supported);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6341_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
unsigned long *supported = config->supported_interfaces;
|
|
|
|
|
|
|
|
/* Translate the default cmode */
|
|
|
|
mv88e6xxx_translate_cmode(chip->ports[port].cmode, supported);
|
|
|
|
|
|
|
|
/* No ethtool bits for 200Mbps */
|
|
|
|
config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100 |
|
|
|
|
MAC_1000FD;
|
|
|
|
|
|
|
|
/* The C_Mode field is programmable on port 5 */
|
|
|
|
if (port == 5) {
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_SGMII, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_1000BASEX, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_2500BASEX, supported);
|
|
|
|
|
|
|
|
config->mac_capabilities |= MAC_2500FD;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6390_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
unsigned long *supported = config->supported_interfaces;
|
|
|
|
|
|
|
|
/* Translate the default cmode */
|
|
|
|
mv88e6xxx_translate_cmode(chip->ports[port].cmode, supported);
|
|
|
|
|
|
|
|
/* No ethtool bits for 200Mbps */
|
|
|
|
config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100 |
|
|
|
|
MAC_1000FD;
|
|
|
|
|
|
|
|
/* The C_Mode field is programmable on ports 9 and 10 */
|
|
|
|
if (port == 9 || port == 10) {
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_SGMII, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_1000BASEX, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_2500BASEX, supported);
|
|
|
|
|
|
|
|
config->mac_capabilities |= MAC_2500FD;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6390x_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
unsigned long *supported = config->supported_interfaces;
|
|
|
|
|
|
|
|
mv88e6390_phylink_get_caps(chip, port, config);
|
|
|
|
|
|
|
|
/* For the 6x90X, ports 2-7 can be in automedia mode.
|
|
|
|
* (Note that 6x90 doesn't support RXAUI nor XAUI).
|
|
|
|
*
|
|
|
|
* Port 2 can also support 1000BASE-X in automedia mode if port 9 is
|
|
|
|
* configured for 1000BASE-X, SGMII or 2500BASE-X.
|
|
|
|
* Port 3-4 can also support 1000BASE-X in automedia mode if port 9 is
|
|
|
|
* configured for RXAUI, 1000BASE-X, SGMII or 2500BASE-X.
|
|
|
|
*
|
|
|
|
* Port 5 can also support 1000BASE-X in automedia mode if port 10 is
|
|
|
|
* configured for 1000BASE-X, SGMII or 2500BASE-X.
|
|
|
|
* Port 6-7 can also support 1000BASE-X in automedia mode if port 10 is
|
|
|
|
* configured for RXAUI, 1000BASE-X, SGMII or 2500BASE-X.
|
|
|
|
*
|
|
|
|
* For now, be permissive (as the old code was) and allow 1000BASE-X
|
|
|
|
* on ports 2..7.
|
|
|
|
*/
|
|
|
|
if (port >= 2 && port <= 7)
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_1000BASEX, supported);
|
|
|
|
|
|
|
|
/* The C_Mode field can also be programmed for 10G speeds */
|
|
|
|
if (port == 9 || port == 10) {
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_XAUI, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_RXAUI, supported);
|
|
|
|
|
|
|
|
config->mac_capabilities |= MAC_10000FD;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6393x_phylink_get_caps(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
unsigned long *supported = config->supported_interfaces;
|
|
|
|
bool is_6191x =
|
|
|
|
chip->info->prod_num == MV88E6XXX_PORT_SWITCH_ID_PROD_6191X;
|
2023-05-29 08:02:46 +00:00
|
|
|
bool is_6361 =
|
|
|
|
chip->info->prod_num == MV88E6XXX_PORT_SWITCH_ID_PROD_6361;
|
2022-02-03 13:30:42 +00:00
|
|
|
|
|
|
|
mv88e6xxx_translate_cmode(chip->ports[port].cmode, supported);
|
|
|
|
|
|
|
|
config->mac_capabilities = MAC_SYM_PAUSE | MAC_10 | MAC_100 |
|
|
|
|
MAC_1000FD;
|
|
|
|
|
|
|
|
/* The C_Mode field can be programmed for ports 0, 9 and 10 */
|
|
|
|
if (port == 0 || port == 9 || port == 10) {
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_SGMII, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_1000BASEX, supported);
|
|
|
|
|
|
|
|
/* 6191X supports >1G modes only on port 10 */
|
|
|
|
if (!is_6191x || port == 10) {
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_2500BASEX, supported);
|
2023-05-29 08:02:46 +00:00
|
|
|
config->mac_capabilities |= MAC_2500FD;
|
|
|
|
|
|
|
|
/* 6361 only supports up to 2500BaseX */
|
|
|
|
if (!is_6361) {
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_5GBASER, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_10GBASER, supported);
|
2023-06-05 17:44:42 +00:00
|
|
|
__set_bit(PHY_INTERFACE_MODE_USXGMII, supported);
|
2023-05-29 08:02:46 +00:00
|
|
|
config->mac_capabilities |= MAC_5000FD |
|
|
|
|
MAC_10000FD;
|
|
|
|
}
|
2022-02-03 13:30:42 +00:00
|
|
|
}
|
|
|
|
}
|
2022-08-22 14:41:36 +00:00
|
|
|
|
|
|
|
if (port == 0) {
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_RMII, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_RGMII, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_RGMII_ID, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_RGMII_RXID, supported);
|
|
|
|
__set_bit(PHY_INTERFACE_MODE_RGMII_TXID, supported);
|
|
|
|
}
|
2022-02-03 13:30:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6xxx_get_caps(struct dsa_switch *ds, int port,
|
|
|
|
struct phylink_config *config)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
net: dsa: mv88e6xxx: avoid reg_lock deadlock in mv88e6xxx_setup_port()
In the blamed commit, it was not noticed that one implementation of
chip->info->ops->phylink_get_caps(), called by mv88e6xxx_get_caps(),
may access hardware registers, and in doing so, it takes the
mv88e6xxx_reg_lock(). Namely, this is mv88e6352_phylink_get_caps().
This is a problem because mv88e6xxx_get_caps(), apart from being
a top-level function (method invoked by dsa_switch_ops), is now also
directly called from mv88e6xxx_setup_port(), which runs under the
mv88e6xxx_reg_lock() taken by mv88e6xxx_setup(). Therefore, when running
on mv88e6352, the reg_lock would be acquired a second time and the
system would deadlock on driver probe.
The things that mv88e6xxx_setup() can compete with in terms of register
access with are the IRQ handlers and MDIO bus operations registered by
mv88e6xxx_probe(). So there is a real need to acquire the register lock.
The register lock can, in principle, be dropped and re-acquired pretty
much at will within the driver, as long as no operations that involve
waiting for indirect access to complete (essentially, callers of
mv88e6xxx_smi_direct_wait() and mv88e6xxx_wait_mask()) are interrupted
with the lock released. However, I would guess that in mv88e6xxx_setup(),
the critical section is kept open for such a long time just in order to
optimize away multiple lock/unlock operations on the registers.
We could, in principle, drop the reg_lock right before the
mv88e6xxx_setup_port() -> mv88e6xxx_get_caps() call, and
re-acquire it immediately afterwards. But this would look ugly, because
mv88e6xxx_setup_port() would release a lock which it didn't acquire, but
the caller did.
A cleaner solution to this issue comes from the observation that struct
mv88e6xxxx_ops methods generally assume they are called with the
reg_lock already acquired. Whereas mv88e6352_phylink_get_caps() is more
the exception rather than the norm, in that it acquires the lock itself.
Let's enforce the same locking pattern/convention for
chip->info->ops->phylink_get_caps() as well, and make
mv88e6xxx_get_caps(), the top-level function, acquire the register lock
explicitly, for this one implementation that will access registers for
port 4 to work properly.
This means that mv88e6xxx_setup_port() will no longer call the top-level
function, but the low-level mv88e6xxx_ops method which expects the
correct calling context (register lock held).
Compared to chip->info->ops->phylink_get_caps(), mv88e6xxx_get_caps()
also fixes up the supported_interfaces bitmap for internal ports, since
that can be done generically and does not require per-switch knowledge.
That's code which will no longer execute, however mv88e6xxx_setup_port()
doesn't need that. It just needs to look at the mac_capabilities bitmap.
Fixes: cc1049ccee20 ("net: dsa: mv88e6xxx: fix speed setting for CPU/DSA ports")
Reported-by: Maksim Kiselev <bigunclemax@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Maksim Kiselev <bigunclemax@gmail.com>
Link: https://lore.kernel.org/r/20221214110120.3368472-1-vladimir.oltean@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-14 11:01:20 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2022-02-03 13:30:42 +00:00
|
|
|
chip->info->ops->phylink_get_caps(chip, port, config);
|
net: dsa: mv88e6xxx: avoid reg_lock deadlock in mv88e6xxx_setup_port()
In the blamed commit, it was not noticed that one implementation of
chip->info->ops->phylink_get_caps(), called by mv88e6xxx_get_caps(),
may access hardware registers, and in doing so, it takes the
mv88e6xxx_reg_lock(). Namely, this is mv88e6352_phylink_get_caps().
This is a problem because mv88e6xxx_get_caps(), apart from being
a top-level function (method invoked by dsa_switch_ops), is now also
directly called from mv88e6xxx_setup_port(), which runs under the
mv88e6xxx_reg_lock() taken by mv88e6xxx_setup(). Therefore, when running
on mv88e6352, the reg_lock would be acquired a second time and the
system would deadlock on driver probe.
The things that mv88e6xxx_setup() can compete with in terms of register
access with are the IRQ handlers and MDIO bus operations registered by
mv88e6xxx_probe(). So there is a real need to acquire the register lock.
The register lock can, in principle, be dropped and re-acquired pretty
much at will within the driver, as long as no operations that involve
waiting for indirect access to complete (essentially, callers of
mv88e6xxx_smi_direct_wait() and mv88e6xxx_wait_mask()) are interrupted
with the lock released. However, I would guess that in mv88e6xxx_setup(),
the critical section is kept open for such a long time just in order to
optimize away multiple lock/unlock operations on the registers.
We could, in principle, drop the reg_lock right before the
mv88e6xxx_setup_port() -> mv88e6xxx_get_caps() call, and
re-acquire it immediately afterwards. But this would look ugly, because
mv88e6xxx_setup_port() would release a lock which it didn't acquire, but
the caller did.
A cleaner solution to this issue comes from the observation that struct
mv88e6xxxx_ops methods generally assume they are called with the
reg_lock already acquired. Whereas mv88e6352_phylink_get_caps() is more
the exception rather than the norm, in that it acquires the lock itself.
Let's enforce the same locking pattern/convention for
chip->info->ops->phylink_get_caps() as well, and make
mv88e6xxx_get_caps(), the top-level function, acquire the register lock
explicitly, for this one implementation that will access registers for
port 4 to work properly.
This means that mv88e6xxx_setup_port() will no longer call the top-level
function, but the low-level mv88e6xxx_ops method which expects the
correct calling context (register lock held).
Compared to chip->info->ops->phylink_get_caps(), mv88e6xxx_get_caps()
also fixes up the supported_interfaces bitmap for internal ports, since
that can be done generically and does not require per-switch knowledge.
That's code which will no longer execute, however mv88e6xxx_setup_port()
doesn't need that. It just needs to look at the mac_capabilities bitmap.
Fixes: cc1049ccee20 ("net: dsa: mv88e6xxx: fix speed setting for CPU/DSA ports")
Reported-by: Maksim Kiselev <bigunclemax@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Maksim Kiselev <bigunclemax@gmail.com>
Link: https://lore.kernel.org/r/20221214110120.3368472-1-vladimir.oltean@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-14 11:01:20 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2022-02-03 13:30:42 +00:00
|
|
|
|
2023-05-29 08:02:41 +00:00
|
|
|
if (mv88e6xxx_phy_is_internal(chip, port)) {
|
2022-12-05 19:48:45 +00:00
|
|
|
__set_bit(PHY_INTERFACE_MODE_INTERNAL,
|
|
|
|
config->supported_interfaces);
|
|
|
|
/* Internal ports with no phy-mode need GMII for PHYLIB */
|
2022-02-03 13:30:42 +00:00
|
|
|
__set_bit(PHY_INTERFACE_MODE_GMII,
|
|
|
|
config->supported_interfaces);
|
2022-12-05 19:48:45 +00:00
|
|
|
}
|
2023-07-13 08:42:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct phylink_pcs *mv88e6xxx_mac_select_pcs(struct dsa_switch *ds,
|
|
|
|
int port,
|
|
|
|
phy_interface_t interface)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
struct phylink_pcs *pcs = ERR_PTR(-EOPNOTSUPP);
|
|
|
|
|
|
|
|
if (chip->info->ops->pcs_ops)
|
|
|
|
pcs = chip->info->ops->pcs_ops->pcs_select(chip, port,
|
|
|
|
interface);
|
|
|
|
|
|
|
|
return pcs;
|
2018-05-10 20:17:35 +00:00
|
|
|
}
|
|
|
|
|
2023-05-25 10:38:50 +00:00
|
|
|
static int mv88e6xxx_mac_prepare(struct dsa_switch *ds, int port,
|
|
|
|
unsigned int mode, phy_interface_t interface)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
/* 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.
|
|
|
|
*/
|
|
|
|
if (mode == MLO_AN_INBAND &&
|
|
|
|
chip->ports[port].interface != interface &&
|
|
|
|
chip->info->ops->port_set_link) {
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
err = chip->info->ops->port_set_link(chip, port,
|
|
|
|
LINK_FORCED_DOWN);
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-05-10 20:17:35 +00: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;
|
2021-12-09 09:26:47 +00:00
|
|
|
int err = 0;
|
2018-05-10 20:17:35 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2020-07-19 11:00:35 +00:00
|
|
|
|
2023-05-29 08:02:41 +00:00
|
|
|
if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(chip, port)) {
|
2021-12-09 09:26:47 +00:00
|
|
|
err = mv88e6xxx_port_config_interface(chip, port,
|
|
|
|
state->interface);
|
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
goto err_unlock;
|
|
|
|
}
|
2020-03-14 10:15:43 +00:00
|
|
|
|
2023-05-25 10:38:50 +00:00
|
|
|
err_unlock:
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
dev_err(ds->dev, "p%d: failed to configure MAC/PCS\n", port);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_mac_finish(struct dsa_switch *ds, int port,
|
|
|
|
unsigned int mode, phy_interface_t interface)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err = 0;
|
|
|
|
|
2020-07-19 11:00:35 +00:00
|
|
|
/* Undo the forced down state above after completing configuration
|
2021-12-09 09:26:47 +00:00
|
|
|
* irrespective of its state on entry, which allows the link to come
|
|
|
|
* up in the in-band case where there is no separate SERDES. Also
|
|
|
|
* ensure that the link can come up if the PPU is in use and we are
|
|
|
|
* in PHY mode (we treat the PPU as an effective in-band mechanism.)
|
2020-07-19 11:00:35 +00:00
|
|
|
*/
|
2023-05-25 10:38:50 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
2021-12-09 09:26:47 +00:00
|
|
|
if (chip->info->ops->port_set_link &&
|
2023-05-25 10:38:50 +00:00
|
|
|
((mode == MLO_AN_INBAND &&
|
|
|
|
chip->ports[port].interface != interface) ||
|
2021-12-09 09:26:47 +00:00
|
|
|
(mode == MLO_AN_PHY && mv88e6xxx_port_ppu_updates(chip, port))))
|
2023-05-25 10:38:50 +00:00
|
|
|
err = chip->info->ops->port_set_link(chip, port, LINK_UNFORCED);
|
2020-07-19 11:00:35 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-05-10 20:17:35 +00:00
|
|
|
|
2023-05-25 10:38:50 +00:00
|
|
|
chip->ports[port].interface = interface;
|
|
|
|
|
|
|
|
return err;
|
2018-05-10 20:17:35 +00: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 20:17:35 +00: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 20:17:35 +00:00
|
|
|
|
2020-02-26 10:23:51 +00:00
|
|
|
ops = chip->info->ops;
|
2018-05-10 20:17:35 +00:00
|
|
|
|
2020-03-14 10:16:03 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's"
This commit fixes a misunderstanding in commit 4a3e0aeddf09 ("net: dsa:
mv88e6xxx: don't use PHY_DETECT on internal PHY's").
For Marvell DSA switches with the PHY_DETECT bit (for non-6250 family
devices), controls whether the PPU polls the PHY to retrieve the link,
speed, duplex and pause status to update the port configuration. This
applies for both internal and external PHYs.
For some switches such as 88E6352 and 88E6390X, PHY_DETECT has an
additional function of enabling auto-media mode between the internal
PHY and SERDES blocks depending on which first gains link.
The original intention of commit 5d5b231da7ac (net: dsa: mv88e6xxx: use
PHY_DETECT in mac_link_up/mac_link_down) was to allow this bit to be
used to detect when this propagation is enabled, and allow software to
update the port configuration. This has found to be necessary for some
switches which do not automatically propagate status from the SERDES to
the port, which includes the 88E6390. However, commit 4a3e0aeddf09
("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's") breaks
this assumption.
Maarten Zanders has confirmed that the issue he was addressing was for
an 88E6250 switch, which does not have a PHY_DETECT bit in bit 12, but
instead a link status bit. Therefore, mv88e6xxx_port_ppu_updates() does
not report correctly.
This patch resolves the above issues by reverting Maarten's change and
instead making mv88e6xxx_port_ppu_updates() indicate whether the port
is internal for the 88E6250 family of switches.
Yes, you're right, I'm targeting the 6250 family. And yes, your
suggestion would solve my case and is a better implementation for
the other devices (as far as I can see).
Fixes: 4a3e0aeddf09 ("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Maarten Zanders <maarten.zanders@mind.be>
Link: https://lore.kernel.org/r/E1muXm7-00EwJB-7n@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-07 10:32:43 +00:00
|
|
|
/* Force the link down if we know the port may not be automatically
|
|
|
|
* updated by the switch or if we are using fixed-link mode.
|
2021-10-11 14:27:20 +00:00
|
|
|
*/
|
net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's"
This commit fixes a misunderstanding in commit 4a3e0aeddf09 ("net: dsa:
mv88e6xxx: don't use PHY_DETECT on internal PHY's").
For Marvell DSA switches with the PHY_DETECT bit (for non-6250 family
devices), controls whether the PPU polls the PHY to retrieve the link,
speed, duplex and pause status to update the port configuration. This
applies for both internal and external PHYs.
For some switches such as 88E6352 and 88E6390X, PHY_DETECT has an
additional function of enabling auto-media mode between the internal
PHY and SERDES blocks depending on which first gains link.
The original intention of commit 5d5b231da7ac (net: dsa: mv88e6xxx: use
PHY_DETECT in mac_link_up/mac_link_down) was to allow this bit to be
used to detect when this propagation is enabled, and allow software to
update the port configuration. This has found to be necessary for some
switches which do not automatically propagate status from the SERDES to
the port, which includes the 88E6390. However, commit 4a3e0aeddf09
("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's") breaks
this assumption.
Maarten Zanders has confirmed that the issue he was addressing was for
an 88E6250 switch, which does not have a PHY_DETECT bit in bit 12, but
instead a link status bit. Therefore, mv88e6xxx_port_ppu_updates() does
not report correctly.
This patch resolves the above issues by reverting Maarten's change and
instead making mv88e6xxx_port_ppu_updates() indicate whether the port
is internal for the 88E6250 family of switches.
Yes, you're right, I'm targeting the 6250 family. And yes, your
suggestion would solve my case and is a better implementation for
the other devices (as far as I can see).
Fixes: 4a3e0aeddf09 ("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Maarten Zanders <maarten.zanders@mind.be>
Link: https://lore.kernel.org/r/E1muXm7-00EwJB-7n@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-07 10:32:43 +00:00
|
|
|
if ((!mv88e6xxx_port_ppu_updates(chip, port) ||
|
2020-11-24 04:34:37 +00:00
|
|
|
mode == MLO_AN_FIXED) && ops->port_sync_link)
|
|
|
|
err = ops->port_sync_link(chip, port, mode, false);
|
2021-12-11 22:51:41 +00:00
|
|
|
|
|
|
|
if (!err && ops->port_set_speed_duplex)
|
|
|
|
err = ops->port_set_speed_duplex(chip, port, SPEED_UNFORCED,
|
|
|
|
DUPLEX_UNFORCED);
|
2020-03-14 10:16:03 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-05-10 20:17:35 +00: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 20:17:35 +00: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 20:17:35 +00: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);
|
net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's"
This commit fixes a misunderstanding in commit 4a3e0aeddf09 ("net: dsa:
mv88e6xxx: don't use PHY_DETECT on internal PHY's").
For Marvell DSA switches with the PHY_DETECT bit (for non-6250 family
devices), controls whether the PPU polls the PHY to retrieve the link,
speed, duplex and pause status to update the port configuration. This
applies for both internal and external PHYs.
For some switches such as 88E6352 and 88E6390X, PHY_DETECT has an
additional function of enabling auto-media mode between the internal
PHY and SERDES blocks depending on which first gains link.
The original intention of commit 5d5b231da7ac (net: dsa: mv88e6xxx: use
PHY_DETECT in mac_link_up/mac_link_down) was to allow this bit to be
used to detect when this propagation is enabled, and allow software to
update the port configuration. This has found to be necessary for some
switches which do not automatically propagate status from the SERDES to
the port, which includes the 88E6390. However, commit 4a3e0aeddf09
("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's") breaks
this assumption.
Maarten Zanders has confirmed that the issue he was addressing was for
an 88E6250 switch, which does not have a PHY_DETECT bit in bit 12, but
instead a link status bit. Therefore, mv88e6xxx_port_ppu_updates() does
not report correctly.
This patch resolves the above issues by reverting Maarten's change and
instead making mv88e6xxx_port_ppu_updates() indicate whether the port
is internal for the 88E6250 family of switches.
Yes, you're right, I'm targeting the 6250 family. And yes, your
suggestion would solve my case and is a better implementation for
the other devices (as far as I can see).
Fixes: 4a3e0aeddf09 ("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Maarten Zanders <maarten.zanders@mind.be>
Link: https://lore.kernel.org/r/E1muXm7-00EwJB-7n@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-07 10:32:43 +00:00
|
|
|
/* Configure and force the link up if we know that the port may not
|
|
|
|
* automatically updated by the switch or if we are using fixed-link
|
|
|
|
* mode.
|
2021-10-11 14:27:20 +00:00
|
|
|
*/
|
net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's"
This commit fixes a misunderstanding in commit 4a3e0aeddf09 ("net: dsa:
mv88e6xxx: don't use PHY_DETECT on internal PHY's").
For Marvell DSA switches with the PHY_DETECT bit (for non-6250 family
devices), controls whether the PPU polls the PHY to retrieve the link,
speed, duplex and pause status to update the port configuration. This
applies for both internal and external PHYs.
For some switches such as 88E6352 and 88E6390X, PHY_DETECT has an
additional function of enabling auto-media mode between the internal
PHY and SERDES blocks depending on which first gains link.
The original intention of commit 5d5b231da7ac (net: dsa: mv88e6xxx: use
PHY_DETECT in mac_link_up/mac_link_down) was to allow this bit to be
used to detect when this propagation is enabled, and allow software to
update the port configuration. This has found to be necessary for some
switches which do not automatically propagate status from the SERDES to
the port, which includes the 88E6390. However, commit 4a3e0aeddf09
("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's") breaks
this assumption.
Maarten Zanders has confirmed that the issue he was addressing was for
an 88E6250 switch, which does not have a PHY_DETECT bit in bit 12, but
instead a link status bit. Therefore, mv88e6xxx_port_ppu_updates() does
not report correctly.
This patch resolves the above issues by reverting Maarten's change and
instead making mv88e6xxx_port_ppu_updates() indicate whether the port
is internal for the 88E6250 family of switches.
Yes, you're right, I'm targeting the 6250 family. And yes, your
suggestion would solve my case and is a better implementation for
the other devices (as far as I can see).
Fixes: 4a3e0aeddf09 ("net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Maarten Zanders <maarten.zanders@mind.be>
Link: https://lore.kernel.org/r/E1muXm7-00EwJB-7n@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-07 10:32:43 +00:00
|
|
|
if (!mv88e6xxx_port_ppu_updates(chip, port) ||
|
2021-10-11 14:27:20 +00:00
|
|
|
mode == MLO_AN_FIXED) {
|
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 04:34:37 +00: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 20:17:35 +00:00
|
|
|
}
|
|
|
|
|
2016-11-21 22:26:58 +00: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
|
|
|
{
|
2023-12-14 13:50:22 +00:00
|
|
|
int err;
|
|
|
|
|
2016-11-21 22:26:58 +00: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
|
|
|
|
2023-12-14 13:50:22 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
err = chip->info->ops->stats_snapshot(chip, port);
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
return err;
|
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
|
|
|
}
|
|
|
|
|
2023-12-14 13:50:25 +00:00
|
|
|
#define MV88E6XXX_HW_STAT_MAPPER(_fn) \
|
|
|
|
_fn(in_good_octets, 8, 0x00, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_bad_octets, 4, 0x02, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_unicast, 4, 0x04, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_broadcasts, 4, 0x06, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_multicasts, 4, 0x07, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_pause, 4, 0x16, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_undersize, 4, 0x18, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_fragments, 4, 0x19, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_oversize, 4, 0x1a, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_jabber, 4, 0x1b, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_rx_error, 4, 0x1c, STATS_TYPE_BANK0), \
|
|
|
|
_fn(in_fcs_error, 4, 0x1d, STATS_TYPE_BANK0), \
|
|
|
|
_fn(out_octets, 8, 0x0e, STATS_TYPE_BANK0), \
|
|
|
|
_fn(out_unicast, 4, 0x10, STATS_TYPE_BANK0), \
|
|
|
|
_fn(out_broadcasts, 4, 0x13, STATS_TYPE_BANK0), \
|
|
|
|
_fn(out_multicasts, 4, 0x12, STATS_TYPE_BANK0), \
|
|
|
|
_fn(out_pause, 4, 0x15, STATS_TYPE_BANK0), \
|
|
|
|
_fn(excessive, 4, 0x11, STATS_TYPE_BANK0), \
|
|
|
|
_fn(collisions, 4, 0x1e, STATS_TYPE_BANK0), \
|
|
|
|
_fn(deferred, 4, 0x05, STATS_TYPE_BANK0), \
|
|
|
|
_fn(single, 4, 0x14, STATS_TYPE_BANK0), \
|
|
|
|
_fn(multiple, 4, 0x17, STATS_TYPE_BANK0), \
|
|
|
|
_fn(out_fcs_error, 4, 0x03, STATS_TYPE_BANK0), \
|
|
|
|
_fn(late, 4, 0x1f, STATS_TYPE_BANK0), \
|
|
|
|
_fn(hist_64bytes, 4, 0x08, STATS_TYPE_BANK0), \
|
|
|
|
_fn(hist_65_127bytes, 4, 0x09, STATS_TYPE_BANK0), \
|
|
|
|
_fn(hist_128_255bytes, 4, 0x0a, STATS_TYPE_BANK0), \
|
|
|
|
_fn(hist_256_511bytes, 4, 0x0b, STATS_TYPE_BANK0), \
|
|
|
|
_fn(hist_512_1023bytes, 4, 0x0c, STATS_TYPE_BANK0), \
|
|
|
|
_fn(hist_1024_max_bytes, 4, 0x0d, STATS_TYPE_BANK0), \
|
|
|
|
_fn(sw_in_discards, 4, 0x10, STATS_TYPE_PORT), \
|
|
|
|
_fn(sw_in_filtered, 2, 0x12, STATS_TYPE_PORT), \
|
|
|
|
_fn(sw_out_filtered, 2, 0x13, STATS_TYPE_PORT), \
|
|
|
|
_fn(in_discards, 4, 0x00, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_filtered, 4, 0x01, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_accepted, 4, 0x02, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_bad_accepted, 4, 0x03, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_good_avb_class_a, 4, 0x04, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_good_avb_class_b, 4, 0x05, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_bad_avb_class_a, 4, 0x06, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_bad_avb_class_b, 4, 0x07, STATS_TYPE_BANK1), \
|
|
|
|
_fn(tcam_counter_0, 4, 0x08, STATS_TYPE_BANK1), \
|
|
|
|
_fn(tcam_counter_1, 4, 0x09, STATS_TYPE_BANK1), \
|
|
|
|
_fn(tcam_counter_2, 4, 0x0a, STATS_TYPE_BANK1), \
|
|
|
|
_fn(tcam_counter_3, 4, 0x0b, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_da_unknown, 4, 0x0e, STATS_TYPE_BANK1), \
|
|
|
|
_fn(in_management, 4, 0x0f, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_queue_0, 4, 0x10, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_queue_1, 4, 0x11, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_queue_2, 4, 0x12, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_queue_3, 4, 0x13, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_queue_4, 4, 0x14, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_queue_5, 4, 0x15, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_queue_6, 4, 0x16, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_queue_7, 4, 0x17, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_cut_through, 4, 0x18, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_octets_a, 4, 0x1a, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_octets_b, 4, 0x1b, STATS_TYPE_BANK1), \
|
|
|
|
_fn(out_management, 4, 0x1f, STATS_TYPE_BANK1), \
|
|
|
|
/* */
|
|
|
|
|
|
|
|
#define MV88E6XXX_HW_STAT_ENTRY(_string, _size, _reg, _type) \
|
|
|
|
{ #_string, _size, _reg, _type }
|
|
|
|
static const struct mv88e6xxx_hw_stat mv88e6xxx_hw_stats[] = {
|
|
|
|
MV88E6XXX_HW_STAT_MAPPER(MV88E6XXX_HW_STAT_ENTRY)
|
|
|
|
};
|
|
|
|
|
|
|
|
#define MV88E6XXX_HW_STAT_ENUM(_string, _size, _reg, _type) \
|
|
|
|
MV88E6XXX_HW_STAT_ID_ ## _string
|
|
|
|
enum mv88e6xxx_hw_stat_id {
|
|
|
|
MV88E6XXX_HW_STAT_MAPPER(MV88E6XXX_HW_STAT_ENUM)
|
2015-04-02 02:06:38 +00:00
|
|
|
};
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
static uint64_t _mv88e6xxx_get_ethtool_stat(struct mv88e6xxx_chip *chip,
|
2023-12-14 13:50:23 +00:00
|
|
|
const struct mv88e6xxx_hw_stat *s,
|
2016-11-21 22:27:04 +00:00
|
|
|
int port, u16 bank1_select,
|
|
|
|
u16 histogram)
|
2015-06-20 16:42:30 +00:00
|
|
|
{
|
|
|
|
u32 low;
|
|
|
|
u32 high = 0;
|
2016-11-21 22:27:02 +00:00
|
|
|
u16 reg = 0;
|
2016-09-20 23:40:31 +00:00
|
|
|
int err;
|
2015-06-20 16:42:30 +00:00
|
|
|
u64 value;
|
|
|
|
|
2015-12-23 12:23:17 +00:00
|
|
|
switch (s->type) {
|
2016-11-21 22:27:02 +00:00
|
|
|
case STATS_TYPE_PORT:
|
2016-09-20 23:40:31 +00:00
|
|
|
err = mv88e6xxx_port_read(chip, port, s->reg, ®);
|
|
|
|
if (err)
|
2018-04-27 08:18:58 +00:00
|
|
|
return U64_MAX;
|
2015-06-20 16:42:30 +00:00
|
|
|
|
2016-09-20 23:40:31 +00:00
|
|
|
low = reg;
|
2018-03-01 01:02:31 +00:00
|
|
|
if (s->size == 4) {
|
2016-09-20 23:40:31 +00:00
|
|
|
err = mv88e6xxx_port_read(chip, port, s->reg + 1, ®);
|
|
|
|
if (err)
|
2018-04-27 08:18:58 +00:00
|
|
|
return U64_MAX;
|
2019-05-29 07:02:11 +00:00
|
|
|
low |= ((u32)reg) << 16;
|
2015-06-20 16:42:30 +00:00
|
|
|
}
|
2015-12-23 12:23:17 +00:00
|
|
|
break;
|
2016-11-21 22:27:02 +00:00
|
|
|
case STATS_TYPE_BANK1:
|
2016-11-21 22:27:04 +00:00
|
|
|
reg = bank1_select;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2016-11-21 22:27:02 +00:00
|
|
|
case STATS_TYPE_BANK0:
|
2016-11-21 22:27:04 +00:00
|
|
|
reg |= s->reg | histogram;
|
2016-11-21 22:27:05 +00:00
|
|
|
mv88e6xxx_g1_stats_read(chip, reg, &low);
|
2018-03-01 01:02:31 +00:00
|
|
|
if (s->size == 8)
|
2016-11-21 22:27:05 +00:00
|
|
|
mv88e6xxx_g1_stats_read(chip, reg + 1, &high);
|
2017-05-12 03:11:29 +00:00
|
|
|
break;
|
|
|
|
default:
|
2018-04-27 08:18:58 +00:00
|
|
|
return U64_MAX;
|
2015-06-20 16:42:30 +00:00
|
|
|
}
|
2019-02-28 17:14:03 +00:00
|
|
|
value = (((u64)high) << 32) | low;
|
2015-06-20 16:42:30 +00:00
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
2018-03-01 01:02:29 +00: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
|
|
|
{
|
2023-12-14 13:50:25 +00:00
|
|
|
const struct mv88e6xxx_hw_stat *stat;
|
2015-12-23 12:23:17 +00:00
|
|
|
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 12:23:17 +00:00
|
|
|
for (i = 0, j = 0; i < ARRAY_SIZE(mv88e6xxx_hw_stats); i++) {
|
|
|
|
stat = &mv88e6xxx_hw_stats[i];
|
2016-11-21 22:27:02 +00:00
|
|
|
if (stat->type & types) {
|
2015-12-23 12:23:17 +00: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 01:02:29 +00:00
|
|
|
|
|
|
|
return j;
|
2015-04-02 02:06:38 +00:00
|
|
|
}
|
|
|
|
|
2018-03-01 01:02:29 +00:00
|
|
|
static int mv88e6095_stats_get_strings(struct mv88e6xxx_chip *chip,
|
|
|
|
uint8_t *data)
|
2016-11-21 22:27:02 +00:00
|
|
|
{
|
2018-03-01 01:02:29 +00:00
|
|
|
return mv88e6xxx_stats_get_strings(chip, data,
|
|
|
|
STATS_TYPE_BANK0 | STATS_TYPE_PORT);
|
2016-11-21 22:27:02 +00: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 01:02:29 +00:00
|
|
|
static int mv88e6320_stats_get_strings(struct mv88e6xxx_chip *chip,
|
|
|
|
uint8_t *data)
|
2016-11-21 22:27:02 +00:00
|
|
|
{
|
2018-03-01 01:02:29 +00:00
|
|
|
return mv88e6xxx_stats_get_strings(chip, data,
|
|
|
|
STATS_TYPE_BANK0 | STATS_TYPE_BANK1);
|
2016-11-21 22:27:02 +00:00
|
|
|
}
|
|
|
|
|
2018-03-28 21:50:28 +00: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++)
|
2022-08-30 20:14:52 +00:00
|
|
|
strscpy(data + i * ETH_GSTRING_LEN,
|
2018-03-28 21:50:28 +00:00
|
|
|
mv88e6xxx_atu_vtu_stats_strings[i],
|
|
|
|
ETH_GSTRING_LEN);
|
|
|
|
}
|
|
|
|
|
2016-11-21 22:27:02 +00:00
|
|
|
static void mv88e6xxx_get_strings(struct dsa_switch *ds, int port,
|
2018-04-25 19:12:50 +00:00
|
|
|
u32 stringset, uint8_t *data)
|
2015-04-02 02:06:38 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2018-03-01 01:02:29 +00:00
|
|
|
int count = 0;
|
2016-11-21 22:27:02 +00:00
|
|
|
|
2018-04-25 19:12:50 +00:00
|
|
|
if (stringset != ETH_SS_STATS)
|
|
|
|
return;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-03-01 01:02:28 +00:00
|
|
|
|
2016-11-21 22:27:02 +00:00
|
|
|
if (chip->info->ops->stats_get_strings)
|
2018-03-01 01:02:29 +00: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 21:50:28 +00:00
|
|
|
count = chip->info->ops->serdes_get_strings(chip, port, data);
|
2018-03-01 01:02:29 +00:00
|
|
|
}
|
2018-03-01 01:02:28 +00:00
|
|
|
|
2018-03-28 21:50:28 +00: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 22:27:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_stats_get_sset_count(struct mv88e6xxx_chip *chip,
|
|
|
|
int types)
|
|
|
|
{
|
2023-12-14 13:50:25 +00:00
|
|
|
const struct mv88e6xxx_hw_stat *stat;
|
2015-12-23 12:23:17 +00:00
|
|
|
int i, j;
|
|
|
|
|
|
|
|
for (i = 0, j = 0; i < ARRAY_SIZE(mv88e6xxx_hw_stats); i++) {
|
|
|
|
stat = &mv88e6xxx_hw_stats[i];
|
2016-11-21 22:27:02 +00:00
|
|
|
if (stat->type & types)
|
2015-12-23 12:23:17 +00:00
|
|
|
j++;
|
|
|
|
}
|
|
|
|
return j;
|
2015-04-02 02:06:38 +00:00
|
|
|
}
|
|
|
|
|
2016-11-21 22:27:02 +00: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 22:27:02 +00: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 19:12:50 +00:00
|
|
|
static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port, int sset)
|
2016-11-21 22:27:02 +00:00
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2018-03-01 01:02:29 +00:00
|
|
|
int serdes_count = 0;
|
|
|
|
int count = 0;
|
2016-11-21 22:27:02 +00:00
|
|
|
|
2018-04-25 19:12:50 +00:00
|
|
|
if (sset != ETH_SS_STATS)
|
|
|
|
return 0;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-11-21 22:27:02 +00:00
|
|
|
if (chip->info->ops->stats_get_sset_count)
|
2018-03-01 01:02:29 +00: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 21:50:28 +00:00
|
|
|
if (serdes_count < 0) {
|
2018-03-01 01:02:29 +00:00
|
|
|
count = serdes_count;
|
2018-03-28 21:50:28 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
count += serdes_count;
|
|
|
|
count += ARRAY_SIZE(mv88e6xxx_atu_vtu_stats_strings);
|
|
|
|
|
2018-03-01 01:02:29 +00:00
|
|
|
out:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-11-21 22:27:02 +00:00
|
|
|
|
2018-03-01 01:02:29 +00:00
|
|
|
return count;
|
2016-11-21 22:27:02 +00:00
|
|
|
}
|
|
|
|
|
2023-12-14 13:50:23 +00:00
|
|
|
static size_t mv88e6095_stats_get_stat(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
const struct mv88e6xxx_hw_stat *stat,
|
|
|
|
uint64_t *data)
|
2016-11-21 22:27:03 +00:00
|
|
|
{
|
2023-12-14 13:50:23 +00:00
|
|
|
if (!(stat->type & (STATS_TYPE_BANK0 | STATS_TYPE_PORT)))
|
|
|
|
return 0;
|
2016-11-21 22:27:03 +00:00
|
|
|
|
2023-12-14 13:50:23 +00:00
|
|
|
*data = _mv88e6xxx_get_ethtool_stat(chip, stat, port, 0,
|
2023-12-14 13:50:27 +00:00
|
|
|
MV88E6XXX_G1_STATS_OP_HIST_RX);
|
2023-12-14 13:50:23 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2018-02-15 13:38:34 +00:00
|
|
|
|
2023-12-14 13:50:23 +00:00
|
|
|
static size_t mv88e6250_stats_get_stat(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
const struct mv88e6xxx_hw_stat *stat,
|
|
|
|
uint64_t *data)
|
|
|
|
{
|
|
|
|
if (!(stat->type & STATS_TYPE_BANK0))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
*data = _mv88e6xxx_get_ethtool_stat(chip, stat, port, 0,
|
2023-12-14 13:50:27 +00:00
|
|
|
MV88E6XXX_G1_STATS_OP_HIST_RX);
|
2023-12-14 13:50:23 +00:00
|
|
|
return 1;
|
2016-11-21 22:27:03 +00:00
|
|
|
}
|
|
|
|
|
2023-12-14 13:50:23 +00:00
|
|
|
static size_t mv88e6320_stats_get_stat(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
const struct mv88e6xxx_hw_stat *stat,
|
|
|
|
uint64_t *data)
|
2016-11-21 22:27:03 +00:00
|
|
|
{
|
2023-12-14 13:50:23 +00:00
|
|
|
if (!(stat->type & (STATS_TYPE_BANK0 | STATS_TYPE_BANK1)))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
*data = _mv88e6xxx_get_ethtool_stat(chip, stat, port,
|
|
|
|
MV88E6XXX_G1_STATS_OP_BANK_1_BIT_9,
|
2023-12-14 13:50:27 +00:00
|
|
|
MV88E6XXX_G1_STATS_OP_HIST_RX);
|
2023-12-14 13:50:23 +00:00
|
|
|
return 1;
|
2016-11-21 22:27:03 +00:00
|
|
|
}
|
|
|
|
|
2023-12-14 13:50:23 +00:00
|
|
|
static size_t mv88e6390_stats_get_stat(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
const struct mv88e6xxx_hw_stat *stat,
|
|
|
|
uint64_t *data)
|
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
|
|
|
{
|
2023-12-14 13:50:23 +00:00
|
|
|
if (!(stat->type & (STATS_TYPE_BANK0 | STATS_TYPE_BANK1)))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
*data = _mv88e6xxx_get_ethtool_stat(chip, stat, port,
|
|
|
|
MV88E6XXX_G1_STATS_OP_BANK_1_BIT_10,
|
|
|
|
0);
|
|
|
|
return 1;
|
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
|
|
|
}
|
|
|
|
|
2023-12-14 13:50:23 +00:00
|
|
|
static size_t mv88e6xxx_stats_get_stat(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
const struct mv88e6xxx_hw_stat *stat,
|
|
|
|
uint64_t *data)
|
2016-11-21 22:27:03 +00:00
|
|
|
{
|
2023-12-14 13:50:23 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (chip->info->ops->stats_get_stat) {
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
ret = chip->info->ops->stats_get_stat(chip, port, stat, data);
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
2016-11-21 22:27:04 +00:00
|
|
|
}
|
|
|
|
|
2023-12-14 13:50:23 +00:00
|
|
|
static size_t mv88e6xxx_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
uint64_t *data)
|
2016-11-21 22:27:04 +00:00
|
|
|
{
|
2023-12-14 13:50:25 +00:00
|
|
|
const struct mv88e6xxx_hw_stat *stat;
|
2023-12-14 13:50:23 +00:00
|
|
|
size_t i, j;
|
|
|
|
|
|
|
|
for (i = 0, j = 0; i < ARRAY_SIZE(mv88e6xxx_hw_stats); i++) {
|
|
|
|
stat = &mv88e6xxx_hw_stats[i];
|
|
|
|
j += mv88e6xxx_stats_get_stat(chip, port, stat, &data[j]);
|
|
|
|
}
|
|
|
|
return j;
|
2016-11-21 22:27:03 +00:00
|
|
|
}
|
|
|
|
|
2018-03-28 21:50:28 +00: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 22:27:03 +00:00
|
|
|
static void mv88e6xxx_get_stats(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
uint64_t *data)
|
|
|
|
{
|
2023-12-14 13:50:23 +00:00
|
|
|
size_t count;
|
2018-03-01 01:02:29 +00:00
|
|
|
|
2023-12-14 13:50:23 +00:00
|
|
|
count = mv88e6xxx_stats_get_stats(chip, port, data);
|
2018-03-01 01:02:29 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-03-01 01:02:29 +00:00
|
|
|
if (chip->info->ops->serdes_get_stats) {
|
|
|
|
data += count;
|
2018-03-28 21:50:28 +00:00
|
|
|
count = chip->info->ops->serdes_get_stats(chip, port, data);
|
2018-03-01 01:02:29 +00:00
|
|
|
}
|
2018-03-28 21:50:28 +00: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 22:27:03 +00:00
|
|
|
}
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
static void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds, int port,
|
|
|
|
uint64_t *data)
|
2015-04-02 02:06:38 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2015-12-23 12:23:17 +00:00
|
|
|
int ret;
|
|
|
|
|
2016-11-21 22:26:58 +00:00
|
|
|
ret = mv88e6xxx_stats_snapshot(chip, port);
|
2018-02-15 13:38:34 +00:00
|
|
|
if (ret < 0)
|
2015-12-23 12:23:17 +00:00
|
|
|
return;
|
2016-11-21 22:27:03 +00:00
|
|
|
|
|
|
|
mv88e6xxx_get_stats(chip, port, data);
|
2015-04-02 02:06:38 +00:00
|
|
|
}
|
|
|
|
|
2023-12-14 13:50:26 +00:00
|
|
|
static void mv88e6xxx_get_eth_mac_stats(struct dsa_switch *ds, int port,
|
|
|
|
struct ethtool_eth_mac_stats *mac_stats)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = mv88e6xxx_stats_snapshot(chip, port);
|
|
|
|
if (ret < 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
#define MV88E6XXX_ETH_MAC_STAT_MAP(_id, _member) \
|
|
|
|
mv88e6xxx_stats_get_stat(chip, port, \
|
|
|
|
&mv88e6xxx_hw_stats[MV88E6XXX_HW_STAT_ID_ ## _id], \
|
|
|
|
&mac_stats->stats._member)
|
|
|
|
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(out_unicast, FramesTransmittedOK);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(single, SingleCollisionFrames);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(multiple, MultipleCollisionFrames);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(in_unicast, FramesReceivedOK);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(in_fcs_error, FrameCheckSequenceErrors);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(out_octets, OctetsTransmittedOK);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(deferred, FramesWithDeferredXmissions);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(late, LateCollisions);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(in_good_octets, OctetsReceivedOK);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(out_multicasts, MulticastFramesXmittedOK);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(out_broadcasts, BroadcastFramesXmittedOK);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(excessive, FramesWithExcessiveDeferral);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(in_multicasts, MulticastFramesReceivedOK);
|
|
|
|
MV88E6XXX_ETH_MAC_STAT_MAP(in_broadcasts, BroadcastFramesReceivedOK);
|
|
|
|
|
|
|
|
#undef MV88E6XXX_ETH_MAC_STAT_MAP
|
|
|
|
|
|
|
|
mac_stats->stats.FramesTransmittedOK += mac_stats->stats.MulticastFramesXmittedOK;
|
|
|
|
mac_stats->stats.FramesTransmittedOK += mac_stats->stats.BroadcastFramesXmittedOK;
|
|
|
|
mac_stats->stats.FramesReceivedOK += mac_stats->stats.MulticastFramesReceivedOK;
|
|
|
|
mac_stats->stats.FramesReceivedOK += mac_stats->stats.BroadcastFramesReceivedOK;
|
|
|
|
}
|
|
|
|
|
2023-12-14 13:50:28 +00:00
|
|
|
static void mv88e6xxx_get_rmon_stats(struct dsa_switch *ds, int port,
|
|
|
|
struct ethtool_rmon_stats *rmon_stats,
|
|
|
|
const struct ethtool_rmon_hist_range **ranges)
|
|
|
|
{
|
|
|
|
static const struct ethtool_rmon_hist_range rmon_ranges[] = {
|
|
|
|
{ 64, 64 },
|
|
|
|
{ 65, 127 },
|
|
|
|
{ 128, 255 },
|
|
|
|
{ 256, 511 },
|
|
|
|
{ 512, 1023 },
|
|
|
|
{ 1024, 65535 },
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = mv88e6xxx_stats_snapshot(chip, port);
|
|
|
|
if (ret < 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
#define MV88E6XXX_RMON_STAT_MAP(_id, _member) \
|
|
|
|
mv88e6xxx_stats_get_stat(chip, port, \
|
|
|
|
&mv88e6xxx_hw_stats[MV88E6XXX_HW_STAT_ID_ ## _id], \
|
|
|
|
&rmon_stats->stats._member)
|
|
|
|
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(in_undersize, undersize_pkts);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(in_oversize, oversize_pkts);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(in_fragments, fragments);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(in_jabber, jabbers);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(hist_64bytes, hist[0]);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(hist_65_127bytes, hist[1]);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(hist_128_255bytes, hist[2]);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(hist_256_511bytes, hist[3]);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(hist_512_1023bytes, hist[4]);
|
|
|
|
MV88E6XXX_RMON_STAT_MAP(hist_1024_max_bytes, hist[5]);
|
|
|
|
|
|
|
|
#undef MV88E6XXX_RMON_STAT_MAP
|
|
|
|
|
|
|
|
*ranges = rmon_ranges;
|
|
|
|
}
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
static int mv88e6xxx_get_regs_len(struct dsa_switch *ds, int port)
|
2014-10-29 17:45:05 +00:00
|
|
|
{
|
2020-02-16 17:54:13 +00: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 17:45:05 +00:00
|
|
|
}
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
static void mv88e6xxx_get_regs(struct dsa_switch *ds, int port,
|
|
|
|
struct ethtool_regs *regs, void *_p)
|
2014-10-29 17:45:05 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-09-20 23:40:31 +00:00
|
|
|
int err;
|
|
|
|
u16 reg;
|
2014-10-29 17:45:05 +00:00
|
|
|
u16 *p = _p;
|
|
|
|
int i;
|
|
|
|
|
2018-12-17 21:05:21 +00:00
|
|
|
regs->version = chip->info->prod_num;
|
2014-10-29 17:45:05 +00:00
|
|
|
|
|
|
|
memset(p, 0xff, 32 * sizeof(u16));
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-05-09 17:22:45 +00:00
|
|
|
|
2014-10-29 17:45:05 +00:00
|
|
|
for (i = 0; i < 32; i++) {
|
|
|
|
|
2016-09-20 23:40:31 +00:00
|
|
|
err = mv88e6xxx_port_read(chip, port, i, ®);
|
|
|
|
if (!err)
|
|
|
|
p[i] = reg;
|
2014-10-29 17:45:05 +00:00
|
|
|
}
|
2016-05-09 17:22:45 +00:00
|
|
|
|
2020-02-16 17:54:13 +00: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 17:45:05 +00:00
|
|
|
}
|
|
|
|
|
2017-08-01 20:32:41 +00:00
|
|
|
static int mv88e6xxx_get_mac_eee(struct dsa_switch *ds, int port,
|
2024-01-27 13:25:09 +00:00
|
|
|
struct ethtool_keee *e)
|
2017-07-17 17:03:45 +00:00
|
|
|
{
|
2017-08-01 20:32:40 +00:00
|
|
|
/* Nothing to do on the port's MAC */
|
|
|
|
return 0;
|
2015-03-07 06:23:51 +00:00
|
|
|
}
|
|
|
|
|
2017-08-01 20:32:41 +00:00
|
|
|
static int mv88e6xxx_set_mac_eee(struct dsa_switch *ds, int port,
|
2024-01-27 13:25:09 +00:00
|
|
|
struct ethtool_keee *e)
|
2015-03-07 06:23:51 +00:00
|
|
|
{
|
2017-08-01 20:32:40 +00:00
|
|
|
/* Nothing to do on the port's MAC */
|
|
|
|
return 0;
|
2015-03-07 06:23:51 +00:00
|
|
|
}
|
|
|
|
|
2019-10-21 20:51:26 +00:00
|
|
|
/* Mask of the local ports allowed to receive frames from a given fabric port */
|
2017-03-30 21:37:11 +00:00
|
|
|
static u16 mv88e6xxx_port_vlan(struct mv88e6xxx_chip *chip, int dev, int port)
|
2015-03-27 01:36:35 +00:00
|
|
|
{
|
2019-10-21 20:51:26 +00:00
|
|
|
struct dsa_switch *ds = chip->ds;
|
|
|
|
struct dsa_switch_tree *dst = ds->dst;
|
2021-12-06 16:57:51 +00:00
|
|
|
struct dsa_port *dp, *other_dp;
|
2019-10-21 20:51:26 +00:00
|
|
|
bool found = false;
|
2017-03-30 21:37:11 +00:00
|
|
|
u16 pvlan;
|
2016-02-26 18:16:06 +00:00
|
|
|
|
2021-07-22 15:55:41 +00:00
|
|
|
/* dev is a physical switch */
|
|
|
|
if (dev <= dst->last_switch) {
|
|
|
|
list_for_each_entry(dp, &dst->ports, list) {
|
|
|
|
if (dp->ds->index == dev && dp->index == port) {
|
|
|
|
/* dp might be a DSA link or a user port, so it
|
2021-12-06 16:57:51 +00:00
|
|
|
* might or might not have a bridge.
|
|
|
|
* Use the "found" variable for both cases.
|
2021-07-22 15:55:41 +00:00
|
|
|
*/
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* dev is a virtual bridge */
|
|
|
|
} else {
|
|
|
|
list_for_each_entry(dp, &dst->ports, list) {
|
2021-12-06 16:57:53 +00:00
|
|
|
unsigned int bridge_num = dsa_port_bridge_num_get(dp);
|
|
|
|
|
|
|
|
if (!bridge_num)
|
2021-07-22 15:55:41 +00:00
|
|
|
continue;
|
|
|
|
|
2021-12-06 16:57:53 +00:00
|
|
|
if (bridge_num + dst->last_switch != dev)
|
2021-07-22 15:55:41 +00:00
|
|
|
continue;
|
|
|
|
|
2019-10-21 20:51:26 +00:00
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2017-03-30 21:37:11 +00:00
|
|
|
|
2021-07-22 15:55:41 +00:00
|
|
|
/* Prevent frames from unknown switch or virtual bridge */
|
2019-10-21 20:51:26 +00:00
|
|
|
if (!found)
|
2017-03-30 21:37:11 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Frames from DSA links and CPU ports can egress any local port */
|
2019-10-21 20:51:26 +00:00
|
|
|
if (dp->type == DSA_PORT_TYPE_CPU || dp->type == DSA_PORT_TYPE_DSA)
|
2017-03-30 21:37:11 +00:00
|
|
|
return mv88e6xxx_port_mask(chip);
|
|
|
|
|
|
|
|
pvlan = 0;
|
|
|
|
|
2022-02-03 10:16:53 +00:00
|
|
|
/* Frames from standalone user ports can only egress on the
|
|
|
|
* upstream port.
|
|
|
|
*/
|
|
|
|
if (!dsa_port_bridge_dev_get(dp))
|
|
|
|
return BIT(dsa_switch_upstream_port(ds));
|
|
|
|
|
|
|
|
/* Frames from bridged user ports can egress any local DSA
|
|
|
|
* links and CPU ports, as well as any local member of their
|
|
|
|
* bridge group.
|
2017-03-30 21:37:11 +00:00
|
|
|
*/
|
2021-12-06 16:57:51 +00:00
|
|
|
dsa_switch_for_each_port(other_dp, ds)
|
|
|
|
if (other_dp->type == DSA_PORT_TYPE_CPU ||
|
|
|
|
other_dp->type == DSA_PORT_TYPE_DSA ||
|
2021-12-06 16:57:53 +00:00
|
|
|
dsa_port_bridge_same(dp, other_dp))
|
2021-12-06 16:57:51 +00:00
|
|
|
pvlan |= BIT(other_dp->index);
|
2017-03-30 21:37:11 +00:00
|
|
|
|
|
|
|
return pvlan;
|
|
|
|
}
|
|
|
|
|
2017-03-30 21:37:12 +00:00
|
|
|
static int mv88e6xxx_port_vlan_map(struct mv88e6xxx_chip *chip, int port)
|
2017-03-30 21:37:11 +00:00
|
|
|
{
|
|
|
|
u16 output_ports = mv88e6xxx_port_vlan(chip, chip->ds->index, port);
|
2016-02-26 18:16:06 +00:00
|
|
|
|
|
|
|
/* prevent frames from going back out of the port they came in on */
|
|
|
|
output_ports &= ~BIT(port);
|
2015-03-27 01:36:35 +00:00
|
|
|
|
2016-11-04 02:23:28 +00:00
|
|
|
return mv88e6xxx_port_set_vlan_map(chip, port, output_ports);
|
2015-03-27 01:36:35 +00:00
|
|
|
}
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
static void mv88e6xxx_port_stp_state_set(struct dsa_switch *ds, int port,
|
|
|
|
u8 state)
|
2015-03-27 01:36:35 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-05-14 00:38:23 +00:00
|
|
|
int err;
|
2015-03-27 01:36:35 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-06-08 22:34:10 +00:00
|
|
|
err = mv88e6xxx_port_set_state(chip, port, state);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-05-14 00:38:23 +00:00
|
|
|
|
|
|
|
if (err)
|
2017-06-08 22:34:08 +00:00
|
|
|
dev_err(ds->dev, "p%d: failed to update state\n", port);
|
2015-03-27 01:36:35 +00:00
|
|
|
}
|
|
|
|
|
2018-05-11 21:16:35 +00: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-27 01:56:45 +00:00
|
|
|
static int mv88e6xxx_devmap_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
{
|
2019-10-31 02:09:13 +00:00
|
|
|
struct dsa_switch *ds = chip->ds;
|
2018-04-27 01:56:45 +00: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-31 02:09:13 +00:00
|
|
|
port = dsa_routing_port(ds, target);
|
|
|
|
if (port == ds->num_ports)
|
|
|
|
port = 0x1f;
|
2018-04-27 01:56:45 +00:00
|
|
|
|
|
|
|
err = mv88e6xxx_g2_device_mapping_write(chip, target, port);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-05-09 15:38:49 +00: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 15:38:50 +00:00
|
|
|
err = mv88e6xxx_g1_set_device_number(chip, chip->ds->index);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2018-04-27 01:56:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-04-27 01:56:44 +00: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 15:38:51 +00: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 17:03:43 +00: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 17:03:41 +00: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 21:12:49 +00:00
|
|
|
static int mv88e6xxx_atu_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
{
|
2017-03-11 21:12:51 +00:00
|
|
|
int err;
|
|
|
|
|
2017-03-11 21:12:54 +00:00
|
|
|
err = mv88e6xxx_g1_atu_flush(chip, 0, true);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2020-12-10 11:06:44 +00: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 21:12:51 +00:00
|
|
|
|
2017-03-11 21:12:49 +00:00
|
|
|
return mv88e6xxx_g1_atu_set_age_time(chip, 300000);
|
|
|
|
}
|
|
|
|
|
2017-06-19 14:55:36 +00: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 18:18:05 +00: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 21:37:09 +00:00
|
|
|
static int mv88e6xxx_pvt_map(struct mv88e6xxx_chip *chip, int dev, int port)
|
|
|
|
{
|
2021-01-13 08:42:54 +00:00
|
|
|
struct dsa_switch_tree *dst = chip->ds->dst;
|
|
|
|
struct dsa_switch *ds;
|
|
|
|
struct dsa_port *dp;
|
2017-03-30 21:37:09 +00:00
|
|
|
u16 pvlan = 0;
|
|
|
|
|
|
|
|
if (!mv88e6xxx_has_pvt(chip))
|
2019-10-21 20:51:25 +00:00
|
|
|
return 0;
|
2017-03-30 21:37:09 +00:00
|
|
|
|
|
|
|
/* Skip the local source device, which uses in-chip port VLAN */
|
2021-01-13 08:42:54 +00:00
|
|
|
if (dev != chip->ds->index) {
|
2017-03-30 21:37:15 +00:00
|
|
|
pvlan = mv88e6xxx_port_vlan(chip, dev, port);
|
2017-03-30 21:37:09 +00:00
|
|
|
|
2021-01-13 08:42:54 +00:00
|
|
|
ds = dsa_switch_find(dst->index, dev);
|
|
|
|
dp = ds ? dsa_to_port(ds, port) : NULL;
|
2022-02-23 14:00:49 +00:00
|
|
|
if (dp && dp->lag) {
|
2021-01-13 08:42:54 +00:00
|
|
|
/* 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
|
2022-02-23 14:00:47 +00:00
|
|
|
* the LAG ID (one-based) as the port number
|
|
|
|
* (zero-based).
|
2021-01-13 08:42:54 +00:00
|
|
|
*/
|
2021-04-21 12:04:52 +00:00
|
|
|
dev = MV88E6XXX_G2_PVT_ADDR_DEV_TRUNK;
|
2022-02-23 14:00:49 +00:00
|
|
|
port = dsa_port_lag_id_get(dp) - 1;
|
2021-01-13 08:42:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-03-30 21:37:09 +00:00
|
|
|
return mv88e6xxx_g2_pvt_write(chip, dev, port, pvlan);
|
|
|
|
}
|
|
|
|
|
2017-03-30 21:37:08 +00:00
|
|
|
static int mv88e6xxx_pvt_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
{
|
2017-03-30 21:37:09 +00:00
|
|
|
int dev, port;
|
|
|
|
int err;
|
|
|
|
|
2017-03-30 21:37:08 +00: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 21:37:09 +00: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 21:37:08 +00:00
|
|
|
}
|
|
|
|
|
2022-03-16 15:08:57 +00:00
|
|
|
static int mv88e6xxx_port_fast_age_fid(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
u16 fid)
|
2016-09-22 20:49:24 +00:00
|
|
|
{
|
2022-03-16 15:08:57 +00:00
|
|
|
if (dsa_to_port(chip->ds, port)->lag)
|
2021-03-18 19:25:34 +00:00
|
|
|
/* 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.
|
|
|
|
*/
|
2022-03-16 15:08:57 +00:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
return mv88e6xxx_g1_atu_remove(chip, fid, port, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6xxx_port_fast_age(struct dsa_switch *ds, int port)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err;
|
2021-03-18 19:25:34 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2022-03-16 15:08:57 +00:00
|
|
|
err = mv88e6xxx_port_fast_age_fid(chip, port, 0);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-09-22 20:49:24 +00:00
|
|
|
|
|
|
|
if (err)
|
2022-03-16 15:08:57 +00:00
|
|
|
dev_err(chip->ds->dev, "p%d: failed to flush ATU: %d\n",
|
|
|
|
port, err);
|
2016-09-22 20:49:24 +00:00
|
|
|
}
|
|
|
|
|
2017-05-01 18:05:13 +00:00
|
|
|
static int mv88e6xxx_vtu_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
{
|
2020-11-10 18:57:20 +00:00
|
|
|
if (!mv88e6xxx_max_vid(chip))
|
2017-05-01 18:05:13 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return mv88e6xxx_g1_vtu_flush(chip);
|
|
|
|
}
|
|
|
|
|
2021-03-18 19:25:36 +00:00
|
|
|
static int mv88e6xxx_vtu_get(struct mv88e6xxx_chip *chip, u16 vid,
|
|
|
|
struct mv88e6xxx_vtu_entry *entry)
|
2017-05-01 18:05:22 +00:00
|
|
|
{
|
2021-03-18 19:25:36 +00:00
|
|
|
int err;
|
|
|
|
|
2017-05-01 18:05:22 +00:00
|
|
|
if (!chip->info->ops->vtu_getnext)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2021-03-18 19:25:36 +00: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 18:05:22 +00:00
|
|
|
}
|
|
|
|
|
2023-01-08 09:48:49 +00:00
|
|
|
int mv88e6xxx_vtu_walk(struct mv88e6xxx_chip *chip,
|
|
|
|
int (*cb)(struct mv88e6xxx_chip *chip,
|
|
|
|
const struct mv88e6xxx_vtu_entry *entry,
|
|
|
|
void *priv),
|
|
|
|
void *priv)
|
2021-03-18 19:25:35 +00:00
|
|
|
{
|
|
|
|
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 18:05:23 +00: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 19:25:35 +00: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 19:11:06 +00:00
|
|
|
int mv88e6xxx_fid_map(struct mv88e6xxx_chip *chip, unsigned long *fid_bitmap)
|
2016-02-26 18:16:03 +00:00
|
|
|
{
|
|
|
|
bitmap_zero(fid_bitmap, MV88E6XXX_N_FID);
|
|
|
|
|
2022-02-03 10:16:56 +00:00
|
|
|
/* Every FID has an associated VID, so walking the VTU
|
|
|
|
* will discover the full set of FIDs in use.
|
|
|
|
*/
|
2021-03-18 19:25:35 +00:00
|
|
|
return mv88e6xxx_vtu_walk(chip, mv88e6xxx_fid_map_vlan, fid_bitmap);
|
2020-09-18 19:11:06 +00: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;
|
|
|
|
|
2022-02-03 10:16:56 +00:00
|
|
|
*fid = find_first_zero_bit(fid_bitmap, MV88E6XXX_N_FID);
|
2016-06-21 16:28:20 +00:00
|
|
|
if (unlikely(*fid >= mv88e6xxx_num_databases(chip)))
|
2016-02-26 18:16:03 +00:00
|
|
|
return -ENOSPC;
|
|
|
|
|
|
|
|
/* Clear the database */
|
2017-03-11 21:12:54 +00:00
|
|
|
return mv88e6xxx_g1_atu_flush(chip, *fid, true);
|
2016-02-26 18:16:03 +00:00
|
|
|
}
|
|
|
|
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
static int mv88e6xxx_stu_loadpurge(struct mv88e6xxx_chip *chip,
|
|
|
|
struct mv88e6xxx_stu_entry *entry)
|
|
|
|
{
|
|
|
|
if (!chip->info->ops->stu_loadpurge)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
return chip->info->ops->stu_loadpurge(chip, entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_stu_setup(struct mv88e6xxx_chip *chip)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_stu_entry stu = {
|
|
|
|
.valid = true,
|
|
|
|
.sid = 0
|
|
|
|
};
|
|
|
|
|
|
|
|
if (!mv88e6xxx_has_stu(chip))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Make sure that SID 0 is always valid. This is used by VTU
|
|
|
|
* entries that do not make use of the STU, e.g. when creating
|
|
|
|
* a VLAN upper on a port that is also part of a VLAN
|
|
|
|
* filtering bridge.
|
|
|
|
*/
|
|
|
|
return mv88e6xxx_stu_loadpurge(chip, &stu);
|
|
|
|
}
|
|
|
|
|
2022-03-16 15:08:57 +00:00
|
|
|
static int mv88e6xxx_sid_get(struct mv88e6xxx_chip *chip, u8 *sid)
|
|
|
|
{
|
|
|
|
DECLARE_BITMAP(busy, MV88E6XXX_N_SID) = { 0 };
|
|
|
|
struct mv88e6xxx_mst *mst;
|
|
|
|
|
|
|
|
__set_bit(0, busy);
|
|
|
|
|
|
|
|
list_for_each_entry(mst, &chip->msts, node)
|
|
|
|
__set_bit(mst->stu.sid, busy);
|
|
|
|
|
|
|
|
*sid = find_first_zero_bit(busy, MV88E6XXX_N_SID);
|
|
|
|
|
|
|
|
return (*sid >= mv88e6xxx_max_sid(chip)) ? -ENOSPC : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_mst_put(struct mv88e6xxx_chip *chip, u8 sid)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_mst *mst, *tmp;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!sid)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(mst, tmp, &chip->msts, node) {
|
|
|
|
if (mst->stu.sid != sid)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!refcount_dec_and_test(&mst->refcnt))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
mst->stu.valid = false;
|
|
|
|
err = mv88e6xxx_stu_loadpurge(chip, &mst->stu);
|
|
|
|
if (err) {
|
|
|
|
refcount_set(&mst->refcnt, 1);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_del(&mst->node);
|
|
|
|
kfree(mst);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_mst_get(struct mv88e6xxx_chip *chip, struct net_device *br,
|
|
|
|
u16 msti, u8 *sid)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_mst *mst;
|
|
|
|
int err, i;
|
|
|
|
|
|
|
|
if (!mv88e6xxx_has_stu(chip)) {
|
|
|
|
err = -EOPNOTSUPP;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!msti) {
|
|
|
|
*sid = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_for_each_entry(mst, &chip->msts, node) {
|
|
|
|
if (mst->br == br && mst->msti == msti) {
|
|
|
|
refcount_inc(&mst->refcnt);
|
|
|
|
*sid = mst->stu.sid;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
err = mv88e6xxx_sid_get(chip, sid);
|
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
mst = kzalloc(sizeof(*mst), GFP_KERNEL);
|
|
|
|
if (!mst) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&mst->node);
|
|
|
|
refcount_set(&mst->refcnt, 1);
|
|
|
|
mst->br = br;
|
|
|
|
mst->msti = msti;
|
|
|
|
mst->stu.valid = true;
|
|
|
|
mst->stu.sid = *sid;
|
|
|
|
|
|
|
|
/* The bridge starts out all ports in the disabled state. But
|
|
|
|
* a STU state of disabled means to go by the port-global
|
|
|
|
* state. So we set all user port's initial state to blocking,
|
|
|
|
* to match the bridge's behavior.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); i++)
|
|
|
|
mst->stu.state[i] = dsa_is_user_port(chip->ds, i) ?
|
|
|
|
MV88E6XXX_PORT_CTL0_STATE_BLOCKING :
|
|
|
|
MV88E6XXX_PORT_CTL0_STATE_DISABLED;
|
|
|
|
|
|
|
|
err = mv88e6xxx_stu_loadpurge(chip, &mst->stu);
|
|
|
|
if (err)
|
|
|
|
goto err_free;
|
|
|
|
|
|
|
|
list_add_tail(&mst->node, &chip->msts);
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_free:
|
|
|
|
kfree(mst);
|
|
|
|
err:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_mst_state_set(struct dsa_switch *ds, int port,
|
|
|
|
const struct switchdev_mst_state *st)
|
|
|
|
{
|
|
|
|
struct dsa_port *dp = dsa_to_port(ds, port);
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
struct mv88e6xxx_mst *mst;
|
|
|
|
u8 state;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!mv88e6xxx_has_stu(chip))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
switch (st->state) {
|
|
|
|
case BR_STATE_DISABLED:
|
|
|
|
case BR_STATE_BLOCKING:
|
|
|
|
case BR_STATE_LISTENING:
|
|
|
|
state = MV88E6XXX_PORT_CTL0_STATE_BLOCKING;
|
|
|
|
break;
|
|
|
|
case BR_STATE_LEARNING:
|
|
|
|
state = MV88E6XXX_PORT_CTL0_STATE_LEARNING;
|
|
|
|
break;
|
|
|
|
case BR_STATE_FORWARDING:
|
|
|
|
state = MV88E6XXX_PORT_CTL0_STATE_FORWARDING;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_for_each_entry(mst, &chip->msts, node) {
|
|
|
|
if (mst->br == dsa_port_bridge_dev_get(dp) &&
|
|
|
|
mst->msti == st->msti) {
|
|
|
|
if (mst->stu.state[port] == state)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
mst->stu.state[port] = state;
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
err = mv88e6xxx_stu_loadpurge(chip, &mst->stu);
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
2016-02-12 17:09:40 +00: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 00:01:46 +00:00
|
|
|
u16 vid)
|
2016-02-12 17:09:40 +00:00
|
|
|
{
|
2021-12-06 16:57:50 +00:00
|
|
|
struct dsa_port *dp = dsa_to_port(ds, port), *other_dp;
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2019-08-01 18:36:34 +00:00
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
2021-12-06 16:57:50 +00:00
|
|
|
int err;
|
2016-02-12 17:09:40 +00:00
|
|
|
|
2017-09-25 21:32:20 +00:00
|
|
|
/* DSA and CPU ports have to be members of multiple vlans */
|
2021-12-06 16:57:50 +00:00
|
|
|
if (dsa_port_is_dsa(dp) || dsa_port_is_cpu(dp))
|
2017-09-25 21:32:20 +00:00
|
|
|
return 0;
|
|
|
|
|
2021-03-18 19:25:36 +00: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 00:01:46 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2016-02-12 17:09:40 +00: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 00:01:46 +00:00
|
|
|
if (!vlan.valid)
|
|
|
|
return 0;
|
2016-02-12 17:09:40 +00:00
|
|
|
|
2021-12-06 16:57:50 +00:00
|
|
|
dsa_switch_for_each_user_port(other_dp, ds) {
|
2021-12-06 16:57:53 +00:00
|
|
|
struct net_device *other_br;
|
|
|
|
|
2021-12-06 16:57:50 +00:00
|
|
|
if (vlan.member[other_dp->index] ==
|
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 00:01:46 +00:00
|
|
|
MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER)
|
|
|
|
continue;
|
2016-02-12 17:09:40 +00:00
|
|
|
|
2021-12-06 16:57:53 +00:00
|
|
|
if (dsa_port_bridge_same(dp, other_dp))
|
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 00:01:46 +00:00
|
|
|
break; /* same bridge, check next VLAN */
|
2016-02-12 17:09:40 +00:00
|
|
|
|
2021-12-06 16:57:53 +00:00
|
|
|
other_br = dsa_port_bridge_dev_get(other_dp);
|
|
|
|
if (!other_br)
|
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 00:01:46 +00:00
|
|
|
continue;
|
2016-12-11 20:07:19 +00: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 00:01:46 +00:00
|
|
|
dev_err(ds->dev, "p%d: hw VLAN %d already used by port %d in %s\n",
|
2021-12-06 16:57:53 +00:00
|
|
|
port, vlan.vid, other_dp->index, netdev_name(other_br));
|
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 00:01:46 +00:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
2016-02-12 17:09:40 +00:00
|
|
|
|
2019-08-01 18:36:33 +00:00
|
|
|
return 0;
|
2016-02-12 17:09:40 +00:00
|
|
|
}
|
|
|
|
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
static int mv88e6xxx_port_commit_pvid(struct mv88e6xxx_chip *chip, int port)
|
|
|
|
{
|
|
|
|
struct dsa_port *dp = dsa_to_port(chip->ds, port);
|
2021-12-06 16:57:53 +00:00
|
|
|
struct net_device *br = dsa_port_bridge_dev_get(dp);
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
struct mv88e6xxx_port *p = &chip->ports[port];
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
u16 pvid = MV88E6XXX_VID_STANDALONE;
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
bool drop_untagged = false;
|
|
|
|
int err;
|
|
|
|
|
2021-12-06 16:57:53 +00:00
|
|
|
if (br) {
|
|
|
|
if (br_vlan_enabled(br)) {
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
pvid = p->bridge_pvid.vid;
|
|
|
|
drop_untagged = !p->bridge_pvid.valid;
|
|
|
|
} else {
|
|
|
|
pvid = MV88E6XXX_VID_BRIDGED;
|
|
|
|
}
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_set_pvid(chip, port, pvid);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
return mv88e6xxx_port_drop_untagged(chip, port, drop_untagged);
|
|
|
|
}
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
static int mv88e6xxx_port_vlan_filtering(struct dsa_switch *ds, int port,
|
2021-02-13 20:43:19 +00:00
|
|
|
bool vlan_filtering,
|
|
|
|
struct netlink_ext_ack *extack)
|
2016-02-26 18:16:08 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2017-06-12 16:37:41 +00:00
|
|
|
u16 mode = vlan_filtering ? MV88E6XXX_PORT_CTL2_8021Q_MODE_SECURE :
|
|
|
|
MV88E6XXX_PORT_CTL2_8021Q_MODE_DISABLED;
|
2016-09-20 23:40:31 +00:00
|
|
|
int err;
|
2016-02-26 18:16:08 +00: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 00:01:50 +00:00
|
|
|
if (!mv88e6xxx_max_vid(chip))
|
|
|
|
return -EOPNOTSUPP;
|
2016-05-09 17:22:47 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
|
2016-11-04 02:23:31 +00:00
|
|
|
err = mv88e6xxx_port_set_8021q_mode(chip, port, mode);
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_commit_pvid(chip, port);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
unlock:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-02-26 18:16:08 +00:00
|
|
|
|
2016-09-20 23:40:31 +00:00
|
|
|
return err;
|
2016-02-26 18:16:08 +00:00
|
|
|
}
|
|
|
|
|
2016-06-20 17:13:58 +00:00
|
|
|
static int
|
|
|
|
mv88e6xxx_port_vlan_prepare(struct dsa_switch *ds, int port,
|
2017-11-30 16:23:57 +00:00
|
|
|
const struct switchdev_obj_port_vlan *vlan)
|
2015-11-01 17:33:55 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-02-12 17:09:40 +00:00
|
|
|
int err;
|
|
|
|
|
2020-11-10 18:57:20 +00:00
|
|
|
if (!mv88e6xxx_max_vid(chip))
|
2016-05-09 17:22:47 +00:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2016-02-12 17:09:40 +00: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 18:36:33 +00: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 00:01:46 +00:00
|
|
|
err = mv88e6xxx_port_check_hw_vlan(ds, port, vlan->vid);
|
2019-08-01 18:36:33 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-02-12 17:09:40 +00:00
|
|
|
|
2019-08-01 18:36:33 +00:00
|
|
|
return err;
|
2015-11-01 17:33:55 +00:00
|
|
|
}
|
|
|
|
|
2017-11-09 21:29:55 +00: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 18:36:35 +00:00
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
|
|
|
u16 fid;
|
2017-11-09 21:29:55 +00:00
|
|
|
int err;
|
|
|
|
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
/* Ports have two private address databases: one for when the port is
|
|
|
|
* standalone and one for when the port is under a bridge and the
|
|
|
|
* 802.1Q mode is disabled. When the port is standalone, DSA wants its
|
|
|
|
* address database to remain 100% empty, so we never load an ATU entry
|
|
|
|
* into a standalone port's database. Therefore, translate the null
|
|
|
|
* VLAN ID into the port's database used for VLAN-unaware bridging.
|
|
|
|
*/
|
2019-08-01 18:36:35 +00:00
|
|
|
if (vid == 0) {
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
fid = MV88E6XXX_FID_BRIDGED;
|
2019-08-01 18:36:35 +00:00
|
|
|
} else {
|
2021-03-18 19:25:36 +00:00
|
|
|
err = mv88e6xxx_vtu_get(chip, vid, &vlan);
|
2019-08-01 18:36:35 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* switchdev expects -EOPNOTSUPP to honor software VLANs */
|
2021-03-18 19:25:36 +00:00
|
|
|
if (!vlan.valid)
|
2019-08-01 18:36:35 +00:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
fid = vlan.fid;
|
|
|
|
}
|
2017-11-09 21:29:55 +00:00
|
|
|
|
2019-09-07 20:00:47 +00:00
|
|
|
entry.state = 0;
|
2017-11-09 21:29:55 +00:00
|
|
|
ether_addr_copy(entry.mac, addr);
|
|
|
|
eth_addr_dec(entry.mac);
|
|
|
|
|
2019-08-01 18:36:35 +00:00
|
|
|
err = mv88e6xxx_g1_atu_getnext(chip, fid, &entry);
|
2017-11-09 21:29:55 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* Initialize a fresh ATU entry if it isn't found */
|
2019-09-07 20:00:47 +00:00
|
|
|
if (!entry.state || !ether_addr_equal(entry.mac, addr)) {
|
2017-11-09 21:29:55 +00: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 20:00:47 +00:00
|
|
|
if (!state) {
|
2017-11-09 21:29:55 +00:00
|
|
|
entry.portvec &= ~BIT(port);
|
|
|
|
if (!entry.portvec)
|
2019-09-07 20:00:47 +00:00
|
|
|
entry.state = 0;
|
2017-11-09 21:29:55 +00:00
|
|
|
} else {
|
2021-01-30 13:43:34 +00:00
|
|
|
if (state == MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC)
|
|
|
|
entry.portvec = BIT(port);
|
|
|
|
else
|
|
|
|
entry.portvec |= BIT(port);
|
|
|
|
|
2017-11-09 21:29:55 +00:00
|
|
|
entry.state = state;
|
|
|
|
}
|
|
|
|
|
2019-08-01 18:36:35 +00:00
|
|
|
return mv88e6xxx_g1_atu_loadpurge(chip, fid, &entry);
|
2017-11-09 21:29:55 +00:00
|
|
|
}
|
|
|
|
|
2019-09-07 20:00:49 +00: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 19:38:08 +00:00
|
|
|
if (fs->m_ext.vlan_tci != htons(0xffff))
|
2019-09-07 20:00:49 +00: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 21:29:56 +00: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 19:25:37 +00:00
|
|
|
u8 broadcast[ETH_ALEN];
|
|
|
|
|
|
|
|
eth_broadcast_addr(broadcast);
|
2017-11-09 21:29:56 +00: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 19:25:40 +00: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 21:29:56 +00:00
|
|
|
err = mv88e6xxx_port_add_broadcast(chip, port, vid);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-03-18 19:25:40 +00: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 18:36:37 +00: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 16:52:22 +00:00
|
|
|
{
|
2019-08-01 18:36:37 +00:00
|
|
|
const u8 non_member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER;
|
2016-09-29 16:21:58 +00:00
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
2019-08-01 18:36:37 +00:00
|
|
|
int i, err;
|
2015-08-13 16:52:22 +00:00
|
|
|
|
2021-03-18 19:25:36 +00:00
|
|
|
err = mv88e6xxx_vtu_get(chip, vid, &vlan);
|
2017-11-09 21:29:56 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2021-03-18 19:25:36 +00:00
|
|
|
if (!vlan.valid) {
|
2019-08-01 18:36:37 +00:00
|
|
|
memset(&vlan, 0, sizeof(vlan));
|
|
|
|
|
2022-02-03 10:16:56 +00:00
|
|
|
if (vid == MV88E6XXX_VID_STANDALONE)
|
|
|
|
vlan.policy = true;
|
|
|
|
|
2019-08-01 18:36:37 +00:00
|
|
|
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 18:36:37 +00:00
|
|
|
dev_info(chip->dev, "p%d: already a member of VLAN %d\n",
|
|
|
|
port, vid);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2015-11-01 17:33:55 +00:00
|
|
|
}
|
|
|
|
|
2021-01-09 00:01:53 +00:00
|
|
|
static int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
|
2021-02-13 20:43:18 +00:00
|
|
|
const struct switchdev_obj_port_vlan *vlan,
|
|
|
|
struct netlink_ext_ack *extack)
|
2015-11-01 17:33:55 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2015-11-01 17:33:55 +00:00
|
|
|
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
|
|
|
|
bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
struct mv88e6xxx_port *p = &chip->ports[port];
|
2020-02-26 17:14:26 +00:00
|
|
|
bool warn;
|
2017-06-07 22:12:13 +00:00
|
|
|
u8 member;
|
2021-01-09 00:01:53 +00:00
|
|
|
int err;
|
2015-11-01 17:33:55 +00:00
|
|
|
|
2021-06-21 08:54:38 +00:00
|
|
|
if (!vlan->vid)
|
|
|
|
return 0;
|
|
|
|
|
2021-01-09 00:01:53 +00:00
|
|
|
err = mv88e6xxx_port_vlan_prepare(ds, port, vlan);
|
|
|
|
if (err)
|
|
|
|
return err;
|
2016-05-09 17:22:47 +00:00
|
|
|
|
2017-06-07 22:12:13 +00:00
|
|
|
if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port))
|
2017-06-15 16:14:02 +00:00
|
|
|
member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNMODIFIED;
|
2017-06-07 22:12:13 +00:00
|
|
|
else if (untagged)
|
2017-06-15 16:14:02 +00:00
|
|
|
member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNTAGGED;
|
2017-06-07 22:12:13 +00:00
|
|
|
else
|
2017-06-15 16:14:02 +00:00
|
|
|
member = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_TAGGED;
|
2017-06-07 22:12:13 +00:00
|
|
|
|
2023-10-23 18:17:28 +00:00
|
|
|
/* net/dsa/user.c will call dsa_port_vlan_add() for the affected port
|
2020-02-26 17:14:26 +00:00
|
|
|
* 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 17:33:55 +00:00
|
|
|
|
2021-01-09 00:01:53 +00: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 00:01:46 +00:00
|
|
|
dev_err(ds->dev, "p%d: failed to add VLAN %d%c\n", port,
|
|
|
|
vlan->vid, untagged ? 'u' : 't');
|
2021-01-09 00:01:53 +00:00
|
|
|
goto out;
|
|
|
|
}
|
2015-11-01 17:33:55 +00:00
|
|
|
|
2021-01-09 00:01:53 +00:00
|
|
|
if (pvid) {
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
p->bridge_pvid.vid = vlan->vid;
|
|
|
|
p->bridge_pvid.valid = true;
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_commit_pvid(chip, port);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
} else if (vlan->vid && p->bridge_pvid.vid == vlan->vid) {
|
|
|
|
/* The old pvid was reinstalled as a non-pvid VLAN */
|
|
|
|
p->bridge_pvid.valid = false;
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_commit_pvid(chip, port);
|
|
|
|
if (err)
|
2021-01-09 00:01:53 +00:00
|
|
|
goto out;
|
|
|
|
}
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
|
2021-01-09 00:01:53 +00:00
|
|
|
out:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2021-01-09 00:01:53 +00:00
|
|
|
|
|
|
|
return err;
|
2015-08-13 16:52:22 +00:00
|
|
|
}
|
|
|
|
|
2019-08-01 18:36:36 +00:00
|
|
|
static int mv88e6xxx_port_vlan_leave(struct mv88e6xxx_chip *chip,
|
|
|
|
int port, u16 vid)
|
2015-08-13 16:52:21 +00:00
|
|
|
{
|
2016-09-29 16:21:58 +00:00
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
2015-08-13 16:52:21 +00:00
|
|
|
int i, err;
|
|
|
|
|
2019-08-01 18:36:36 +00:00
|
|
|
if (!vid)
|
2021-07-22 13:05:51 +00:00
|
|
|
return 0;
|
2019-08-01 18:36:36 +00:00
|
|
|
|
2021-03-18 19:25:36 +00:00
|
|
|
err = mv88e6xxx_vtu_get(chip, vid, &vlan);
|
2015-08-13 16:52:21 +00:00
|
|
|
if (err)
|
2015-11-01 17:33:55 +00:00
|
|
|
return err;
|
2015-08-13 16:52:21 +00:00
|
|
|
|
2019-08-01 18:36:36 +00: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 19:25:36 +00:00
|
|
|
if (!vlan.valid ||
|
2019-08-01 18:36:36 +00:00
|
|
|
vlan.member[port] == MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER)
|
2016-02-05 19:04:39 +00:00
|
|
|
return -EOPNOTSUPP;
|
2015-08-13 16:52:21 +00:00
|
|
|
|
2017-06-15 16:14:02 +00:00
|
|
|
vlan.member[port] = MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER;
|
2015-08-13 16:52:21 +00:00
|
|
|
|
|
|
|
/* keep the VLAN unless all ports are excluded */
|
2015-10-11 22:08:36 +00:00
|
|
|
vlan.valid = false;
|
2016-09-29 16:21:57 +00:00
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i) {
|
2017-06-15 16:14:02 +00:00
|
|
|
if (vlan.member[i] !=
|
|
|
|
MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_NON_MEMBER) {
|
2015-10-11 22:08:36 +00:00
|
|
|
vlan.valid = true;
|
2015-08-13 16:52:21 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-01 18:05:23 +00:00
|
|
|
err = mv88e6xxx_vtu_loadpurge(chip, &vlan);
|
2015-11-01 17:33:55 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2022-03-16 15:08:57 +00:00
|
|
|
if (!vlan.valid) {
|
|
|
|
err = mv88e6xxx_mst_put(chip, vlan.sid);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-03-11 21:12:55 +00:00
|
|
|
return mv88e6xxx_g1_atu_remove(chip, vlan.fid, port, false);
|
2015-11-01 17:33:55 +00:00
|
|
|
}
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
static int mv88e6xxx_port_vlan_del(struct dsa_switch *ds, int port,
|
|
|
|
const struct switchdev_obj_port_vlan *vlan)
|
2015-11-01 17:33:55 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
struct mv88e6xxx_port *p = &chip->ports[port];
|
2015-11-01 17:33:55 +00: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 00:01:46 +00:00
|
|
|
u16 pvid;
|
2015-11-01 17:33:55 +00:00
|
|
|
|
2020-11-10 18:57:20 +00:00
|
|
|
if (!mv88e6xxx_max_vid(chip))
|
2016-05-09 17:22:47 +00:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2022-02-11 17:45:06 +00:00
|
|
|
/* The ATU removal procedure needs the FID to be mapped in the VTU,
|
|
|
|
* but FDB deletion runs concurrently with VLAN deletion. Flush the DSA
|
|
|
|
* switchdev workqueue to ensure that all FDB entries are deleted
|
|
|
|
* before we remove the VLAN.
|
|
|
|
*/
|
|
|
|
dsa_flush_workqueue();
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2015-11-01 17:33:55 +00:00
|
|
|
|
2016-11-04 02:23:30 +00:00
|
|
|
err = mv88e6xxx_port_get_pvid(chip, port, &pvid);
|
2015-08-13 16:52:21 +00: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 00:01:46 +00:00
|
|
|
err = mv88e6xxx_port_vlan_leave(chip, port, vlan->vid);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
if (vlan->vid == pvid) {
|
net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware
The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679ca2a
("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
some issues with VLAN and decided the best way to deal with them was to
make the DSA core ignore VLANs added by the bridge while VLAN awareness
is turned off. Those issues were never explained, just presented as
"at least one corner case".
That approach had problems of its own, presented by
commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always
receive bridge VLANs") for the DSA core, followed by
commit 1fb74191988f ("net: dsa: mv88e6xxx: fix vlan setup") which
applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
particular.
We still don't know what corner case Andrew saw when he wrote
commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled"), but Tobias now reports that when we use TX forwarding
offload, pinging an external station from the bridge device is broken if
the front-facing DSA user port has flooding turned off. The full
description is in the link below, but for short, when a mv88e6xxx port
is under a VLAN-unaware bridge, it inherits that bridge's pvid.
So packets ingressing a user port will be classified to e.g. VID 1
(assuming that value for the bridge_default_pvid), whereas when
tag_dsa.c xmits towards a user port, it always sends packets using a VID
of 0 if that port is standalone or under a VLAN-unaware bridge - or at
least it did so prior to commit d82f8ab0d874 ("net: dsa: tag_dsa:
offload the bridge forwarding process").
In any case, when there is a conversation between the CPU and a station
connected to a user port, the station's MAC address is learned in VID 1
but the CPU tries to transmit through VID 0. The packets reach the
intended station, but via flooding and not by virtue of matching the
existing ATU entry.
DSA has established (and enforced in other drivers: sja1105, felix,
mt7530) that a VLAN-unaware port should use a private pvid, and not
inherit the one from the bridge. The bridge's pvid should only be
inherited when that bridge is VLAN-aware, so all state transitions need
to be handled. On the other hand, all bridge VLANs should sit in the VTU
starting with the moment when the bridge offloads them via switchdev,
they are just not used.
This solves the problem that Tobias sees because packets ingressing on
VLAN-unaware user ports now get classified to VID 0, which is also the
VID used by tag_dsa.c on xmit.
Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:10 +00:00
|
|
|
p->bridge_pvid.valid = false;
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_commit_pvid(chip, port);
|
2015-11-01 17:33:55 +00:00
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
2015-08-13 16:52:21 +00:00
|
|
|
unlock:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2015-08-13 16:52:21 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2022-03-16 15:08:57 +00:00
|
|
|
static int mv88e6xxx_port_vlan_fast_age(struct dsa_switch *ds, int port, u16 vid)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
err = mv88e6xxx_vtu_get(chip, vid, &vlan);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_fast_age_fid(chip, port, vlan.fid);
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_vlan_msti_set(struct dsa_switch *ds,
|
|
|
|
struct dsa_bridge bridge,
|
|
|
|
const struct switchdev_vlan_msti *msti)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
struct mv88e6xxx_vtu_entry vlan;
|
|
|
|
u8 old_sid, new_sid;
|
|
|
|
int err;
|
|
|
|
|
2022-03-18 20:13:21 +00:00
|
|
|
if (!mv88e6xxx_has_stu(chip))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2022-03-16 15:08:57 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
err = mv88e6xxx_vtu_get(chip, msti->vid, &vlan);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
if (!vlan.valid) {
|
|
|
|
err = -EINVAL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
old_sid = vlan.sid;
|
|
|
|
|
|
|
|
err = mv88e6xxx_mst_get(chip, bridge.dev, msti->msti, &new_sid);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
if (new_sid != old_sid) {
|
|
|
|
vlan.sid = new_sid;
|
|
|
|
|
|
|
|
err = mv88e6xxx_vtu_loadpurge(chip, &vlan);
|
|
|
|
if (err) {
|
|
|
|
mv88e6xxx_mst_put(chip, new_sid);
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
err = mv88e6xxx_mst_put(chip, old_sid);
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-08-06 13:15:40 +00:00
|
|
|
static int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
|
net: dsa: request drivers to perform FDB isolation
For DSA, to encourage drivers to perform FDB isolation simply means to
track which bridge does each FDB and MDB entry belong to. It then
becomes the driver responsibility to use something that makes the FDB
entry from one bridge not match the FDB lookup of ports from other
bridges.
The top-level functions where the bridge is determined are:
- dsa_port_fdb_{add,del}
- dsa_port_host_fdb_{add,del}
- dsa_port_mdb_{add,del}
- dsa_port_host_mdb_{add,del}
aka the pre-crosschip-notifier functions.
Changing the API to pass a reference to a bridge is not superfluous, and
looking at the passed bridge argument is not the same as having the
driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
method.
DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
and those do not have any dp->bridge information to retrieve, because
they are not in any bridge - they are merely the pipes that serve the
user ports that are in one or multiple bridges.
The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
in a larger "struct dsa_db" database. Although only databases associated
to bridges are notified for now, this API will be the starting point for
implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
entries on the CPU port which belong to the corresponding user port's
port database. These are supposed to match only when the port is
standalone.
It is better to introduce the API in its expected final form than to
introduce it for bridges first, then to have to change drivers which may
have made one or more assumptions.
Drivers can use the provided bridge.num, but they can also use a
different numbering scheme that is more convenient.
DSA must perform refcounting on the CPU and DSA ports by also taking
into account the bridge number. So if two bridges request the same local
address, DSA must notify the driver twice, once for each bridge.
In fact, if the driver supports FDB isolation, DSA must perform
refcounting per bridge, but if the driver doesn't, DSA must refcount
host addresses across all bridges, otherwise it would be telling the
driver to delete an FDB entry for a bridge and the driver would delete
it for all bridges. So introduce a bool fdb_isolation in drivers which
would make all bridge databases passed to the cross-chip notifier have
the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
say that all bridge databases are the same database - which is
essentially the legacy behavior.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-25 09:22:22 +00:00
|
|
|
const unsigned char *addr, u16 vid,
|
|
|
|
struct dsa_db db)
|
2015-08-06 05:44:08 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2017-08-06 13:15:40 +00:00
|
|
|
int err;
|
2015-08-06 05:44:08 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-08-06 13:15:40 +00: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 13:15:40 +00:00
|
|
|
|
|
|
|
return err;
|
2015-08-06 05:44:08 +00:00
|
|
|
}
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
static int mv88e6xxx_port_fdb_del(struct dsa_switch *ds, int port,
|
net: dsa: request drivers to perform FDB isolation
For DSA, to encourage drivers to perform FDB isolation simply means to
track which bridge does each FDB and MDB entry belong to. It then
becomes the driver responsibility to use something that makes the FDB
entry from one bridge not match the FDB lookup of ports from other
bridges.
The top-level functions where the bridge is determined are:
- dsa_port_fdb_{add,del}
- dsa_port_host_fdb_{add,del}
- dsa_port_mdb_{add,del}
- dsa_port_host_mdb_{add,del}
aka the pre-crosschip-notifier functions.
Changing the API to pass a reference to a bridge is not superfluous, and
looking at the passed bridge argument is not the same as having the
driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
method.
DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
and those do not have any dp->bridge information to retrieve, because
they are not in any bridge - they are merely the pipes that serve the
user ports that are in one or multiple bridges.
The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
in a larger "struct dsa_db" database. Although only databases associated
to bridges are notified for now, this API will be the starting point for
implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
entries on the CPU port which belong to the corresponding user port's
port database. These are supposed to match only when the port is
standalone.
It is better to introduce the API in its expected final form than to
introduce it for bridges first, then to have to change drivers which may
have made one or more assumptions.
Drivers can use the provided bridge.num, but they can also use a
different numbering scheme that is more convenient.
DSA must perform refcounting on the CPU and DSA ports by also taking
into account the bridge number. So if two bridges request the same local
address, DSA must notify the driver twice, once for each bridge.
In fact, if the driver supports FDB isolation, DSA must perform
refcounting per bridge, but if the driver doesn't, DSA must refcount
host addresses across all bridges, otherwise it would be telling the
driver to delete an FDB entry for a bridge and the driver would delete
it for all bridges. So introduce a bool fdb_isolation in drivers which
would make all bridge databases passed to the cross-chip notifier have
the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
say that all bridge databases are the same database - which is
essentially the legacy behavior.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-25 09:22:22 +00:00
|
|
|
const unsigned char *addr, u16 vid,
|
|
|
|
struct dsa_db db)
|
2015-08-06 05:44:08 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-08-31 15:50:04 +00:00
|
|
|
int err;
|
2015-08-06 05:44:08 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2019-09-07 20:00:47 +00: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 05:44:08 +00:00
|
|
|
|
2016-08-31 15:50:04 +00:00
|
|
|
return err;
|
2015-08-06 05:44:08 +00:00
|
|
|
}
|
|
|
|
|
2016-08-31 15:50:04 +00:00
|
|
|
static int mv88e6xxx_port_db_dump_fid(struct mv88e6xxx_chip *chip,
|
|
|
|
u16 fid, u16 vid, int port,
|
2017-08-06 13:15:49 +00:00
|
|
|
dsa_fdb_dump_cb_t *cb, void *data)
|
2016-02-26 18:16:02 +00:00
|
|
|
{
|
2017-03-11 21:12:53 +00:00
|
|
|
struct mv88e6xxx_atu_entry addr;
|
2017-08-06 13:15:49 +00:00
|
|
|
bool is_static;
|
2016-02-26 18:16:02 +00:00
|
|
|
int err;
|
|
|
|
|
2019-09-07 20:00:47 +00:00
|
|
|
addr.state = 0;
|
2017-03-11 21:12:53 +00:00
|
|
|
eth_broadcast_addr(addr.mac);
|
2016-02-26 18:16:02 +00:00
|
|
|
|
|
|
|
do {
|
2017-03-11 21:12:53 +00:00
|
|
|
err = mv88e6xxx_g1_atu_getnext(chip, fid, &addr);
|
2016-02-26 18:16:02 +00:00
|
|
|
if (err)
|
2016-08-31 15:50:04 +00:00
|
|
|
return err;
|
2016-02-26 18:16:02 +00:00
|
|
|
|
2019-09-07 20:00:47 +00:00
|
|
|
if (!addr.state)
|
2016-02-26 18:16:02 +00:00
|
|
|
break;
|
|
|
|
|
2017-03-11 21:12:57 +00:00
|
|
|
if (addr.trunk || (addr.portvec & BIT(port)) == 0)
|
2016-08-31 15:50:04 +00:00
|
|
|
continue;
|
|
|
|
|
2017-08-06 13:15:49 +00:00
|
|
|
if (!is_unicast_ether_addr(addr.mac))
|
|
|
|
continue;
|
2016-08-31 15:50:04 +00:00
|
|
|
|
2017-08-06 13:15:49 +00:00
|
|
|
is_static = (addr.state ==
|
|
|
|
MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC);
|
|
|
|
err = cb(addr.mac, vid, is_static, data);
|
2016-08-31 15:50:04 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2016-02-26 18:16:02 +00:00
|
|
|
} while (!is_broadcast_ether_addr(addr.mac));
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-03-18 19:25:35 +00: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 15:50:04 +00:00
|
|
|
static int mv88e6xxx_port_db_dump(struct mv88e6xxx_chip *chip, int port,
|
2017-08-06 13:15:49 +00:00
|
|
|
dsa_fdb_dump_cb_t *cb, void *data)
|
2015-10-22 13:34:41 +00:00
|
|
|
{
|
2021-03-18 19:25:35 +00:00
|
|
|
struct mv88e6xxx_port_db_dump_vlan_ctx ctx = {
|
|
|
|
.port = port,
|
|
|
|
.cb = cb,
|
|
|
|
.data = data,
|
|
|
|
};
|
2016-02-26 18:16:04 +00:00
|
|
|
u16 fid;
|
2015-10-22 13:34:41 +00:00
|
|
|
int err;
|
|
|
|
|
2016-02-26 18:16:04 +00:00
|
|
|
/* Dump port's default Filtering Information Database (VLAN ID 0) */
|
2016-11-04 02:23:29 +00:00
|
|
|
err = mv88e6xxx_port_get_fid(chip, port, &fid);
|
2016-02-26 18:16:04 +00:00
|
|
|
if (err)
|
2016-08-31 15:50:04 +00:00
|
|
|
return err;
|
2016-02-26 18:16:04 +00:00
|
|
|
|
2017-08-06 13:15:49 +00:00
|
|
|
err = mv88e6xxx_port_db_dump_fid(chip, fid, 0, port, cb, data);
|
2016-02-26 18:16:04 +00:00
|
|
|
if (err)
|
2016-08-31 15:50:04 +00:00
|
|
|
return err;
|
2016-02-26 18:16:04 +00:00
|
|
|
|
2021-03-18 19:25:35 +00:00
|
|
|
return mv88e6xxx_vtu_walk(chip, mv88e6xxx_port_db_dump_vlan, &ctx);
|
2016-08-31 15:50:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_fdb_dump(struct dsa_switch *ds, int port,
|
2017-08-06 13:15:49 +00:00
|
|
|
dsa_fdb_dump_cb_t *cb, void *data)
|
2016-08-31 15:50:04 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2019-06-12 16:42:47 +00:00
|
|
|
int err;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2019-06-12 16:42:47 +00: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 15:50:04 +00:00
|
|
|
|
2019-06-12 16:42:47 +00:00
|
|
|
return err;
|
2015-10-22 13:34:41 +00:00
|
|
|
}
|
|
|
|
|
2017-03-30 21:37:12 +00:00
|
|
|
static int mv88e6xxx_bridge_map(struct mv88e6xxx_chip *chip,
|
net: dsa: keep the bridge_dev and bridge_num as part of the same structure
The main desire behind this is to provide coherent bridge information to
the fast path without locking.
For example, right now we set dp->bridge_dev and dp->bridge_num from
separate code paths, it is theoretically possible for a packet
transmission to read these two port properties consecutively and find a
bridge number which does not correspond with the bridge device.
Another desire is to start passing more complex bridge information to
dsa_switch_ops functions. For example, with FDB isolation, it is
expected that drivers will need to be passed the bridge which requested
an FDB/MDB entry to be offloaded, and along with that bridge_dev, the
associated bridge_num should be passed too, in case the driver might
want to implement an isolation scheme based on that number.
We already pass the {bridge_dev, bridge_num} pair to the TX forwarding
offload switch API, however we'd like to remove that and squash it into
the basic bridge join/leave API. So that means we need to pass this
pair to the bridge join/leave API.
During dsa_port_bridge_leave, first we unset dp->bridge_dev, then we
call the driver's .port_bridge_leave with what used to be our
dp->bridge_dev, but provided as an argument.
When bridge_dev and bridge_num get folded into a single structure, we
need to preserve this behavior in dsa_port_bridge_leave: we need a copy
of what used to be in dp->bridge.
Switch drivers check bridge membership by comparing dp->bridge_dev with
the provided bridge_dev, but now, if we provide the struct dsa_bridge as
a pointer, they cannot keep comparing dp->bridge to the provided
pointer, since this only points to an on-stack copy. To make this
obvious and prevent driver writers from forgetting and doing stupid
things, in this new API, the struct dsa_bridge is provided as a full
structure (not very large, contains an int and a pointer) instead of a
pointer. An explicit comparison function needs to be used to determine
bridge membership: dsa_port_offloads_bridge().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-06 16:57:56 +00:00
|
|
|
struct dsa_bridge bridge)
|
2015-11-04 22:23:40 +00:00
|
|
|
{
|
2019-10-21 20:51:27 +00:00
|
|
|
struct dsa_switch *ds = chip->ds;
|
|
|
|
struct dsa_switch_tree *dst = ds->dst;
|
|
|
|
struct dsa_port *dp;
|
2017-03-30 21:37:12 +00:00
|
|
|
int err;
|
2016-02-26 18:16:05 +00:00
|
|
|
|
2019-10-21 20:51:27 +00:00
|
|
|
list_for_each_entry(dp, &dst->ports, list) {
|
net: dsa: keep the bridge_dev and bridge_num as part of the same structure
The main desire behind this is to provide coherent bridge information to
the fast path without locking.
For example, right now we set dp->bridge_dev and dp->bridge_num from
separate code paths, it is theoretically possible for a packet
transmission to read these two port properties consecutively and find a
bridge number which does not correspond with the bridge device.
Another desire is to start passing more complex bridge information to
dsa_switch_ops functions. For example, with FDB isolation, it is
expected that drivers will need to be passed the bridge which requested
an FDB/MDB entry to be offloaded, and along with that bridge_dev, the
associated bridge_num should be passed too, in case the driver might
want to implement an isolation scheme based on that number.
We already pass the {bridge_dev, bridge_num} pair to the TX forwarding
offload switch API, however we'd like to remove that and squash it into
the basic bridge join/leave API. So that means we need to pass this
pair to the bridge join/leave API.
During dsa_port_bridge_leave, first we unset dp->bridge_dev, then we
call the driver's .port_bridge_leave with what used to be our
dp->bridge_dev, but provided as an argument.
When bridge_dev and bridge_num get folded into a single structure, we
need to preserve this behavior in dsa_port_bridge_leave: we need a copy
of what used to be in dp->bridge.
Switch drivers check bridge membership by comparing dp->bridge_dev with
the provided bridge_dev, but now, if we provide the struct dsa_bridge as
a pointer, they cannot keep comparing dp->bridge to the provided
pointer, since this only points to an on-stack copy. To make this
obvious and prevent driver writers from forgetting and doing stupid
things, in this new API, the struct dsa_bridge is provided as a full
structure (not very large, contains an int and a pointer) instead of a
pointer. An explicit comparison function needs to be used to determine
bridge membership: dsa_port_offloads_bridge().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-06 16:57:56 +00:00
|
|
|
if (dsa_port_offloads_bridge(dp, &bridge)) {
|
2019-10-21 20:51:27 +00:00
|
|
|
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 21:37:13 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-03-30 21:37:12 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-06 16:57:58 +00:00
|
|
|
/* Treat the software bridge as a virtual single-port switch behind the
|
|
|
|
* CPU and map in the PVT. First dst->last_switch elements are taken by
|
|
|
|
* physical switches, so start from beyond that range.
|
|
|
|
*/
|
|
|
|
static int mv88e6xxx_map_virtual_bridge_to_pvt(struct dsa_switch *ds,
|
|
|
|
unsigned int bridge_num)
|
|
|
|
{
|
|
|
|
u8 dev = bridge_num + ds->dst->last_switch;
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
|
|
|
return mv88e6xxx_pvt_map(chip, dev, 0);
|
|
|
|
}
|
|
|
|
|
2017-03-30 21:37:12 +00:00
|
|
|
static int mv88e6xxx_port_bridge_join(struct dsa_switch *ds, int port,
|
2021-12-06 16:57:57 +00:00
|
|
|
struct dsa_bridge bridge,
|
2022-02-25 09:22:23 +00:00
|
|
|
bool *tx_fwd_offload,
|
|
|
|
struct netlink_ext_ack *extack)
|
2017-03-30 21:37:12 +00:00
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
|
net: dsa: keep the bridge_dev and bridge_num as part of the same structure
The main desire behind this is to provide coherent bridge information to
the fast path without locking.
For example, right now we set dp->bridge_dev and dp->bridge_num from
separate code paths, it is theoretically possible for a packet
transmission to read these two port properties consecutively and find a
bridge number which does not correspond with the bridge device.
Another desire is to start passing more complex bridge information to
dsa_switch_ops functions. For example, with FDB isolation, it is
expected that drivers will need to be passed the bridge which requested
an FDB/MDB entry to be offloaded, and along with that bridge_dev, the
associated bridge_num should be passed too, in case the driver might
want to implement an isolation scheme based on that number.
We already pass the {bridge_dev, bridge_num} pair to the TX forwarding
offload switch API, however we'd like to remove that and squash it into
the basic bridge join/leave API. So that means we need to pass this
pair to the bridge join/leave API.
During dsa_port_bridge_leave, first we unset dp->bridge_dev, then we
call the driver's .port_bridge_leave with what used to be our
dp->bridge_dev, but provided as an argument.
When bridge_dev and bridge_num get folded into a single structure, we
need to preserve this behavior in dsa_port_bridge_leave: we need a copy
of what used to be in dp->bridge.
Switch drivers check bridge membership by comparing dp->bridge_dev with
the provided bridge_dev, but now, if we provide the struct dsa_bridge as
a pointer, they cannot keep comparing dp->bridge to the provided
pointer, since this only points to an on-stack copy. To make this
obvious and prevent driver writers from forgetting and doing stupid
things, in this new API, the struct dsa_bridge is provided as a full
structure (not very large, contains an int and a pointer) instead of a
pointer. An explicit comparison function needs to be used to determine
bridge membership: dsa_port_offloads_bridge().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-06 16:57:56 +00:00
|
|
|
err = mv88e6xxx_bridge_map(chip, bridge);
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
2022-02-03 10:16:53 +00:00
|
|
|
err = mv88e6xxx_port_set_map_da(chip, port, true);
|
|
|
|
if (err)
|
2022-02-07 08:24:39 +00:00
|
|
|
goto unlock;
|
2022-02-03 10:16:53 +00:00
|
|
|
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
err = mv88e6xxx_port_commit_pvid(chip, port);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
2021-12-06 16:57:58 +00:00
|
|
|
if (mv88e6xxx_has_pvt(chip)) {
|
|
|
|
err = mv88e6xxx_map_virtual_bridge_to_pvt(ds, bridge.num);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
*tx_fwd_offload = true;
|
|
|
|
}
|
|
|
|
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
unlock:
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-02-12 17:09:39 +00:00
|
|
|
|
2016-02-26 18:16:05 +00:00
|
|
|
return err;
|
2015-11-04 22:23:40 +00:00
|
|
|
}
|
|
|
|
|
2017-01-27 20:29:41 +00:00
|
|
|
static void mv88e6xxx_port_bridge_leave(struct dsa_switch *ds, int port,
|
net: dsa: keep the bridge_dev and bridge_num as part of the same structure
The main desire behind this is to provide coherent bridge information to
the fast path without locking.
For example, right now we set dp->bridge_dev and dp->bridge_num from
separate code paths, it is theoretically possible for a packet
transmission to read these two port properties consecutively and find a
bridge number which does not correspond with the bridge device.
Another desire is to start passing more complex bridge information to
dsa_switch_ops functions. For example, with FDB isolation, it is
expected that drivers will need to be passed the bridge which requested
an FDB/MDB entry to be offloaded, and along with that bridge_dev, the
associated bridge_num should be passed too, in case the driver might
want to implement an isolation scheme based on that number.
We already pass the {bridge_dev, bridge_num} pair to the TX forwarding
offload switch API, however we'd like to remove that and squash it into
the basic bridge join/leave API. So that means we need to pass this
pair to the bridge join/leave API.
During dsa_port_bridge_leave, first we unset dp->bridge_dev, then we
call the driver's .port_bridge_leave with what used to be our
dp->bridge_dev, but provided as an argument.
When bridge_dev and bridge_num get folded into a single structure, we
need to preserve this behavior in dsa_port_bridge_leave: we need a copy
of what used to be in dp->bridge.
Switch drivers check bridge membership by comparing dp->bridge_dev with
the provided bridge_dev, but now, if we provide the struct dsa_bridge as
a pointer, they cannot keep comparing dp->bridge to the provided
pointer, since this only points to an on-stack copy. To make this
obvious and prevent driver writers from forgetting and doing stupid
things, in this new API, the struct dsa_bridge is provided as a full
structure (not very large, contains an int and a pointer) instead of a
pointer. An explicit comparison function needs to be used to determine
bridge membership: dsa_port_offloads_bridge().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-06 16:57:56 +00:00
|
|
|
struct dsa_bridge bridge)
|
2016-02-05 19:07:14 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
int err;
|
2016-02-26 18:16:05 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
|
2021-12-06 16:57:58 +00:00
|
|
|
if (bridge.tx_fwd_offload &&
|
|
|
|
mv88e6xxx_map_virtual_bridge_to_pvt(ds, bridge.num))
|
|
|
|
dev_err(ds->dev, "failed to remap cross-chip Port VLAN\n");
|
|
|
|
|
net: dsa: keep the bridge_dev and bridge_num as part of the same structure
The main desire behind this is to provide coherent bridge information to
the fast path without locking.
For example, right now we set dp->bridge_dev and dp->bridge_num from
separate code paths, it is theoretically possible for a packet
transmission to read these two port properties consecutively and find a
bridge number which does not correspond with the bridge device.
Another desire is to start passing more complex bridge information to
dsa_switch_ops functions. For example, with FDB isolation, it is
expected that drivers will need to be passed the bridge which requested
an FDB/MDB entry to be offloaded, and along with that bridge_dev, the
associated bridge_num should be passed too, in case the driver might
want to implement an isolation scheme based on that number.
We already pass the {bridge_dev, bridge_num} pair to the TX forwarding
offload switch API, however we'd like to remove that and squash it into
the basic bridge join/leave API. So that means we need to pass this
pair to the bridge join/leave API.
During dsa_port_bridge_leave, first we unset dp->bridge_dev, then we
call the driver's .port_bridge_leave with what used to be our
dp->bridge_dev, but provided as an argument.
When bridge_dev and bridge_num get folded into a single structure, we
need to preserve this behavior in dsa_port_bridge_leave: we need a copy
of what used to be in dp->bridge.
Switch drivers check bridge membership by comparing dp->bridge_dev with
the provided bridge_dev, but now, if we provide the struct dsa_bridge as
a pointer, they cannot keep comparing dp->bridge to the provided
pointer, since this only points to an on-stack copy. To make this
obvious and prevent driver writers from forgetting and doing stupid
things, in this new API, the struct dsa_bridge is provided as a full
structure (not very large, contains an int and a pointer) instead of a
pointer. An explicit comparison function needs to be used to determine
bridge membership: dsa_port_offloads_bridge().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-06 16:57:56 +00:00
|
|
|
if (mv88e6xxx_bridge_map(chip, bridge) ||
|
2017-03-30 21:37:12 +00:00
|
|
|
mv88e6xxx_port_vlan_map(chip, port))
|
|
|
|
dev_err(ds->dev, "failed to remap in-chip Port VLAN\n");
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
|
2022-02-03 10:16:53 +00:00
|
|
|
err = mv88e6xxx_port_set_map_da(chip, port, false);
|
|
|
|
if (err)
|
|
|
|
dev_err(ds->dev,
|
|
|
|
"port %d failed to restore map-DA: %pe\n",
|
|
|
|
port, ERR_PTR(err));
|
|
|
|
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
err = mv88e6xxx_port_commit_pvid(chip, port);
|
|
|
|
if (err)
|
|
|
|
dev_err(ds->dev,
|
|
|
|
"port %d failed to restore standalone pvid: %pe\n",
|
|
|
|
port, ERR_PTR(err));
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-02-05 19:07:14 +00: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 16:37:41 +00:00
|
|
|
static int mv88e6xxx_crosschip_bridge_join(struct dsa_switch *ds,
|
|
|
|
int tree_index, int sw_index,
|
2022-02-25 09:22:23 +00:00
|
|
|
int port, struct dsa_bridge bridge,
|
|
|
|
struct netlink_ext_ack *extack)
|
2017-03-30 21:37:15 +00:00
|
|
|
{
|
|
|
|
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 16:37:41 +00: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 16:37:41 +00:00
|
|
|
err = mv88e6xxx_pvt_map(chip, sw_index, port);
|
2021-12-09 22:24:24 +00:00
|
|
|
err = err ? : mv88e6xxx_map_virtual_bridge_to_pvt(ds, bridge.num);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2017-03-30 21:37:15 +00: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 16:37:41 +00:00
|
|
|
static void mv88e6xxx_crosschip_bridge_leave(struct dsa_switch *ds,
|
|
|
|
int tree_index, int sw_index,
|
net: dsa: keep the bridge_dev and bridge_num as part of the same structure
The main desire behind this is to provide coherent bridge information to
the fast path without locking.
For example, right now we set dp->bridge_dev and dp->bridge_num from
separate code paths, it is theoretically possible for a packet
transmission to read these two port properties consecutively and find a
bridge number which does not correspond with the bridge device.
Another desire is to start passing more complex bridge information to
dsa_switch_ops functions. For example, with FDB isolation, it is
expected that drivers will need to be passed the bridge which requested
an FDB/MDB entry to be offloaded, and along with that bridge_dev, the
associated bridge_num should be passed too, in case the driver might
want to implement an isolation scheme based on that number.
We already pass the {bridge_dev, bridge_num} pair to the TX forwarding
offload switch API, however we'd like to remove that and squash it into
the basic bridge join/leave API. So that means we need to pass this
pair to the bridge join/leave API.
During dsa_port_bridge_leave, first we unset dp->bridge_dev, then we
call the driver's .port_bridge_leave with what used to be our
dp->bridge_dev, but provided as an argument.
When bridge_dev and bridge_num get folded into a single structure, we
need to preserve this behavior in dsa_port_bridge_leave: we need a copy
of what used to be in dp->bridge.
Switch drivers check bridge membership by comparing dp->bridge_dev with
the provided bridge_dev, but now, if we provide the struct dsa_bridge as
a pointer, they cannot keep comparing dp->bridge to the provided
pointer, since this only points to an on-stack copy. To make this
obvious and prevent driver writers from forgetting and doing stupid
things, in this new API, the struct dsa_bridge is provided as a full
structure (not very large, contains an int and a pointer) instead of a
pointer. An explicit comparison function needs to be used to determine
bridge membership: dsa_port_offloads_bridge().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-06 16:57:56 +00:00
|
|
|
int port, struct dsa_bridge bridge)
|
2017-03-30 21:37:15 +00:00
|
|
|
{
|
|
|
|
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 16:37:41 +00:00
|
|
|
if (tree_index != ds->dst->index)
|
|
|
|
return;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2021-12-09 22:24:24 +00:00
|
|
|
if (mv88e6xxx_pvt_map(chip, sw_index, port) ||
|
|
|
|
mv88e6xxx_map_virtual_bridge_to_pvt(ds, bridge.num))
|
2017-03-30 21:37:15 +00: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 21:37:15 +00:00
|
|
|
}
|
|
|
|
|
2016-12-05 22:30:27 +00: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 22:30:26 +00: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) {
|
2023-08-15 00:13:23 +00:00
|
|
|
/* If the switch has just been reset and not yet completed
|
|
|
|
* loading EEPROM, the reset may interrupt the I2C transaction
|
|
|
|
* mid-byte, causing the first EEPROM read after the reset
|
|
|
|
* from the wrong location resulting in the switch booting
|
|
|
|
* to wrong mode and inoperable.
|
|
|
|
*/
|
2023-09-22 12:47:41 +00:00
|
|
|
if (chip->info->ops->get_eeprom)
|
|
|
|
mv88e6xxx_g2_eeprom_wait(chip);
|
2023-08-15 00:13:23 +00:00
|
|
|
|
2016-12-05 22:30:26 +00:00
|
|
|
gpiod_set_value_cansleep(gpiod, 1);
|
|
|
|
usleep_range(10000, 20000);
|
|
|
|
gpiod_set_value_cansleep(gpiod, 0);
|
|
|
|
usleep_range(10000, 20000);
|
2020-11-16 16:43:01 +00:00
|
|
|
|
2023-09-22 12:47:41 +00:00
|
|
|
if (chip->info->ops->get_eeprom)
|
|
|
|
mv88e6xxx_g2_eeprom_wait(chip);
|
2016-12-05 22:30:26 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-05 22:30:25 +00:00
|
|
|
static int mv88e6xxx_disable_ports(struct mv88e6xxx_chip *chip)
|
2016-05-09 17:22:49 +00:00
|
|
|
{
|
2016-12-05 22:30:25 +00:00
|
|
|
int i, err;
|
2016-05-09 17:22:49 +00:00
|
|
|
|
2016-12-05 22:30:25 +00:00
|
|
|
/* Set all ports to the Disabled state */
|
2016-09-29 16:21:57 +00:00
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
|
2017-06-08 22:34:10 +00:00
|
|
|
err = mv88e6xxx_port_set_state(chip, i, BR_STATE_DISABLED);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2016-05-09 17:22:49 +00:00
|
|
|
}
|
|
|
|
|
2016-12-05 22:30:25 +00:00
|
|
|
/* Wait for transmit queues to drain,
|
|
|
|
* i.e. 2ms for a maximum frame to be transmitted at 10 Mbps.
|
|
|
|
*/
|
2016-05-09 17:22:49 +00:00
|
|
|
usleep_range(2000, 4000);
|
|
|
|
|
2016-12-05 22:30:25 +00: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 22:30:26 +00:00
|
|
|
mv88e6xxx_hardware_reset(chip);
|
2016-05-09 17:22:49 +00:00
|
|
|
|
2016-12-05 22:30:27 +00:00
|
|
|
return mv88e6xxx_software_reset(chip);
|
2016-05-09 17:22:49 +00:00
|
|
|
}
|
|
|
|
|
2017-03-11 21:12:59 +00:00
|
|
|
static int mv88e6xxx_set_port_mode(struct mv88e6xxx_chip *chip, int port,
|
2017-06-08 22:34:09 +00:00
|
|
|
enum mv88e6xxx_frame_mode frame,
|
|
|
|
enum mv88e6xxx_egress_mode egress, u16 etype)
|
2016-12-03 03:35:19 +00:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-03-11 21:12:59 +00:00
|
|
|
if (!chip->info->ops->port_set_frame_mode)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_set_egress_mode(chip, port, egress);
|
2016-12-03 03:35:19 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2017-03-11 21:12:59 +00: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 03:35:19 +00:00
|
|
|
}
|
|
|
|
|
2017-03-11 21:12:59 +00:00
|
|
|
static int mv88e6xxx_set_port_mode_normal(struct mv88e6xxx_chip *chip, int port)
|
2016-12-03 03:35:19 +00:00
|
|
|
{
|
2017-03-11 21:12:59 +00:00
|
|
|
return mv88e6xxx_set_port_mode(chip, port, MV88E6XXX_FRAME_MODE_NORMAL,
|
2017-06-08 22:34:09 +00:00
|
|
|
MV88E6XXX_EGRESS_MODE_UNMODIFIED,
|
2017-06-12 16:37:45 +00:00
|
|
|
MV88E6XXX_PORT_ETH_TYPE_DEFAULT);
|
2017-03-11 21:12:59 +00:00
|
|
|
}
|
2016-12-03 03:35:19 +00:00
|
|
|
|
2017-03-11 21:12:59 +00: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 22:34:09 +00:00
|
|
|
MV88E6XXX_EGRESS_MODE_UNMODIFIED,
|
2017-06-12 16:37:45 +00:00
|
|
|
MV88E6XXX_PORT_ETH_TYPE_DEFAULT);
|
2017-03-11 21:12:59 +00:00
|
|
|
}
|
2016-12-03 03:35:19 +00:00
|
|
|
|
2017-03-11 21:12:59 +00: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 22:34:09 +00:00
|
|
|
MV88E6XXX_EGRESS_MODE_ETHERTYPE,
|
|
|
|
ETH_P_EDSA);
|
2017-03-11 21:12:59 +00:00
|
|
|
}
|
2016-12-03 03:35:19 +00:00
|
|
|
|
2017-03-11 21:12:59 +00: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 03:35:19 +00:00
|
|
|
|
2017-10-26 15:22:54 +00:00
|
|
|
if (dsa_is_user_port(chip->ds, port))
|
2017-03-11 21:12:59 +00:00
|
|
|
return mv88e6xxx_set_port_mode_normal(chip, port);
|
2016-12-03 03:35:19 +00:00
|
|
|
|
2017-03-11 21:12:59 +00:00
|
|
|
/* Setup CPU port mode depending on its supported tag format */
|
2021-04-20 18:53:07 +00:00
|
|
|
if (chip->tag_protocol == DSA_TAG_PROTO_DSA)
|
2017-03-11 21:12:59 +00:00
|
|
|
return mv88e6xxx_set_port_mode_dsa(chip, port);
|
2016-12-03 03:35:19 +00:00
|
|
|
|
2021-04-20 18:53:07 +00:00
|
|
|
if (chip->tag_protocol == DSA_TAG_PROTO_EDSA)
|
2017-03-11 21:12:59 +00:00
|
|
|
return mv88e6xxx_set_port_mode_edsa(chip, port);
|
2016-12-03 03:35:19 +00:00
|
|
|
|
2017-03-11 21:12:59 +00:00
|
|
|
return -EINVAL;
|
2016-12-03 03:35:19 +00:00
|
|
|
}
|
|
|
|
|
2017-03-11 21:13:00 +00:00
|
|
|
static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port)
|
2016-12-03 03:35:19 +00:00
|
|
|
{
|
2017-03-11 21:13:00 +00:00
|
|
|
bool message = dsa_is_dsa_port(chip->ds, port);
|
2016-12-03 03:35:19 +00:00
|
|
|
|
2017-03-11 21:13:00 +00:00
|
|
|
return mv88e6xxx_port_set_message_port(chip, port, message);
|
2017-03-11 21:12:59 +00:00
|
|
|
}
|
2016-12-03 03:35:19 +00:00
|
|
|
|
2017-03-11 21:13:00 +00:00
|
|
|
static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port)
|
2017-03-11 21:12:59 +00: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 15:15:56 +00:00
|
|
|
int err;
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
if (chip->info->ops->port_set_ucast_flood) {
|
2021-03-18 19:25:38 +00: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 15:15:56 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
if (chip->info->ops->port_set_mcast_flood) {
|
2021-03-18 19:25:38 +00: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 15:15:56 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
2017-03-11 21:12:50 +00:00
|
|
|
|
2019-06-15 20:35:29 +00:00
|
|
|
return 0;
|
2017-03-11 21:12:50 +00:00
|
|
|
}
|
|
|
|
|
2021-03-17 13:46:41 +00: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 20:34:10 +00: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 20:34:13 +00:00
|
|
|
upstream_port = dsa_upstream_port(ds, port);
|
2017-12-05 20:34:10 +00: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 20:34:11 +00: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 13:46:41 +00:00
|
|
|
err = mv88e6xxx_set_egress_port(chip,
|
2019-11-07 21:11:13 +00:00
|
|
|
MV88E6XXX_EGRESS_DIR_INGRESS,
|
|
|
|
upstream_port);
|
2021-03-17 13:46:41 +00:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
return err;
|
2019-11-07 21:11:13 +00:00
|
|
|
|
2021-03-17 13:46:41 +00:00
|
|
|
err = mv88e6xxx_set_egress_port(chip,
|
2019-11-07 21:11:13 +00:00
|
|
|
MV88E6XXX_EGRESS_DIR_EGRESS,
|
|
|
|
upstream_port);
|
2021-03-17 13:46:41 +00:00
|
|
|
if (err && err != -EOPNOTSUPP)
|
|
|
|
return err;
|
2017-12-05 20:34:11 +00:00
|
|
|
}
|
|
|
|
|
2017-12-05 20:34:10 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
|
2015-03-27 01:36:29 +00:00
|
|
|
{
|
2022-02-10 17:48:23 +00:00
|
|
|
struct device_node *phy_handle = NULL;
|
2016-06-21 16:28:20 +00:00
|
|
|
struct dsa_switch *ds = chip->ds;
|
2022-02-10 17:48:23 +00:00
|
|
|
struct dsa_port *dp;
|
2023-07-13 08:42:28 +00:00
|
|
|
int tx_amp;
|
2016-09-20 23:40:31 +00:00
|
|
|
int err;
|
2015-05-05 23:09:47 +00:00
|
|
|
u16 reg;
|
2015-03-27 01:36:29 +00:00
|
|
|
|
2018-08-09 13:38:47 +00:00
|
|
|
chip->ports[port].chip = chip;
|
|
|
|
chip->ports[port].port = port;
|
|
|
|
|
2023-07-13 08:42:28 +00:00
|
|
|
err = mv88e6xxx_port_setup_mac(chip, port, LINK_UNFORCED,
|
|
|
|
SPEED_UNFORCED, DUPLEX_UNFORCED,
|
|
|
|
PAUSE_ON, PHY_INTERFACE_MODE_NA);
|
2016-11-04 02:23:36 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-05-05 23:09:47 +00: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.
|
|
|
|
*/
|
2023-03-29 15:01:40 +00:00
|
|
|
reg = MV88E6185_PORT_CTL0_USE_TAG | MV88E6185_PORT_CTL0_USE_IP |
|
2017-06-12 16:37:37 +00:00
|
|
|
MV88E6XXX_PORT_CTL0_STATE_FORWARDING;
|
2023-03-29 15:01:40 +00:00
|
|
|
/* Forward any IPv4 IGMP or IPv6 MLD frames received
|
|
|
|
* by a USER port to the CPU port to allow snooping.
|
|
|
|
*/
|
|
|
|
if (dsa_is_user_port(ds, port))
|
|
|
|
reg |= MV88E6XXX_PORT_CTL0_IGMP_MLD_SNOOP;
|
|
|
|
|
2017-06-12 16:37:37 +00:00
|
|
|
err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_CTL0, reg);
|
2016-12-03 03:35:19 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-08-17 21:52:52 +00:00
|
|
|
|
2017-03-11 21:13:00 +00:00
|
|
|
err = mv88e6xxx_setup_port_mode(chip, port);
|
2016-12-03 03:35:19 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-05-05 23:09:47 +00:00
|
|
|
|
2017-03-11 21:13:00 +00:00
|
|
|
err = mv88e6xxx_setup_egress_floods(chip, port);
|
2017-03-11 21:12:59 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2021-09-26 17:41:25 +00:00
|
|
|
/* Port Control 2: don't force a good FCS, set the MTU size to
|
2022-02-03 10:16:53 +00:00
|
|
|
* 10222 bytes, disable 802.1q tags checking, don't discard
|
|
|
|
* tagged or untagged frames on this port, skip destination
|
|
|
|
* address lookup on user ports, disable ARP mirroring and don't
|
|
|
|
* send a copy of all transmitted/received frames on this port
|
|
|
|
* to the CPU.
|
2015-05-05 23:09:47 +00:00
|
|
|
*/
|
2022-02-03 10:16:53 +00:00
|
|
|
err = mv88e6xxx_port_set_map_da(chip, port, !dsa_is_user_port(ds, port));
|
2017-02-04 19:15:28 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-08-13 16:52:23 +00:00
|
|
|
|
2017-12-05 20:34:10 +00:00
|
|
|
err = mv88e6xxx_setup_upstream_port(chip, port);
|
|
|
|
if (err)
|
|
|
|
return err;
|
2015-05-05 23:09:47 +00:00
|
|
|
|
2022-02-03 10:16:56 +00:00
|
|
|
/* On chips that support it, set all downstream DSA ports'
|
|
|
|
* VLAN policy to TRAP. In combination with loading
|
|
|
|
* MV88E6XXX_VID_STANDALONE as a policy entry in the VTU, this
|
|
|
|
* provides a better isolation barrier between standalone
|
|
|
|
* ports, as the ATU is bypassed on any intermediate switches
|
|
|
|
* between the incoming port and the CPU.
|
|
|
|
*/
|
|
|
|
if (dsa_is_downstream_port(ds, port) &&
|
|
|
|
chip->info->ops->port_set_policy) {
|
|
|
|
err = chip->info->ops->port_set_policy(chip, port,
|
|
|
|
MV88E6XXX_POLICY_MAPPING_VTU,
|
|
|
|
MV88E6XXX_POLICY_ACTION_TRAP);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* User ports start out in standalone mode and 802.1Q is
|
|
|
|
* therefore disabled. On DSA ports, all valid VIDs are always
|
|
|
|
* loaded in the VTU - therefore, enable 802.1Q in order to take
|
|
|
|
* advantage of VLAN policy on chips that supports it.
|
|
|
|
*/
|
2017-02-04 19:15:28 +00:00
|
|
|
err = mv88e6xxx_port_set_8021q_mode(chip, port,
|
2022-02-03 10:16:56 +00:00
|
|
|
dsa_is_user_port(ds, port) ?
|
|
|
|
MV88E6XXX_PORT_CTL2_8021Q_MODE_DISABLED :
|
|
|
|
MV88E6XXX_PORT_CTL2_8021Q_MODE_SECURE);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* Bind MV88E6XXX_VID_STANDALONE to MV88E6XXX_FID_STANDALONE by
|
|
|
|
* virtue of the fact that mv88e6xxx_atu_new() will pick it as
|
|
|
|
* the first free FID. This will be used as the private PVID for
|
|
|
|
* unbridged ports. Shared (DSA and CPU) ports must also be
|
|
|
|
* members of this VID, in order to trap all frames assigned to
|
|
|
|
* it to the CPU.
|
|
|
|
*/
|
|
|
|
err = mv88e6xxx_port_vlan_join(chip, port, MV88E6XXX_VID_STANDALONE,
|
|
|
|
MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNMODIFIED,
|
|
|
|
false);
|
2017-02-04 19:15:28 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
/* Associate MV88E6XXX_VID_BRIDGED with MV88E6XXX_FID_BRIDGED in the
|
|
|
|
* ATU by virtue of the fact that mv88e6xxx_atu_new() will pick it as
|
|
|
|
* the first free FID after MV88E6XXX_FID_STANDALONE. This will be used
|
|
|
|
* as the private PVID on ports under a VLAN-unaware bridge.
|
|
|
|
* Shared (DSA and CPU) ports must also be members of it, to translate
|
|
|
|
* the VID from the DSA tag into MV88E6XXX_FID_BRIDGED, instead of
|
|
|
|
* relying on their port default FID.
|
|
|
|
*/
|
|
|
|
err = mv88e6xxx_port_vlan_join(chip, port, MV88E6XXX_VID_BRIDGED,
|
2022-02-03 10:16:56 +00:00
|
|
|
MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNMODIFIED,
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
false);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2017-06-08 22:34:13 +00:00
|
|
|
if (chip->info->ops->port_set_jumbo_size) {
|
2021-09-26 17:41:25 +00:00
|
|
|
err = chip->info->ops->port_set_jumbo_size(chip, port, 10218);
|
2016-12-03 03:45:17 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-03-18 19:25:39 +00: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-05 23:09:47 +00:00
|
|
|
*/
|
2021-03-18 19:25:39 +00:00
|
|
|
if (dsa_is_user_port(ds, port))
|
2016-04-14 18:42:07 +00:00
|
|
|
reg = 0;
|
2021-03-18 19:25:39 +00:00
|
|
|
else
|
|
|
|
reg = 1 << port;
|
2015-11-03 15:52:36 +00:00
|
|
|
|
2017-06-12 16:37:43 +00:00
|
|
|
err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_ASSOC_VECTOR,
|
|
|
|
reg);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-05-05 23:09:47 +00:00
|
|
|
|
|
|
|
/* Egress rate control 2: disable egress rate control. */
|
2017-06-12 16:37:42 +00:00
|
|
|
err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_EGRESS_RATE_CTL2,
|
|
|
|
0x0000);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-05-05 23:09:47 +00:00
|
|
|
|
2017-06-08 22:34:12 +00:00
|
|
|
if (chip->info->ops->port_pause_limit) {
|
|
|
|
err = chip->info->ops->port_pause_limit(chip, port, 0, 0);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2016-12-03 03:45:19 +00:00
|
|
|
}
|
2015-05-05 23:09:47 +00:00
|
|
|
|
2017-03-11 21:13:01 +00: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 21:13:02 +00:00
|
|
|
if (chip->info->ops->port_disable_pri_override) {
|
|
|
|
err = chip->info->ops->port_disable_pri_override(chip, port);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2016-12-03 03:35:16 +00:00
|
|
|
}
|
2016-08-22 14:01:02 +00:00
|
|
|
|
2016-12-03 03:35:16 +00:00
|
|
|
if (chip->info->ops->port_tag_remap) {
|
|
|
|
err = chip->info->ops->port_tag_remap(chip, port);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-05-05 23:09:47 +00:00
|
|
|
}
|
|
|
|
|
2016-12-03 03:45:18 +00:00
|
|
|
if (chip->info->ops->port_egress_rate_limiting) {
|
|
|
|
err = chip->info->ops->port_egress_rate_limiting(chip, port);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-05-05 23:09:47 +00:00
|
|
|
}
|
|
|
|
|
2019-07-31 08:23:49 +00: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-27 01:36:29 +00:00
|
|
|
|
2022-02-10 17:48:23 +00:00
|
|
|
if (chip->info->ops->serdes_set_tx_amplitude) {
|
2023-07-13 08:42:28 +00:00
|
|
|
dp = dsa_to_port(ds, port);
|
2022-02-10 17:48:23 +00:00
|
|
|
if (dp)
|
|
|
|
phy_handle = of_parse_phandle(dp->dn, "phy-handle", 0);
|
|
|
|
|
|
|
|
if (phy_handle && !of_property_read_u32(phy_handle,
|
|
|
|
"tx-p2p-microvolt",
|
|
|
|
&tx_amp))
|
|
|
|
err = chip->info->ops->serdes_set_tx_amplitude(chip,
|
|
|
|
port, tx_amp);
|
|
|
|
if (phy_handle) {
|
|
|
|
of_node_put(phy_handle);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 18:42:09 +00:00
|
|
|
/* Port based VLAN map: give each port the same default address
|
2016-02-26 18:16:06 +00:00
|
|
|
* database, and allow bidirectional communication between the
|
|
|
|
* CPU and DSA port(s), and the other ports.
|
2015-03-27 01:36:29 +00:00
|
|
|
*/
|
net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports
Similar to commit 6087175b7991 ("net: dsa: mt7530: use independent VLAN
learning on VLAN-unaware bridges"), software forwarding between an
unoffloaded LAG port (a bonding interface with an unsupported policy)
and a mv88e6xxx user port directly under a bridge is broken.
We adopt the same strategy, which is to make the standalone ports not
find any ATU entry learned on a bridge port.
Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
as many FIDs as VIDs (4096). The FID is derived from the VID when
possible (the VTU maps a VID to a FID), with a fallback to the port
based default FID value when not (802.1Q Mode is disabled on the port,
or the classified VID isn't present in the VTU).
The mv88e6xxx driver makes the following use of FIDs and VIDs:
- the port's DefaultVID (to which untagged & pvid-tagged packets get
classified) is 0 and is absent from the VTU, so this kind of packets is
processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
- every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
mv88e6xxx_atu_new() associates a FID with that VID which increases
linearly starting from 1. Like this:
bridge vlan add dev lan0 vid 100 # FID 1
bridge vlan add dev lan1 vid 100 # still FID 1
bridge vlan add dev lan2 vid 1024 # FID 2
The FID allocation made by the driver is sub-optimal for the following
reasons:
(a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
of 0 too. The difference is that the bridged ports may learn ATU
entries, while the standalone port has the requirement that it must
not, and must not find them either. Standalone ports must not use
the same FID as ports belonging to a bridge. All standalone ports
can use the same FID, since the ATU will never have an entry in
that FID.
(b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
default FID of 0 on all their ports. The FDBs will not be isolated
between these bridges. Every VLAN-unaware bridge must use the same
FID on all its ports, different from the FID of other bridge ports.
(c) Each bridge VLAN uses a unique FID which is useful for Independent
VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
will result in the same FID being used by mv88e6xxx_atu_new().
The correct behavior is for VLAN 1 in br0 to have a different FID
compared to VLAN 1 in br1.
This patch cannot fix all the above. Traditionally the DSA framework did
not care about this, and the reality is that DSA core involvement is
needed for the aforementioned issues to be solved. The only thing we can
solve here is an issue which does not require API changes, and that is
issue (a), aka use a different FID for standalone ports vs ports under
VLAN-unaware bridges.
The first step is deciding what VID and FID to use for standalone ports,
and what VID and FID for bridged ports. The 0/0 pair for standalone
ports is what they used up till now, let's keep using that. For bridged
ports, there are 2 cases:
- VLAN-aware ports will never end up using the port default FID, because
packets will always be classified to a VID in the VTU or dropped
otherwise. The FID is the one associated with the VID in the VTU.
- On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
zero (just as in the case of standalone ports), and just change the
port's default FID from 0 to a different number (say 1).
However, Tobias points out that there is one more requirement to cater to:
cross-chip bridging. The Marvell DSA header does not carry the FID in
it, only the VID. So once a packet crosses a DSA link, if it has a VID
of zero it will get classified to the default FID of that cascade port.
Relying on a port default FID for upstream cascade ports results in
contradictions: a default FID of 0 breaks ATU isolation of bridged ports
on the downstream switch, a default FID of 1 breaks standalone ports on
the downstream switch.
So not only must standalone ports have different FIDs compared to
bridged ports, they must also have different DefaultVID values.
IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
bridges, and VID 4095 maps to FID 1.
For the xmit operation to look up the same ATU database, we need to put
VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
too. All shared ports are configured to map this VID to the bridging
FID, because they are members of that VLAN in the VTU. Shared ports
don't need to have 802.1QMode enabled in any way, they always parse the
VID from the DSA header, they don't need to look at the 802.1Q header.
We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
mention that mv88e6xxx_vtu_setup() which was located right below that
call was flushing the VTU so those entries wouldn't be preserved.
So we need to relocate the VTU flushing prior to the port initialization
during ->setup(). Also note that this is why it is safe to assume that
VID 4095 will get associated with FID 1: the user ports haven't been
created, so there is no avenue for the user to create a bridge VLAN
which could otherwise race with the creation of another FID which would
otherwise use up the non-reserved FID value of 1.
[ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
mv88e6xxx_port_db_load_purge() is the function to access the ATU for
FDB/MDB entries, and it used to determine the FID to use for
VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
But the driver only called mv88e6xxx_port_set_fid() once, during probe,
so no surprises, the port FID was always 0, the call to get_fid() was
redundant. As much as I would have wanted to not touch that code, the
logic is broken when we add a new FID which is not the port-based
default. Now the port-based default FID only corresponds to standalone
ports, and FDB/MDB entries belong to the bridging service. So while in
the future, when the DSA API will support FDB isolation, we will have to
figure out the FID based on the bridge number, for now there's a single
bridging FID, so hardcode that.
Lastly, the tagger needs to check, when it is transmitting a VLAN
untagged skb, whether it is sending it towards a bridged or a standalone
port. When we see it is bridged we assume the bridge is VLAN-unaware.
Not because it cannot be VLAN-aware but:
- if we are transmitting from a VLAN-aware bridge we are likely doing so
using TX forwarding offload. That code path guarantees that skbs have
a vlan hwaccel tag in them, so we would not enter the "else" branch
of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
- if we are transmitting on behalf of a VLAN-aware bridge but with no TX
forwarding offload (no PVT support, out of space in the PVT, whatever),
we would indeed be transmitting with VLAN 4095 instead of the bridge
device's pvid. However we would be injecting a "From CPU" frame, and
the switch won't learn from that - it only learns from "Forward" frames.
So it is inconsequential for address learning. And VLAN 4095 is
absolutely enough for the frame to exit the switch, since we never
remove that VLAN from any port.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-07 16:47:11 +00:00
|
|
|
err = mv88e6xxx_port_set_fid(chip, port, MV88E6XXX_FID_STANDALONE);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2016-02-26 18:16:04 +00:00
|
|
|
|
2017-03-30 21:37:12 +00:00
|
|
|
err = mv88e6xxx_port_vlan_map(chip, port);
|
2016-09-20 23:40:31 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2015-03-27 01:36:29 +00:00
|
|
|
|
|
|
|
/* Default VLAN ID and priority: don't set a default VLAN
|
|
|
|
* ID, and set the default packet priority to zero.
|
|
|
|
*/
|
2017-06-12 16:37:40 +00:00
|
|
|
return mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_DEFAULT_VLAN, 0);
|
2015-05-05 23:09:48 +00:00
|
|
|
}
|
|
|
|
|
2020-07-11 20:32:05 +00: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)
|
2021-09-26 17:41:26 +00:00
|
|
|
return 10240 - VLAN_ETH_HLEN - EDSA_HLEN - ETH_FCS_LEN;
|
2020-07-23 23:21:22 +00:00
|
|
|
else if (chip->info->ops->set_max_frame_size)
|
2021-09-26 17:41:26 +00:00
|
|
|
return 1632 - VLAN_ETH_HLEN - EDSA_HLEN - ETH_FCS_LEN;
|
net: dsa: mv88e6xxx: fix max_mtu of 1492 on 6165, 6191, 6220, 6250, 6290
There are 3 classes of switch families that the driver is aware of, as
far as mv88e6xxx_change_mtu() is concerned:
- MTU configuration is available per port. Here, the
chip->info->ops->port_set_jumbo_size() method will be present.
- MTU configuration is global to the switch. Here, the
chip->info->ops->set_max_frame_size() method will be present.
- We don't know how to change the MTU. Here, none of the above methods
will be present.
Switch families MV88E6165, MV88E6191, MV88E6220, MV88E6250 and MV88E6290
fall in category 3.
The blamed commit has adjusted the MTU for all 3 categories by EDSA_HLEN
(8 bytes), resulting in a new maximum MTU of 1492 being reported by the
driver for these switches.
I don't have the hardware to test, but I do have a MV88E6390 switch on
which I can simulate this by commenting out its .port_set_jumbo_size
definition from mv88e6390_ops. The result is this set of messages at
probe time:
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 1
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 2
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 3
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 4
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 5
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 6
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 7
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 8
It is highly implausible that there exist Ethernet switches which don't
support the standard MTU of 1500 octets, and this is what the DSA
framework says as well - the error comes from dsa_slave_create() ->
dsa_slave_change_mtu(slave_dev, ETH_DATA_LEN).
But the error messages are alarming, and it would be good to suppress
them.
As a consequence of this unlikeliness, we reimplement mv88e6xxx_get_max_mtu()
and mv88e6xxx_change_mtu() on switches from the 3rd category as follows:
the maximum supported MTU is 1500, and any request to set the MTU to a
value larger than that fails in dev_validate_mtu().
Fixes: b9c587fed61c ("dsa: mv88e6xxx: Include tagger overhead when setting MTU for DSA and CPU ports")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2023-03-14 18:24:05 +00:00
|
|
|
return ETH_DATA_LEN;
|
2020-07-11 20:32:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_change_mtu(struct dsa_switch *ds, int port, int new_mtu)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int ret = 0;
|
|
|
|
|
net: dsa: mv88e6xxx: fix max_mtu of 1492 on 6165, 6191, 6220, 6250, 6290
There are 3 classes of switch families that the driver is aware of, as
far as mv88e6xxx_change_mtu() is concerned:
- MTU configuration is available per port. Here, the
chip->info->ops->port_set_jumbo_size() method will be present.
- MTU configuration is global to the switch. Here, the
chip->info->ops->set_max_frame_size() method will be present.
- We don't know how to change the MTU. Here, none of the above methods
will be present.
Switch families MV88E6165, MV88E6191, MV88E6220, MV88E6250 and MV88E6290
fall in category 3.
The blamed commit has adjusted the MTU for all 3 categories by EDSA_HLEN
(8 bytes), resulting in a new maximum MTU of 1492 being reported by the
driver for these switches.
I don't have the hardware to test, but I do have a MV88E6390 switch on
which I can simulate this by commenting out its .port_set_jumbo_size
definition from mv88e6390_ops. The result is this set of messages at
probe time:
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 1
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 2
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 3
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 4
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 5
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 6
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 7
mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 8
It is highly implausible that there exist Ethernet switches which don't
support the standard MTU of 1500 octets, and this is what the DSA
framework says as well - the error comes from dsa_slave_create() ->
dsa_slave_change_mtu(slave_dev, ETH_DATA_LEN).
But the error messages are alarming, and it would be good to suppress
them.
As a consequence of this unlikeliness, we reimplement mv88e6xxx_get_max_mtu()
and mv88e6xxx_change_mtu() on switches from the 3rd category as follows:
the maximum supported MTU is 1500, and any request to set the MTU to a
value larger than that fails in dev_validate_mtu().
Fixes: b9c587fed61c ("dsa: mv88e6xxx: Include tagger overhead when setting MTU for DSA and CPU ports")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2023-03-14 18:24:05 +00:00
|
|
|
/* For families where we don't know how to alter the MTU,
|
|
|
|
* just accept any value up to ETH_DATA_LEN
|
|
|
|
*/
|
|
|
|
if (!chip->info->ops->port_set_jumbo_size &&
|
|
|
|
!chip->info->ops->set_max_frame_size) {
|
|
|
|
if (new_mtu > ETH_DATA_LEN)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-09-26 17:41:26 +00:00
|
|
|
if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port))
|
|
|
|
new_mtu += EDSA_HLEN;
|
|
|
|
|
2020-07-11 20:32:05 +00:00
|
|
|
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-23 23:21:22 +00:00
|
|
|
else if (chip->info->ops->set_max_frame_size)
|
|
|
|
ret = chip->info->ops->set_max_frame_size(chip, new_mtu);
|
2020-07-11 20:32:05 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-07-19 00:45:40 +00:00
|
|
|
static int mv88e6xxx_set_ageing_time(struct dsa_switch *ds,
|
|
|
|
unsigned int ageing_time)
|
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-07-19 00:45:40 +00:00
|
|
|
int err;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-03-11 21:12:48 +00: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-19 00:45:40 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-05-11 21:16:36 +00:00
|
|
|
static int mv88e6xxx_stats_setup(struct mv88e6xxx_chip *chip)
|
2015-03-27 01:36:28 +00:00
|
|
|
{
|
2016-05-09 17:22:49 +00:00
|
|
|
int err;
|
2015-05-05 23:09:47 +00:00
|
|
|
|
2016-11-21 22:27:01 +00:00
|
|
|
/* Initialize the statistics unit */
|
2018-05-11 21:16:36 +00:00
|
|
|
if (chip->info->ops->stats_set_histogram) {
|
|
|
|
err = chip->info->ops->stats_set_histogram(chip);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
2016-11-21 22:27:01 +00:00
|
|
|
|
2017-11-09 23:36:41 +00:00
|
|
|
return mv88e6xxx_g1_stats_clear(chip);
|
2016-07-19 00:45:30 +00:00
|
|
|
}
|
|
|
|
|
2019-01-08 23:24:03 +00: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 21:31:51 +00:00
|
|
|
err = mv88e6xxx_port_hidden_read(chip, 0xf, port, 0, &val);
|
2019-01-08 23:24:03 +00: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 21:31:51 +00:00
|
|
|
err = mv88e6xxx_port_hidden_write(chip, 0xf, port, 0, 0x01c0);
|
2019-01-08 23:24:03 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return mv88e6xxx_software_reset(chip);
|
|
|
|
}
|
|
|
|
|
2021-04-12 16:57:39 +00:00
|
|
|
/* prod_id for switch families which do not have a PHY model number */
|
|
|
|
static const u16 family_prod_id_table[] = {
|
|
|
|
[MV88E6XXX_FAMILY_6341] = MV88E6XXX_PORT_SWITCH_ID_PROD_6341,
|
|
|
|
[MV88E6XXX_FAMILY_6390] = MV88E6XXX_PORT_SWITCH_ID_PROD_6390,
|
2021-04-20 07:54:02 +00:00
|
|
|
[MV88E6XXX_FAMILY_6393] = MV88E6XXX_PORT_SWITCH_ID_PROD_6393X,
|
2021-04-12 16:57:39 +00:00
|
|
|
};
|
|
|
|
|
2016-08-15 21:19:00 +00:00
|
|
|
static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
|
2015-04-02 02:06:36 +00:00
|
|
|
{
|
2017-01-24 13:53:49 +00:00
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
|
|
|
|
struct mv88e6xxx_chip *chip = mdio_bus->chip;
|
2021-04-12 16:57:39 +00:00
|
|
|
u16 prod_id;
|
2016-08-15 21:19:00 +00:00
|
|
|
u16 val;
|
|
|
|
int err;
|
2015-04-02 02:06:36 +00:00
|
|
|
|
2017-01-24 13:53:48 +00:00
|
|
|
if (!chip->info->ops->phy_read)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-01-24 13:53:48 +00: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 21:19:00 +00:00
|
|
|
|
2021-04-12 16:57:39 +00:00
|
|
|
/* Some internal PHYs don't have a model number. */
|
|
|
|
if (reg == MII_PHYSID2 && !(val & 0x3f0) &&
|
|
|
|
chip->info->family < ARRAY_SIZE(family_prod_id_table)) {
|
|
|
|
prod_id = family_prod_id_table[chip->info->family];
|
|
|
|
if (prod_id)
|
|
|
|
val |= prod_id >> 4;
|
2017-02-01 02:40:05 +00:00
|
|
|
}
|
|
|
|
|
2016-08-15 21:19:00 +00:00
|
|
|
return err ? err : val;
|
2015-04-02 02:06:36 +00:00
|
|
|
}
|
|
|
|
|
2023-01-09 15:30:51 +00:00
|
|
|
static int mv88e6xxx_mdio_read_c45(struct mii_bus *bus, int phy, int devad,
|
|
|
|
int reg)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
|
|
|
|
struct mv88e6xxx_chip *chip = mdio_bus->chip;
|
|
|
|
u16 val;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!chip->info->ops->phy_read_c45)
|
2024-02-04 23:14:15 +00:00
|
|
|
return -ENODEV;
|
2023-01-09 15:30:51 +00:00
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
err = chip->info->ops->phy_read_c45(chip, bus, phy, devad, reg, &val);
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
return err ? err : val;
|
|
|
|
}
|
|
|
|
|
2016-08-15 21:19:00 +00:00
|
|
|
static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
|
2015-04-02 02:06:36 +00:00
|
|
|
{
|
2017-01-24 13:53:49 +00:00
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
|
|
|
|
struct mv88e6xxx_chip *chip = mdio_bus->chip;
|
2016-08-15 21:19:00 +00:00
|
|
|
int err;
|
2015-04-02 02:06:36 +00:00
|
|
|
|
2017-01-24 13:53:48 +00:00
|
|
|
if (!chip->info->ops->phy_write)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-01-24 13:53:48 +00: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 21:19:00 +00:00
|
|
|
|
|
|
|
return err;
|
2015-04-02 02:06:36 +00:00
|
|
|
}
|
|
|
|
|
2023-01-09 15:30:51 +00:00
|
|
|
static int mv88e6xxx_mdio_write_c45(struct mii_bus *bus, int phy, int devad,
|
|
|
|
int reg, u16 val)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
|
|
|
|
struct mv88e6xxx_chip *chip = mdio_bus->chip;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!chip->info->ops->phy_write_c45)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
err = chip->info->ops->phy_write_c45(chip, bus, phy, devad, reg, val);
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip *chip,
|
2017-01-24 13:53:50 +00:00
|
|
|
struct device_node *np,
|
|
|
|
bool external)
|
2016-06-04 19:17:06 +00:00
|
|
|
{
|
|
|
|
static int index;
|
2017-01-24 13:53:49 +00:00
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus;
|
2016-06-04 19:17:06 +00:00
|
|
|
struct mii_bus *bus;
|
|
|
|
int err;
|
|
|
|
|
2018-02-22 00:51:49 +00:00
|
|
|
if (external) {
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2024-02-27 17:54:22 +00:00
|
|
|
if (chip->info->family == MV88E6XXX_FAMILY_6393)
|
|
|
|
err = mv88e6393x_g2_scratch_gpio_set_smi(chip, true);
|
|
|
|
else
|
|
|
|
err = mv88e6390_g2_scratch_gpio_set_smi(chip, true);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-02-22 00:51:49 +00:00
|
|
|
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2022-02-07 16:15:47 +00:00
|
|
|
bus = mdiobus_alloc_size(sizeof(*mdio_bus));
|
2016-06-04 19:17:06 +00:00
|
|
|
if (!bus)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2017-01-24 13:53:49 +00:00
|
|
|
mdio_bus = bus->priv;
|
2017-01-24 13:53:50 +00:00
|
|
|
mdio_bus->bus = bus;
|
2017-01-24 13:53:49 +00:00
|
|
|
mdio_bus->chip = chip;
|
2017-01-24 13:53:50 +00:00
|
|
|
INIT_LIST_HEAD(&mdio_bus->list);
|
|
|
|
mdio_bus->external = external;
|
2017-01-24 13:53:49 +00:00
|
|
|
|
2016-06-04 19:17:06 +00:00
|
|
|
if (np) {
|
|
|
|
bus->name = np->full_name;
|
2017-07-18 21:43:19 +00:00
|
|
|
snprintf(bus->id, MII_BUS_ID_SIZE, "%pOF", np);
|
2016-06-04 19:17:06 +00: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;
|
2023-01-09 15:30:51 +00:00
|
|
|
bus->read_c45 = mv88e6xxx_mdio_read_c45;
|
|
|
|
bus->write_c45 = mv88e6xxx_mdio_write_c45;
|
2016-06-21 16:28:20 +00:00
|
|
|
bus->parent = chip->dev;
|
2023-03-19 14:02:38 +00:00
|
|
|
bus->phy_mask = ~GENMASK(chip->info->phy_base_addr +
|
|
|
|
mv88e6xxx_num_ports(chip) - 1,
|
|
|
|
chip->info->phy_base_addr);
|
2016-06-04 19:17:06 +00:00
|
|
|
|
2018-03-17 19:32:05 +00:00
|
|
|
if (!external) {
|
|
|
|
err = mv88e6xxx_g2_irq_mdio_setup(chip, bus);
|
|
|
|
if (err)
|
2022-02-07 16:15:47 +00:00
|
|
|
goto out;
|
2018-03-17 19:32:05 +00:00
|
|
|
}
|
|
|
|
|
2018-05-15 23:56:19 +00:00
|
|
|
err = of_mdiobus_register(bus, np);
|
2016-06-04 19:17:06 +00:00
|
|
|
if (err) {
|
2016-06-21 16:28:20 +00:00
|
|
|
dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
|
2018-03-17 19:32:05 +00:00
|
|
|
mv88e6xxx_g2_irq_mdio_free(chip, bus);
|
2022-02-07 16:15:47 +00:00
|
|
|
goto out;
|
2016-06-04 19:17:06 +00:00
|
|
|
}
|
2017-01-24 13:53:50 +00:00
|
|
|
|
|
|
|
if (external)
|
|
|
|
list_add_tail(&mdio_bus->list, &chip->mdios);
|
|
|
|
else
|
|
|
|
list_add(&mdio_bus->list, &chip->mdios);
|
2016-06-04 19:17:06 +00:00
|
|
|
|
|
|
|
return 0;
|
2022-02-07 16:15:47 +00:00
|
|
|
|
|
|
|
out:
|
|
|
|
mdiobus_free(bus);
|
|
|
|
return err;
|
2017-01-24 13:53:50 +00:00
|
|
|
}
|
2016-06-04 19:17:06 +00:00
|
|
|
|
2017-12-07 00:05:57 +00:00
|
|
|
static void mv88e6xxx_mdios_unregister(struct mv88e6xxx_chip *chip)
|
|
|
|
|
|
|
|
{
|
2022-02-10 17:40:17 +00:00
|
|
|
struct mv88e6xxx_mdio_bus *mdio_bus, *p;
|
2017-12-07 00:05:57 +00:00
|
|
|
struct mii_bus *bus;
|
|
|
|
|
2022-02-10 17:40:17 +00:00
|
|
|
list_for_each_entry_safe(mdio_bus, p, &chip->mdios, list) {
|
2017-12-07 00:05:57 +00:00
|
|
|
bus = mdio_bus->bus;
|
|
|
|
|
2018-03-17 19:32:05 +00:00
|
|
|
if (!mdio_bus->external)
|
|
|
|
mv88e6xxx_g2_irq_mdio_free(chip, bus);
|
|
|
|
|
2017-12-07 00:05:57 +00:00
|
|
|
mdiobus_unregister(bus);
|
2022-02-07 16:15:47 +00:00
|
|
|
mdiobus_free(bus);
|
2017-12-07 00:05:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-03-15 16:38:45 +00:00
|
|
|
static int mv88e6xxx_mdios_register(struct mv88e6xxx_chip *chip)
|
2017-01-24 13:53:50 +00:00
|
|
|
{
|
2023-03-15 16:38:45 +00:00
|
|
|
struct device_node *np = chip->dev->of_node;
|
2017-01-24 13:53:50 +00:00
|
|
|
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);
|
2022-05-26 14:52:08 +00:00
|
|
|
of_node_put(child);
|
2017-01-24 13:53:50 +00:00
|
|
|
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 02:32:57 +00:00
|
|
|
if (of_device_is_compatible(
|
|
|
|
child, "marvell,mv88e6xxx-mdio-external")) {
|
2017-01-24 13:53:50 +00:00
|
|
|
err = mv88e6xxx_mdio_register(chip, child, true);
|
2017-12-07 00:05:57 +00:00
|
|
|
if (err) {
|
|
|
|
mv88e6xxx_mdios_unregister(chip);
|
2019-07-23 10:43:07 +00:00
|
|
|
of_node_put(child);
|
2017-01-24 13:53:50 +00:00
|
|
|
return err;
|
2017-12-07 00:05:57 +00:00
|
|
|
}
|
2017-01-24 13:53:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2016-06-04 19:17:06 +00:00
|
|
|
}
|
|
|
|
|
2023-03-15 16:38:44 +00:00
|
|
|
static void mv88e6xxx_teardown(struct dsa_switch *ds)
|
|
|
|
{
|
2023-03-15 16:38:45 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
2023-03-15 16:38:44 +00:00
|
|
|
mv88e6xxx_teardown_devlink_params(ds);
|
|
|
|
dsa_devlink_resources_unregister(ds);
|
|
|
|
mv88e6xxx_teardown_devlink_regions_global(ds);
|
2023-03-15 16:38:45 +00:00
|
|
|
mv88e6xxx_mdios_unregister(chip);
|
2023-03-15 16:38:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_setup(struct dsa_switch *ds)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
u8 cmode;
|
|
|
|
int err;
|
|
|
|
int i;
|
|
|
|
|
2023-03-15 16:38:45 +00:00
|
|
|
err = mv88e6xxx_mdios_register(chip);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2023-03-15 16:38:44 +00:00
|
|
|
chip->ds = ds;
|
2023-10-23 18:17:28 +00:00
|
|
|
ds->user_mii_bus = mv88e6xxx_default_mdio_bus(chip);
|
2023-03-15 16:38:44 +00:00
|
|
|
|
|
|
|
/* Since virtual bridges are mapped in the PVT, the number we support
|
|
|
|
* depends on the physical switch topology. We need to let DSA figure
|
|
|
|
* that out and therefore we cannot set this at dsa_register_switch()
|
|
|
|
* time.
|
|
|
|
*/
|
|
|
|
if (mv88e6xxx_has_pvt(chip))
|
|
|
|
ds->max_num_bridges = MV88E6XXX_MAX_PVT_SWITCHES -
|
|
|
|
ds->dst->last_switch - 1;
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
if (chip->info->ops->setup_errata) {
|
|
|
|
err = chip->info->ops->setup_errata(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
chip->ports[i].cmode = cmode;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
err = mv88e6xxx_vtu_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
/* Must be called after mv88e6xxx_vtu_setup (which flushes the
|
|
|
|
* VTU, thereby also flushing the STU).
|
|
|
|
*/
|
|
|
|
err = mv88e6xxx_stu_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
/* Setup Switch Port Registers */
|
|
|
|
for (i = 0; i < mv88e6xxx_num_ports(chip); i++) {
|
|
|
|
if (dsa_is_unused_port(ds, i))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Prevent the use of an invalid port. */
|
|
|
|
if (mv88e6xxx_is_invalid_port(chip, i)) {
|
|
|
|
dev_err(chip->dev, "port %d is invalid\n", i);
|
|
|
|
err = -EINVAL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = mv88e6xxx_setup_port(chip, i);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = mv88e6xxx_irl_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_mac_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_phy_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_pvt_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_atu_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_broadcast_setup(chip, 0);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_pot_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_rmu_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_rsvd2cpu_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_trunk_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_devmap_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_pri_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
/* Setup PTP Hardware Clock and timestamping */
|
|
|
|
if (chip->info->ptp_support) {
|
|
|
|
err = mv88e6xxx_ptp_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
err = mv88e6xxx_hwtstamp_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = mv88e6xxx_stats_setup(chip);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
if (err)
|
2023-03-15 16:38:45 +00:00
|
|
|
goto out_mdios;
|
2023-03-15 16:38:44 +00:00
|
|
|
|
|
|
|
/* 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.
|
|
|
|
*/
|
|
|
|
err = mv88e6xxx_setup_devlink_resources(ds);
|
|
|
|
if (err)
|
2023-03-15 16:38:45 +00:00
|
|
|
goto out_mdios;
|
2023-03-15 16:38:44 +00:00
|
|
|
|
|
|
|
err = mv88e6xxx_setup_devlink_params(ds);
|
|
|
|
if (err)
|
|
|
|
goto out_resources;
|
|
|
|
|
|
|
|
err = mv88e6xxx_setup_devlink_regions_global(ds);
|
|
|
|
if (err)
|
|
|
|
goto out_params;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_params:
|
|
|
|
mv88e6xxx_teardown_devlink_params(ds);
|
|
|
|
out_resources:
|
|
|
|
dsa_devlink_resources_unregister(ds);
|
2023-03-15 16:38:45 +00:00
|
|
|
out_mdios:
|
|
|
|
mv88e6xxx_mdios_unregister(chip);
|
2023-03-15 16:38:44 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_setup(struct dsa_switch *ds, int port)
|
|
|
|
{
|
2023-07-13 08:42:33 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err;
|
|
|
|
|
2023-11-24 04:15:29 +00:00
|
|
|
if (chip->info->ops->pcs_ops &&
|
|
|
|
chip->info->ops->pcs_ops->pcs_init) {
|
2023-07-13 08:42:33 +00:00
|
|
|
err = chip->info->ops->pcs_ops->pcs_init(chip, port);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2023-03-15 16:38:44 +00:00
|
|
|
return mv88e6xxx_setup_devlink_regions_port(ds, port);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6xxx_port_teardown(struct dsa_switch *ds, int port)
|
|
|
|
{
|
2023-07-13 08:42:33 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
|
2023-03-15 16:38:44 +00:00
|
|
|
mv88e6xxx_teardown_devlink_regions_port(ds, port);
|
2023-07-13 08:42:33 +00:00
|
|
|
|
2023-11-24 04:15:29 +00:00
|
|
|
if (chip->info->ops->pcs_ops &&
|
|
|
|
chip->info->ops->pcs_ops->pcs_teardown)
|
2023-07-13 08:42:33 +00:00
|
|
|
chip->info->ops->pcs_ops->pcs_teardown(chip, port);
|
2023-03-15 16:38:44 +00:00
|
|
|
}
|
|
|
|
|
2016-07-20 22:18:35 +00:00
|
|
|
static int mv88e6xxx_get_eeprom_len(struct dsa_switch *ds)
|
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-07-20 22:18:35 +00:00
|
|
|
|
|
|
|
return chip->eeprom_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_get_eeprom(struct dsa_switch *ds,
|
|
|
|
struct ethtool_eeprom *eeprom, u8 *data)
|
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-07-20 22:18:35 +00:00
|
|
|
int err;
|
|
|
|
|
2016-09-29 16:22:02 +00:00
|
|
|
if (!chip->info->ops->get_eeprom)
|
|
|
|
return -EOPNOTSUPP;
|
2016-07-20 22:18:35 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-09-29 16:22:02 +00: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 22:18:35 +00: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 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-07-20 22:18:35 +00:00
|
|
|
int err;
|
|
|
|
|
2016-09-29 16:22:02 +00:00
|
|
|
if (!chip->info->ops->set_eeprom)
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2016-07-20 22:18:35 +00:00
|
|
|
if (eeprom->magic != 0xc3ec4951)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-09-29 16:22:02 +00: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 22:18:35 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2016-09-29 16:22:00 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6085_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6097 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
|
2017-05-26 22:03:06 +00:00
|
|
|
.phy_read = mv88e6185_phy_ppu_read,
|
|
|
|
.phy_write = mv88e6185_phy_ppu_write,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2022-11-10 09:10:27 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:28 +00:00
|
|
|
.ppu_enable = mv88e6185_g1_ppu_enable,
|
|
|
|
.ppu_disable = mv88e6185_g1_ppu_disable,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6185_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6085_g1_rmu_disable,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6185_phylink_get_caps,
|
2020-07-23 23:21:22 +00:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6095_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6095 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
|
2017-05-26 22:03:06 +00:00
|
|
|
.phy_read = mv88e6185_phy_ppu_read,
|
|
|
|
.phy_write = mv88e6185_phy_ppu_write,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6185_port_set_forward_unknown,
|
|
|
|
.port_set_mcast_flood = mv88e6185_port_set_default_forward,
|
2017-02-04 19:15:28 +00:00
|
|
|
.port_set_upstream_port = mv88e6095_port_set_upstream_port,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
|
2016-12-05 22:30:28 +00:00
|
|
|
.ppu_enable = mv88e6185_g1_ppu_enable,
|
|
|
|
.ppu_disable = mv88e6185_g1_ppu_disable,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6185_g1_reset,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2022-02-13 18:51:54 +00:00
|
|
|
.phylink_get_caps = mv88e6095_phylink_get_caps,
|
2023-07-13 08:42:43 +00:00
|
|
|
.pcs_ops = &mv88e6185_pcs_ops,
|
2020-07-23 23:21:22 +00:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
2016-11-22 16:47:21 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6097_ops = {
|
2016-11-25 08:41:30 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6097 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-11-22 16:47:21 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-22 16:47:21 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2022-02-03 10:16:55 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6095_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-22 16:47:21 +00:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-22 16:47:21 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-14 10:29:30 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2020-11-24 04:34:39 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6085_g1_rmu_disable,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-02-13 18:51:54 +00:00
|
|
|
.phylink_get_caps = mv88e6095_phylink_get_caps,
|
2023-07-13 08:42:43 +00:00
|
|
|
.pcs_ops = &mv88e6185_pcs_ops,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2020-07-23 23:21:22 +00:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-11-22 16:47:21 +00:00
|
|
|
};
|
|
|
|
|
2016-09-29 16:22:00 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6123_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6165 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2017-06-02 21:22:46 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6185_phylink_get_caps,
|
2020-07-23 23:21:22 +00:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6131_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6185 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
|
2017-05-26 22:03:06 +00:00
|
|
|
.phy_read = mv88e6185_phy_ppu_read,
|
|
|
|
.phy_write = mv88e6185_phy_ppu_write,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6185_port_set_forward_unknown,
|
|
|
|
.port_set_mcast_flood = mv88e6185_port_set_default_forward,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-02-04 19:15:28 +00:00
|
|
|
.port_set_upstream_port = mv88e6095_port_set_upstream_port,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2018-08-09 13:38:37 +00:00
|
|
|
.port_set_pause = mv88e6185_port_set_pause,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
|
2016-12-05 22:30:28 +00:00
|
|
|
.ppu_enable = mv88e6185_g1_ppu_enable,
|
2018-05-09 15:38:49 +00:00
|
|
|
.set_cascade_port = mv88e6185_g1_set_cascade_port,
|
2016-12-05 22:30:28 +00:00
|
|
|
.ppu_disable = mv88e6185_g1_ppu_disable,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6185_g1_reset,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6185_phylink_get_caps,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
2017-03-28 17:50:32 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6141_ops = {
|
|
|
|
/* MV88E6XXX_FAMILY_6341 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2017-03-28 17:50:32 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2017-03-28 17:50:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2017-03-28 17:50:32 +00: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 00:21:27 +00:00
|
|
|
.port_max_speed_mode = mv88e6341_port_max_speed_mode,
|
2017-03-28 17:50:32 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2021-06-30 22:22:26 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2017-03-28 17:50:32 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2017-03-28 17:50:32 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2017-03-28 17:50:32 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-28 17:50:32 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-08-26 21:31:55 +00:00
|
|
|
.port_set_cmode = mv88e6341_port_set_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2017-03-28 17:50:32 +00:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2021-06-30 22:22:27 +00:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2017-03-28 17:50:32 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-03-28 17:50:32 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2017-03-28 17:50:32 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2021-06-30 22:22:28 +00:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2021-06-30 22:22:29 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2019-08-26 21:31:53 +00:00
|
|
|
.serdes_get_lane = mv88e6341_serdes_get_lane,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2021-06-30 22:22:30 +00:00
|
|
|
.serdes_get_sset_count = mv88e6390_serdes_get_sset_count,
|
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2021-06-30 22:22:31 +00:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6341_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6390_pcs_ops,
|
2017-03-28 17:50:32 +00:00
|
|
|
};
|
|
|
|
|
2016-09-29 16:22:00 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6161_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6165 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2022-11-10 09:10:27 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2019-03-01 22:43:39 +00:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2018-07-18 20:38:21 +00:00
|
|
|
.avb_ops = &mv88e6165_avb_ops,
|
2018-07-18 20:38:22 +00:00
|
|
|
.ptp_ops = &mv88e6165_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6185_phylink_get_caps,
|
2021-09-26 17:41:24 +00:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6165_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6165 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2017-01-24 13:53:47 +00:00
|
|
|
.phy_read = mv88e6165_phy_read,
|
|
|
|
.phy_write = mv88e6165_phy_write,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2018-07-18 20:38:21 +00:00
|
|
|
.avb_ops = &mv88e6165_avb_ops,
|
2018-07-18 20:38:22 +00:00
|
|
|
.ptp_ops = &mv88e6165_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6185_phylink_get_caps,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6171_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6351 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-10 14:44:01 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2023-11-24 04:15:28 +00:00
|
|
|
.phylink_get_caps = mv88e6351_phylink_get_caps,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6172_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6352 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:02 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-04 02:23:34 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6352_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2020-02-16 17:54:14 +00:00
|
|
|
.serdes_get_regs_len = mv88e6352_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6352_serdes_get_regs,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6352_phylink_get_caps,
|
2023-07-13 08:42:48 +00:00
|
|
|
.pcs_ops = &mv88e6352_pcs_ops,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6175_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6351 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-10 14:44:01 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2023-11-24 04:15:28 +00:00
|
|
|
.phylink_get_caps = mv88e6351_phylink_get_caps,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6176_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6352 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:02 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-04 02:23:34 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6352_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6352_serdes_irq_mapping,
|
2020-02-16 17:54:14 +00:00
|
|
|
.serdes_get_regs_len = mv88e6352_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6352_serdes_get_regs,
|
2022-02-10 17:48:23 +00:00
|
|
|
.serdes_set_tx_amplitude = mv88e6352_serdes_set_tx_amplitude,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6352_phylink_get_caps,
|
2023-07-13 08:42:48 +00:00
|
|
|
.pcs_ops = &mv88e6352_pcs_ops,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6185_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6185 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
|
2017-05-26 22:03:06 +00:00
|
|
|
.phy_read = mv88e6185_phy_ppu_read,
|
|
|
|
.phy_write = mv88e6185_phy_ppu_write,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6185_port_set_forward_unknown,
|
|
|
|
.port_set_mcast_flood = mv88e6185_port_set_default_forward,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6095_port_egress_rate_limiting,
|
2017-02-04 19:15:28 +00:00
|
|
|
.port_set_upstream_port = mv88e6095_port_set_upstream_port,
|
2018-08-09 13:38:37 +00:00
|
|
|
.port_set_pause = mv88e6185_port_set_pause,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6185_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6xxx_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6185_g2_mgmt_rsvd2cpu,
|
2018-05-09 15:38:49 +00:00
|
|
|
.set_cascade_port = mv88e6185_g1_set_cascade_port,
|
2016-12-05 22:30:28 +00:00
|
|
|
.ppu_enable = mv88e6185_g1_ppu_enable,
|
|
|
|
.ppu_disable = mv88e6185_g1_ppu_disable,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6185_g1_reset,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6185_phylink_get_caps,
|
2023-07-13 08:42:43 +00:00
|
|
|
.pcs_ops = &mv88e6185_pcs_ops,
|
2020-07-23 23:21:22 +00:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
2016-11-21 22:26:57 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6190_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-08 23:24:03 +00:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 23:07:16 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 22:26:57 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 22:26:57 +00: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 00:21:27 +00:00
|
|
|
.port_max_speed_mode = mv88e6390_port_max_speed_mode,
|
2016-12-03 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2020-07-23 23:21:21 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-10 23:32:15 +00:00
|
|
|
.port_set_cmode = mv88e6390_port_set_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:27:00 +00:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 22:27:01 +00:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-08 23:03:43 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 03:45:16 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:27 +00:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6390_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6390_g1_stu_loadpurge,
|
2019-08-26 21:31:52 +00:00
|
|
|
.serdes_get_lane = mv88e6390_serdes_get_lane,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2020-01-18 18:40:56 +00:00
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 17:54:15 +00:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6390_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6390_pcs_ops,
|
2016-11-21 22:26:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6190x_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-08 23:24:03 +00:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 23:07:16 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 22:26:57 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 22:26:57 +00: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 00:21:27 +00:00
|
|
|
.port_max_speed_mode = mv88e6390x_port_max_speed_mode,
|
2016-12-03 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2020-07-23 23:21:21 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-10 23:32:15 +00:00
|
|
|
.port_set_cmode = mv88e6390x_port_set_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:27:00 +00:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 22:27:01 +00:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-08 23:03:43 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 03:45:16 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:27 +00:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6390_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6390_g1_stu_loadpurge,
|
2019-08-26 21:31:52 +00:00
|
|
|
.serdes_get_lane = mv88e6390x_serdes_get_lane,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2020-01-18 18:40:56 +00:00
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 17:54:15 +00:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6390x_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6390_pcs_ops,
|
2016-11-21 22:26:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6191_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-08 23:24:03 +00:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 23:07:16 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 22:26:57 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 22:26:57 +00: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 00:21:27 +00:00
|
|
|
.port_max_speed_mode = mv88e6390_port_max_speed_mode,
|
2016-12-03 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-10 23:32:15 +00:00
|
|
|
.port_set_cmode = mv88e6390_port_set_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:27:00 +00:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 22:27:01 +00:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-08 23:03:43 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 03:45:16 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:27 +00:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6390_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6390_g1_stu_loadpurge,
|
2019-08-26 21:31:52 +00:00
|
|
|
.serdes_get_lane = mv88e6390_serdes_get_lane,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2020-01-18 18:40:56 +00:00
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 17:54:15 +00:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-07-18 20:38:20 +00:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6390_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6390_pcs_ops,
|
2016-11-21 22:26:57 +00:00
|
|
|
};
|
|
|
|
|
2016-09-29 16:22:00 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6240_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6352 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:02 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-04 02:23:34 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6352_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6352_serdes_irq_mapping,
|
2020-02-16 17:54:14 +00:00
|
|
|
.serdes_get_regs_len = mv88e6352_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6352_serdes_get_regs,
|
2022-02-10 17:48:23 +00:00
|
|
|
.serdes_set_tx_amplitude = mv88e6352_serdes_set_tx_amplitude,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 20:38:20 +00:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6352_phylink_get_caps,
|
2023-07-13 08:42:48 +00:00
|
|
|
.pcs_ops = &mv88e6352_pcs_ops,
|
2016-09-29 16:22:00 +00: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,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
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_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00: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 15:15:56 +00: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,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6250_stats_get_stat,
|
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
|
|
|
.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 15:04:48 +00:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2021-01-25 15:04:49 +00:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2019-07-31 08:23:51 +00:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
|
|
|
.ptp_ops = &mv88e6250_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6250_phylink_get_caps,
|
2023-05-30 08:39:14 +00:00
|
|
|
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
|
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
|
|
|
};
|
|
|
|
|
2016-11-21 22:26:57 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6290_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-08 23:24:03 +00:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 23:07:16 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 22:26:57 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 22:26:57 +00: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 00:21:27 +00:00
|
|
|
.port_max_speed_mode = mv88e6390_port_max_speed_mode,
|
2016-12-03 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-10 23:32:15 +00:00
|
|
|
.port_set_cmode = mv88e6390_port_set_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:27:00 +00:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 22:27:01 +00:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-08 23:03:43 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 03:45:16 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:27 +00:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6390_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6390_g1_stu_loadpurge,
|
2019-08-26 21:31:52 +00:00
|
|
|
.serdes_get_lane = mv88e6390_serdes_get_lane,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2020-01-18 18:40:56 +00:00
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2020-02-16 17:54:15 +00:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
2023-01-13 15:12:58 +00:00
|
|
|
.ptp_ops = &mv88e6390_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6390_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6390_pcs_ops,
|
2016-11-21 22:26:57 +00:00
|
|
|
};
|
|
|
|
|
2016-09-29 16:22:00 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6320_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6320 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:02 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2022-10-28 16:31:58 +00:00
|
|
|
.port_set_rgmii_delay = mv88e6320_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6320_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2018-12-19 17:28:54 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 20:38:20 +00:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6185_phylink_get_caps,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6321_ops = {
|
2017-07-17 17:03:37 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6320 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:02 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2022-10-28 16:31:58 +00:00
|
|
|
.port_set_rgmii_delay = mv88e6320_port_set_rgmii_delay,
|
2020-03-14 10:15:53 +00:00
|
|
|
.port_set_speed_duplex = mv88e6185_port_set_speed_duplex,
|
2016-12-03 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6320_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2018-12-19 17:28:54 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2023-04-26 20:28:15 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6185_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 20:38:20 +00:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6185_phylink_get_caps,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
2017-03-28 17:50:33 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6341_ops = {
|
|
|
|
/* MV88E6XXX_FAMILY_6341 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2017-03-28 17:50:33 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2017-03-28 17:50:33 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2017-03-28 17:50:33 +00: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 00:21:27 +00:00
|
|
|
.port_max_speed_mode = mv88e6341_port_max_speed_mode,
|
2017-03-28 17:50:33 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2021-06-30 22:22:26 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2017-03-28 17:50:33 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2017-03-28 17:50:33 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2017-03-28 17:50:33 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-28 17:50:33 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-08-26 21:31:55 +00:00
|
|
|
.port_set_cmode = mv88e6341_port_set_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2017-03-28 17:50:33 +00:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2021-06-30 22:22:27 +00:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2017-03-28 17:50:33 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-03-28 17:50:33 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2017-03-28 17:50:33 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2021-06-30 22:22:28 +00:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2021-06-30 22:22:29 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2019-08-26 21:31:53 +00:00
|
|
|
.serdes_get_lane = mv88e6341_serdes_get_lane,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
2018-07-18 20:38:20 +00:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2021-06-30 22:22:30 +00:00
|
|
|
.serdes_get_sset_count = mv88e6390_serdes_get_sset_count,
|
|
|
|
.serdes_get_strings = mv88e6390_serdes_get_strings,
|
|
|
|
.serdes_get_stats = mv88e6390_serdes_get_stats,
|
2021-06-30 22:22:31 +00:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6341_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6390_pcs_ops,
|
2017-03-28 17:50:33 +00:00
|
|
|
};
|
|
|
|
|
2016-09-29 16:22:00 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6350_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6351 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-10 14:44:01 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2023-11-24 04:15:28 +00:00
|
|
|
.phylink_get_caps = mv88e6351_phylink_get_caps,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6351_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6351 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-10 14:44:01 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
2022-03-19 11:03:45 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 20:38:20 +00:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2023-11-24 04:15:28 +00:00
|
|
|
.phylink_get_caps = mv88e6351_phylink_get_caps,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6352_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6352 */
|
2018-05-11 21:16:35 +00:00
|
|
|
.ieee_pri_map = mv88e6085_g1_ieee_pri_map,
|
|
|
|
.ip_pri_map = mv88e6085_g1_ip_pri_map,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6352_g2_irl_init_all,
|
2016-09-29 16:22:02 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
|
2016-09-29 16:22:01 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-04 02:23:32 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-04 02:23:34 +00: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 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6095_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6097_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:26:58 +00:00
|
|
|
.stats_snapshot = mv88e6320_g1_stats_snapshot,
|
2017-11-09 23:36:41 +00:00
|
|
|
.stats_set_histogram = mv88e6095_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6095_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6095_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6095_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6095_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6095_g1_set_egress_port,
|
2017-02-08 23:03:42 +00:00
|
|
|
.watchdog_ops = &mv88e6097_watchdog_ops,
|
2017-07-17 17:03:41 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6352_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:22 +00:00
|
|
|
.vtu_getnext = mv88e6352_g1_vtu_getnext,
|
2017-05-01 18:05:23 +00:00
|
|
|
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.stu_getnext = mv88e6352_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6352_serdes_irq_mapping,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6352_avb_ops,
|
2018-07-18 20:38:20 +00:00
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2018-03-01 01:02:31 +00: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 17:54:14 +00:00
|
|
|
.serdes_get_regs_len = mv88e6352_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6352_serdes_get_regs,
|
2022-02-10 17:48:23 +00:00
|
|
|
.serdes_set_tx_amplitude = mv88e6352_serdes_set_tx_amplitude,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6352_phylink_get_caps,
|
2023-07-13 08:42:48 +00:00
|
|
|
.pcs_ops = &mv88e6352_pcs_ops,
|
2016-09-29 16:22:00 +00:00
|
|
|
};
|
|
|
|
|
2016-11-21 22:26:57 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6390_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-08 23:24:03 +00:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 23:07:16 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 22:26:57 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 22:26:57 +00: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 00:21:27 +00:00
|
|
|
.port_max_speed_mode = mv88e6390_port_max_speed_mode,
|
2016-12-03 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-10 23:32:15 +00:00
|
|
|
.port_set_cmode = mv88e6390_port_set_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:27:00 +00:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 22:27:01 +00:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-08 23:03:43 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 03:45:16 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:27 +00:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.stu_getnext = mv88e6390_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6390_g1_stu_loadpurge,
|
2019-08-26 21:31:52 +00:00
|
|
|
.serdes_get_lane = mv88e6390_serdes_get_lane,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
2023-01-13 15:12:58 +00:00
|
|
|
.ptp_ops = &mv88e6390_ptp_ops,
|
2019-12-25 05:22:38 +00: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 17:54:15 +00:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6390_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6390_pcs_ops,
|
2016-11-21 22:26:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct mv88e6xxx_ops mv88e6390x_ops = {
|
2016-11-21 22:26:59 +00:00
|
|
|
/* MV88E6XXX_FAMILY_6390 */
|
2019-01-08 23:24:03 +00:00
|
|
|
.setup_errata = mv88e6390_setup_errata,
|
2017-06-19 14:55:36 +00:00
|
|
|
.irl_init_all = mv88e6390_g2_irl_init_all,
|
2017-01-12 23:07:16 +00:00
|
|
|
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
|
|
|
|
.set_eeprom = mv88e6xxx_g2_set_eeprom8,
|
2016-11-21 22:26:57 +00:00
|
|
|
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_set_link = mv88e6xxx_port_set_link,
|
2020-11-24 04:34:37 +00:00
|
|
|
.port_sync_link = mv88e6xxx_port_sync_link,
|
2016-11-21 22:26:57 +00: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 00:21:27 +00:00
|
|
|
.port_max_speed_mode = mv88e6390x_port_max_speed_mode,
|
2016-12-03 03:35:16 +00:00
|
|
|
.port_tag_remap = mv88e6390_port_tag_remap,
|
2019-09-07 20:00:48 +00:00
|
|
|
.port_set_policy = mv88e6352_port_set_policy,
|
2016-12-03 03:35:19 +00: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 15:15:56 +00:00
|
|
|
.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
|
|
|
|
.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
|
2016-12-03 03:35:19 +00:00
|
|
|
.port_set_ether_type = mv88e6351_port_set_ether_type,
|
2017-06-08 22:34:13 +00:00
|
|
|
.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
|
2016-12-03 03:45:18 +00:00
|
|
|
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
|
2017-06-08 22:34:12 +00:00
|
|
|
.port_pause_limit = mv88e6390_port_pause_limit,
|
2017-03-11 21:13:01 +00:00
|
|
|
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
|
2017-03-11 21:13:02 +00:00
|
|
|
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
|
2018-08-09 13:38:45 +00:00
|
|
|
.port_get_cmode = mv88e6352_port_get_cmode,
|
2018-11-10 23:32:14 +00:00
|
|
|
.port_set_cmode = mv88e6390x_port_set_cmode,
|
2019-07-31 08:23:49 +00:00
|
|
|
.port_setup_message_port = mv88e6xxx_setup_message_port,
|
2016-11-21 22:27:00 +00:00
|
|
|
.stats_snapshot = mv88e6390_g1_stats_snapshot,
|
2016-11-21 22:27:01 +00:00
|
|
|
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
|
2016-11-21 22:27:02 +00:00
|
|
|
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
|
|
|
|
.stats_get_strings = mv88e6320_stats_get_strings,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2017-06-08 22:34:11 +00:00
|
|
|
.set_cpu_port = mv88e6390_g1_set_cpu_port,
|
|
|
|
.set_egress_port = mv88e6390_g1_set_egress_port,
|
2017-02-08 23:03:43 +00:00
|
|
|
.watchdog_ops = &mv88e6390_watchdog_ops,
|
2016-12-03 03:45:16 +00:00
|
|
|
.mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
|
2017-07-17 17:03:43 +00:00
|
|
|
.pot_clear = mv88e6xxx_g2_pot_clear,
|
2016-12-05 22:30:27 +00:00
|
|
|
.reset = mv88e6352_g1_reset,
|
2018-05-09 15:38:51 +00:00
|
|
|
.rmu_disable = mv88e6390_g1_rmu_disable,
|
2019-10-24 23:03:52 +00:00
|
|
|
.atu_get_hash = mv88e6165_g1_atu_get_hash,
|
|
|
|
.atu_set_hash = mv88e6165_g1_atu_set_hash,
|
2017-05-01 18:05:27 +00:00
|
|
|
.vtu_getnext = mv88e6390_g1_vtu_getnext,
|
|
|
|
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.stu_getnext = mv88e6390_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6390_g1_stu_loadpurge,
|
2019-08-26 21:31:52 +00:00
|
|
|
.serdes_get_lane = mv88e6390x_serdes_get_lane,
|
2019-08-31 20:18:29 +00:00
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
2020-01-18 18:40:56 +00: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 17:54:15 +00:00
|
|
|
.serdes_get_regs_len = mv88e6390_serdes_get_regs_len,
|
|
|
|
.serdes_get_regs = mv88e6390_serdes_get_regs,
|
2018-02-14 00:07:46 +00:00
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
2018-02-14 00:07:44 +00:00
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
2023-01-13 15:12:58 +00:00
|
|
|
.ptp_ops = &mv88e6390_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6390x_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6390_pcs_ops,
|
2016-11-21 22:26:57 +00:00
|
|
|
};
|
|
|
|
|
2021-03-17 13:46:42 +00:00
|
|
|
static const struct mv88e6xxx_ops mv88e6393x_ops = {
|
|
|
|
/* MV88E6XXX_FAMILY_6393 */
|
|
|
|
.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,
|
2023-01-09 15:30:51 +00:00
|
|
|
.phy_read = mv88e6xxx_g2_smi_phy_read_c22,
|
|
|
|
.phy_write = mv88e6xxx_g2_smi_phy_write_c22,
|
|
|
|
.phy_read_c45 = mv88e6xxx_g2_smi_phy_read_c45,
|
|
|
|
.phy_write_c45 = mv88e6xxx_g2_smi_phy_write_c45,
|
2021-03-17 13:46:42 +00:00
|
|
|
.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 13:46:43 +00:00
|
|
|
.port_set_policy = mv88e6393x_port_set_policy,
|
2021-03-17 13:46:42 +00: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,
|
2023-12-14 13:50:23 +00:00
|
|
|
.stats_get_stat = mv88e6390_stats_get_stat,
|
2021-03-17 13:46:42 +00:00
|
|
|
/* .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,
|
2023-03-31 08:40:13 +00:00
|
|
|
.watchdog_ops = &mv88e6393x_watchdog_ops,
|
2021-03-17 13:46:42 +00:00
|
|
|
.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,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.stu_getnext = mv88e6390_g1_stu_getnext,
|
|
|
|
.stu_loadpurge = mv88e6390_g1_stu_loadpurge,
|
2021-03-17 13:46:42 +00:00
|
|
|
.serdes_get_lane = mv88e6393x_serdes_get_lane,
|
|
|
|
.serdes_irq_mapping = mv88e6390_serdes_irq_mapping,
|
|
|
|
/* TODO: serdes stats */
|
|
|
|
.gpio_ops = &mv88e6352_gpio_ops,
|
|
|
|
.avb_ops = &mv88e6390_avb_ops,
|
|
|
|
.ptp_ops = &mv88e6352_ptp_ops,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6393x_phylink_get_caps,
|
2023-07-13 08:42:53 +00:00
|
|
|
.pcs_ops = &mv88e6393x_pcs_ops,
|
2021-03-17 13:46:42 +00:00
|
|
|
};
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
static const struct mv88e6xxx_info mv88e6xxx_table[] = {
|
2023-05-30 08:39:15 +00:00
|
|
|
[MV88E6020] = {
|
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6020,
|
|
|
|
.family = MV88E6XXX_FAMILY_6250,
|
|
|
|
.name = "Marvell 88E6020",
|
|
|
|
.num_databases = 64,
|
2024-03-26 12:36:54 +00:00
|
|
|
/* Ports 2-4 are not routed to pins
|
|
|
|
* => usable ports 0, 1, 5, 6
|
|
|
|
*/
|
|
|
|
.num_ports = 7,
|
2023-05-30 08:39:15 +00:00
|
|
|
.num_internal_phys = 2,
|
2024-03-26 12:36:54 +00:00
|
|
|
.invalid_port_mask = BIT(2) | BIT(3) | BIT(4),
|
2023-05-30 08:39:15 +00:00
|
|
|
.max_vid = 4095,
|
|
|
|
.port_base_addr = 0x8,
|
|
|
|
.phy_base_addr = 0x0,
|
|
|
|
.global1_addr = 0xf,
|
|
|
|
.global2_addr = 0x7,
|
|
|
|
.age_time_coeff = 15000,
|
|
|
|
.g1_irqs = 9,
|
2023-05-30 08:39:16 +00:00
|
|
|
.g2_irqs = 5,
|
|
|
|
.atu_move_port_mask = 0xf,
|
|
|
|
.dual_chip = true,
|
|
|
|
.ops = &mv88e6250_ops,
|
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6071] = {
|
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6071,
|
|
|
|
.family = MV88E6XXX_FAMILY_6250,
|
|
|
|
.name = "Marvell 88E6071",
|
|
|
|
.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,
|
2023-05-30 08:39:15 +00:00
|
|
|
.g2_irqs = 5,
|
|
|
|
.atu_move_port_mask = 0xf,
|
|
|
|
.dual_chip = true,
|
|
|
|
.ops = &mv88e6250_ops,
|
|
|
|
},
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
[MV88E6085] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6085,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6097,
|
|
|
|
.name = "Marvell 88E6085",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 10,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 8,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6085_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6095] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6095,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6095,
|
|
|
|
.name = "Marvell 88E6095/88E6095F",
|
|
|
|
.num_databases = 256,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 11,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 0,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 8,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6095_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
2016-11-22 16:47:21 +00:00
|
|
|
[MV88E6097] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6097,
|
2016-11-22 16:47:21 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6097,
|
|
|
|
.name = "Marvell 88E6097/88E6097F",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-11-22 16:47:21 +00:00
|
|
|
.num_ports = 11,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 8,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2016-11-22 16:47:21 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-22 16:47:21 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-11-22 16:47:21 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-11-25 08:41:29 +00:00
|
|
|
.g1_irqs = 8,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-11-22 16:47:21 +00:00
|
|
|
.ops = &mv88e6097_ops,
|
|
|
|
},
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
[MV88E6123] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6123,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6165,
|
|
|
|
.name = "Marvell 88E6123",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 1024,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 3,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6123_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6131] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6131,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6185,
|
|
|
|
.name = "Marvell 88E6131",
|
|
|
|
.num_databases = 256,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 8,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 0,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6131_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
2017-03-28 17:50:32 +00:00
|
|
|
[MV88E6141] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6141,
|
2017-03-28 17:50:32 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6341,
|
2018-03-20 09:44:40 +00:00
|
|
|
.name = "Marvell 88E6141",
|
2017-03-28 17:50:32 +00:00
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 2048,
|
2017-03-28 17:50:32 +00:00
|
|
|
.num_ports = 6,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 11,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2017-03-28 17:50:32 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x10,
|
2017-03-28 17:50:32 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2017-03-28 17:50:32 +00:00
|
|
|
.age_time_coeff = 3750,
|
|
|
|
.atu_move_port_mask = 0x1f,
|
2018-03-17 19:32:03 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2017-03-28 17:50:32 +00:00
|
|
|
.ops = &mv88e6141_ops,
|
|
|
|
},
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
[MV88E6161] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6161,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6165,
|
|
|
|
.name = "Marvell 88E6161",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 1024,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 6,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2018-07-18 20:38:22 +00:00
|
|
|
.ptp_support = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6161_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6165] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6165,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6165,
|
|
|
|
.name = "Marvell 88E6165",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 6,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 0,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2018-07-18 20:38:22 +00:00
|
|
|
.ptp_support = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6165_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6171] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6171,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6351,
|
|
|
|
.name = "Marvell 88E6171",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6171_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6172] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6172,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6352,
|
|
|
|
.name = "Marvell 88E6172",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 15,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6172_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6175] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6175,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6351,
|
|
|
|
.name = "Marvell 88E6175",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6175_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6176] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6176,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6352,
|
|
|
|
.name = "Marvell 88E6176",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 15,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6176_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6185] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6185,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6185,
|
|
|
|
.name = "Marvell 88E6185",
|
|
|
|
.num_databases = 256,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 10,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 0,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 8,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6185_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
2016-11-21 22:26:57 +00:00
|
|
|
[MV88E6190] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6190,
|
2016-11-21 22:26:57 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
.name = "Marvell 88E6190",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 16384,
|
2016-11-21 22:26:57 +00:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 09:06:05 +00:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 16,
|
2017-05-01 18:05:27 +00:00
|
|
|
.max_vid = 8191,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 22:26:57 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-01 23:46:15 +00:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 22:26:57 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 14,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2016-11-21 22:26:57 +00:00
|
|
|
.ops = &mv88e6190_ops,
|
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6190X] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6190X,
|
2016-11-21 22:26:57 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
.name = "Marvell 88E6190X",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 16384,
|
2016-11-21 22:26:57 +00:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 09:06:05 +00:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 16,
|
2017-05-01 18:05:27 +00:00
|
|
|
.max_vid = 8191,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 22:26:57 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-01 23:46:15 +00:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 22:26:57 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2016-11-21 22:26:57 +00:00
|
|
|
.ops = &mv88e6190x_ops,
|
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6191] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6191,
|
2016-11-21 22:26:57 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
.name = "Marvell 88E6191",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 16384,
|
2016-11-21 22:26:57 +00:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 09:06:05 +00:00
|
|
|
.num_internal_phys = 9,
|
2017-05-01 18:05:27 +00:00
|
|
|
.max_vid = 8191,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 22:26:57 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-01 23:46:15 +00:00
|
|
|
.age_time_coeff = 3750,
|
2016-12-03 03:35:18 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2017-03-28 17:50:34 +00:00
|
|
|
.ops = &mv88e6191_ops,
|
2016-11-21 22:26:57 +00:00
|
|
|
},
|
|
|
|
|
2021-03-17 13:46:42 +00: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 */
|
2023-05-29 08:02:44 +00:00
|
|
|
.num_internal_phys = 8,
|
|
|
|
.internal_phys_offset = 1,
|
2021-03-17 13:46:42 +00:00
|
|
|
.max_vid = 8191,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2021-03-17 13:46:42 +00:00
|
|
|
.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,
|
|
|
|
.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 */
|
2023-05-29 08:02:44 +00:00
|
|
|
.num_internal_phys = 8,
|
|
|
|
.internal_phys_offset = 1,
|
2021-03-17 13:46:42 +00:00
|
|
|
.max_vid = 8191,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2021-03-17 13:46:42 +00:00
|
|
|
.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,
|
|
|
|
.ptp_support = true,
|
|
|
|
.ops = &mv88e6393x_ops,
|
|
|
|
},
|
|
|
|
|
2019-07-31 08:23:46 +00: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 08:23:48 +00:00
|
|
|
.invalid_port_mask = BIT(2) | BIT(3) | BIT(4),
|
2019-07-31 08:23:46 +00: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,
|
2019-07-31 08:23:51 +00:00
|
|
|
.ptp_support = true,
|
2019-07-31 08:23:46 +00:00
|
|
|
.ops = &mv88e6250_ops,
|
|
|
|
},
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
[MV88E6240] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6240,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6352,
|
|
|
|
.name = "Marvell 88E6240",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 15,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6240_ops,
|
2016-05-09 17:22:58 +00: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,
|
2019-07-31 08:23:51 +00: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 22:26:57 +00:00
|
|
|
[MV88E6290] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6290,
|
2016-11-21 22:26:57 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
.name = "Marvell 88E6290",
|
|
|
|
.num_databases = 4096,
|
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 09:06:05 +00:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 16,
|
2017-05-01 18:05:27 +00:00
|
|
|
.max_vid = 8191,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 22:26:57 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-01 23:46:15 +00:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 22:26:57 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2016-11-21 22:26:57 +00:00
|
|
|
.ops = &mv88e6290_ops,
|
|
|
|
},
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
[MV88E6320] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6320,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6320,
|
|
|
|
.name = "Marvell 88E6320",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 15,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 8,
|
2018-03-17 19:32:04 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6320_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6321] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6321,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6320,
|
|
|
|
.name = "Marvell 88E6321",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 15,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 8,
|
2018-03-17 19:32:04 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6321_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
2017-01-30 19:29:34 +00:00
|
|
|
[MV88E6341] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6341,
|
2017-01-30 19:29:34 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6341,
|
|
|
|
.name = "Marvell 88E6341",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 2048,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2017-01-30 19:29:34 +00:00
|
|
|
.num_ports = 6,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 11,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2017-01-30 19:29:34 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x10,
|
2017-01-30 19:29:34 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2017-01-30 19:29:34 +00:00
|
|
|
.age_time_coeff = 3750,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2018-03-17 19:32:03 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2017-01-30 19:29:34 +00:00
|
|
|
.ops = &mv88e6341_ops,
|
|
|
|
},
|
|
|
|
|
2016-05-09 17:22:58 +00:00
|
|
|
[MV88E6350] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6350,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6351,
|
|
|
|
.name = "Marvell 88E6350",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6350_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6351] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6351,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6351,
|
|
|
|
.name = "Marvell 88E6351",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
2022-03-19 11:03:45 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6351_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
[MV88E6352] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6352,
|
2016-05-09 17:22:58 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6352,
|
|
|
|
.name = "Marvell 88E6352",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 8192,
|
2016-05-09 17:22:58 +00:00
|
|
|
.num_ports = 7,
|
2018-03-17 19:32:04 +00:00
|
|
|
.num_internal_phys = 5,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 15,
|
2017-05-01 18:05:10 +00:00
|
|
|
.max_vid = 4095,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2016-06-20 17:14:10 +00:00
|
|
|
.port_base_addr = 0x10,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-09-29 16:21:53 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2016-07-19 00:45:39 +00:00
|
|
|
.age_time_coeff = 15000,
|
2016-10-16 17:56:49 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 10,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0xf,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2016-09-29 16:22:00 +00:00
|
|
|
.ops = &mv88e6352_ops,
|
2016-05-09 17:22:58 +00:00
|
|
|
},
|
2023-05-29 08:02:46 +00:00
|
|
|
[MV88E6361] = {
|
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6361,
|
|
|
|
.family = MV88E6XXX_FAMILY_6393,
|
|
|
|
.name = "Marvell 88E6361",
|
|
|
|
.num_databases = 4096,
|
|
|
|
.num_macs = 16384,
|
|
|
|
.num_ports = 11,
|
|
|
|
/* Ports 1, 2 and 8 are not routed */
|
|
|
|
.invalid_port_mask = BIT(1) | BIT(2) | BIT(8),
|
|
|
|
.num_internal_phys = 5,
|
|
|
|
.internal_phys_offset = 3,
|
|
|
|
.max_vid = 4095,
|
|
|
|
.max_sid = 63,
|
|
|
|
.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,
|
|
|
|
.ptp_support = true,
|
|
|
|
.ops = &mv88e6393x_ops,
|
|
|
|
},
|
2016-11-21 22:26:57 +00:00
|
|
|
[MV88E6390] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6390,
|
2016-11-21 22:26:57 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
.name = "Marvell 88E6390",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 16384,
|
2016-11-21 22:26:57 +00:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 09:06:05 +00:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 16,
|
2017-05-01 18:05:27 +00:00
|
|
|
.max_vid = 8191,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 22:26:57 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-01 23:46:15 +00:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 22:26:57 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_UNDOCUMENTED,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2016-11-21 22:26:57 +00:00
|
|
|
.ops = &mv88e6390_ops,
|
|
|
|
},
|
|
|
|
[MV88E6390X] = {
|
2017-06-12 16:37:36 +00:00
|
|
|
.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6390X,
|
2016-11-21 22:26:57 +00:00
|
|
|
.family = MV88E6XXX_FAMILY_6390,
|
|
|
|
.name = "Marvell 88E6390X",
|
|
|
|
.num_databases = 4096,
|
2019-11-05 00:12:58 +00:00
|
|
|
.num_macs = 16384,
|
2016-11-21 22:26:57 +00:00
|
|
|
.num_ports = 11, /* 10 + Z80 */
|
2019-03-02 09:06:05 +00:00
|
|
|
.num_internal_phys = 9,
|
2018-02-14 00:07:46 +00:00
|
|
|
.num_gpio = 16,
|
2017-05-01 18:05:27 +00:00
|
|
|
.max_vid = 8191,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2016-11-21 22:26:57 +00:00
|
|
|
.port_base_addr = 0x0,
|
2018-05-05 18:58:22 +00:00
|
|
|
.phy_base_addr = 0x0,
|
2016-11-21 22:26:57 +00:00
|
|
|
.global1_addr = 0x1b,
|
2017-07-17 17:03:44 +00:00
|
|
|
.global2_addr = 0x1c,
|
2017-02-01 23:46:15 +00:00
|
|
|
.age_time_coeff = 3750,
|
2016-11-21 22:26:57 +00:00
|
|
|
.g1_irqs = 9,
|
2017-07-17 17:03:40 +00:00
|
|
|
.g2_irqs = 14,
|
2017-03-11 21:12:55 +00:00
|
|
|
.atu_move_port_mask = 0x1f,
|
2017-03-30 21:37:07 +00:00
|
|
|
.pvt = true,
|
2017-07-17 17:03:46 +00:00
|
|
|
.multi_chip = true,
|
2021-04-20 18:53:07 +00:00
|
|
|
.edsa_support = MV88E6XXX_EDSA_UNDOCUMENTED,
|
2018-02-14 00:07:45 +00:00
|
|
|
.ptp_support = true,
|
2016-11-21 22:26:57 +00:00
|
|
|
.ops = &mv88e6390x_ops,
|
|
|
|
},
|
2021-03-17 13:46:42 +00: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 */
|
2023-05-29 08:02:44 +00:00
|
|
|
.num_internal_phys = 8,
|
|
|
|
.internal_phys_offset = 1,
|
2021-03-17 13:46:42 +00:00
|
|
|
.max_vid = 8191,
|
net: dsa: mv88e6xxx: Disentangle STU from VTU
In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states
were kept in the VTU - there was no concept of a SID. Later, the
information was split into two tables, where the VTU only tracked
memberships and deferred the STP state tracking to the STU via a
pointer (SID). This meant that a group of VLANs could share the same
STU entry. Most likely, this was done to align with MSTP (802.1Q-2018,
Clause 13), which is built on this principle.
While the VTU is still 4k lines on most devices, the STU is capped at
64 entries. This means that the current stategy, updating STU info
whenever a VTU entry is updated, can not easily support MSTP because:
- The maximum number of VIDs would also be capped at 64, as we would
have to allocate one SID for every VTU entry - even if many VLANs
would effectively share the same MST.
- MSTP updates would be unnecessarily slow as you would have to
iterate over all VLANs that share the same MST.
In order to support MSTP offloading in the future, manage the STU as a
separate entity from the VTU.
Only add support for newer hardware with separate VTU and
STU. VTU-only devices can also be supported, but essentially this
requires a software implementation of an STU (fanning out state
changed to all VLANs tied to the same MST).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 15:08:55 +00:00
|
|
|
.max_sid = 63,
|
2021-03-17 13:46:42 +00:00
|
|
|
.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,
|
|
|
|
.ptp_support = true,
|
|
|
|
.ops = &mv88e6393x_ops,
|
|
|
|
},
|
2016-05-09 17:22:58 +00:00
|
|
|
};
|
|
|
|
|
2016-06-20 17:14:04 +00:00
|
|
|
static const struct mv88e6xxx_info *mv88e6xxx_lookup_info(unsigned int prod_num)
|
2015-10-30 23:39:48 +00:00
|
|
|
{
|
2016-04-17 17:23:58 +00:00
|
|
|
int i;
|
2015-10-30 23:39:48 +00:00
|
|
|
|
2016-06-20 17:14:04 +00: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 23:39:48 +00:00
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
static int mv88e6xxx_detect(struct mv88e6xxx_chip *chip)
|
2016-06-20 17:14:08 +00:00
|
|
|
{
|
|
|
|
const struct mv88e6xxx_info *info;
|
2016-07-20 22:18:36 +00:00
|
|
|
unsigned int prod_num, rev;
|
|
|
|
u16 id;
|
|
|
|
int err;
|
2016-06-20 17:14:08 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2017-06-12 16:37:36 +00: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 22:18:36 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2016-06-20 17:14:08 +00:00
|
|
|
|
2017-06-12 16:37:36 +00:00
|
|
|
prod_num = id & MV88E6XXX_PORT_SWITCH_ID_PROD_MASK;
|
|
|
|
rev = id & MV88E6XXX_PORT_SWITCH_ID_REV_MASK;
|
2016-06-20 17:14:08 +00:00
|
|
|
|
|
|
|
info = mv88e6xxx_lookup_info(prod_num);
|
|
|
|
if (!info)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2016-06-20 17:14:09 +00:00
|
|
|
/* Update the compatible info with the probed one */
|
2016-06-21 16:28:20 +00:00
|
|
|
chip->info = info;
|
2016-06-20 17:14:08 +00:00
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
dev_info(chip->dev, "switch 0x%x detected: %s, revision %u\n",
|
|
|
|
chip->info->prod_num, chip->info->name, rev);
|
2016-06-20 17:14:08 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-04-27 13:09:28 +00:00
|
|
|
static int mv88e6xxx_single_chip_detect(struct mv88e6xxx_chip *chip,
|
|
|
|
struct mdio_device *mdiodev)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* dual_chip takes precedence over single/multi-chip modes */
|
|
|
|
if (chip->info->dual_chip)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* If the mdio addr is 16 indicating the first port address of a switch
|
|
|
|
* (e.g. mv88e6*41) in single chip addressing mode the device may be
|
|
|
|
* configured in single chip addressing mode. Setup the smi access as
|
|
|
|
* single chip addressing mode and attempt to detect the model of the
|
|
|
|
* switch, if this fails the device is not configured in single chip
|
|
|
|
* addressing mode.
|
|
|
|
*/
|
|
|
|
if (mdiodev->addr != 16)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
err = mv88e6xxx_smi_init(chip, mdiodev->bus, 0);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
return mv88e6xxx_detect(chip);
|
|
|
|
}
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
static struct mv88e6xxx_chip *mv88e6xxx_alloc_chip(struct device *dev)
|
2016-06-20 17:14:06 +00:00
|
|
|
{
|
2016-06-21 16:28:20 +00:00
|
|
|
struct mv88e6xxx_chip *chip;
|
2016-06-20 17:14:06 +00:00
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
|
|
|
|
if (!chip)
|
2016-06-20 17:14:06 +00:00
|
|
|
return NULL;
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
chip->dev = dev;
|
2016-06-20 17:14:06 +00:00
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
mutex_init(&chip->reg_lock);
|
2017-01-24 13:53:50 +00:00
|
|
|
INIT_LIST_HEAD(&chip->mdios);
|
2019-09-07 20:00:49 +00:00
|
|
|
idr_init(&chip->policies);
|
2022-03-16 15:08:57 +00:00
|
|
|
INIT_LIST_HEAD(&chip->msts);
|
2016-06-20 17:14:06 +00:00
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
return chip;
|
2016-06-20 17:14:06 +00:00
|
|
|
}
|
|
|
|
|
2017-11-10 23:22:52 +00:00
|
|
|
static enum dsa_tag_protocol mv88e6xxx_get_tag_protocol(struct dsa_switch *ds,
|
2020-01-08 05:06:05 +00:00
|
|
|
int port,
|
|
|
|
enum dsa_tag_protocol m)
|
2016-08-22 14:01:01 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-08-22 14:01:02 +00:00
|
|
|
|
2021-04-20 18:53:07 +00:00
|
|
|
return chip->tag_protocol;
|
2016-08-22 14:01:01 +00:00
|
|
|
}
|
|
|
|
|
2022-05-11 09:50:18 +00:00
|
|
|
static int mv88e6xxx_change_tag_protocol(struct dsa_switch *ds,
|
2021-04-20 18:53:08 +00:00
|
|
|
enum dsa_tag_protocol proto)
|
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
enum dsa_tag_protocol old_protocol;
|
2022-05-11 09:50:18 +00:00
|
|
|
struct dsa_port *cpu_dp;
|
2021-04-20 18:53:08 +00:00
|
|
|
int err;
|
|
|
|
|
|
|
|
switch (proto) {
|
|
|
|
case DSA_TAG_PROTO_EDSA:
|
|
|
|
switch (chip->info->edsa_support) {
|
|
|
|
case MV88E6XXX_EDSA_UNSUPPORTED:
|
|
|
|
return -EPROTONOSUPPORT;
|
|
|
|
case MV88E6XXX_EDSA_UNDOCUMENTED:
|
|
|
|
dev_warn(chip->dev, "Relying on undocumented EDSA tagging behavior\n");
|
|
|
|
fallthrough;
|
|
|
|
case MV88E6XXX_EDSA_SUPPORTED:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case DSA_TAG_PROTO_DSA:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EPROTONOSUPPORT;
|
|
|
|
}
|
|
|
|
|
|
|
|
old_protocol = chip->tag_protocol;
|
|
|
|
chip->tag_protocol = proto;
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
2022-05-11 09:50:18 +00:00
|
|
|
dsa_switch_for_each_cpu_port(cpu_dp, ds) {
|
|
|
|
err = mv88e6xxx_setup_port_mode(chip, cpu_dp->index);
|
|
|
|
if (err) {
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
goto unwind;
|
|
|
|
}
|
|
|
|
}
|
2021-04-20 18:53:08 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
2022-05-11 09:50:18 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
unwind:
|
|
|
|
chip->tag_protocol = old_protocol;
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
dsa_switch_for_each_cpu_port_continue_reverse(cpu_dp, ds)
|
|
|
|
mv88e6xxx_setup_port_mode(chip, cpu_dp->index);
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2021-04-20 18:53:08 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-01-09 00:01:52 +00:00
|
|
|
static int mv88e6xxx_port_mdb_add(struct dsa_switch *ds, int port,
|
net: dsa: request drivers to perform FDB isolation
For DSA, to encourage drivers to perform FDB isolation simply means to
track which bridge does each FDB and MDB entry belong to. It then
becomes the driver responsibility to use something that makes the FDB
entry from one bridge not match the FDB lookup of ports from other
bridges.
The top-level functions where the bridge is determined are:
- dsa_port_fdb_{add,del}
- dsa_port_host_fdb_{add,del}
- dsa_port_mdb_{add,del}
- dsa_port_host_mdb_{add,del}
aka the pre-crosschip-notifier functions.
Changing the API to pass a reference to a bridge is not superfluous, and
looking at the passed bridge argument is not the same as having the
driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
method.
DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
and those do not have any dp->bridge information to retrieve, because
they are not in any bridge - they are merely the pipes that serve the
user ports that are in one or multiple bridges.
The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
in a larger "struct dsa_db" database. Although only databases associated
to bridges are notified for now, this API will be the starting point for
implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
entries on the CPU port which belong to the corresponding user port's
port database. These are supposed to match only when the port is
standalone.
It is better to introduce the API in its expected final form than to
introduce it for bridges first, then to have to change drivers which may
have made one or more assumptions.
Drivers can use the provided bridge.num, but they can also use a
different numbering scheme that is more convenient.
DSA must perform refcounting on the CPU and DSA ports by also taking
into account the bridge number. So if two bridges request the same local
address, DSA must notify the driver twice, once for each bridge.
In fact, if the driver supports FDB isolation, DSA must perform
refcounting per bridge, but if the driver doesn't, DSA must refcount
host addresses across all bridges, otherwise it would be telling the
driver to delete an FDB entry for a bridge and the driver would delete
it for all bridges. So introduce a bool fdb_isolation in drivers which
would make all bridge databases passed to the cross-chip notifier have
the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
say that all bridge databases are the same database - which is
essentially the legacy behavior.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-25 09:22:22 +00:00
|
|
|
const struct switchdev_obj_port_mdb *mdb,
|
|
|
|
struct dsa_db db)
|
2016-08-31 15:50:05 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2021-01-09 00:01:52 +00:00
|
|
|
int err;
|
2016-08-31 15:50:05 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2021-01-09 00:01:52 +00: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 00:01:52 +00:00
|
|
|
|
|
|
|
return err;
|
2016-08-31 15:50:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mv88e6xxx_port_mdb_del(struct dsa_switch *ds, int port,
|
net: dsa: request drivers to perform FDB isolation
For DSA, to encourage drivers to perform FDB isolation simply means to
track which bridge does each FDB and MDB entry belong to. It then
becomes the driver responsibility to use something that makes the FDB
entry from one bridge not match the FDB lookup of ports from other
bridges.
The top-level functions where the bridge is determined are:
- dsa_port_fdb_{add,del}
- dsa_port_host_fdb_{add,del}
- dsa_port_mdb_{add,del}
- dsa_port_host_mdb_{add,del}
aka the pre-crosschip-notifier functions.
Changing the API to pass a reference to a bridge is not superfluous, and
looking at the passed bridge argument is not the same as having the
driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
method.
DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
and those do not have any dp->bridge information to retrieve, because
they are not in any bridge - they are merely the pipes that serve the
user ports that are in one or multiple bridges.
The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
in a larger "struct dsa_db" database. Although only databases associated
to bridges are notified for now, this API will be the starting point for
implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
entries on the CPU port which belong to the corresponding user port's
port database. These are supposed to match only when the port is
standalone.
It is better to introduce the API in its expected final form than to
introduce it for bridges first, then to have to change drivers which may
have made one or more assumptions.
Drivers can use the provided bridge.num, but they can also use a
different numbering scheme that is more convenient.
DSA must perform refcounting on the CPU and DSA ports by also taking
into account the bridge number. So if two bridges request the same local
address, DSA must notify the driver twice, once for each bridge.
In fact, if the driver supports FDB isolation, DSA must perform
refcounting per bridge, but if the driver doesn't, DSA must refcount
host addresses across all bridges, otherwise it would be telling the
driver to delete an FDB entry for a bridge and the driver would delete
it for all bridges. So introduce a bool fdb_isolation in drivers which
would make all bridge databases passed to the cross-chip notifier have
the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
say that all bridge databases are the same database - which is
essentially the legacy behavior.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-25 09:22:22 +00:00
|
|
|
const struct switchdev_obj_port_mdb *mdb,
|
|
|
|
struct dsa_db db)
|
2016-08-31 15:50:05 +00:00
|
|
|
{
|
2016-08-31 22:06:13 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2016-08-31 15:50:05 +00:00
|
|
|
int err;
|
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2019-09-07 20:00:47 +00: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 15:50:05 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-11-07 21:11:14 +00:00
|
|
|
static int mv88e6xxx_port_mirror_add(struct dsa_switch *ds, int port,
|
|
|
|
struct dsa_mall_mirror_tc_entry *mirror,
|
2022-03-16 20:41:43 +00:00
|
|
|
bool ingress,
|
|
|
|
struct netlink_ext_ack *extack)
|
2019-11-07 21:11:14 +00:00
|
|
|
{
|
|
|
|
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 13:46:41 +00:00
|
|
|
err = mv88e6xxx_set_egress_port(chip, direction,
|
|
|
|
mirror->to_local_port);
|
2019-11-07 21:11:14 +00: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 13:46:41 +00:00
|
|
|
if (mv88e6xxx_set_egress_port(chip, direction,
|
|
|
|
dsa_upstream_port(ds, port)))
|
2019-11-07 21:11:14 +00: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 15:15:56 +00: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 19:25:40 +00:00
|
|
|
if (flags.mask & ~(BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD |
|
2023-01-08 09:48:49 +00:00
|
|
|
BR_BCAST_FLOOD | BR_PORT_LOCKED | BR_PORT_MAB))
|
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 15:15:56 +00: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 23:35:05 +00:00
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2023-01-08 09:48:47 +00:00
|
|
|
int err = 0;
|
2019-02-20 23:35:05 +00:00
|
|
|
|
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 15:15:56 +00:00
|
|
|
|
2021-03-18 19:25:39 +00: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;
|
|
|
|
}
|
|
|
|
|
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 15:15:56 +00: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 19:25:40 +00: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;
|
|
|
|
}
|
|
|
|
|
2023-01-08 09:48:49 +00:00
|
|
|
if (flags.mask & BR_PORT_MAB) {
|
|
|
|
bool mab = !!(flags.val & BR_PORT_MAB);
|
|
|
|
|
|
|
|
mv88e6xxx_port_set_mab(chip, port, mab);
|
|
|
|
}
|
|
|
|
|
2022-02-23 10:16:49 +00:00
|
|
|
if (flags.mask & BR_PORT_LOCKED) {
|
|
|
|
bool locked = !!(flags.val & BR_PORT_LOCKED);
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_set_lock(chip, port, locked);
|
|
|
|
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 15:15:56 +00:00
|
|
|
out:
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-01-13 08:42:54 +00:00
|
|
|
static bool mv88e6xxx_lag_can_offload(struct dsa_switch *ds,
|
2022-02-23 14:00:49 +00:00
|
|
|
struct dsa_lag lag,
|
2022-09-11 01:07:03 +00:00
|
|
|
struct netdev_lag_upper_info *info,
|
|
|
|
struct netlink_ext_ack *extack)
|
2021-01-13 08:42:54 +00:00
|
|
|
{
|
2021-01-15 12:52:59 +00:00
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
2021-01-13 08:42:54 +00:00
|
|
|
struct dsa_port *dp;
|
2022-02-23 14:00:49 +00:00
|
|
|
int members = 0;
|
2021-01-13 08:42:54 +00:00
|
|
|
|
2022-09-11 01:07:03 +00:00
|
|
|
if (!mv88e6xxx_has_lag(chip)) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Chip does not support LAG offload");
|
2021-01-15 12:52:59 +00:00
|
|
|
return false;
|
2022-09-11 01:07:03 +00:00
|
|
|
}
|
2021-01-15 12:52:59 +00:00
|
|
|
|
2022-02-23 14:00:49 +00:00
|
|
|
if (!lag.id)
|
2021-01-13 08:42:54 +00:00
|
|
|
return false;
|
|
|
|
|
2022-02-23 14:00:49 +00:00
|
|
|
dsa_lag_foreach_port(dp, ds->dst, &lag)
|
2021-01-13 08:42:54 +00:00
|
|
|
/* Includes the port joining the LAG */
|
|
|
|
members++;
|
|
|
|
|
2022-09-11 01:07:03 +00:00
|
|
|
if (members > 8) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack,
|
|
|
|
"Cannot offload more than 8 LAG ports");
|
2021-01-13 08:42:54 +00:00
|
|
|
return false;
|
2022-09-11 01:07:03 +00:00
|
|
|
}
|
2021-01-13 08:42:54 +00:00
|
|
|
|
|
|
|
/* We could potentially relax this to include active
|
|
|
|
* backup in the future.
|
|
|
|
*/
|
2022-09-11 01:07:03 +00:00
|
|
|
if (info->tx_type != NETDEV_LAG_TX_TYPE_HASH) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack,
|
|
|
|
"Can only offload LAG using hash TX type");
|
2021-01-13 08:42:54 +00:00
|
|
|
return false;
|
2022-09-11 01:07:03 +00:00
|
|
|
}
|
2021-01-13 08:42:54 +00:00
|
|
|
|
|
|
|
/* Ideally we would also validate that the hash type matches
|
|
|
|
* the hardware. Alas, this is always set to unknown on team
|
|
|
|
* interfaces.
|
|
|
|
*/
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2022-02-23 14:00:49 +00:00
|
|
|
static int mv88e6xxx_lag_sync_map(struct dsa_switch *ds, struct dsa_lag lag)
|
2021-01-13 08:42:54 +00:00
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
struct dsa_port *dp;
|
|
|
|
u16 map = 0;
|
|
|
|
int id;
|
|
|
|
|
2022-02-23 14:00:47 +00:00
|
|
|
/* DSA LAG IDs are one-based, hardware is zero-based */
|
2022-02-23 14:00:49 +00:00
|
|
|
id = lag.id - 1;
|
2021-01-13 08:42:54 +00:00
|
|
|
|
|
|
|
/* 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.
|
|
|
|
*/
|
2022-02-23 14:00:49 +00:00
|
|
|
dsa_lag_foreach_port(dp, ds->dst, &lag)
|
2021-01-13 08:42:54 +00:00
|
|
|
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 dsa_port *dp;
|
2022-02-23 14:00:49 +00:00
|
|
|
struct dsa_lag *lag;
|
2021-01-13 08:42:54 +00:00
|
|
|
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. */
|
2022-02-23 14:00:48 +00:00
|
|
|
dsa_switch_for_each_port(dp, ds) {
|
2022-02-23 14:00:49 +00:00
|
|
|
if (!dp->lag)
|
2021-01-13 08:42:54 +00:00
|
|
|
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) {
|
2022-02-23 14:00:49 +00:00
|
|
|
lag = dsa_lag_by_id(ds->dst, id);
|
|
|
|
if (!lag)
|
2021-01-13 08:42:54 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
num_tx = 0;
|
2022-02-23 14:00:49 +00:00
|
|
|
dsa_lag_foreach_port(dp, ds->dst, lag) {
|
2021-01-13 08:42:54 +00:00
|
|
|
if (dp->lag_tx_enabled)
|
|
|
|
num_tx++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!num_tx)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
nth = 0;
|
2022-02-23 14:00:49 +00:00
|
|
|
dsa_lag_foreach_port(dp, ds->dst, lag) {
|
2021-01-13 08:42:54 +00:00
|
|
|
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,
|
2022-02-23 14:00:49 +00:00
|
|
|
struct dsa_lag lag)
|
2021-01-13 08:42:54 +00:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = mv88e6xxx_lag_sync_masks(ds);
|
|
|
|
|
|
|
|
if (!err)
|
2022-02-23 14:00:49 +00:00
|
|
|
err = mv88e6xxx_lag_sync_map(ds, lag);
|
2021-01-13 08:42:54 +00:00
|
|
|
|
|
|
|
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,
|
2022-02-23 14:00:49 +00:00
|
|
|
struct dsa_lag lag,
|
2022-09-11 01:07:03 +00:00
|
|
|
struct netdev_lag_upper_info *info,
|
|
|
|
struct netlink_ext_ack *extack)
|
2021-01-13 08:42:54 +00:00
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err, id;
|
|
|
|
|
2022-09-11 01:07:03 +00:00
|
|
|
if (!mv88e6xxx_lag_can_offload(ds, lag, info, extack))
|
2021-01-13 08:42:54 +00:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2022-02-23 14:00:47 +00:00
|
|
|
/* DSA LAG IDs are one-based */
|
2022-02-23 14:00:49 +00:00
|
|
|
id = lag.id - 1;
|
2021-01-13 08:42:54 +00:00
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
|
|
|
err = mv88e6xxx_port_set_trunk(chip, port, true, id);
|
|
|
|
if (err)
|
|
|
|
goto err_unlock;
|
|
|
|
|
2022-02-23 14:00:49 +00:00
|
|
|
err = mv88e6xxx_lag_sync_masks_map(ds, lag);
|
2021-01-13 08:42:54 +00:00
|
|
|
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,
|
2022-02-23 14:00:49 +00:00
|
|
|
struct dsa_lag lag)
|
2021-01-13 08:42:54 +00:00
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err_sync, err_trunk;
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
2022-02-23 14:00:49 +00:00
|
|
|
err_sync = mv88e6xxx_lag_sync_masks_map(ds, lag);
|
2021-01-13 08:42:54 +00:00
|
|
|
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,
|
2022-02-23 14:00:49 +00:00
|
|
|
int port, struct dsa_lag lag,
|
2022-09-11 01:07:03 +00:00
|
|
|
struct netdev_lag_upper_info *info,
|
|
|
|
struct netlink_ext_ack *extack)
|
2021-01-13 08:42:54 +00:00
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err;
|
|
|
|
|
2022-09-11 01:07:03 +00:00
|
|
|
if (!mv88e6xxx_lag_can_offload(ds, lag, info, extack))
|
2021-01-13 08:42:54 +00:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
|
|
|
|
2022-02-23 14:00:49 +00:00
|
|
|
err = mv88e6xxx_lag_sync_masks_map(ds, lag);
|
2021-01-13 08:42:54 +00:00
|
|
|
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,
|
2022-02-23 14:00:49 +00:00
|
|
|
int port, struct dsa_lag lag)
|
2021-01-13 08:42:54 +00:00
|
|
|
{
|
|
|
|
struct mv88e6xxx_chip *chip = ds->priv;
|
|
|
|
int err_sync, err_pvt;
|
|
|
|
|
|
|
|
mv88e6xxx_reg_lock(chip);
|
2022-02-23 14:00:49 +00:00
|
|
|
err_sync = mv88e6xxx_lag_sync_masks_map(ds, lag);
|
2021-01-13 08:42:54 +00:00
|
|
|
err_pvt = mv88e6xxx_pvt_map(chip, sw_index, port);
|
|
|
|
mv88e6xxx_reg_unlock(chip);
|
|
|
|
return err_sync ? : err_pvt;
|
|
|
|
}
|
|
|
|
|
2017-01-08 22:52:08 +00:00
|
|
|
static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
|
2016-08-22 14:01:01 +00:00
|
|
|
.get_tag_protocol = mv88e6xxx_get_tag_protocol,
|
2021-04-20 18:53:08 +00:00
|
|
|
.change_tag_protocol = mv88e6xxx_change_tag_protocol,
|
2016-05-09 17:22:58 +00:00
|
|
|
.setup = mv88e6xxx_setup,
|
2019-10-24 23:03:52 +00:00
|
|
|
.teardown = mv88e6xxx_teardown,
|
net: dsa: tear down devlink port regions when tearing down the devlink port on error
Commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal")
decided it was fine to ignore errors on certain ports that fail to
probe, and go on with the ports that do probe fine.
Commit fb6ec87f7229 ("net: dsa: Fix type was not set for devlink port")
noticed that devlink_port_type_eth_set(dlp, dp->slave); does not get
called, and devlink notices after a timeout of 3600 seconds and prints a
WARN_ON. So it went ahead to unregister the devlink port. And because
there exists an UNUSED port flavour, we actually re-register the devlink
port as UNUSED.
Commit 08156ba430b4 ("net: dsa: Add devlink port regions support to
DSA") added devlink port regions, which are set up by the driver and not
by DSA.
When we trigger the devlink port deregistration and reregistration as
unused, devlink now prints another WARN_ON, from here:
devlink_port_unregister:
WARN_ON(!list_empty(&devlink_port->region_list));
So the port still has regions, which makes sense, because they were set
up by the driver, and the driver doesn't know we're unregistering the
devlink port.
Somebody needs to tear them down, and optionally (actually it would be
nice, to be consistent) set them up again for the new devlink port.
But DSA's layering stays in our way quite badly here.
The options I've considered are:
1. Introduce a function in devlink to just change a port's type and
flavour. No dice, devlink keeps a lot of state, it really wants the
port to not be registered when you set its parameters, so changing
anything can only be done by destroying what we currently have and
recreating it.
2. Make DSA cache the parameters passed to dsa_devlink_port_region_create,
and the region returned, keep those in a list, then when the devlink
port unregister needs to take place, the existing devlink regions are
destroyed by DSA, and we replay the creation of new regions using the
cached parameters. Problem: mv88e6xxx keeps the region pointers in
chip->ports[port].region, and these will remain stale after DSA frees
them. There are many things DSA can do, but updating mv88e6xxx's
private pointers is not one of them.
3. Just let the driver do it (i.e. introduce a very specific method
called ds->ops->port_reinit_as_unused, which unregisters its devlink
port devlink regions, then the old devlink port, then registers the
new one, then the devlink port regions for it). While it does work,
as opposed to the others, it's pretty horrible from an API
perspective and we can do better.
4. Introduce a new pair of methods, ->port_setup and ->port_teardown,
which in the case of mv88e6xxx must register and unregister the
devlink port regions. Call these 2 methods when the port must be
reinitialized as unused.
Naturally, I went for the 4th approach.
Fixes: 08156ba430b4 ("net: dsa: Add devlink port regions support to DSA")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-17 14:29:16 +00:00
|
|
|
.port_setup = mv88e6xxx_port_setup,
|
|
|
|
.port_teardown = mv88e6xxx_port_teardown,
|
2022-02-03 13:30:42 +00:00
|
|
|
.phylink_get_caps = mv88e6xxx_get_caps,
|
2023-07-13 08:42:33 +00:00
|
|
|
.phylink_mac_select_pcs = mv88e6xxx_mac_select_pcs,
|
2023-05-25 10:38:50 +00:00
|
|
|
.phylink_mac_prepare = mv88e6xxx_mac_prepare,
|
2018-05-10 20:17:35 +00:00
|
|
|
.phylink_mac_config = mv88e6xxx_mac_config,
|
2023-05-25 10:38:50 +00:00
|
|
|
.phylink_mac_finish = mv88e6xxx_mac_finish,
|
2018-05-10 20:17:35 +00:00
|
|
|
.phylink_mac_link_down = mv88e6xxx_mac_link_down,
|
|
|
|
.phylink_mac_link_up = mv88e6xxx_mac_link_up,
|
2016-05-09 17:22:58 +00:00
|
|
|
.get_strings = mv88e6xxx_get_strings,
|
|
|
|
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
|
2023-12-14 13:50:26 +00:00
|
|
|
.get_eth_mac_stats = mv88e6xxx_get_eth_mac_stats,
|
2023-12-14 13:50:28 +00:00
|
|
|
.get_rmon_stats = mv88e6xxx_get_rmon_stats,
|
2016-05-09 17:22:58 +00:00
|
|
|
.get_sset_count = mv88e6xxx_get_sset_count,
|
2020-07-11 20:32:05 +00:00
|
|
|
.port_max_mtu = mv88e6xxx_get_max_mtu,
|
|
|
|
.port_change_mtu = mv88e6xxx_change_mtu,
|
2017-08-01 20:32:41 +00:00
|
|
|
.get_mac_eee = mv88e6xxx_get_mac_eee,
|
|
|
|
.set_mac_eee = mv88e6xxx_set_mac_eee,
|
2016-05-10 21:27:25 +00:00
|
|
|
.get_eeprom_len = mv88e6xxx_get_eeprom_len,
|
2016-05-09 17:22:58 +00: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 20:00:49 +00:00
|
|
|
.get_rxnfc = mv88e6xxx_get_rxnfc,
|
|
|
|
.set_rxnfc = mv88e6xxx_set_rxnfc,
|
2016-07-19 00:45:40 +00:00
|
|
|
.set_ageing_time = mv88e6xxx_set_ageing_time,
|
2016-05-09 17:22:58 +00: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 15:15:56 +00:00
|
|
|
.port_pre_bridge_flags = mv88e6xxx_port_pre_bridge_flags,
|
|
|
|
.port_bridge_flags = mv88e6xxx_port_bridge_flags,
|
2016-05-09 17:22:58 +00:00
|
|
|
.port_stp_state_set = mv88e6xxx_port_stp_state_set,
|
2022-03-16 15:08:57 +00:00
|
|
|
.port_mst_state_set = mv88e6xxx_port_mst_state_set,
|
2016-09-22 20:49:24 +00:00
|
|
|
.port_fast_age = mv88e6xxx_port_fast_age,
|
2022-03-16 15:08:57 +00:00
|
|
|
.port_vlan_fast_age = mv88e6xxx_port_vlan_fast_age,
|
2016-05-09 17:22:58 +00:00
|
|
|
.port_vlan_filtering = mv88e6xxx_port_vlan_filtering,
|
|
|
|
.port_vlan_add = mv88e6xxx_port_vlan_add,
|
|
|
|
.port_vlan_del = mv88e6xxx_port_vlan_del,
|
2022-03-16 15:08:57 +00:00
|
|
|
.vlan_msti_set = mv88e6xxx_vlan_msti_set,
|
2022-04-29 14:32:14 +00:00
|
|
|
.port_fdb_add = mv88e6xxx_port_fdb_add,
|
|
|
|
.port_fdb_del = mv88e6xxx_port_fdb_del,
|
|
|
|
.port_fdb_dump = mv88e6xxx_port_fdb_dump,
|
|
|
|
.port_mdb_add = mv88e6xxx_port_mdb_add,
|
|
|
|
.port_mdb_del = mv88e6xxx_port_mdb_del,
|
2019-11-07 21:11:14 +00:00
|
|
|
.port_mirror_add = mv88e6xxx_port_mirror_add,
|
|
|
|
.port_mirror_del = mv88e6xxx_port_mirror_del,
|
2017-03-30 21:37:15 +00:00
|
|
|
.crosschip_bridge_join = mv88e6xxx_crosschip_bridge_join,
|
|
|
|
.crosschip_bridge_leave = mv88e6xxx_crosschip_bridge_leave,
|
2018-02-14 00:07:50 +00: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-24 23:03:52 +00:00
|
|
|
.devlink_param_get = mv88e6xxx_devlink_param_get,
|
|
|
|
.devlink_param_set = mv88e6xxx_devlink_param_set,
|
2020-09-18 19:11:09 +00:00
|
|
|
.devlink_info_get = mv88e6xxx_devlink_info_get,
|
2021-01-13 08:42:54 +00: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 17:22:58 +00:00
|
|
|
};
|
|
|
|
|
2017-01-26 18:45:51 +00:00
|
|
|
static int mv88e6xxx_register_switch(struct mv88e6xxx_chip *chip)
|
2016-06-20 17:14:02 +00:00
|
|
|
{
|
2016-06-21 16:28:20 +00:00
|
|
|
struct device *dev = chip->dev;
|
2016-06-20 17:14:02 +00:00
|
|
|
struct dsa_switch *ds;
|
|
|
|
|
2019-10-21 20:51:30 +00:00
|
|
|
ds = devm_kzalloc(dev, sizeof(*ds), GFP_KERNEL);
|
2016-06-20 17:14:02 +00:00
|
|
|
if (!ds)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-10-21 20:51:30 +00:00
|
|
|
ds->dev = dev;
|
|
|
|
ds->num_ports = mv88e6xxx_num_ports(chip);
|
2016-06-21 16:28:20 +00:00
|
|
|
ds->priv = chip;
|
2018-05-19 20:31:34 +00:00
|
|
|
ds->dev = dev;
|
2016-08-23 16:38:56 +00:00
|
|
|
ds->ops = &mv88e6xxx_switch_ops;
|
2017-03-15 19:53:50 +00:00
|
|
|
ds->ageing_time_min = chip->info->age_time_coeff;
|
|
|
|
ds->ageing_time_max = chip->info->age_time_coeff * U8_MAX;
|
2016-06-20 17:14:02 +00:00
|
|
|
|
2021-01-13 08:42:54 +00: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 12:52:59 +00:00
|
|
|
ds->num_lag_ids = mv88e6xxx_has_lag(chip) ? 16 : 0;
|
2021-01-13 08:42:54 +00:00
|
|
|
|
2016-06-20 17:14:02 +00:00
|
|
|
dev_set_drvdata(dev, ds);
|
|
|
|
|
2017-05-26 22:12:51 +00:00
|
|
|
return dsa_register_switch(ds);
|
2016-06-20 17:14:02 +00:00
|
|
|
}
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
static void mv88e6xxx_unregister_switch(struct mv88e6xxx_chip *chip)
|
2016-06-20 17:14:02 +00:00
|
|
|
{
|
2016-06-21 16:28:20 +00:00
|
|
|
dsa_unregister_switch(chip->ds);
|
2016-06-20 17:14:02 +00:00
|
|
|
}
|
|
|
|
|
2018-05-19 20:31:34 +00: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 11:07:28 +00: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 17:13:58 +00:00
|
|
|
static int mv88e6xxx_probe(struct mdio_device *mdiodev)
|
2011-11-25 14:36:19 +00:00
|
|
|
{
|
2018-05-19 20:31:34 +00:00
|
|
|
struct dsa_mv88e6xxx_pdata *pdata = mdiodev->dev.platform_data;
|
2018-05-20 23:04:24 +00:00
|
|
|
const struct mv88e6xxx_info *compat_info = NULL;
|
2016-05-10 21:27:21 +00:00
|
|
|
struct device *dev = &mdiodev->dev;
|
2016-05-10 21:27:25 +00:00
|
|
|
struct device_node *np = dev->of_node;
|
2016-06-21 16:28:20 +00:00
|
|
|
struct mv88e6xxx_chip *chip;
|
2018-05-19 20:31:34 +00:00
|
|
|
int port;
|
2016-05-10 21:27:22 +00:00
|
|
|
int err;
|
2016-05-10 21:27:21 +00:00
|
|
|
|
2018-05-30 22:15:42 +00:00
|
|
|
if (!np && !pdata)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-05-19 20:31:34 +00: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 17:14:09 +00:00
|
|
|
if (!compat_info)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
chip = mv88e6xxx_alloc_chip(dev);
|
2018-05-19 20:31:34 +00:00
|
|
|
if (!chip) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-05-10 21:27:21 +00:00
|
|
|
|
2016-06-21 16:28:20 +00:00
|
|
|
chip->info = compat_info;
|
2016-06-20 17:14:09 +00:00
|
|
|
|
2016-11-21 22:26:55 +00:00
|
|
|
chip->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
|
2018-05-19 20:31:34 +00:00
|
|
|
if (IS_ERR(chip->reset)) {
|
|
|
|
err = PTR_ERR(chip->reset);
|
|
|
|
goto out;
|
|
|
|
}
|
2019-06-27 18:17:39 +00:00
|
|
|
if (chip->reset)
|
2023-05-30 14:52:23 +00:00
|
|
|
usleep_range(10000, 20000);
|
2016-11-21 22:26:55 +00:00
|
|
|
|
2022-04-27 13:09:28 +00:00
|
|
|
/* Detect if the device is configured in single chip addressing mode,
|
|
|
|
* otherwise continue with address specific smi init/detection.
|
|
|
|
*/
|
|
|
|
err = mv88e6xxx_single_chip_detect(chip, mdiodev);
|
|
|
|
if (err) {
|
|
|
|
err = mv88e6xxx_smi_init(chip, mdiodev->bus, mdiodev->addr);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
err = mv88e6xxx_detect(chip);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
}
|
2016-05-10 21:27:21 +00:00
|
|
|
|
2021-04-20 18:53:07 +00:00
|
|
|
if (chip->info->edsa_support == MV88E6XXX_EDSA_SUPPORTED)
|
|
|
|
chip->tag_protocol = DSA_TAG_PROTO_EDSA;
|
|
|
|
else
|
|
|
|
chip->tag_protocol = DSA_TAG_PROTO_DSA;
|
|
|
|
|
2016-08-15 21:19:00 +00:00
|
|
|
mv88e6xxx_phy_init(chip);
|
|
|
|
|
2018-05-19 20:31:35 +00: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 21:27:25 +00:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2016-10-16 17:56:49 +00:00
|
|
|
err = mv88e6xxx_switch_reset(chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2016-10-16 17:56:49 +00:00
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
2019-04-30 22:10:50 +00:00
|
|
|
if (np) {
|
|
|
|
chip->irq = of_irq_get(np, 0);
|
|
|
|
if (chip->irq == -EPROBE_DEFER) {
|
|
|
|
err = chip->irq;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-10-16 17:56:49 +00:00
|
|
|
}
|
|
|
|
|
2019-04-30 22:10:50 +00:00
|
|
|
if (pdata)
|
|
|
|
chip->irq = pdata->irq;
|
|
|
|
|
2018-02-22 21:58:32 +00:00
|
|
|
/* Has to be performed before the MDIO bus is created, because
|
2018-03-20 09:44:41 +00:00
|
|
|
* the PHYs will link their interrupts to these interrupt
|
2018-02-22 21:58:32 +00:00
|
|
|
* controllers
|
|
|
|
*/
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_lock(chip);
|
2018-02-22 21:58:32 +00:00
|
|
|
if (chip->irq > 0)
|
2016-10-16 17:56:49 +00:00
|
|
|
err = mv88e6xxx_g1_irq_setup(chip);
|
2018-02-22 21:58:32 +00:00
|
|
|
else
|
|
|
|
err = mv88e6xxx_irq_poll_setup(chip);
|
2019-06-20 13:50:42 +00:00
|
|
|
mv88e6xxx_reg_unlock(chip);
|
2018-01-14 01:32:44 +00:00
|
|
|
|
2018-02-22 21:58:32 +00:00
|
|
|
if (err)
|
|
|
|
goto out;
|
2018-01-14 01:32:45 +00:00
|
|
|
|
2018-02-22 21:58:32 +00:00
|
|
|
if (chip->info->g2_irqs > 0) {
|
|
|
|
err = mv88e6xxx_g2_irq_setup(chip);
|
2018-01-14 01:32:45 +00:00
|
|
|
if (err)
|
2018-02-22 21:58:32 +00:00
|
|
|
goto out_g1_irq;
|
2016-10-16 17:56:49 +00:00
|
|
|
}
|
|
|
|
|
2018-02-22 21:58:32 +00: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-26 18:45:51 +00:00
|
|
|
err = mv88e6xxx_register_switch(chip);
|
2016-10-16 17:56:49 +00:00
|
|
|
if (err)
|
2023-03-15 16:38:45 +00:00
|
|
|
goto out_g1_vtu_prob_irq;
|
2016-06-04 19:17:07 +00:00
|
|
|
|
2011-11-25 14:36:19 +00:00
|
|
|
return 0;
|
2016-10-16 17:56:49 +00:00
|
|
|
|
2018-01-14 01:32:45 +00:00
|
|
|
out_g1_vtu_prob_irq:
|
2018-02-22 21:58:32 +00:00
|
|
|
mv88e6xxx_g1_vtu_prob_irq_free(chip);
|
2018-01-14 01:32:44 +00:00
|
|
|
out_g1_atu_prob_irq:
|
2018-02-22 21:58:32 +00:00
|
|
|
mv88e6xxx_g1_atu_prob_irq_free(chip);
|
2016-10-16 17:56:49 +00:00
|
|
|
out_g2_irq:
|
2018-02-22 21:58:32 +00:00
|
|
|
if (chip->info->g2_irqs > 0)
|
2016-10-16 17:56:49 +00:00
|
|
|
mv88e6xxx_g2_irq_free(chip);
|
|
|
|
out_g1_irq:
|
2018-02-22 21:58:32 +00:00
|
|
|
if (chip->irq > 0)
|
2016-11-20 19:14:15 +00:00
|
|
|
mv88e6xxx_g1_irq_free(chip);
|
2018-02-22 21:58:32 +00:00
|
|
|
else
|
|
|
|
mv88e6xxx_irq_poll_free(chip);
|
2016-10-16 17:56:49 +00:00
|
|
|
out:
|
2018-05-19 20:31:34 +00:00
|
|
|
if (pdata)
|
|
|
|
dev_put(pdata->netdev);
|
|
|
|
|
2016-10-16 17:56:49 +00:00
|
|
|
return err;
|
2011-11-25 14:36:19 +00:00
|
|
|
}
|
2016-05-10 21:27:21 +00:00
|
|
|
|
|
|
|
static void mv88e6xxx_remove(struct mdio_device *mdiodev)
|
|
|
|
{
|
|
|
|
struct dsa_switch *ds = dev_get_drvdata(&mdiodev->dev);
|
net: dsa: be compatible with masters which unregister on shutdown
Lino reports that on his system with bcmgenet as DSA master and KSZ9897
as a switch, rebooting or shutting down never works properly.
What does the bcmgenet driver have special to trigger this, that other
DSA masters do not? It has an implementation of ->shutdown which simply
calls its ->remove implementation. Otherwise said, it unregisters its
network interface on shutdown.
This message can be seen in a loop, and it hangs the reboot process there:
unregister_netdevice: waiting for eth0 to become free. Usage count = 3
So why 3?
A usage count of 1 is normal for a registered network interface, and any
virtual interface which links itself as an upper of that will increment
it via dev_hold. In the case of DSA, this is the call path:
dsa_slave_create
-> netdev_upper_dev_link
-> __netdev_upper_dev_link
-> __netdev_adjacent_dev_insert
-> dev_hold
So a DSA switch with 3 interfaces will result in a usage count elevated
by two, and netdev_wait_allrefs will wait until they have gone away.
Other stacked interfaces, like VLAN, watch NETDEV_UNREGISTER events and
delete themselves, but DSA cannot just vanish and go poof, at most it
can unbind itself from the switch devices, but that must happen strictly
earlier compared to when the DSA master unregisters its net_device, so
reacting on the NETDEV_UNREGISTER event is way too late.
It seems that it is a pretty established pattern to have a driver's
->shutdown hook redirect to its ->remove hook, so the same code is
executed regardless of whether the driver is unbound from the device, or
the system is just shutting down. As Florian puts it, it is quite a big
hammer for bcmgenet to unregister its net_device during shutdown, but
having a common code path with the driver unbind helps ensure it is well
tested.
So DSA, for better or for worse, has to live with that and engage in an
arms race of implementing the ->shutdown hook too, from all individual
drivers, and do something sane when paired with masters that unregister
their net_device there. The only sane thing to do, of course, is to
unlink from the master.
However, complications arise really quickly.
The pattern of redirecting ->shutdown to ->remove is not unique to
bcmgenet or even to net_device drivers. In fact, SPI controllers do it
too (see dspi_shutdown -> dspi_remove), and presumably, I2C controllers
and MDIO controllers do it too (this is something I have not researched
too deeply, but even if this is not the case today, it is certainly
plausible to happen in the future, and must be taken into consideration).
Since DSA switches might be SPI devices, I2C devices, MDIO devices, the
insane implication is that for the exact same DSA switch device, we
might have both ->shutdown and ->remove getting called.
So we need to do something with that insane environment. The pattern
I've come up with is "if this, then not that", so if either ->shutdown
or ->remove gets called, we set the device's drvdata to NULL, and in the
other hook, we check whether the drvdata is NULL and just do nothing.
This is probably not necessary for platform devices, just for devices on
buses, but I would really insist for consistency among drivers, because
when code is copy-pasted, it is not always copy-pasted from the best
sources.
So depending on whether the DSA switch's ->remove or ->shutdown will get
called first, we cannot really guarantee even for the same driver if
rebooting will result in the same code path on all platforms. But
nonetheless, we need to do something minimally reasonable on ->shutdown
too to fix the bug. Of course, the ->remove will do more (a full
teardown of the tree, with all data structures freed, and this is why
the bug was not caught for so long). The new ->shutdown method is kept
separate from dsa_unregister_switch not because we couldn't have
unregistered the switch, but simply in the interest of doing something
quick and to the point.
The big question is: does the DSA switch's ->shutdown get called earlier
than the DSA master's ->shutdown? If not, there is still a risk that we
might still trigger the WARN_ON in unregister_netdevice that says we are
attempting to unregister a net_device which has uppers. That's no good.
Although the reference to the master net_device won't physically go away
even if DSA's ->shutdown comes afterwards, remember we have a dev_hold
on it.
The answer to that question lies in this comment above device_link_add:
* A side effect of the link creation is re-ordering of dpm_list and the
* devices_kset list by moving the consumer device and all devices depending
* on it to the ends of these lists (that does not happen to devices that have
* not been registered when this function is called).
so the fact that DSA uses device_link_add towards its master is not
exactly for nothing. device_shutdown() walks devices_kset from the back,
so this is our guarantee that DSA's shutdown happens before the master's
shutdown.
Fixes: 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings")
Link: https://lore.kernel.org/netdev/20210909095324.12978-1-LinoSanfilippo@gmx.de/
Reported-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-17 13:34:33 +00:00
|
|
|
struct mv88e6xxx_chip *chip;
|
|
|
|
|
|
|
|
if (!ds)
|
|
|
|
return;
|
|
|
|
|
|
|
|
chip = ds->priv;
|
2016-05-10 21:27:21 +00:00
|
|
|
|
2018-02-14 00:07:50 +00:00
|
|
|
if (chip->info->ptp_support) {
|
|
|
|
mv88e6xxx_hwtstamp_free(chip);
|
2018-02-14 00:07:45 +00:00
|
|
|
mv88e6xxx_ptp_free(chip);
|
2018-02-14 00:07:50 +00:00
|
|
|
}
|
2018-02-14 00:07:45 +00:00
|
|
|
|
2016-08-22 14:01:03 +00:00
|
|
|
mv88e6xxx_phy_destroy(chip);
|
2016-06-21 16:28:20 +00:00
|
|
|
mv88e6xxx_unregister_switch(chip);
|
2016-10-16 17:56:49 +00:00
|
|
|
|
2018-03-17 19:21:09 +00: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 19:14:15 +00:00
|
|
|
mv88e6xxx_g1_irq_free(chip);
|
2018-03-17 19:21:09 +00:00
|
|
|
else
|
|
|
|
mv88e6xxx_irq_poll_free(chip);
|
net: dsa: be compatible with masters which unregister on shutdown
Lino reports that on his system with bcmgenet as DSA master and KSZ9897
as a switch, rebooting or shutting down never works properly.
What does the bcmgenet driver have special to trigger this, that other
DSA masters do not? It has an implementation of ->shutdown which simply
calls its ->remove implementation. Otherwise said, it unregisters its
network interface on shutdown.
This message can be seen in a loop, and it hangs the reboot process there:
unregister_netdevice: waiting for eth0 to become free. Usage count = 3
So why 3?
A usage count of 1 is normal for a registered network interface, and any
virtual interface which links itself as an upper of that will increment
it via dev_hold. In the case of DSA, this is the call path:
dsa_slave_create
-> netdev_upper_dev_link
-> __netdev_upper_dev_link
-> __netdev_adjacent_dev_insert
-> dev_hold
So a DSA switch with 3 interfaces will result in a usage count elevated
by two, and netdev_wait_allrefs will wait until they have gone away.
Other stacked interfaces, like VLAN, watch NETDEV_UNREGISTER events and
delete themselves, but DSA cannot just vanish and go poof, at most it
can unbind itself from the switch devices, but that must happen strictly
earlier compared to when the DSA master unregisters its net_device, so
reacting on the NETDEV_UNREGISTER event is way too late.
It seems that it is a pretty established pattern to have a driver's
->shutdown hook redirect to its ->remove hook, so the same code is
executed regardless of whether the driver is unbound from the device, or
the system is just shutting down. As Florian puts it, it is quite a big
hammer for bcmgenet to unregister its net_device during shutdown, but
having a common code path with the driver unbind helps ensure it is well
tested.
So DSA, for better or for worse, has to live with that and engage in an
arms race of implementing the ->shutdown hook too, from all individual
drivers, and do something sane when paired with masters that unregister
their net_device there. The only sane thing to do, of course, is to
unlink from the master.
However, complications arise really quickly.
The pattern of redirecting ->shutdown to ->remove is not unique to
bcmgenet or even to net_device drivers. In fact, SPI controllers do it
too (see dspi_shutdown -> dspi_remove), and presumably, I2C controllers
and MDIO controllers do it too (this is something I have not researched
too deeply, but even if this is not the case today, it is certainly
plausible to happen in the future, and must be taken into consideration).
Since DSA switches might be SPI devices, I2C devices, MDIO devices, the
insane implication is that for the exact same DSA switch device, we
might have both ->shutdown and ->remove getting called.
So we need to do something with that insane environment. The pattern
I've come up with is "if this, then not that", so if either ->shutdown
or ->remove gets called, we set the device's drvdata to NULL, and in the
other hook, we check whether the drvdata is NULL and just do nothing.
This is probably not necessary for platform devices, just for devices on
buses, but I would really insist for consistency among drivers, because
when code is copy-pasted, it is not always copy-pasted from the best
sources.
So depending on whether the DSA switch's ->remove or ->shutdown will get
called first, we cannot really guarantee even for the same driver if
rebooting will result in the same code path on all platforms. But
nonetheless, we need to do something minimally reasonable on ->shutdown
too to fix the bug. Of course, the ->remove will do more (a full
teardown of the tree, with all data structures freed, and this is why
the bug was not caught for so long). The new ->shutdown method is kept
separate from dsa_unregister_switch not because we couldn't have
unregistered the switch, but simply in the interest of doing something
quick and to the point.
The big question is: does the DSA switch's ->shutdown get called earlier
than the DSA master's ->shutdown? If not, there is still a risk that we
might still trigger the WARN_ON in unregister_netdevice that says we are
attempting to unregister a net_device which has uppers. That's no good.
Although the reference to the master net_device won't physically go away
even if DSA's ->shutdown comes afterwards, remember we have a dev_hold
on it.
The answer to that question lies in this comment above device_link_add:
* A side effect of the link creation is re-ordering of dpm_list and the
* devices_kset list by moving the consumer device and all devices depending
* on it to the ends of these lists (that does not happen to devices that have
* not been registered when this function is called).
so the fact that DSA uses device_link_add towards its master is not
exactly for nothing. device_shutdown() walks devices_kset from the back,
so this is our guarantee that DSA's shutdown happens before the master's
shutdown.
Fixes: 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings")
Link: https://lore.kernel.org/netdev/20210909095324.12978-1-LinoSanfilippo@gmx.de/
Reported-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-17 13:34:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void mv88e6xxx_shutdown(struct mdio_device *mdiodev)
|
|
|
|
{
|
|
|
|
struct dsa_switch *ds = dev_get_drvdata(&mdiodev->dev);
|
|
|
|
|
|
|
|
if (!ds)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dsa_switch_shutdown(ds);
|
|
|
|
|
|
|
|
dev_set_drvdata(&mdiodev->dev, NULL);
|
2016-05-10 21:27:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct of_device_id mv88e6xxx_of_match[] = {
|
2016-06-20 17:14:09 +00:00
|
|
|
{
|
|
|
|
.compatible = "marvell,mv88e6085",
|
|
|
|
.data = &mv88e6xxx_table[MV88E6085],
|
|
|
|
},
|
2016-11-21 22:26:57 +00: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 21:27:21 +00:00
|
|
|
{ /* sentinel */ },
|
|
|
|
};
|
|
|
|
|
|
|
|
MODULE_DEVICE_TABLE(of, mv88e6xxx_of_match);
|
|
|
|
|
|
|
|
static struct mdio_driver mv88e6xxx_driver = {
|
|
|
|
.probe = mv88e6xxx_probe,
|
|
|
|
.remove = mv88e6xxx_remove,
|
net: dsa: be compatible with masters which unregister on shutdown
Lino reports that on his system with bcmgenet as DSA master and KSZ9897
as a switch, rebooting or shutting down never works properly.
What does the bcmgenet driver have special to trigger this, that other
DSA masters do not? It has an implementation of ->shutdown which simply
calls its ->remove implementation. Otherwise said, it unregisters its
network interface on shutdown.
This message can be seen in a loop, and it hangs the reboot process there:
unregister_netdevice: waiting for eth0 to become free. Usage count = 3
So why 3?
A usage count of 1 is normal for a registered network interface, and any
virtual interface which links itself as an upper of that will increment
it via dev_hold. In the case of DSA, this is the call path:
dsa_slave_create
-> netdev_upper_dev_link
-> __netdev_upper_dev_link
-> __netdev_adjacent_dev_insert
-> dev_hold
So a DSA switch with 3 interfaces will result in a usage count elevated
by two, and netdev_wait_allrefs will wait until they have gone away.
Other stacked interfaces, like VLAN, watch NETDEV_UNREGISTER events and
delete themselves, but DSA cannot just vanish and go poof, at most it
can unbind itself from the switch devices, but that must happen strictly
earlier compared to when the DSA master unregisters its net_device, so
reacting on the NETDEV_UNREGISTER event is way too late.
It seems that it is a pretty established pattern to have a driver's
->shutdown hook redirect to its ->remove hook, so the same code is
executed regardless of whether the driver is unbound from the device, or
the system is just shutting down. As Florian puts it, it is quite a big
hammer for bcmgenet to unregister its net_device during shutdown, but
having a common code path with the driver unbind helps ensure it is well
tested.
So DSA, for better or for worse, has to live with that and engage in an
arms race of implementing the ->shutdown hook too, from all individual
drivers, and do something sane when paired with masters that unregister
their net_device there. The only sane thing to do, of course, is to
unlink from the master.
However, complications arise really quickly.
The pattern of redirecting ->shutdown to ->remove is not unique to
bcmgenet or even to net_device drivers. In fact, SPI controllers do it
too (see dspi_shutdown -> dspi_remove), and presumably, I2C controllers
and MDIO controllers do it too (this is something I have not researched
too deeply, but even if this is not the case today, it is certainly
plausible to happen in the future, and must be taken into consideration).
Since DSA switches might be SPI devices, I2C devices, MDIO devices, the
insane implication is that for the exact same DSA switch device, we
might have both ->shutdown and ->remove getting called.
So we need to do something with that insane environment. The pattern
I've come up with is "if this, then not that", so if either ->shutdown
or ->remove gets called, we set the device's drvdata to NULL, and in the
other hook, we check whether the drvdata is NULL and just do nothing.
This is probably not necessary for platform devices, just for devices on
buses, but I would really insist for consistency among drivers, because
when code is copy-pasted, it is not always copy-pasted from the best
sources.
So depending on whether the DSA switch's ->remove or ->shutdown will get
called first, we cannot really guarantee even for the same driver if
rebooting will result in the same code path on all platforms. But
nonetheless, we need to do something minimally reasonable on ->shutdown
too to fix the bug. Of course, the ->remove will do more (a full
teardown of the tree, with all data structures freed, and this is why
the bug was not caught for so long). The new ->shutdown method is kept
separate from dsa_unregister_switch not because we couldn't have
unregistered the switch, but simply in the interest of doing something
quick and to the point.
The big question is: does the DSA switch's ->shutdown get called earlier
than the DSA master's ->shutdown? If not, there is still a risk that we
might still trigger the WARN_ON in unregister_netdevice that says we are
attempting to unregister a net_device which has uppers. That's no good.
Although the reference to the master net_device won't physically go away
even if DSA's ->shutdown comes afterwards, remember we have a dev_hold
on it.
The answer to that question lies in this comment above device_link_add:
* A side effect of the link creation is re-ordering of dpm_list and the
* devices_kset list by moving the consumer device and all devices depending
* on it to the ends of these lists (that does not happen to devices that have
* not been registered when this function is called).
so the fact that DSA uses device_link_add towards its master is not
exactly for nothing. device_shutdown() walks devices_kset from the back,
so this is our guarantee that DSA's shutdown happens before the master's
shutdown.
Fixes: 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings")
Link: https://lore.kernel.org/netdev/20210909095324.12978-1-LinoSanfilippo@gmx.de/
Reported-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-17 13:34:33 +00:00
|
|
|
.shutdown = mv88e6xxx_shutdown,
|
2016-05-10 21:27:21 +00:00
|
|
|
.mdiodrv.driver = {
|
|
|
|
.name = "mv88e6085",
|
|
|
|
.of_match_table = mv88e6xxx_of_match,
|
2019-02-05 11:07:28 +00:00
|
|
|
.pm = &mv88e6xxx_pm_ops,
|
2016-05-10 21:27:21 +00:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2019-04-27 17:19:10 +00: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");
|