2019-05-27 08:55:01 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 13:44:02 +00:00
|
|
|
/*
|
2017-06-02 17:06:15 -04:00
|
|
|
* Marvell 88E6xxx Ethernet switch single-chip definition
|
2016-06-21 12:28:19 -04:00
|
|
|
*
|
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
|
|
|
|
|
*/
|
|
|
|
|
|
2017-06-02 17:06:15 -04:00
|
|
|
#ifndef _MV88E6XXX_CHIP_H
|
|
|
|
|
#define _MV88E6XXX_CHIP_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
|
|
|
|
2019-09-07 16:00:49 -04:00
|
|
|
#include <linux/idr.h>
|
2015-08-10 09:09:47 -04:00
|
|
|
#include <linux/if_vlan.h>
|
2016-10-16 19:56:49 +02:00
|
|
|
#include <linux/irq.h>
|
2016-05-10 23:27:22 +02:00
|
|
|
#include <linux/gpio/consumer.h>
|
2018-02-22 22:58:32 +01:00
|
|
|
#include <linux/kthread.h>
|
net: dsa: mv88e6xxx: Support LED control
This adds control over the hardware LEDs in the Marvell
MV88E6xxx DSA switch and enables it for MV88E6352.
This fixes an imminent problem on the Inteno XG6846 which
has a WAN LED that simply do not work with hardware
defaults: driver amendment is necessary.
The patch is modeled after Christian Marangis LED support
code for the QCA8k DSA switch, I got help with the register
definitions from Tim Harvey.
After this patch it is possible to activate hardware link
indication like this (or with a similar script):
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link
This makes the green link indicator come up on any link
speed. It is also possible to be more elaborate, like this:
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link_1000
cd /sys/class/leds/Marvell\ 88E6352:05:01:amber:wan/
echo netdev > trigger
echo 1 > link_100
Making the green LED come on for a gigabit link and the
amber LED come on for a 100 mbit link.
Each port has 2 LED slots (the hardware may use just one or
none) and the hardware triggers are specified in four bits per
LED, and some of the hardware triggers are only available on the
SFP (fiber) uplink. The restrictions are described in the
port.h header file where the registers are described. For
example, selector 1 set for LED 1 on port 5 or 6 will indicate
Fiber 1000 (gigabit) and activity with a blinking LED, but
ONLY for an SFP connection. If port 5/6 is used with something
not SFP, this selector is a noop: something else need to be
selected.
After the previous series rewriting the MV88E6xxx DT
bindings to use YAML a "leds" subnode is already valid
for each port, in my scratch device tree it looks like
this:
leds {
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0>;
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_LAN;
default-state = "off";
linux,default-trigger = "netdev";
};
led@1 {
reg = <1>;
color = <LED_COLOR_ID_AMBER>;
function = LED_FUNCTION_LAN;
default-state = "off";
};
};
This DT config is not yet configuring everything: when the netdev
default trigger is assigned the hw acceleration callbacks are
not called, and there is no way to set the netdev sub-trigger
type (such as link_1000) from the device tree, such as if you want
a gigabit link indicator. This has to be done from userspace at
this point.
We add LED operations to all switches in the 6352 family:
6172, 6176, 6240 and 6352.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241001-mv88e6xxx-leds-v4-1-cc11c4f49b18@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-01 11:27:21 +02:00
|
|
|
#include <linux/leds.h>
|
2017-02-07 15:03:05 -08:00
|
|
|
#include <linux/phy.h>
|
net: dsa: mv88e6xxx: Support LED control
This adds control over the hardware LEDs in the Marvell
MV88E6xxx DSA switch and enables it for MV88E6352.
This fixes an imminent problem on the Inteno XG6846 which
has a WAN LED that simply do not work with hardware
defaults: driver amendment is necessary.
The patch is modeled after Christian Marangis LED support
code for the QCA8k DSA switch, I got help with the register
definitions from Tim Harvey.
After this patch it is possible to activate hardware link
indication like this (or with a similar script):
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link
This makes the green link indicator come up on any link
speed. It is also possible to be more elaborate, like this:
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link_1000
cd /sys/class/leds/Marvell\ 88E6352:05:01:amber:wan/
echo netdev > trigger
echo 1 > link_100
Making the green LED come on for a gigabit link and the
amber LED come on for a 100 mbit link.
Each port has 2 LED slots (the hardware may use just one or
none) and the hardware triggers are specified in four bits per
LED, and some of the hardware triggers are only available on the
SFP (fiber) uplink. The restrictions are described in the
port.h header file where the registers are described. For
example, selector 1 set for LED 1 on port 5 or 6 will indicate
Fiber 1000 (gigabit) and activity with a blinking LED, but
ONLY for an SFP connection. If port 5/6 is used with something
not SFP, this selector is a noop: something else need to be
selected.
After the previous series rewriting the MV88E6xxx DT
bindings to use YAML a "leds" subnode is already valid
for each port, in my scratch device tree it looks like
this:
leds {
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0>;
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_LAN;
default-state = "off";
linux,default-trigger = "netdev";
};
led@1 {
reg = <1>;
color = <LED_COLOR_ID_AMBER>;
function = LED_FUNCTION_LAN;
default-state = "off";
};
};
This DT config is not yet configuring everything: when the netdev
default trigger is assigned the hw acceleration callbacks are
not called, and there is no way to set the netdev sub-trigger
type (such as link_1000) from the device tree, such as if you want
a gigabit link indicator. This has to be done from userspace at
this point.
We add LED operations to all switches in the 6352 family:
6172, 6176, 6240 and 6352.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241001-mv88e6xxx-leds-v4-1-cc11c4f49b18@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-01 11:27:21 +02:00
|
|
|
#include <linux/property.h>
|
2018-02-14 01:07:45 +01:00
|
|
|
#include <linux/ptp_clock_kernel.h>
|
|
|
|
|
#include <linux/timecounter.h>
|
2017-03-28 23:45:06 +02:00
|
|
|
#include <net/dsa.h>
|
2015-08-10 09:09:47 -04:00
|
|
|
|
2021-09-26 19:41:26 +02:00
|
|
|
#define EDSA_HLEN 8
|
2016-02-26 13:16:03 -05:00
|
|
|
#define MV88E6XXX_N_FID 4096
|
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 16:08:55 +01:00
|
|
|
#define MV88E6XXX_N_SID 64
|
2016-02-26 13:16:03 -05: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 19:47:11 +03:00
|
|
|
#define MV88E6XXX_FID_STANDALONE 0
|
|
|
|
|
#define MV88E6XXX_FID_BRIDGED 1
|
|
|
|
|
|
2017-03-30 17:37:09 -04:00
|
|
|
/* PVT limits for 4-bit port and 5-bit switch */
|
|
|
|
|
#define MV88E6XXX_MAX_PVT_SWITCHES 32
|
|
|
|
|
#define MV88E6XXX_MAX_PVT_PORTS 16
|
2021-04-21 14:04:54 +02:00
|
|
|
#define MV88E6XXX_MAX_PVT_ENTRIES \
|
|
|
|
|
(MV88E6XXX_MAX_PVT_SWITCHES * MV88E6XXX_MAX_PVT_PORTS)
|
2017-03-30 17:37:09 -04:00
|
|
|
|
2018-02-14 01:07:46 +01:00
|
|
|
#define MV88E6XXX_MAX_GPIO 16
|
|
|
|
|
|
2017-06-08 18:34:09 -04:00
|
|
|
enum mv88e6xxx_egress_mode {
|
|
|
|
|
MV88E6XXX_EGRESS_MODE_UNMODIFIED,
|
|
|
|
|
MV88E6XXX_EGRESS_MODE_UNTAGGED,
|
|
|
|
|
MV88E6XXX_EGRESS_MODE_TAGGED,
|
|
|
|
|
MV88E6XXX_EGRESS_MODE_ETHERTYPE,
|
|
|
|
|
};
|
|
|
|
|
|
2019-11-07 22:11:13 +01:00
|
|
|
enum mv88e6xxx_egress_direction {
|
|
|
|
|
MV88E6XXX_EGRESS_DIR_INGRESS,
|
|
|
|
|
MV88E6XXX_EGRESS_DIR_EGRESS,
|
|
|
|
|
};
|
|
|
|
|
|
2016-12-03 04:35:19 +01:00
|
|
|
enum mv88e6xxx_frame_mode {
|
|
|
|
|
MV88E6XXX_FRAME_MODE_NORMAL,
|
|
|
|
|
MV88E6XXX_FRAME_MODE_DSA,
|
|
|
|
|
MV88E6XXX_FRAME_MODE_PROVIDER,
|
|
|
|
|
MV88E6XXX_FRAME_MODE_ETHERTYPE,
|
|
|
|
|
};
|
|
|
|
|
|
2016-05-09 13:22:58 -04:00
|
|
|
/* List of supported models */
|
|
|
|
|
enum mv88e6xxx_model {
|
2023-05-30 10:39:15 +02:00
|
|
|
MV88E6020,
|
2023-05-30 10:39:16 +02:00
|
|
|
MV88E6071,
|
2016-05-09 13:22:58 -04:00
|
|
|
MV88E6085,
|
|
|
|
|
MV88E6095,
|
2016-11-22 17:47:21 +01:00
|
|
|
MV88E6097,
|
2016-05-09 13:22:58 -04:00
|
|
|
MV88E6123,
|
|
|
|
|
MV88E6131,
|
2017-01-30 20:29:35 +01:00
|
|
|
MV88E6141,
|
2016-05-09 13:22:58 -04:00
|
|
|
MV88E6161,
|
|
|
|
|
MV88E6165,
|
|
|
|
|
MV88E6171,
|
|
|
|
|
MV88E6172,
|
|
|
|
|
MV88E6175,
|
|
|
|
|
MV88E6176,
|
|
|
|
|
MV88E6185,
|
2016-11-21 23:26:57 +01:00
|
|
|
MV88E6190,
|
|
|
|
|
MV88E6190X,
|
|
|
|
|
MV88E6191,
|
2021-03-17 14:46:42 +01:00
|
|
|
MV88E6191X,
|
|
|
|
|
MV88E6193X,
|
2019-07-31 10:23:46 +02:00
|
|
|
MV88E6220,
|
2016-05-09 13:22:58 -04:00
|
|
|
MV88E6240,
|
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,
|
2016-11-21 23:26:57 +01:00
|
|
|
MV88E6290,
|
2016-05-09 13:22:58 -04:00
|
|
|
MV88E6320,
|
|
|
|
|
MV88E6321,
|
2017-01-30 20:29:34 +01:00
|
|
|
MV88E6341,
|
2016-05-09 13:22:58 -04:00
|
|
|
MV88E6350,
|
|
|
|
|
MV88E6351,
|
|
|
|
|
MV88E6352,
|
2023-05-29 10:02:46 +02:00
|
|
|
MV88E6361,
|
2016-11-21 23:26:57 +01:00
|
|
|
MV88E6390,
|
|
|
|
|
MV88E6390X,
|
2021-03-17 14:46:42 +01:00
|
|
|
MV88E6393X,
|
2016-05-09 13:22:58 -04:00
|
|
|
};
|
|
|
|
|
|
2016-04-17 13:24:00 -04:00
|
|
|
enum mv88e6xxx_family {
|
|
|
|
|
MV88E6XXX_FAMILY_NONE,
|
|
|
|
|
MV88E6XXX_FAMILY_6065, /* 6031 6035 6061 6065 */
|
|
|
|
|
MV88E6XXX_FAMILY_6095, /* 6092 6095 */
|
|
|
|
|
MV88E6XXX_FAMILY_6097, /* 6046 6085 6096 6097 */
|
|
|
|
|
MV88E6XXX_FAMILY_6165, /* 6123 6161 6165 */
|
|
|
|
|
MV88E6XXX_FAMILY_6185, /* 6108 6121 6122 6131 6152 6155 6182 6185 */
|
2023-05-30 10:39:16 +02:00
|
|
|
MV88E6XXX_FAMILY_6250, /* 6220 6250 6020 6071 */
|
2016-04-17 13:24:00 -04:00
|
|
|
MV88E6XXX_FAMILY_6320, /* 6320 6321 */
|
2017-01-30 20:29:34 +01:00
|
|
|
MV88E6XXX_FAMILY_6341, /* 6141 6341 */
|
2016-04-17 13:24:00 -04:00
|
|
|
MV88E6XXX_FAMILY_6351, /* 6171 6175 6350 6351 */
|
|
|
|
|
MV88E6XXX_FAMILY_6352, /* 6172 6176 6240 6352 */
|
2016-11-21 23:26:57 +01:00
|
|
|
MV88E6XXX_FAMILY_6390, /* 6190 6190X 6191 6290 6390 6390X */
|
2023-05-29 10:02:46 +02:00
|
|
|
MV88E6XXX_FAMILY_6393, /* 6191X 6193X 6361 6393X */
|
2016-04-17 13:24:00 -04:00
|
|
|
};
|
|
|
|
|
|
2021-04-20 20:53:07 +02:00
|
|
|
/**
|
|
|
|
|
* enum mv88e6xxx_edsa_support - Ethertype DSA tag support level
|
|
|
|
|
* @MV88E6XXX_EDSA_UNSUPPORTED: Device has no support for EDSA tags
|
|
|
|
|
* @MV88E6XXX_EDSA_UNDOCUMENTED: Documentation indicates that
|
|
|
|
|
* egressing FORWARD frames with an EDSA
|
|
|
|
|
* tag is reserved for future use, but
|
|
|
|
|
* empirical data shows that this mode
|
|
|
|
|
* is supported.
|
|
|
|
|
* @MV88E6XXX_EDSA_SUPPORTED: EDSA tags are fully supported.
|
|
|
|
|
*/
|
|
|
|
|
enum mv88e6xxx_edsa_support {
|
|
|
|
|
MV88E6XXX_EDSA_UNSUPPORTED = 0,
|
|
|
|
|
MV88E6XXX_EDSA_UNDOCUMENTED,
|
|
|
|
|
MV88E6XXX_EDSA_SUPPORTED,
|
|
|
|
|
};
|
|
|
|
|
|
2017-02-09 00:00:43 +01:00
|
|
|
struct mv88e6xxx_ops;
|
|
|
|
|
|
2016-04-17 13:23:59 -04:00
|
|
|
struct mv88e6xxx_info {
|
2016-04-17 13:24:00 -04:00
|
|
|
enum mv88e6xxx_family family;
|
2016-04-17 13:23:59 -04:00
|
|
|
u16 prod_num;
|
|
|
|
|
const char *name;
|
2016-04-17 13:24:02 -04:00
|
|
|
unsigned int num_databases;
|
2019-11-05 01:12:58 +01:00
|
|
|
unsigned int num_macs;
|
2016-04-17 13:24:01 -04:00
|
|
|
unsigned int num_ports;
|
2018-03-17 20:32:04 +01:00
|
|
|
unsigned int num_internal_phys;
|
2018-02-14 01:07:46 +01:00
|
|
|
unsigned int num_gpio;
|
2017-05-01 14:05:10 -04:00
|
|
|
unsigned int max_vid;
|
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 16:08:55 +01:00
|
|
|
unsigned int max_sid;
|
2016-06-20 13:14:10 -04:00
|
|
|
unsigned int port_base_addr;
|
2018-05-05 20:58:22 +02:00
|
|
|
unsigned int phy_base_addr;
|
2016-09-29 12:21:53 -04:00
|
|
|
unsigned int global1_addr;
|
2017-07-17 13:03:44 -04:00
|
|
|
unsigned int global2_addr;
|
2016-07-18 20:45:39 -04:00
|
|
|
unsigned int age_time_coeff;
|
2016-10-16 19:56:49 +02:00
|
|
|
unsigned int g1_irqs;
|
2017-07-17 13:03:40 -04:00
|
|
|
unsigned int g2_irqs;
|
2024-12-07 15:18:44 -06:00
|
|
|
int stats_type;
|
2017-03-30 17:37:07 -04:00
|
|
|
bool pvt;
|
2017-07-17 13:03:46 -04:00
|
|
|
|
2019-07-31 10:23:48 +02:00
|
|
|
/* Mark certain ports as invalid. This is required for example for the
|
|
|
|
|
* MV88E6220 (which is in general a MV88E6250 with 7 ports) but the
|
|
|
|
|
* ports 2-4 are not routet to pins.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int invalid_port_mask;
|
2017-07-17 13:03:46 -04:00
|
|
|
/* Multi-chip Addressing Mode.
|
|
|
|
|
* Some chips respond to only 2 registers of its own SMI device address
|
|
|
|
|
* when it is non-zero, and use indirect access to internal registers.
|
|
|
|
|
*/
|
|
|
|
|
bool multi_chip;
|
2019-06-04 07:34:24 +00:00
|
|
|
/* Dual-chip Addressing Mode
|
|
|
|
|
* Some chips respond to only half of the 32 SMI addresses,
|
|
|
|
|
* allowing two to coexist on the same SMI interface.
|
|
|
|
|
*/
|
|
|
|
|
bool dual_chip;
|
|
|
|
|
|
2021-04-20 20:53:07 +02:00
|
|
|
enum mv88e6xxx_edsa_support edsa_support;
|
2017-03-11 16:12:55 -05:00
|
|
|
|
|
|
|
|
/* Mask for FromPort and ToPort value of PortVec used in ATU Move
|
|
|
|
|
* operation. 0 means that the ATU Move operation is not supported.
|
|
|
|
|
*/
|
|
|
|
|
u8 atu_move_port_mask;
|
2016-09-29 12:22:00 -04:00
|
|
|
const struct mv88e6xxx_ops *ops;
|
2018-02-14 01:07:45 +01:00
|
|
|
|
|
|
|
|
/* Supports PTP */
|
|
|
|
|
bool ptp_support;
|
2023-05-29 10:02:43 +02:00
|
|
|
|
|
|
|
|
/* Internal PHY start index. 0 means that internal PHYs range starts at
|
|
|
|
|
* port 0, 1 means internal PHYs range starts at port 1, etc
|
|
|
|
|
*/
|
|
|
|
|
unsigned int internal_phys_offset;
|
2015-10-30 19:39:48 -04:00
|
|
|
};
|
|
|
|
|
|
2015-08-10 09:09:50 -04:00
|
|
|
struct mv88e6xxx_atu_entry {
|
|
|
|
|
u8 state;
|
|
|
|
|
bool trunk;
|
2017-03-11 16:12:57 -05:00
|
|
|
u16 portvec;
|
2015-08-10 09:09:50 -04:00
|
|
|
u8 mac[ETH_ALEN];
|
|
|
|
|
};
|
|
|
|
|
|
2016-09-29 12:21:58 -04:00
|
|
|
struct mv88e6xxx_vtu_entry {
|
2015-08-13 12:52:19 -04:00
|
|
|
u16 vid;
|
|
|
|
|
u16 fid;
|
|
|
|
|
u8 sid;
|
|
|
|
|
bool valid;
|
2022-02-03 11:16:54 +01:00
|
|
|
bool policy;
|
2017-05-01 14:05:11 -04:00
|
|
|
u8 member[DSA_MAX_PORTS];
|
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 16:08:55 +01:00
|
|
|
u8 state[DSA_MAX_PORTS]; /* Older silicon has no STU */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct mv88e6xxx_stu_entry {
|
|
|
|
|
u8 sid;
|
|
|
|
|
bool valid;
|
2017-05-01 14:05:11 -04:00
|
|
|
u8 state[DSA_MAX_PORTS];
|
2015-08-13 12:52:19 -04:00
|
|
|
};
|
|
|
|
|
|
2016-09-29 12:21:59 -04:00
|
|
|
struct mv88e6xxx_bus_ops;
|
2017-02-09 00:03:42 +01:00
|
|
|
struct mv88e6xxx_irq_ops;
|
2018-02-14 01:07:46 +01:00
|
|
|
struct mv88e6xxx_gpio_ops;
|
2018-02-14 01:07:44 +01:00
|
|
|
struct mv88e6xxx_avb_ops;
|
2018-07-18 22:38:20 +02:00
|
|
|
struct mv88e6xxx_ptp_ops;
|
2023-07-13 09:42:33 +01:00
|
|
|
struct mv88e6xxx_pcs_ops;
|
2024-10-20 14:38:28 +08:00
|
|
|
struct mv88e6xxx_cc_coeffs;
|
2016-06-20 13:14:11 -04:00
|
|
|
|
2016-10-16 19:56:49 +02:00
|
|
|
struct mv88e6xxx_irq {
|
|
|
|
|
u16 masked;
|
|
|
|
|
struct irq_chip chip;
|
|
|
|
|
struct irq_domain *domain;
|
2020-07-05 21:38:07 +02:00
|
|
|
int nirqs;
|
2016-10-16 19:56:49 +02:00
|
|
|
};
|
|
|
|
|
|
2018-02-14 01:07:50 +01:00
|
|
|
/* state flags for mv88e6xxx_port_hwtstamp::state */
|
|
|
|
|
enum {
|
|
|
|
|
MV88E6XXX_HWTSTAMP_ENABLED,
|
|
|
|
|
MV88E6XXX_HWTSTAMP_TX_IN_PROGRESS,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct mv88e6xxx_port_hwtstamp {
|
|
|
|
|
/* Port index */
|
|
|
|
|
int port_id;
|
|
|
|
|
|
|
|
|
|
/* Timestamping state */
|
|
|
|
|
unsigned long state;
|
|
|
|
|
|
|
|
|
|
/* Resources for receive timestamping */
|
|
|
|
|
struct sk_buff_head rx_queue;
|
|
|
|
|
struct sk_buff_head rx_queue2;
|
|
|
|
|
|
|
|
|
|
/* Resources for transmit timestamping */
|
|
|
|
|
unsigned long tx_tstamp_start;
|
|
|
|
|
struct sk_buff *tx_skb;
|
|
|
|
|
u16 tx_seq_id;
|
|
|
|
|
|
|
|
|
|
/* Current timestamp configuration */
|
net: dsa: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()
New timestamping API was introduced in commit 66f7223039c0 ("net: add
NDOs for configuring hardware timestamping") from kernel v6.6. It is
time to convert DSA to the new API, so that the ndo_eth_ioctl() path can
be removed completely.
Move the ds->ops->port_hwtstamp_get() and ds->ops->port_hwtstamp_set()
calls from dsa_user_ioctl() to dsa_user_hwtstamp_get() and
dsa_user_hwtstamp_set().
Due to the fact that the underlying ifreq type changes to
kernel_hwtstamp_config, the drivers and the Ocelot switchdev front-end,
all hooked up directly or indirectly, must also be converted all at once.
The conversion also updates the comment from dsa_port_supports_hwtstamp(),
which is no longer true because kernel_hwtstamp_config is kernel memory
and does not need copy_to_user(). I've deliberated whether it is
necessary to also update "err != -EOPNOTSUPP" to a more general "!err",
but all drivers now either return 0 or -EOPNOTSUPP.
The existing logic from the ocelot_ioctl() function, to avoid
configuring timestamping if the PHY supports the operation, is obsoleted
by more advanced core logic in dev_set_hwtstamp_phylib().
This is only a partial preparation for proper PHY timestamping support.
None of these switch driver currently sets up PTP traps for PHY
timestamping, so setting dev->see_all_hwtstamp_requests is not yet
necessary and the conversion is relatively trivial.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # felix, sja1105, mv88e6xxx
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20250508095236.887789-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08 12:52:36 +03:00
|
|
|
struct kernel_hwtstamp_config tstamp_config;
|
2018-02-14 01:07:50 +01:00
|
|
|
};
|
|
|
|
|
|
2019-09-07 16:00:48 -04:00
|
|
|
enum mv88e6xxx_policy_mapping {
|
|
|
|
|
MV88E6XXX_POLICY_MAPPING_DA,
|
|
|
|
|
MV88E6XXX_POLICY_MAPPING_SA,
|
|
|
|
|
MV88E6XXX_POLICY_MAPPING_VTU,
|
|
|
|
|
MV88E6XXX_POLICY_MAPPING_ETYPE,
|
|
|
|
|
MV88E6XXX_POLICY_MAPPING_PPPOE,
|
|
|
|
|
MV88E6XXX_POLICY_MAPPING_VBAS,
|
|
|
|
|
MV88E6XXX_POLICY_MAPPING_OPT82,
|
|
|
|
|
MV88E6XXX_POLICY_MAPPING_UDP,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum mv88e6xxx_policy_action {
|
|
|
|
|
MV88E6XXX_POLICY_ACTION_NORMAL,
|
|
|
|
|
MV88E6XXX_POLICY_ACTION_MIRROR,
|
|
|
|
|
MV88E6XXX_POLICY_ACTION_TRAP,
|
|
|
|
|
MV88E6XXX_POLICY_ACTION_DISCARD,
|
|
|
|
|
};
|
|
|
|
|
|
2019-09-07 16:00:49 -04:00
|
|
|
struct mv88e6xxx_policy {
|
|
|
|
|
enum mv88e6xxx_policy_mapping mapping;
|
|
|
|
|
enum mv88e6xxx_policy_action action;
|
|
|
|
|
struct ethtool_rx_flow_spec fs;
|
|
|
|
|
u8 addr[ETH_ALEN];
|
|
|
|
|
int port;
|
|
|
|
|
u16 vid;
|
|
|
|
|
};
|
|
|
|
|
|
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 19:47:10 +03:00
|
|
|
struct mv88e6xxx_vlan {
|
|
|
|
|
u16 vid;
|
|
|
|
|
bool valid;
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-01 02:02:31 +01:00
|
|
|
struct mv88e6xxx_port {
|
2018-08-09 15:38:47 +02:00
|
|
|
struct mv88e6xxx_chip *chip;
|
|
|
|
|
int port;
|
net: dsa: mv88e6xxx: Support LED control
This adds control over the hardware LEDs in the Marvell
MV88E6xxx DSA switch and enables it for MV88E6352.
This fixes an imminent problem on the Inteno XG6846 which
has a WAN LED that simply do not work with hardware
defaults: driver amendment is necessary.
The patch is modeled after Christian Marangis LED support
code for the QCA8k DSA switch, I got help with the register
definitions from Tim Harvey.
After this patch it is possible to activate hardware link
indication like this (or with a similar script):
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link
This makes the green link indicator come up on any link
speed. It is also possible to be more elaborate, like this:
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link_1000
cd /sys/class/leds/Marvell\ 88E6352:05:01:amber:wan/
echo netdev > trigger
echo 1 > link_100
Making the green LED come on for a gigabit link and the
amber LED come on for a 100 mbit link.
Each port has 2 LED slots (the hardware may use just one or
none) and the hardware triggers are specified in four bits per
LED, and some of the hardware triggers are only available on the
SFP (fiber) uplink. The restrictions are described in the
port.h header file where the registers are described. For
example, selector 1 set for LED 1 on port 5 or 6 will indicate
Fiber 1000 (gigabit) and activity with a blinking LED, but
ONLY for an SFP connection. If port 5/6 is used with something
not SFP, this selector is a noop: something else need to be
selected.
After the previous series rewriting the MV88E6xxx DT
bindings to use YAML a "leds" subnode is already valid
for each port, in my scratch device tree it looks like
this:
leds {
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0>;
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_LAN;
default-state = "off";
linux,default-trigger = "netdev";
};
led@1 {
reg = <1>;
color = <LED_COLOR_ID_AMBER>;
function = LED_FUNCTION_LAN;
default-state = "off";
};
};
This DT config is not yet configuring everything: when the netdev
default trigger is assigned the hw acceleration callbacks are
not called, and there is no way to set the netdev sub-trigger
type (such as link_1000) from the device tree, such as if you want
a gigabit link indicator. This has to be done from userspace at
this point.
We add LED operations to all switches in the 6352 family:
6172, 6176, 6240 and 6352.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241001-mv88e6xxx-leds-v4-1-cc11c4f49b18@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-01 11:27:21 +02:00
|
|
|
struct fwnode_handle *fwnode;
|
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 19:47:10 +03:00
|
|
|
struct mv88e6xxx_vlan bridge_pvid;
|
2018-03-01 02:02:31 +01:00
|
|
|
u64 serdes_stats[2];
|
2018-03-28 23:50:28 +02:00
|
|
|
u64 atu_member_violation;
|
|
|
|
|
u64 atu_miss_violation;
|
|
|
|
|
u64 atu_full_violation;
|
|
|
|
|
u64 vtu_member_violation;
|
|
|
|
|
u64 vtu_miss_violation;
|
2020-07-19 12:00:35 +01:00
|
|
|
phy_interface_t interface;
|
2018-08-09 15:38:45 +02:00
|
|
|
u8 cmode;
|
2019-11-07 22:11:14 +01:00
|
|
|
bool mirror_ingress;
|
|
|
|
|
bool mirror_egress;
|
2020-09-18 21:11:07 +02:00
|
|
|
struct devlink_region *region;
|
2023-07-13 09:42:33 +01:00
|
|
|
void *pcs_private;
|
2023-01-08 10:48:49 +01:00
|
|
|
|
net: dsa: mv88e6xxx: Support LED control
This adds control over the hardware LEDs in the Marvell
MV88E6xxx DSA switch and enables it for MV88E6352.
This fixes an imminent problem on the Inteno XG6846 which
has a WAN LED that simply do not work with hardware
defaults: driver amendment is necessary.
The patch is modeled after Christian Marangis LED support
code for the QCA8k DSA switch, I got help with the register
definitions from Tim Harvey.
After this patch it is possible to activate hardware link
indication like this (or with a similar script):
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link
This makes the green link indicator come up on any link
speed. It is also possible to be more elaborate, like this:
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link_1000
cd /sys/class/leds/Marvell\ 88E6352:05:01:amber:wan/
echo netdev > trigger
echo 1 > link_100
Making the green LED come on for a gigabit link and the
amber LED come on for a 100 mbit link.
Each port has 2 LED slots (the hardware may use just one or
none) and the hardware triggers are specified in four bits per
LED, and some of the hardware triggers are only available on the
SFP (fiber) uplink. The restrictions are described in the
port.h header file where the registers are described. For
example, selector 1 set for LED 1 on port 5 or 6 will indicate
Fiber 1000 (gigabit) and activity with a blinking LED, but
ONLY for an SFP connection. If port 5/6 is used with something
not SFP, this selector is a noop: something else need to be
selected.
After the previous series rewriting the MV88E6xxx DT
bindings to use YAML a "leds" subnode is already valid
for each port, in my scratch device tree it looks like
this:
leds {
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0>;
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_LAN;
default-state = "off";
linux,default-trigger = "netdev";
};
led@1 {
reg = <1>;
color = <LED_COLOR_ID_AMBER>;
function = LED_FUNCTION_LAN;
default-state = "off";
};
};
This DT config is not yet configuring everything: when the netdev
default trigger is assigned the hw acceleration callbacks are
not called, and there is no way to set the netdev sub-trigger
type (such as link_1000) from the device tree, such as if you want
a gigabit link indicator. This has to be done from userspace at
this point.
We add LED operations to all switches in the 6352 family:
6172, 6176, 6240 and 6352.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241001-mv88e6xxx-leds-v4-1-cc11c4f49b18@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-01 11:27:21 +02:00
|
|
|
/* LED related information */
|
|
|
|
|
bool fiber;
|
|
|
|
|
struct led_classdev led0;
|
|
|
|
|
struct led_classdev led1;
|
|
|
|
|
|
2023-01-08 10:48:49 +01:00
|
|
|
/* MacAuth Bypass control flag */
|
|
|
|
|
bool mab;
|
2020-09-18 21:11:07 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum mv88e6xxx_region_id {
|
|
|
|
|
MV88E6XXX_REGION_GLOBAL1 = 0,
|
|
|
|
|
MV88E6XXX_REGION_GLOBAL2,
|
|
|
|
|
MV88E6XXX_REGION_ATU,
|
2020-11-09 09:29:27 +01:00
|
|
|
MV88E6XXX_REGION_VTU,
|
2022-03-16 16:08:56 +01:00
|
|
|
MV88E6XXX_REGION_STU,
|
2021-04-21 14:04:54 +02:00
|
|
|
MV88E6XXX_REGION_PVT,
|
2020-09-18 21:11:07 +02:00
|
|
|
|
|
|
|
|
_MV88E6XXX_REGION_MAX,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct mv88e6xxx_region_priv {
|
|
|
|
|
enum mv88e6xxx_region_id id;
|
2018-03-01 02:02:31 +01:00
|
|
|
};
|
|
|
|
|
|
2022-03-16 16:08:57 +01:00
|
|
|
struct mv88e6xxx_mst {
|
|
|
|
|
struct list_head node;
|
|
|
|
|
|
|
|
|
|
refcount_t refcnt;
|
|
|
|
|
struct net_device *br;
|
|
|
|
|
u16 msti;
|
|
|
|
|
|
|
|
|
|
struct mv88e6xxx_stu_entry stu;
|
|
|
|
|
};
|
|
|
|
|
|
2023-12-14 14:50:23 +01:00
|
|
|
#define STATS_TYPE_PORT BIT(0)
|
|
|
|
|
#define STATS_TYPE_BANK0 BIT(1)
|
|
|
|
|
#define STATS_TYPE_BANK1 BIT(2)
|
|
|
|
|
|
|
|
|
|
struct mv88e6xxx_hw_stat {
|
|
|
|
|
char string[ETH_GSTRING_LEN];
|
|
|
|
|
size_t size;
|
|
|
|
|
int reg;
|
|
|
|
|
int type;
|
|
|
|
|
};
|
|
|
|
|
|
2016-06-21 12:28:20 -04:00
|
|
|
struct mv88e6xxx_chip {
|
2016-04-17 13:23:59 -04:00
|
|
|
const struct mv88e6xxx_info *info;
|
|
|
|
|
|
2021-04-20 20:53:07 +02:00
|
|
|
/* Currently configured tagging protocol */
|
|
|
|
|
enum dsa_tag_protocol tag_protocol;
|
|
|
|
|
|
2016-04-13 02:40:40 +02:00
|
|
|
/* The dsa_switch this private structure is related to */
|
|
|
|
|
struct dsa_switch *ds;
|
|
|
|
|
|
2016-04-28 21:24:06 -04:00
|
|
|
/* The device this structure is associated to */
|
|
|
|
|
struct device *dev;
|
|
|
|
|
|
2016-06-20 13:14:05 -04:00
|
|
|
/* This mutex protects the access to the switch registers */
|
|
|
|
|
struct mutex reg_lock;
|
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-04-13 02:40:42 +02:00
|
|
|
/* The MII bus and the address on the bus that is used to
|
|
|
|
|
* communication with the switch
|
|
|
|
|
*/
|
2016-09-29 12:21:59 -04:00
|
|
|
const struct mv88e6xxx_bus_ops *smi_ops;
|
2016-04-13 02:40:42 +02:00
|
|
|
struct mii_bus *bus;
|
|
|
|
|
int sw_addr;
|
|
|
|
|
|
2013-01-08 16:05:53 +00:00
|
|
|
/* Handles automatic disabling and re-enabling of the PHY
|
2008-10-07 13:45:18 +00:00
|
|
|
* polling unit.
|
|
|
|
|
*/
|
2016-09-29 12:21:59 -04:00
|
|
|
const struct mv88e6xxx_bus_ops *phy_ops;
|
2008-10-07 13:45:18 +00:00
|
|
|
struct mutex ppu_mutex;
|
|
|
|
|
int ppu_disabled;
|
|
|
|
|
struct work_struct ppu_work;
|
|
|
|
|
struct timer_list ppu_timer;
|
|
|
|
|
|
2013-01-08 16:05:53 +00:00
|
|
|
/* This mutex serialises access to the statistics unit.
|
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
|
|
|
* Hold this mutex over snapshot + dump sequences.
|
|
|
|
|
*/
|
|
|
|
|
struct mutex stats_mutex;
|
2014-10-29 10:44:56 -07:00
|
|
|
|
2016-05-10 23:27:22 +02:00
|
|
|
/* A switch may have a GPIO line tied to its reset pin. Parse
|
|
|
|
|
* this from the device tree, and use it before performing
|
|
|
|
|
* switch soft reset.
|
|
|
|
|
*/
|
|
|
|
|
struct gpio_desc *reset;
|
2016-05-10 23:27:25 +02:00
|
|
|
|
|
|
|
|
/* set to size of eeprom if supported by the switch */
|
2018-05-19 22:31:35 +02:00
|
|
|
u32 eeprom_len;
|
2016-06-04 21:17:06 +02:00
|
|
|
|
2017-01-24 14:53:50 +01:00
|
|
|
/* List of mdio busses */
|
|
|
|
|
struct list_head mdios;
|
2016-10-16 19:56:49 +02:00
|
|
|
|
2019-09-07 16:00:49 -04:00
|
|
|
/* Policy Control List IDs and rules */
|
|
|
|
|
struct idr policies;
|
|
|
|
|
|
2016-10-16 19:56:49 +02:00
|
|
|
/* There can be two interrupt controllers, which are chained
|
|
|
|
|
* off a GPIO as interrupt source
|
|
|
|
|
*/
|
|
|
|
|
struct mv88e6xxx_irq g1_irq;
|
|
|
|
|
struct mv88e6xxx_irq g2_irq;
|
|
|
|
|
int irq;
|
2020-02-08 16:54:32 +01:00
|
|
|
char irq_name[64];
|
2016-11-20 20:14:18 +01:00
|
|
|
int device_irq;
|
2020-02-08 16:54:32 +01:00
|
|
|
char device_irq_name[64];
|
2017-02-09 00:03:42 +01:00
|
|
|
int watchdog_irq;
|
2020-02-08 16:54:32 +01:00
|
|
|
char watchdog_irq_name[64];
|
2018-03-01 02:02:31 +01:00
|
|
|
|
2018-01-14 02:32:44 +01:00
|
|
|
int atu_prob_irq;
|
2020-02-08 16:54:32 +01:00
|
|
|
char atu_prob_irq_name[64];
|
2018-01-14 02:32:45 +01:00
|
|
|
int vtu_prob_irq;
|
2020-02-08 16:54:32 +01:00
|
|
|
char vtu_prob_irq_name[64];
|
2018-02-22 22:58:32 +01:00
|
|
|
struct kthread_worker *kworker;
|
|
|
|
|
struct kthread_delayed_work irq_poll_work;
|
2018-02-14 01:07:45 +01:00
|
|
|
|
2018-02-14 01:07:46 +01:00
|
|
|
/* GPIO resources */
|
|
|
|
|
u8 gpio_data[2];
|
|
|
|
|
|
2018-02-14 01:07:45 +01:00
|
|
|
/* This cyclecounter abstracts the switch PTP time.
|
|
|
|
|
* reg_lock must be held for any operation that read()s.
|
|
|
|
|
*/
|
|
|
|
|
struct cyclecounter tstamp_cc;
|
|
|
|
|
struct timecounter tstamp_tc;
|
|
|
|
|
struct delayed_work overflow_work;
|
2024-10-20 14:38:29 +08:00
|
|
|
const struct mv88e6xxx_cc_coeffs *cc_coeffs;
|
2018-02-14 01:07:45 +01:00
|
|
|
|
|
|
|
|
struct ptp_clock *ptp_clock;
|
|
|
|
|
struct ptp_clock_info ptp_clock_info;
|
2018-02-14 01:07:47 +01:00
|
|
|
struct delayed_work tai_event_work;
|
|
|
|
|
struct ptp_pin_desc pin_config[MV88E6XXX_MAX_GPIO];
|
|
|
|
|
u16 trig_config;
|
|
|
|
|
u16 evcap_config;
|
2018-07-18 22:38:25 +02:00
|
|
|
u16 enable_count;
|
2018-02-14 01:07:50 +01:00
|
|
|
|
2019-11-07 22:11:14 +01:00
|
|
|
/* Current ingress and egress monitor ports */
|
|
|
|
|
int egress_dest_port;
|
|
|
|
|
int ingress_dest_port;
|
|
|
|
|
|
2018-02-14 01:07:50 +01:00
|
|
|
/* Per-port timestamping resources. */
|
|
|
|
|
struct mv88e6xxx_port_hwtstamp port_hwtstamp[DSA_MAX_PORTS];
|
2018-03-01 02:02:31 +01:00
|
|
|
|
|
|
|
|
/* Array of port structures. */
|
|
|
|
|
struct mv88e6xxx_port ports[DSA_MAX_PORTS];
|
2020-09-18 21:11:07 +02:00
|
|
|
|
|
|
|
|
/* devlink regions */
|
|
|
|
|
struct devlink_region *regions[_MV88E6XXX_REGION_MAX];
|
2022-03-16 16:08:57 +01:00
|
|
|
|
|
|
|
|
/* Bridge MST to SID mappings */
|
|
|
|
|
struct list_head msts;
|
2024-10-07 10:29:05 +13:00
|
|
|
|
|
|
|
|
/* FID map */
|
|
|
|
|
DECLARE_BITMAP(fid_bitmap, MV88E6XXX_N_FID);
|
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-09-29 12:21:59 -04:00
|
|
|
struct mv88e6xxx_bus_ops {
|
2016-06-21 12:28:20 -04:00
|
|
|
int (*read)(struct mv88e6xxx_chip *chip, int addr, int reg, u16 *val);
|
|
|
|
|
int (*write)(struct mv88e6xxx_chip *chip, int addr, int reg, u16 val);
|
2022-01-28 17:26:50 +01:00
|
|
|
int (*init)(struct mv88e6xxx_chip *chip);
|
2016-06-20 13:14:11 -04:00
|
|
|
};
|
|
|
|
|
|
2017-01-24 14:53:49 +01:00
|
|
|
struct mv88e6xxx_mdio_bus {
|
2017-01-24 14:53:50 +01:00
|
|
|
struct mii_bus *bus;
|
2017-01-24 14:53:49 +01:00
|
|
|
struct mv88e6xxx_chip *chip;
|
2017-01-24 14:53:50 +01:00
|
|
|
struct list_head list;
|
|
|
|
|
bool external;
|
2017-01-24 14:53:49 +01:00
|
|
|
};
|
|
|
|
|
|
2016-09-29 12:22:00 -04:00
|
|
|
struct mv88e6xxx_ops {
|
2019-01-09 00:24:03 +01:00
|
|
|
/* Switch Setup Errata, called early in the switch setup to
|
|
|
|
|
* allow any errata actions to be performed
|
|
|
|
|
*/
|
|
|
|
|
int (*setup_errata)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
|
2018-05-11 17:16:35 -04:00
|
|
|
int (*ieee_pri_map)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
int (*ip_pri_map)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
|
2017-06-19 10:55:36 -04:00
|
|
|
/* Ingress Rate Limit unit (IRL) operations */
|
|
|
|
|
int (*irl_init_all)(struct mv88e6xxx_chip *chip, int port);
|
|
|
|
|
|
2016-09-29 12:22:02 -04:00
|
|
|
int (*get_eeprom)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct ethtool_eeprom *eeprom, u8 *data);
|
|
|
|
|
int (*set_eeprom)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct ethtool_eeprom *eeprom, u8 *data);
|
|
|
|
|
|
2016-09-29 12:22:01 -04:00
|
|
|
int (*set_switch_mac)(struct mv88e6xxx_chip *chip, u8 *addr);
|
|
|
|
|
|
2017-01-24 14:53:48 +01:00
|
|
|
int (*phy_read)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mii_bus *bus,
|
|
|
|
|
int addr, int reg, u16 *val);
|
|
|
|
|
int (*phy_write)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mii_bus *bus,
|
|
|
|
|
int addr, int reg, u16 val);
|
2016-11-04 03:23:32 +01:00
|
|
|
|
2023-01-09 16:30:51 +01:00
|
|
|
int (*phy_read_c45)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mii_bus *bus,
|
|
|
|
|
int addr, int devad, int reg, u16 *val);
|
|
|
|
|
int (*phy_write_c45)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mii_bus *bus,
|
|
|
|
|
int addr, int devad, int reg, u16 val);
|
|
|
|
|
|
2017-07-17 13:03:43 -04:00
|
|
|
/* Priority Override Table operations */
|
|
|
|
|
int (*pot_clear)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
|
2016-12-05 17:30:28 -05:00
|
|
|
/* PHY Polling Unit (PPU) operations */
|
|
|
|
|
int (*ppu_enable)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
int (*ppu_disable)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
|
2024-04-23 09:47:48 +02:00
|
|
|
/* Additional handlers to run before and after hard reset, to make sure
|
|
|
|
|
* that the switch and EEPROM are in a good state.
|
|
|
|
|
*/
|
|
|
|
|
int (*hardware_reset_pre)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
int (*hardware_reset_post)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
|
2016-12-05 17:30:27 -05:00
|
|
|
/* Switch Software Reset */
|
|
|
|
|
int (*reset)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
|
2016-11-04 03:23:34 +01:00
|
|
|
/* RGMII Receive/Transmit Timing Control
|
|
|
|
|
* Add delay on PHY_INTERFACE_MODE_RGMII_*ID, no delay otherwise.
|
|
|
|
|
*/
|
|
|
|
|
int (*port_set_rgmii_delay)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
phy_interface_t mode);
|
|
|
|
|
|
2016-11-04 03:23:32 +01:00
|
|
|
#define LINK_FORCED_DOWN 0
|
|
|
|
|
#define LINK_FORCED_UP 1
|
|
|
|
|
#define LINK_UNFORCED -2
|
|
|
|
|
|
|
|
|
|
/* Port's MAC link state
|
|
|
|
|
* Use LINK_FORCED_UP or LINK_FORCED_DOWN to force link up or down,
|
|
|
|
|
* or LINK_UNFORCED for normal link detection.
|
|
|
|
|
*/
|
|
|
|
|
int (*port_set_link)(struct mv88e6xxx_chip *chip, int port, int link);
|
2016-11-04 03:23:33 +01:00
|
|
|
|
2020-11-24 17:34:37 +13:00
|
|
|
/* Synchronise the port link state with that of the SERDES
|
|
|
|
|
*/
|
|
|
|
|
int (*port_sync_link)(struct mv88e6xxx_chip *chip, int port, unsigned int mode, bool isup);
|
|
|
|
|
|
2018-08-09 15:38:37 +02:00
|
|
|
#define PAUSE_ON 1
|
|
|
|
|
#define PAUSE_OFF 0
|
|
|
|
|
|
|
|
|
|
/* Enable/disable sending Pause */
|
|
|
|
|
int (*port_set_pause)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
int pause);
|
|
|
|
|
|
2016-11-04 03:23:35 +01:00
|
|
|
#define SPEED_UNFORCED -2
|
2020-03-14 10:15:53 +00:00
|
|
|
#define DUPLEX_UNFORCED -2
|
2016-11-04 03:23:35 +01:00
|
|
|
|
2020-03-14 10:15:53 +00:00
|
|
|
/* Port's MAC speed (in Mbps) and MAC duplex mode
|
2016-11-04 03:23:35 +01:00
|
|
|
*
|
|
|
|
|
* Depending on the chip, 10, 100, 200, 1000, 2500, 10000 are valid.
|
2022-06-21 10:37:40 +01:00
|
|
|
* Use SPEED_UNFORCED for normal detection.
|
2020-03-14 10:15:53 +00:00
|
|
|
*
|
|
|
|
|
* Use DUPLEX_HALF or DUPLEX_FULL to force half or full duplex,
|
|
|
|
|
* or DUPLEX_UNFORCED for normal duplex detection.
|
2016-11-04 03:23:35 +01:00
|
|
|
*/
|
2020-03-14 10:15:53 +00:00
|
|
|
int (*port_set_speed_duplex)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
int speed, int duplex);
|
2016-11-21 23:26:58 +01:00
|
|
|
|
2019-03-08 01:21:27 +01:00
|
|
|
/* What interface mode should be used for maximum speed? */
|
2023-05-29 10:02:45 +02:00
|
|
|
phy_interface_t (*port_max_speed_mode)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
int port);
|
2019-03-08 01:21:27 +01:00
|
|
|
|
2016-12-03 04:35:16 +01:00
|
|
|
int (*port_tag_remap)(struct mv88e6xxx_chip *chip, int port);
|
|
|
|
|
|
2019-09-07 16:00:48 -04:00
|
|
|
int (*port_set_policy)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
enum mv88e6xxx_policy_mapping mapping,
|
|
|
|
|
enum mv88e6xxx_policy_action action);
|
|
|
|
|
|
2016-12-03 04:35:19 +01:00
|
|
|
int (*port_set_frame_mode)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
enum mv88e6xxx_frame_mode mode);
|
net: dsa: act as passthrough for bridge port flags
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask that has a single bit set - therefore only one feature
should change. However, DSA currently groups together unicast and
multicast flooding in the .port_egress_floods method, which limits our
options when we try to add support for turning off broadcast flooding:
do we extend .port_egress_floods with a third parameter which b53 and
mv88e6xxx will ignore? But that means that the DSA layer, which
currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
see that .port_egress_floods is implemented, and will report that all 3
types of flooding are supported - not necessarily true.
Another configuration is when the user specifies more than one flag at
the same time, in the same netlink message. If we were to create one
individual function per offloadable bridge port flag, we would limit the
expressiveness of the switch driver of refusing certain combinations of
flag values. For example, a switch may not have an explicit knob for
flooding of unknown multicast, just for flooding in general. In that
case, the only correct thing to do is to allow changes to BR_FLOOD and
BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
a separate .port_set_unicast_flood and .port_set_multicast_flood would
not allow the driver to possibly reject that.
Also, DSA doesn't consider it necessary to inform the driver that a
SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
just calls .port_egress_floods for the CPU port. When we'll add support
for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
problem because the flood settings will need to be held statefully in
the DSA middle layer, otherwise changing the mrouter port attribute will
impact the flooding attribute. And that's _assuming_ that the underlying
hardware doesn't have anything else to do when a multicast router
attaches to a port than flood unknown traffic to it. If it does, there
will need to be a dedicated .port_set_mrouter anyway.
So we need to let the DSA drivers see the exact form that the bridge
passes this switchdev attribute in, otherwise we are standing in the
way. Therefore we also need to use this form of language when
communicating to the driver that it needs to configure its initial
(before bridge join) and final (after bridge leave) port flags.
The b53 and mv88e6xxx drivers are converted to the passthrough API and
their implementation of .port_egress_floods is split into two: a
function that configures unicast flooding and another for multicast.
The mv88e6xxx implementation is quite hairy, and it turns out that
the implementations of unknown unicast flooding are actually the same
for 6185 and for 6352:
behind the confusing names actually lie two individual bits:
NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
so there was no reason to entangle them in the first place.
Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
PORT_CTL0, which has the exact same bit index. I have left the
implementations separate though, for the only reason that the names are
different enough to confuse me, since I am not able to double-check with
a user manual. The multicast flooding setting for 6185 is in a different
register than for 6352 though.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 17:15:56 +02:00
|
|
|
int (*port_set_ucast_flood)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
bool unicast);
|
|
|
|
|
int (*port_set_mcast_flood)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
bool multicast);
|
2016-12-03 04:35:19 +01:00
|
|
|
int (*port_set_ether_type)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
u16 etype);
|
2017-06-08 18:34:13 -04:00
|
|
|
int (*port_set_jumbo_size)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
size_t size);
|
2016-12-03 04:35:19 +01:00
|
|
|
|
2016-12-03 04:45:18 +01:00
|
|
|
int (*port_egress_rate_limiting)(struct mv88e6xxx_chip *chip, int port);
|
2017-06-08 18:34:12 -04:00
|
|
|
int (*port_pause_limit)(struct mv88e6xxx_chip *chip, int port, u8 in,
|
|
|
|
|
u8 out);
|
2017-03-11 16:13:01 -05:00
|
|
|
int (*port_disable_learn_limit)(struct mv88e6xxx_chip *chip, int port);
|
2017-03-11 16:13:02 -05:00
|
|
|
int (*port_disable_pri_override)(struct mv88e6xxx_chip *chip, int port);
|
2019-07-31 10:23:49 +02:00
|
|
|
int (*port_setup_message_port)(struct mv88e6xxx_chip *chip, int port);
|
2016-12-03 04:45:18 +01:00
|
|
|
|
net: dsa: mv88e6xxx: Set the CMODE for mv88e6390 ports 9 & 10
Unlike most ports, ports 9 and 10 of the 6390X family have configurable
PHY modes. Set the mode as part of adjust_link().
Ordering is important, because the SERDES interfaces connected to
ports 9 and 10 can be split and assigned to other ports. The CMODE has
to be correctly set before the SERDES interface on another port can be
configured. Such configuration is likely to be performed in
port_enable() and port_disabled(), called on slave_open() and
slave_close().
The simple case is port 9 and 10 are used for 'CPU' or 'DSA'. In this
case, the CMODE is set via a phy-mode in dsa_cpu_dsa_setup(), which is
called early in the switch setup.
When ports 9 or 10 are used as user ports, and have a fixed-phy, when
the fixed fixed-phy is attached, dsa_slave_adjust_link() is called,
which results in the adjust_link function being called, setting the
cmode. The port_enable() will for other ports will be called much
later.
When ports 9 or 10 are used as user ports and have a real phy attached
which does not use all the available SERDES interface, e.g. a 1Gbps
SGMII, there is currently no mechanism in place to set the CMODE of
the port from software. It must be hoped the stripping resistors are
correct.
At the same time, add a function to get the cmode. This will be needed
when configuring the SERDES interfaces.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-04 20:02:50 +01:00
|
|
|
/* CMODE control what PHY mode the MAC will use, eg. SGMII, RGMII, etc.
|
|
|
|
|
* Some chips allow this to be configured on specific ports.
|
|
|
|
|
*/
|
|
|
|
|
int (*port_set_cmode)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
phy_interface_t mode);
|
2018-08-09 15:38:45 +02:00
|
|
|
int (*port_get_cmode)(struct mv88e6xxx_chip *chip, int port, u8 *cmode);
|
net: dsa: mv88e6xxx: Set the CMODE for mv88e6390 ports 9 & 10
Unlike most ports, ports 9 and 10 of the 6390X family have configurable
PHY modes. Set the mode as part of adjust_link().
Ordering is important, because the SERDES interfaces connected to
ports 9 and 10 can be split and assigned to other ports. The CMODE has
to be correctly set before the SERDES interface on another port can be
configured. Such configuration is likely to be performed in
port_enable() and port_disabled(), called on slave_open() and
slave_close().
The simple case is port 9 and 10 are used for 'CPU' or 'DSA'. In this
case, the CMODE is set via a phy-mode in dsa_cpu_dsa_setup(), which is
called early in the switch setup.
When ports 9 or 10 are used as user ports, and have a fixed-phy, when
the fixed fixed-phy is attached, dsa_slave_adjust_link() is called,
which results in the adjust_link function being called, setting the
cmode. The port_enable() will for other ports will be called much
later.
When ports 9 or 10 are used as user ports and have a real phy attached
which does not use all the available SERDES interface, e.g. a 1Gbps
SGMII, there is currently no mechanism in place to set the CMODE of
the port from software. It must be hoped the stripping resistors are
correct.
At the same time, add a function to get the cmode. This will be needed
when configuring the SERDES interfaces.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-04 20:02:50 +01:00
|
|
|
|
net: dsa: mv88e6xxx: Support LED control
This adds control over the hardware LEDs in the Marvell
MV88E6xxx DSA switch and enables it for MV88E6352.
This fixes an imminent problem on the Inteno XG6846 which
has a WAN LED that simply do not work with hardware
defaults: driver amendment is necessary.
The patch is modeled after Christian Marangis LED support
code for the QCA8k DSA switch, I got help with the register
definitions from Tim Harvey.
After this patch it is possible to activate hardware link
indication like this (or with a similar script):
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link
This makes the green link indicator come up on any link
speed. It is also possible to be more elaborate, like this:
cd /sys/class/leds/Marvell\ 88E6352:05:00:green:wan/
echo netdev > trigger
echo 1 > link_1000
cd /sys/class/leds/Marvell\ 88E6352:05:01:amber:wan/
echo netdev > trigger
echo 1 > link_100
Making the green LED come on for a gigabit link and the
amber LED come on for a 100 mbit link.
Each port has 2 LED slots (the hardware may use just one or
none) and the hardware triggers are specified in four bits per
LED, and some of the hardware triggers are only available on the
SFP (fiber) uplink. The restrictions are described in the
port.h header file where the registers are described. For
example, selector 1 set for LED 1 on port 5 or 6 will indicate
Fiber 1000 (gigabit) and activity with a blinking LED, but
ONLY for an SFP connection. If port 5/6 is used with something
not SFP, this selector is a noop: something else need to be
selected.
After the previous series rewriting the MV88E6xxx DT
bindings to use YAML a "leds" subnode is already valid
for each port, in my scratch device tree it looks like
this:
leds {
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0>;
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_LAN;
default-state = "off";
linux,default-trigger = "netdev";
};
led@1 {
reg = <1>;
color = <LED_COLOR_ID_AMBER>;
function = LED_FUNCTION_LAN;
default-state = "off";
};
};
This DT config is not yet configuring everything: when the netdev
default trigger is assigned the hw acceleration callbacks are
not called, and there is no way to set the netdev sub-trigger
type (such as link_1000) from the device tree, such as if you want
a gigabit link indicator. This has to be done from userspace at
this point.
We add LED operations to all switches in the 6352 family:
6172, 6176, 6240 and 6352.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241001-mv88e6xxx-leds-v4-1-cc11c4f49b18@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-01 11:27:21 +02:00
|
|
|
/* LED control */
|
|
|
|
|
int (*port_setup_leds)(struct mv88e6xxx_chip *chip, int port);
|
|
|
|
|
|
2017-02-04 20:15:28 +01:00
|
|
|
/* Some devices have a per port register indicating what is
|
|
|
|
|
* the upstream port this port should forward to.
|
|
|
|
|
*/
|
|
|
|
|
int (*port_set_upstream_port)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
int upstream_port);
|
|
|
|
|
|
2016-11-21 23:26:58 +01:00
|
|
|
/* Snapshot the statistics for a port. The statistics can then
|
|
|
|
|
* be read back a leisure but still with a consistent view.
|
|
|
|
|
*/
|
|
|
|
|
int (*stats_snapshot)(struct mv88e6xxx_chip *chip, int port);
|
2016-11-21 23:27:01 +01:00
|
|
|
|
|
|
|
|
/* Set the histogram mode for statistics, when the control registers
|
|
|
|
|
* are separated out of the STATS_OP register.
|
|
|
|
|
*/
|
|
|
|
|
int (*stats_set_histogram)(struct mv88e6xxx_chip *chip);
|
2016-09-29 12:22:00 -04:00
|
|
|
|
2016-11-21 23:27:02 +01:00
|
|
|
/* Return the number of strings describing statistics */
|
|
|
|
|
int (*stats_get_sset_count)(struct mv88e6xxx_chip *chip);
|
2024-10-27 21:48:28 -07:00
|
|
|
void (*stats_get_strings)(struct mv88e6xxx_chip *chip, uint8_t **data);
|
2023-12-14 14:50:23 +01:00
|
|
|
size_t (*stats_get_stat)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
const struct mv88e6xxx_hw_stat *stat,
|
|
|
|
|
uint64_t *data);
|
2017-06-08 18:34:11 -04:00
|
|
|
int (*set_cpu_port)(struct mv88e6xxx_chip *chip, int port);
|
2019-11-07 22:11:13 +01:00
|
|
|
int (*set_egress_port)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
enum mv88e6xxx_egress_direction direction,
|
|
|
|
|
int port);
|
2018-05-09 11:38:49 -04:00
|
|
|
|
|
|
|
|
#define MV88E6XXX_CASCADE_PORT_NONE 0xe
|
|
|
|
|
#define MV88E6XXX_CASCADE_PORT_MULTIPLE 0xf
|
|
|
|
|
|
|
|
|
|
int (*set_cascade_port)(struct mv88e6xxx_chip *chip, int port);
|
|
|
|
|
|
2017-02-09 00:03:42 +01:00
|
|
|
const struct mv88e6xxx_irq_ops *watchdog_ops;
|
2016-12-03 04:45:16 +01:00
|
|
|
|
|
|
|
|
int (*mgmt_rsvd2cpu)(struct mv88e6xxx_chip *chip);
|
2017-05-01 14:05:22 -04:00
|
|
|
|
2019-08-26 23:31:52 +02:00
|
|
|
/* SERDES lane mapping */
|
2021-03-17 14:46:40 +01:00
|
|
|
int (*serdes_get_lane)(struct mv88e6xxx_chip *chip, int port);
|
2019-08-26 23:31:52 +02:00
|
|
|
|
2018-08-09 15:38:48 +02:00
|
|
|
/* SERDES interrupt handling */
|
2019-08-31 16:18:29 -04:00
|
|
|
unsigned int (*serdes_irq_mapping)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
int port);
|
2018-08-09 15:38:48 +02:00
|
|
|
|
2018-03-01 02:02:29 +01:00
|
|
|
/* Statistics from the SERDES interface */
|
|
|
|
|
int (*serdes_get_sset_count)(struct mv88e6xxx_chip *chip, int port);
|
2024-10-27 21:48:28 -07:00
|
|
|
int (*serdes_get_strings)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint8_t **data);
|
2023-12-14 14:50:24 +01:00
|
|
|
size_t (*serdes_get_stats)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
uint64_t *data);
|
2018-03-01 02:02:29 +01:00
|
|
|
|
2020-02-16 18:54:13 +01:00
|
|
|
/* SERDES registers for ethtool */
|
|
|
|
|
int (*serdes_get_regs_len)(struct mv88e6xxx_chip *chip, int port);
|
|
|
|
|
void (*serdes_get_regs)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
void *_p);
|
|
|
|
|
|
2022-02-10 18:48:23 +01:00
|
|
|
/* SERDES SGMII/Fiber Output Amplitude */
|
|
|
|
|
int (*serdes_set_tx_amplitude)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
int val);
|
|
|
|
|
|
2019-10-25 01:03:52 +02:00
|
|
|
/* Address Translation Unit operations */
|
|
|
|
|
int (*atu_get_hash)(struct mv88e6xxx_chip *chip, u8 *hash);
|
|
|
|
|
int (*atu_set_hash)(struct mv88e6xxx_chip *chip, u8 hash);
|
|
|
|
|
|
2017-05-01 14:05:22 -04:00
|
|
|
/* VLAN Translation Unit operations */
|
|
|
|
|
int (*vtu_getnext)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mv88e6xxx_vtu_entry *entry);
|
2017-05-01 14:05:23 -04:00
|
|
|
int (*vtu_loadpurge)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mv88e6xxx_vtu_entry *entry);
|
2018-02-14 01:07:44 +01: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 16:08:55 +01:00
|
|
|
/* Spanning Tree Unit operations */
|
|
|
|
|
int (*stu_getnext)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mv88e6xxx_stu_entry *entry);
|
|
|
|
|
int (*stu_loadpurge)(struct mv88e6xxx_chip *chip,
|
|
|
|
|
struct mv88e6xxx_stu_entry *entry);
|
|
|
|
|
|
2018-02-14 01:07:46 +01:00
|
|
|
/* GPIO operations */
|
|
|
|
|
const struct mv88e6xxx_gpio_ops *gpio_ops;
|
|
|
|
|
|
2018-02-14 01:07:44 +01:00
|
|
|
/* Interface to the AVB/PTP registers */
|
|
|
|
|
const struct mv88e6xxx_avb_ops *avb_ops;
|
2018-05-09 11:38:51 -04:00
|
|
|
|
|
|
|
|
/* Remote Management Unit operations */
|
|
|
|
|
int (*rmu_disable)(struct mv88e6xxx_chip *chip);
|
2018-07-18 22:38:20 +02:00
|
|
|
|
|
|
|
|
/* Precision Time Protocol operations */
|
|
|
|
|
const struct mv88e6xxx_ptp_ops *ptp_ops;
|
2018-08-09 15:38:39 +02:00
|
|
|
|
|
|
|
|
/* Phylink */
|
2022-02-03 13:30:42 +00:00
|
|
|
void (*phylink_get_caps)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
struct phylink_config *config);
|
2020-07-24 11:21:22 +12:00
|
|
|
|
2023-07-13 09:42:33 +01:00
|
|
|
const struct mv88e6xxx_pcs_ops *pcs_ops;
|
|
|
|
|
|
2020-07-24 11:21:22 +12:00
|
|
|
/* Max Frame Size */
|
|
|
|
|
int (*set_max_frame_size)(struct mv88e6xxx_chip *chip, int mtu);
|
2015-12-23 13:23:17 +01:00
|
|
|
};
|
|
|
|
|
|
2017-02-09 00:03:42 +01:00
|
|
|
struct mv88e6xxx_irq_ops {
|
|
|
|
|
/* Action to be performed when the interrupt happens */
|
|
|
|
|
int (*irq_action)(struct mv88e6xxx_chip *chip, int irq);
|
|
|
|
|
/* Setup the hardware to generate the interrupt */
|
|
|
|
|
int (*irq_setup)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
/* Reset the hardware to stop generating the interrupt */
|
|
|
|
|
void (*irq_free)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
};
|
|
|
|
|
|
2018-02-14 01:07:46 +01:00
|
|
|
struct mv88e6xxx_gpio_ops {
|
|
|
|
|
/* Get/set data on GPIO pin */
|
|
|
|
|
int (*get_data)(struct mv88e6xxx_chip *chip, unsigned int pin);
|
|
|
|
|
int (*set_data)(struct mv88e6xxx_chip *chip, unsigned int pin,
|
|
|
|
|
int value);
|
|
|
|
|
|
|
|
|
|
/* get/set GPIO direction */
|
|
|
|
|
int (*get_dir)(struct mv88e6xxx_chip *chip, unsigned int pin);
|
|
|
|
|
int (*set_dir)(struct mv88e6xxx_chip *chip, unsigned int pin,
|
|
|
|
|
bool input);
|
|
|
|
|
|
|
|
|
|
/* get/set GPIO pin control */
|
|
|
|
|
int (*get_pctl)(struct mv88e6xxx_chip *chip, unsigned int pin,
|
|
|
|
|
int *func);
|
|
|
|
|
int (*set_pctl)(struct mv88e6xxx_chip *chip, unsigned int pin,
|
|
|
|
|
int func);
|
|
|
|
|
};
|
|
|
|
|
|
2018-02-14 01:07:44 +01:00
|
|
|
struct mv88e6xxx_avb_ops {
|
|
|
|
|
/* Access port-scoped Precision Time Protocol registers */
|
|
|
|
|
int (*port_ptp_read)(struct mv88e6xxx_chip *chip, int port, int addr,
|
|
|
|
|
u16 *data, int len);
|
|
|
|
|
int (*port_ptp_write)(struct mv88e6xxx_chip *chip, int port, int addr,
|
|
|
|
|
u16 data);
|
|
|
|
|
|
|
|
|
|
/* Access global Precision Time Protocol registers */
|
|
|
|
|
int (*ptp_read)(struct mv88e6xxx_chip *chip, int addr, u16 *data,
|
|
|
|
|
int len);
|
|
|
|
|
int (*ptp_write)(struct mv88e6xxx_chip *chip, int addr, u16 data);
|
|
|
|
|
|
|
|
|
|
/* Access global Time Application Interface registers */
|
|
|
|
|
int (*tai_read)(struct mv88e6xxx_chip *chip, int addr, u16 *data,
|
|
|
|
|
int len);
|
|
|
|
|
int (*tai_write)(struct mv88e6xxx_chip *chip, int addr, u16 data);
|
|
|
|
|
};
|
|
|
|
|
|
2018-07-18 22:38:20 +02:00
|
|
|
struct mv88e6xxx_ptp_ops {
|
2025-07-01 14:32:25 +02:00
|
|
|
u64 (*clock_read)(struct cyclecounter *cc);
|
2018-07-18 22:38:20 +02:00
|
|
|
int (*ptp_enable)(struct ptp_clock_info *ptp,
|
|
|
|
|
struct ptp_clock_request *rq, int on);
|
|
|
|
|
int (*ptp_verify)(struct ptp_clock_info *ptp, unsigned int pin,
|
|
|
|
|
enum ptp_pin_function func, unsigned int chan);
|
|
|
|
|
void (*event_work)(struct work_struct *ugly);
|
2018-07-18 22:38:23 +02:00
|
|
|
int (*port_enable)(struct mv88e6xxx_chip *chip, int port);
|
|
|
|
|
int (*port_disable)(struct mv88e6xxx_chip *chip, int port);
|
2018-07-18 22:38:25 +02:00
|
|
|
int (*global_enable)(struct mv88e6xxx_chip *chip);
|
|
|
|
|
int (*global_disable)(struct mv88e6xxx_chip *chip);
|
2023-01-13 16:12:58 +01:00
|
|
|
int (*set_ptp_cpu_port)(struct mv88e6xxx_chip *chip, int port);
|
2018-07-18 22:38:20 +02:00
|
|
|
int n_ext_ts;
|
2018-07-18 22:38:23 +02:00
|
|
|
int arr0_sts_reg;
|
|
|
|
|
int arr1_sts_reg;
|
|
|
|
|
int dep_sts_reg;
|
2018-07-18 22:38:24 +02:00
|
|
|
u32 rx_filters;
|
2018-07-18 22:38:20 +02:00
|
|
|
};
|
|
|
|
|
|
2023-07-13 09:42:33 +01:00
|
|
|
struct mv88e6xxx_pcs_ops {
|
|
|
|
|
int (*pcs_init)(struct mv88e6xxx_chip *chip, int port);
|
|
|
|
|
void (*pcs_teardown)(struct mv88e6xxx_chip *chip, int port);
|
|
|
|
|
struct phylink_pcs *(*pcs_select)(struct mv88e6xxx_chip *chip, int port,
|
|
|
|
|
phy_interface_t mode);
|
|
|
|
|
|
|
|
|
|
};
|
|
|
|
|
|
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 16:08:55 +01:00
|
|
|
static inline bool mv88e6xxx_has_stu(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
2022-03-18 21:13:20 +01:00
|
|
|
return chip->info->max_sid > 0 &&
|
|
|
|
|
chip->info->ops->stu_loadpurge &&
|
|
|
|
|
chip->info->ops->stu_getnext;
|
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 16:08:55 +01:00
|
|
|
}
|
|
|
|
|
|
2017-03-30 17:37:07 -04:00
|
|
|
static inline bool mv88e6xxx_has_pvt(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return chip->info->pvt;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-15 13:52:59 +01:00
|
|
|
static inline bool mv88e6xxx_has_lag(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return !!chip->info->global2_addr;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-29 12:21:56 -04:00
|
|
|
static inline unsigned int mv88e6xxx_num_databases(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return chip->info->num_databases;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-05 01:12:58 +01:00
|
|
|
static inline unsigned int mv88e6xxx_num_macs(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return chip->info->num_macs;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-29 12:21:57 -04:00
|
|
|
static inline unsigned int mv88e6xxx_num_ports(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return chip->info->num_ports;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-10 19:57:20 +01:00
|
|
|
static inline unsigned int mv88e6xxx_max_vid(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return chip->info->max_vid;
|
|
|
|
|
}
|
|
|
|
|
|
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 16:08:55 +01:00
|
|
|
static inline unsigned int mv88e6xxx_max_sid(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return chip->info->max_sid;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-11 16:12:47 -05:00
|
|
|
static inline u16 mv88e6xxx_port_mask(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
2020-07-05 21:38:07 +02:00
|
|
|
return GENMASK((s32)mv88e6xxx_num_ports(chip) - 1, 0);
|
2017-03-11 16:12:47 -05:00
|
|
|
}
|
|
|
|
|
|
2018-02-14 01:07:46 +01:00
|
|
|
static inline unsigned int mv88e6xxx_num_gpio(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
return chip->info->num_gpio;
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-31 10:23:48 +02:00
|
|
|
static inline bool mv88e6xxx_is_invalid_port(struct mv88e6xxx_chip *chip, int port)
|
|
|
|
|
{
|
|
|
|
|
return (chip->info->invalid_port_mask & BIT(port)) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-08 10:48:49 +01:00
|
|
|
static inline void mv88e6xxx_port_set_mab(struct mv88e6xxx_chip *chip,
|
|
|
|
|
int port, bool mab)
|
|
|
|
|
{
|
|
|
|
|
chip->ports[port].mab = mab;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-02 14:45:33 -04:00
|
|
|
int mv88e6xxx_read(struct mv88e6xxx_chip *chip, int addr, int reg, u16 *val);
|
|
|
|
|
int mv88e6xxx_write(struct mv88e6xxx_chip *chip, int addr, int reg, u16 val);
|
2019-08-09 18:47:54 -04:00
|
|
|
int mv88e6xxx_wait_mask(struct mv88e6xxx_chip *chip, int addr, int reg,
|
|
|
|
|
u16 mask, u16 val);
|
2019-08-09 18:47:55 -04:00
|
|
|
int mv88e6xxx_wait_bit(struct mv88e6xxx_chip *chip, int addr, int reg,
|
|
|
|
|
int bit, int val);
|
2017-05-26 01:03:20 +02:00
|
|
|
struct mii_bus *mv88e6xxx_default_mdio_bus(struct mv88e6xxx_chip *chip);
|
2017-06-02 17:06:15 -04:00
|
|
|
|
2019-06-20 13:50:42 +00:00
|
|
|
static inline void mv88e6xxx_reg_lock(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
mutex_lock(&chip->reg_lock);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void mv88e6xxx_reg_unlock(struct mv88e6xxx_chip *chip)
|
|
|
|
|
{
|
|
|
|
|
mutex_unlock(&chip->reg_lock);
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-08 10:48:49 +01: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);
|
|
|
|
|
|
2017-06-02 17:06:15 -04:00
|
|
|
#endif /* _MV88E6XXX_CHIP_H */
|