Skip to contentSkip to conversation

net: dsa: lantiq_gswip: Add support for MaxLinear GSW1xx switch family

PATCH Applied Daniel Golle 6 participants 25 messages Nov 3, 2025 – Nov 6, 2025

Subsystems (5)
lore
Share & tools
lore
#0 lore raw

v7 cover net: dsa: lantiq_gswip: Add support for MaxLinear GSW1xx switch family

This patch series extends the existing lantiq_gswip DSA driver to support the MaxLinear GSW1xx family of dedicated Ethernet switch ICs. These switches are based on the same IP as the Lantiq/Intel GSWIP found in VR9 and xRX MIPS router SoCs which are currently supported by the lantiq_gswip driver, but they are dedicated ICs connected via MDIO rather than built-in components of a SoC accessible via memory-mapped I/O.

The series includes several improvements and refactoring to implement support for GSW1xx switch ICs by reusing the existing lantiq_gswip driver.

The GSW1xx family includes several variants:
- GSW120: 4 ports, 2 PHYs, RGMII & SGMII/2500Base-X
- GSW125: 4 ports, 2 PHYs, RGMII & SGMII/2500Base-X, industrial temperature
- GSW140: 6 ports, 4 PHYs, RGMII & SGMII/2500Base-X
- GSW141: 6 ports, 4 PHYs, RGMII & SGMII
- GSW145: 6 ports, 4 PHYs, RGMII & SGMII/2500Base-X, industrial temperature

Key features implemented:
- MDIO-based register access using regmap
- Support for SGMII/1000Base-X/2500Base-X SerDes interfaces
- Configurable RGMII delays via device tree properties
- Configurable RMII clock direction
- Energy Efficient Ethernet (EEE) support
- enabling/disabling learning
---
Series history:
v7:
* improve cover letter
* complete documentation of series history, add lore links
* dt-bindings: put patternProperties: after properties: to follow standardized order
* dt-bindings: drop the addition of 'reg-names' to the list of required properties and also don't add it to the existing example

v6: https://lore.kernel.org/all/[email protected]/
* keep properties on top level and use allOf for
conditional constraints
* switch order of patches, move deviation from dsa.yaml#/$defs/ethernet-ports to this patch which actually needs it

v5: https://lore.kernel.org/all/[email protected]/
* dt-bindings: drop maxlinear,rx-inverted from example

v4: https://lore.kernel.org/all/[email protected]/
* break out PCS reset into dedicated function
* drop hacky support for reverse-SGMII
* remove again the custom properties for TX and RX inverted SerDes PCS in favor of waiting for generic properties to land
* use __be16 to access tag fields
* define ETH_P_MXLGSW in if_ether.h
* drop *_SHIFT macros, get rid of _MASK suffix, use FIELD helpers
* print tag using %8ph
* drop maxlinear,rx-inverted and maxlinear,tx-inverted properties for now in favor of upcoming generic properties
* rework to use legacy codepath as fallback for RGMII delays
* set GSWIP_MII_CFG_RMII_CLK bit in RMII case inside the switch statement instead of a (wrong) if-clause just below
* keep previous behavior regarding GSWIP_TABLE_MAC_BRIDGE_VAL1_VALID for GSWIP 2.1 and earlier, this has been clarified by MaxLinear engineers
* remove misleading default delays

v3: https://lore.kernel.org/all/[email protected]/
* avoid disrupting link when calling .pcs_config()
* sort functions and phylink_pcs_ops instance in same order as struct definition
* always set bootstrap override bits and add explanatory comment
* move definitions to separate header file
* add custom properties for TX and RX inverted data on the SerDes interface
* dt-bindings: redefine ports node so properties which are defined actually apply
* dt-bindings: describe RGMII port with 2ps delay as 'rgmii-id' in example

v2: https://lore.kernel.org/all/[email protected]/
* removed left-overs of 4k VLAN support
* fix use of uninitialized variable
* remove git conflict left-overs which has somehow creeped into dt-bindings
* indent dt-bindings example with 4 spaces instead of tabs

v1: https://lore.kernel.org/all/[email protected]/
* preparations have been merged in several separate series:

    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=f0a24b2547cfdd5ec85a131e386a2ce4ff9179cb

    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=88224095b4e512b027289183f432c0e84925d648

    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=764a47a639c73e8d941cbbb10696a0eb98d10d7b

    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=1d8f0059091e757973324ae76253c2c059e0810f

    https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=6e8e6baf16ce7d2310959ae81d0194a56874e0d2

* comments received for the tag_max-gsw.c driver have been addressed

RFC: https://lore.kernel.org/all/[email protected]/

Daniel Golle (12):
net: dsa: lantiq_gswip: split into common and MMIO parts
net: dsa: lantiq_gswip: support enable/disable learning
net: dsa: lantiq_gswip: support Energy Efficient Ethernet
net: dsa: lantiq_gswip: set link parameters also for CPU port
net: dsa: lantiq_gswip: define and use
GSWIP_TABLE_MAC_BRIDGE_VAL1_VALID
dt-bindings: net: dsa: lantiq,gswip: add MaxLinear RMII refclk output
property
net: dsa: lantiq_gswip: add vendor property to setup MII refclk output
dt-bindings: net: dsa: lantiq,gswip: add support for MII delay
properties
net: dsa: lantiq_gswip: allow adjusting MII delays
dt-bindings: net: dsa: lantiq,gswip: add support for MaxLinear GSW1xx
switches
net: dsa: add tagging driver for MaxLinear GSW1xx switch family
net: dsa: add driver for MaxLinear GSW1xx switch family

 .../bindings/net/dsa/lantiq,gswip.yaml        |  164 +-
 MAINTAINERS                                   |    3 +-
 drivers/net/dsa/lantiq/Kconfig                |   18 +-
 drivers/net/dsa/lantiq/Makefile               |    2 +
 drivers/net/dsa/lantiq/lantiq_gswip.c         | 1617 +--------------
 drivers/net/dsa/lantiq/lantiq_gswip.h         |   20 +
 drivers/net/dsa/lantiq/lantiq_gswip_common.c  | 1737 +++++++++++++++++
 drivers/net/dsa/lantiq/mxl-gsw1xx.c           |  733 +++++++
 drivers/net/dsa/lantiq/mxl-gsw1xx.h           |  126 ++
 drivers/net/dsa/lantiq/mxl-gsw1xx_pce.h       |  154 ++
 include/net/dsa.h                             |    2 +
 include/uapi/linux/if_ether.h                 |    1 +
 net/dsa/Kconfig                               |    8 +
 net/dsa/Makefile                              |    1 +
 net/dsa/tag_mxl-gsw1xx.c                      |  116 ++
 15 files changed, 3101 insertions(+), 1601 deletions(-)
 create mode 100644 drivers/net/dsa/lantiq/lantiq_gswip_common.c
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx.c
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx.h
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx_pce.h
 create mode 100644 net/dsa/tag_mxl-gsw1xx.c
Signature · 1 line
2.51.2
#1 lore raw

PATCH v7 1/12 net: dsa: lantiq_gswip: split into common and MMIO parts

Move all parts specific for the MMIO/SoC driver into a module of its own to prepare for supporting MDIO-connected switch ICs.
Modify gswip_probe() functions by splitting it into a common function gswip_probe_common() which covers allocating, initializing and registering the DSA switch, while keeping transport-specific regmap initialization as well as PHY firmware loading in the new MMIO/SoC-specific gswip_probe() function.

---
v7: no changes

v6: no changes

v5: no changes

v4: no changes

v3: no changes

v2: no changes

since RFC: no changes

 drivers/net/dsa/lantiq/Kconfig               |    6 +-
 drivers/net/dsa/lantiq/Makefile              |    1 +
 drivers/net/dsa/lantiq/lantiq_gswip.c        | 1617 +----------------
 drivers/net/dsa/lantiq/lantiq_gswip.h        |    4 +
 drivers/net/dsa/lantiq/lantiq_gswip_common.c | 1622 ++++++++++++++++++
 5 files changed, 1658 insertions(+), 1592 deletions(-)
 create mode 100644 drivers/net/dsa/lantiq/lantiq_gswip_common.c
drivers/net/dsa/lantiq/Kconfig +5 -1
index 3cfa16840cf5..78db82a47d09 100644
@@ -1,8 +1,12 @@
+config NET_DSA_LANTIQ_COMMON
+	tristate
+	select REGMAP
+
 config NET_DSA_LANTIQ_GSWIP
 	tristate "Lantiq / Intel GSWIP"
 	depends on HAS_IOMEM
 	select NET_DSA_TAG_GSWIP
-	select REGMAP
+	select NET_DSA_LANTIQ_COMMON
 	help
 	  This enables support for the Lantiq / Intel GSWIP 2.1 found in
 	  the xrx200 / VR9 SoC.
drivers/net/dsa/lantiq/Makefile +1 -0
index 849f85ebebd6..65ffa7bb71aa 100644
@@ -1 +1,2 @@
 obj-$(CONFIG_NET_DSA_LANTIQ_GSWIP) += lantiq_gswip.o
+obj-$(CONFIG_NET_DSA_LANTIQ_COMMON) += lantiq_gswip_common.o
drivers/net/dsa/lantiq/lantiq_gswip.c +26 -1591

1,665 lines not on this page · raw message

drivers/net/dsa/lantiq/lantiq_gswip.h +4 -0
index 24d759e06e15..d86290db19b4 100644
@@ -278,4 +278,8 @@ struct gswip_priv {
 	u16 version;
 };
 
+void gswip_disable_switch(struct gswip_priv *priv);
+
+int gswip_probe_common(struct gswip_priv *priv, u32 version);
+
 #endif /* __LANTIQ_GSWIP_H */
drivers/net/dsa/lantiq/lantiq_gswip_common.c new file +1622 -0

1,312 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Signature · 1 line
2.51.2

Part of the diff is not shown here. View the raw message.

#2 lore raw

PATCH v7 2/12 net: dsa: lantiq_gswip: support enable/disable learning

In reply to Daniel Golle

Switch API 2.2 or later supports enabling or disabling learning on each port. Implement support for BR_LEARNING bridge flag and announce support for BR_LEARNING on GSWIP 2.2 or later.

---
v7: no changes

v6: no changes

v5: no changes

v4: no changes

v3: no changes

v2: initialize supported flags with 0

since RFC: no changes

 drivers/net/dsa/lantiq/lantiq_gswip.h        |  3 ++
 drivers/net/dsa/lantiq/lantiq_gswip_common.c | 43 ++++++++++++++++++++
 2 files changed, 46 insertions(+)
drivers/net/dsa/lantiq/lantiq_gswip.h +3 -0
index d86290db19b4..fb7d2c02bde9 100644
@@ -157,6 +157,9 @@
 #define  GSWIP_PCE_PCTRL_0_PSTATE_LEARNING	0x3
 #define  GSWIP_PCE_PCTRL_0_PSTATE_FORWARDING	0x7
 #define  GSWIP_PCE_PCTRL_0_PSTATE_MASK	GENMASK(2, 0)
+/* Ethernet Switch PCE Port Control Register 3 */
+#define GSWIP_PCE_PCTRL_3p(p)		(0x483 + ((p) * 0xA))
+#define  GSWIP_PCE_PCTRL_3_LNDIS	BIT(15)  /* Learning Disable */
 #define GSWIP_PCE_VCTRL(p)		(0x485 + ((p) * 0xA))
 #define  GSWIP_PCE_VCTRL_UVR		BIT(0)	/* Unknown VLAN Rule */
 #define  GSWIP_PCE_VCTRL_VINR		GENMASK(2, 1) /* VLAN Ingress Tag Rule */
drivers/net/dsa/lantiq/lantiq_gswip_common.c +43 -0

55 lines not on this page · raw message

Signature · 1 line
2.51.2
#3 lore raw

PATCH v7 3/12 net: dsa: lantiq_gswip: support Energy Efficient Ethernet

In reply to Daniel Golle

Introduce support for Energy Efficient Ethernet (EEE) on hardware version 2.2 or later.

---
v7: no changes

v6: no changes

v5: no changes

v4: no changes

v3: no changes

v2: no changes

since RFC: no changes

 drivers/net/dsa/lantiq/lantiq_gswip.h        |  7 +++
 drivers/net/dsa/lantiq/lantiq_gswip_common.c | 47 ++++++++++++++++++++
 2 files changed, 54 insertions(+)
drivers/net/dsa/lantiq/lantiq_gswip.h +7 -0
index fb7d2c02bde9..56de869fc472 100644
@@ -2,6 +2,7 @@
 #ifndef __LANTIQ_GSWIP_H
 #define __LANTIQ_GSWIP_H
 
+#include <linux/bitfield.h>
 #include <linux/clk.h>
 #include <linux/mutex.h>
 #include <linux/phylink.h>
@@ -193,6 +194,12 @@
 #define GSWIP_MAC_CTRL_2p(p)		(0x905 + ((p) * 0xC))
 #define GSWIP_MAC_CTRL_2_LCHKL		BIT(2) /* Frame Length Check Long Enable */
 #define GSWIP_MAC_CTRL_2_MLEN		BIT(3) /* Maximum Untagged Frame Lnegth */
+#define GSWIP_MAC_CTRL_4p(p)		(0x907 + ((p) * 0xC))
+#define  GSWIP_MAC_CTRL_4_LPIEN		BIT(7) /* LPI Mode Enable */
+#define  GSWIP_MAC_CTRL_4_GWAIT_MASK	GENMASK(14, 8) /* LPI Wait Time 1G */
+#define  GSWIP_MAC_CTRL_4_GWAIT(t)	u16_encode_bits((t), GSWIP_MAC_CTRL_4_GWAIT_MASK)
+#define  GSWIP_MAC_CTRL_4_WAIT_MASK	GENMASK(6, 0) /* LPI Wait Time 100M */
+#define  GSWIP_MAC_CTRL_4_WAIT(t)	u16_encode_bits((t), GSWIP_MAC_CTRL_4_WAIT_MASK)
 
 /* Ethernet Switch Fetch DMA Port Control Register */
 #define GSWIP_FDMA_PCTRLp(p)		(0xA80 + ((p) * 0x6))
drivers/net/dsa/lantiq/lantiq_gswip_common.c +47 -0

65 lines not on this page · raw message

Signature · 1 line
2.51.2
#4 lore raw

PATCH v7 4/12 net: dsa: lantiq_gswip: set link parameters also for CPU port

In reply to Daniel Golle

On standalone switch ICs the link parameters of the CPU port need to be setup just like user ports. The destinction in the driver to not carry out link parameter setup for the CPU port does make sense for in-SoC switches on which the CPU port is internally connected to the SoC's Ethernet MAC.
Set link parameters also for the CPU port unless it is an internal interface. Note that the internal TP PHYs anyway cannot be used as CPU ports, hence it doesn't matter that they are now also covered by that condition.

---
v7: no changes

v6: no changes

v5: no changes

v4: improve commit message

v3: no changes

v2: no changes

since RFC: no changes

 drivers/net/dsa/lantiq/lantiq_gswip_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/dsa/lantiq/lantiq_gswip_common.c +1 -1
index 092187603dea..0ac87eb23bb5 100644
@@ -1459,7 +1459,7 @@ static void gswip_phylink_mac_link_up(struct phylink_config *config,
 	struct gswip_priv *priv = dp->ds->priv;
 	int port = dp->index;
 
-	if (!dsa_port_is_cpu(dp)) {
+	if (!dsa_port_is_cpu(dp) || interface != PHY_INTERFACE_MODE_INTERNAL) {
 		gswip_port_set_link(priv, port, true);
 		gswip_port_set_speed(priv, port, speed, interface);
 		gswip_port_set_duplex(priv, port, duplex);
Signature · 1 line
2.51.2
#5 lore raw

PATCH v7 5/12 net: dsa: lantiq_gswip: define and use GSWIP_TABLE_MAC_BRIDGE_VAL1_VALID

In reply to Daniel Golle

When adding FDB entries to the MAC bridge table on GSWIP 2.2 or later it is needed to set an (undocumented) bit to mark the entry as valid. If this bit isn't set for entries in the MAC bridge table, then those entries won't be considered as valid MAC addresses.

---
v7: no changes

v6: no changes

v5: no changes

v4: keep previous behavior for GSWIP 2.1 and earlier, this was clarified
by MaxLinear engineers

v3: no changes

v2: no changes

since RFC: no changes

 drivers/net/dsa/lantiq/lantiq_gswip.h        | 1 +
 drivers/net/dsa/lantiq/lantiq_gswip_common.c | 7 ++++++-
 2 files changed, 7 insertions(+), 1 deletion(-)
drivers/net/dsa/lantiq/lantiq_gswip.h +1 -0
index 56de869fc472..42000954d842 100644
@@ -224,6 +224,7 @@
 #define  GSWIP_TABLE_MAC_BRIDGE_KEY3_FID	GENMASK(5, 0)	/* Filtering identifier */
 #define  GSWIP_TABLE_MAC_BRIDGE_VAL0_PORT	GENMASK(7, 4)	/* Port on learned entries */
 #define  GSWIP_TABLE_MAC_BRIDGE_VAL1_STATIC	BIT(0)		/* Static, non-aging entry */
+#define  GSWIP_TABLE_MAC_BRIDGE_VAL1_VALID	BIT(1)		/* Valid bit */
 
 #define XRX200_GPHY_FW_ALIGN	(16 * 1024)
 
drivers/net/dsa/lantiq/lantiq_gswip_common.c +6 -1
index 0ac87eb23bb5..fdfc265b4c73 100644
@@ -1149,7 +1149,12 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
 	mac_bridge.key[2] = addr[1] | (addr[0] << 8);
 	mac_bridge.key[3] = FIELD_PREP(GSWIP_TABLE_MAC_BRIDGE_KEY3_FID, fid);
 	mac_bridge.val[0] = add ? BIT(port) : 0; /* port map */
-	mac_bridge.val[1] = GSWIP_TABLE_MAC_BRIDGE_VAL1_STATIC;
+	if (GSWIP_VERSION_GE(priv, GSWIP_VERSION_2_2_ETC))
+		mac_bridge.val[1] = add ? (GSWIP_TABLE_MAC_BRIDGE_VAL1_STATIC |
+					   GSWIP_TABLE_MAC_BRIDGE_VAL1_VALID) : 0;
+	else
+		mac_bridge.val[1] = GSWIP_TABLE_MAC_BRIDGE_VAL1_STATIC;
+
 	mac_bridge.valid = add;
 
 	err = gswip_pce_table_entry_write(priv, &mac_bridge);
Signature · 1 line
2.51.2
#6 lore raw

PATCH v7 6/12 dt-bindings: net: dsa: lantiq,gswip: add MaxLinear RMII refclk output property

In reply to Daniel Golle

Add support for the maxlinear,rmii-refclk-out boolean property on port nodes to configure the RMII reference clock to be an output rather than an input.

This property is only applicable for ports in RMII mode and allows the switch to provide the reference clock for RMII-connected PHYs instead of requiring an external clock source.

This corresponds to the driver changes that read this Device Tree property to configure the RMII clock direction.

---
v7:
* put patternProperties: after properties: to follow standardized order

v6:
* switch order of patches, move deviation from dsa.yaml#/$defs/ethernet-ports to this patch which actually needs it

v5: no changes

v4: no changes

v3: no changes

v2: no changes

since RFC: no changes

 .../bindings/net/dsa/lantiq,gswip.yaml         | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml +16 -2
index f3154b19af78..809d0e9d0a15 100644
@@ -6,8 +6,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 
 title: Lantiq GSWIP Ethernet switches
 
-allOf:
-  - $ref: dsa.yaml#/$defs/ethernet-ports
+$ref: dsa.yaml#
 
 maintainers:
   - Hauke Mehrtens <[email protected]>
@@ -91,6 +90,21 @@ properties:
 
     additionalProperties: false
 
+patternProperties:
+  "^(ethernet-)?ports$":
+    type: object
+    patternProperties:
+      "^(ethernet-)?port@[0-6]$":
+        $ref: dsa-port.yaml#
+        unevaluatedProperties: false
+
+        properties:
+          maxlinear,rmii-refclk-out:
+            type: boolean
+            description:
+              Configure the RMII reference clock to be a clock output
+              rather than an input. Only applicable for RMII mode.
+
 required:
   - compatible
   - reg
Signature · 1 line
2.51.2
Reviewed-by on v7 6/12
#7 lore raw

Re: [PATCH net-next v7 06/12] dt-bindings: net: dsa: lantiq,gswip: add MaxLinear RMII refclk output property

Quoted 8 lines · Daniel Golle

Add support for the maxlinear,rmii-refclk-out boolean property on port nodes to configure the RMII reference clock to be an output rather than an input.

This property is only applicable for ports in RMII mode and allows the switch to provide the reference clock for RMII-connected PHYs instead of requiring an external clock source.

Quoted 6 lines

This corresponds to the driver changes that read this Device Tree property to configure the RMII clock direction.

---

Best regards,
Krzysztof

#8 lore raw

PATCH v7 7/12 net: dsa: lantiq_gswip: add vendor property to setup MII refclk output

In reply to Daniel Golle

Read boolean Device Tree property "maxlinear,rmii-refclk-out" and switch the RMII reference clock to be a clock output rather than an input if it is set.

---
v7: no changes

v6: no changes

v5: no changes

v4: set GSWIP_MII_CFG_RMII_CLK bit in RMII case inside the switch
statement instead of a (wrong) if-clause just below

v3: no changes

v2: no changes

since RFC: no changes

 drivers/net/dsa/lantiq/lantiq_gswip_common.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/net/dsa/lantiq/lantiq_gswip_common.c +2 -0
index fdfc265b4c73..7b3debd45b91 100644
@@ -1402,6 +1402,8 @@ static void gswip_phylink_mac_config(struct phylink_config *config,
 		break;
 	case PHY_INTERFACE_MODE_RMII:
 		miicfg |= GSWIP_MII_CFG_MODE_RMIIM;
+		if (of_property_read_bool(dp->dn, "maxlinear,rmii-refclk-out"))
+			miicfg |= GSWIP_MII_CFG_RMII_CLK;
 		break;
 	case PHY_INTERFACE_MODE_RGMII:
 	case PHY_INTERFACE_MODE_RGMII_ID:
Signature · 1 line
2.51.2
#9 lore raw

PATCH v7 8/12 dt-bindings: net: dsa: lantiq,gswip: add support for MII delay properties

In reply to Daniel Golle

Add support for standard tx-internal-delay-ps and rx-internal-delay-ps properties on port nodes to allow fine-tuning of RGMII clock delays.

The GSWIP switch hardware supports delay values in 500 picosecond increments from 0 to 3500 picoseconds, with a post-reset default of 2000 picoseconds for both TX and RX delays. The driver currently sets the delay to 0 in case the PHY is setup to carry out the delay by the corresponding interface modes ("rgmii-id", "rgmii-rxid", "rgmii-txid").

This corresponds to the driver changes that allow adjusting MII delays using Device Tree properties instead of relying solely on the PHY interface mode.

---
v7: no changes

v6:
* switch order of patches

v5: no changes

v4:
* remove misleading defaults

v3:
* redefine ports node so properties are defined actually apply
* RGMII port with 2ps delay is 'rgmii-id' mode

v2: no changes

since RFC: no changes

 .../bindings/net/dsa/lantiq,gswip.yaml         | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml +17 -1
index 809d0e9d0a15..929f6f8e4534 100644
@@ -104,6 +104,20 @@ patternProperties:
             description:
               Configure the RMII reference clock to be a clock output
               rather than an input. Only applicable for RMII mode.
+          tx-internal-delay-ps:
+            enum: [0, 500, 1000, 1500, 2000, 2500, 3000, 3500]
+            description:
+              RGMII TX Clock Delay defined in pico seconds.
+              The delay lines adjust the MII clock vs. data timing.
+              If this property is not present the delay is determined by
+              the interface mode.
+          rx-internal-delay-ps:
+            enum: [0, 500, 1000, 1500, 2000, 2500, 3000, 3500]
+            description:
+              RGMII RX Clock Delay defined in pico seconds.
+              The delay lines adjust the MII clock vs. data timing.
+              If this property is not present the delay is determined by
+              the interface mode.
 
 required:
   - compatible
@@ -127,8 +141,10 @@ examples:
                     port@0 {
                             reg = <0>;
                             label = "lan3";
-                            phy-mode = "rgmii";
+                            phy-mode = "rgmii-id";
                             phy-handle = <&phy0>;
+                            tx-internal-delay-ps = <2000>;
+                            rx-internal-delay-ps = <2000>;
                     };
 
                     port@1 {
Signature · 1 line
2.51.2
#10 lore raw

PATCH v7 9/12 net: dsa: lantiq_gswip: allow adjusting MII delays

In reply to Daniel Golle

Currently the MII clk vs. data delay is configured based on the PHY interface mode.

In addition to that add support for setting up MII delays using the standard Device Tree properties 'tx-internal-delay-ps' and 'rx-internal-delay-ps', using the values determined by the PHY interface mode as default to maintain backward compatibility with legacy device trees.

---
v7: no changes

v6: no changes

v5: no changes

v4: rework to use legacy codepath as fallback

v3: no changes

v2: no changes

since RFC: no changes

 drivers/net/dsa/lantiq/lantiq_gswip.h        |  4 +
 drivers/net/dsa/lantiq/lantiq_gswip_common.c | 94 ++++++++++++--------
 2 files changed, 60 insertions(+), 38 deletions(-)
drivers/net/dsa/lantiq/lantiq_gswip.h +4 -0
index 42000954d842..0c32ec85e127 100644
@@ -82,6 +82,10 @@
 #define GSWIP_MII_PCDU5			0x05
 #define  GSWIP_MII_PCDU_TXDLY_MASK	GENMASK(2, 0)
 #define  GSWIP_MII_PCDU_RXDLY_MASK	GENMASK(9, 7)
+#define  GSWIP_MII_PCDU_TXDLY(x)	u16_encode_bits(((x) / 500), GSWIP_MII_PCDU_TXDLY_MASK)
+#define  GSWIP_MII_PCDU_RXDLY(x)	u16_encode_bits(((x) / 500), GSWIP_MII_PCDU_RXDLY_MASK)
+#define GSWIP_MII_PCDU_RXDLY_DEFAULT	2000 /* picoseconds */
+#define GSWIP_MII_PCDU_TXDLY_DEFAULT	2000 /* picoseconds */
 
 /* GSWIP Core Registers */
 #define GSWIP_SWRES			0x000
drivers/net/dsa/lantiq/lantiq_gswip_common.c +56 -38

112 lines not on this page · raw message

Signature · 1 line
2.51.2
#11 lore raw

PATCH v7 10/12 dt-bindings: net: dsa: lantiq,gswip: add support for MaxLinear GSW1xx switches

In reply to Daniel Golle

Extend the Lantiq GSWIP device tree binding to also cover MaxLinear GSW1xx switches which are based on the same hardware IP but connected via MDIO instead of being memory-mapped.

Add compatible strings for MaxLinear GSW120, GSW125, GSW140, GSW141, and GSW145 switches and adjust the schema to handle the different connection methods with conditional properties.

Add MaxLinear GSW125 example showing MDIO-connected configuration.

---
v7:
* drop the addition of 'reg-names' to the list of required properties and also don't add it to the existing example

v6:
* keep properties on top level and use allOf for conditional constraints

v5:
* drop maxlinear,rx-inverted from example

v4:
* drop maxlinear,rx-inverted and maxlinear,tx-inverted properties for now in favor of upcoming generic properties

v3:
* add maxlinear,rx-inverted and maxlinear,tx-inverted properties

v2:
* remove git conflict left-overs which somehow creeped in
* indent example with 4 spaces instead of tabs

since RFC: no changes

 .../bindings/net/dsa/lantiq,gswip.yaml        | 128 +++++++++++++++++-
 1 file changed, 123 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml +123 -5
index 929f6f8e4534..205b683849a5 100644
@@ -4,7 +4,12 @@
 $id: http://devicetree.org/schemas/net/dsa/lantiq,gswip.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Lantiq GSWIP Ethernet switches
+title: Lantiq GSWIP and MaxLinear GSW1xx Ethernet switches
+
+description:
+  Lantiq GSWIP and MaxLinear GSW1xx switches share the same hardware IP.
+  Lantiq switches are embedded in SoCs and accessed via memory-mapped I/O,
+  while MaxLinear switches are standalone ICs connected via MDIO.
 
 $ref: dsa.yaml#
 
@@ -17,9 +22,14 @@ properties:
       - lantiq,xrx200-gswip
       - lantiq,xrx300-gswip
       - lantiq,xrx330-gswip
+      - maxlinear,gsw120
+      - maxlinear,gsw125
+      - maxlinear,gsw140
+      - maxlinear,gsw141
+      - maxlinear,gsw145
 
   reg:
-    minItems: 3
+    minItems: 1
     maxItems: 3
 
   reg-names:
@@ -36,9 +46,6 @@ properties:
       compatible:
         const: lantiq,xrx200-mdio
 
-    required:
-      - compatible
-
   gphy-fw:
     type: object
     properties:
@@ -123,6 +130,30 @@ required:
   - compatible
   - reg
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - lantiq,xrx200-gswip
+              - lantiq,xrx300-gswip
+              - lantiq,xrx330-gswip
+    then:
+      properties:
+        reg:
+          minItems: 3
+          maxItems: 3
+        mdio:
+          required:
+            - compatible
+    else:
+      properties:
+        reg:
+          maxItems: 1
+        reg-names: false
+        gphy-fw: false
+
 unevaluatedProperties: false
 
 examples:
@@ -230,3 +261,90 @@ examples:
                     };
             };
     };
+
+  - |
+    #include <dt-bindings/leds/common.h>
+
+    mdio {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        switch@1f {
+            compatible = "maxlinear,gsw125";
+            reg = <0x1f>;
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                    reg = <0>;
+                    label = "lan0";
+                    phy-handle = <&switchphy0>;
+                    phy-mode = "internal";
+                };
+
+                port@1 {
+                    reg = <1>;
+                    label = "lan1";
+                    phy-handle = <&switchphy1>;
+                    phy-mode = "internal";
+                };
+
+                port@4 {
+                    reg = <4>;
+                    label = "wan";
+                    phy-mode = "1000base-x";
+                    managed = "in-band-status";
+                };
+
+                port@5 {
+                    reg = <5>;
+                    phy-mode = "rgmii-id";
+                    tx-internal-delay-ps = <2000>;
+                    rx-internal-delay-ps = <2000>;
+                    ethernet = <&eth0>;
+
+                    fixed-link {
+                        speed = <1000>;
+                        full-duplex;
+                    };
+                };
+            };
+
+            mdio {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                switchphy0: switchphy@0 {
+                    reg = <0>;
+
+                    leds {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        led@0 {
+                            reg = <0>;
+                            color = <LED_COLOR_ID_GREEN>;
+                            function = LED_FUNCTION_LAN;
+                        };
+                    };
+                };
+
+                switchphy1: switchphy@1 {
+                    reg = <1>;
+
+                    leds {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        led@0 {
+                            reg = <0>;
+                            color = <LED_COLOR_ID_GREEN>;
+                            function = LED_FUNCTION_LAN;
+                        };
+                    };
+                };
+            };
+        };
+    };
Signature · 1 line
2.51.2
Reviewed-by on v7 10/12
#12 lore raw

Re: [PATCH net-next v7 10/12] dt-bindings: net: dsa: lantiq,gswip: add support for MaxLinear GSW1xx switches

Quoted 8 lines · Daniel Golle

Extend the Lantiq GSWIP device tree binding to also cover MaxLinear GSW1xx switches which are based on the same hardware IP but connected via MDIO instead of being memory-mapped.

Add compatible strings for MaxLinear GSW120, GSW125, GSW140, GSW141, and GSW145 switches and adjust the schema to handle the different connection methods with conditional properties.

Quoted 7 lines

Add MaxLinear GSW125 example showing MDIO-connected configuration.

---
v7:
* drop the addition of 'reg-names' to the list of required properties and also don't add it to the existing example

Best regards,
Krzysztof

#13 lore raw

PATCH v7 11/12 net: dsa: add tagging driver for MaxLinear GSW1xx switch family

In reply to Daniel Golle

Add support for a new DSA tagging protocol driver for the MaxLinear GSW1xx switch family. The GSW1xx switches use a proprietary 8-byte special tag inserted between the source MAC address and the EtherType field to indicate the source and destination ports for frames traversing the CPU port.

Implement the tag handling logic to insert the special tag on transmit and parse it on receive.

---
v7: no changes

v6: no changes

v5: no changes

v4:
* use __be16 to access tag fields
* define ETH_P_MXLGSW in if_ether.h
* drop *_SHIFT macros, get rid of _MASK suffix, use FIELD helpers
* print tag using %8ph

v3: no changes

v2: no changes

since RFC:
* use dsa etype header macros instead of open coding them
* maintain alphabetic order in Kconfig and Makefile

 MAINTAINERS                   |   3 +-
 include/net/dsa.h             |   2 +
 include/uapi/linux/if_ether.h |   1 +
 net/dsa/Kconfig               |   8 +++
 net/dsa/Makefile              |   1 +
 net/dsa/tag_mxl-gsw1xx.c      | 116 ++++++++++++++++++++++++++++++++++
 6 files changed, 130 insertions(+), 1 deletion(-)
 create mode 100644 net/dsa/tag_mxl-gsw1xx.c
MAINTAINERS +2 -1
index 1ab7e8746299..7efaeaf6d893 100644
@@ -14047,7 +14047,7 @@ F:	tools/testing/selftests/landlock/
 K:	landlock
 K:	LANDLOCK
 
-LANTIQ / INTEL Ethernet drivers
+LANTIQ / MAXLINEAR / INTEL Ethernet DSA drivers
 M:	Hauke Mehrtens <[email protected]>
 L:	[email protected]
 S:	Maintained
@@ -14055,6 +14055,7 @@ F:	Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
 F:	drivers/net/dsa/lantiq/*
 F:	drivers/net/ethernet/lantiq_xrx200.c
 F:	net/dsa/tag_gswip.c
+F:	net/dsa/tag_mxl-gsw1xx.c
 
 LANTIQ MIPS ARCHITECTURE
 M:	John Crispin <[email protected]>
include/net/dsa.h +2 -0
index 67762fdaf3c7..2df2e2ead9a8 100644
@@ -56,6 +56,7 @@ struct tc_action;
 #define DSA_TAG_PROTO_VSC73XX_8021Q_VALUE	28
 #define DSA_TAG_PROTO_BRCM_LEGACY_FCS_VALUE	29
 #define DSA_TAG_PROTO_YT921X_VALUE		30
+#define DSA_TAG_PROTO_MXL_GSW1XX_VALUE		31
 
 enum dsa_tag_protocol {
 	DSA_TAG_PROTO_NONE		= DSA_TAG_PROTO_NONE_VALUE,
@@ -89,6 +90,7 @@ enum dsa_tag_protocol {
 	DSA_TAG_PROTO_LAN937X		= DSA_TAG_PROTO_LAN937X_VALUE,
 	DSA_TAG_PROTO_VSC73XX_8021Q	= DSA_TAG_PROTO_VSC73XX_8021Q_VALUE,
 	DSA_TAG_PROTO_YT921X		= DSA_TAG_PROTO_YT921X_VALUE,
+	DSA_TAG_PROTO_MXL_GSW1XX	= DSA_TAG_PROTO_MXL_GSW1XX_VALUE,
 };
 
 struct dsa_switch;
include/uapi/linux/if_ether.h +1 -0
index cfd200c87e5e..2c93b7b731c8 100644
@@ -92,6 +92,7 @@
 #define ETH_P_ETHERCAT	0x88A4		/* EtherCAT			*/
 #define ETH_P_8021AD	0x88A8          /* 802.1ad Service VLAN		*/
 #define ETH_P_802_EX1	0x88B5		/* 802.1 Local Experimental 1.  */
+#define ETH_P_MXLGSW	0x88C3		/* MaxLinear GSW DSA [ NOT AN OFFICIALLY REGISTERED ID ] */
 #define ETH_P_PREAUTH	0x88C7		/* 802.11 Preauthentication */
 #define ETH_P_TIPC	0x88CA		/* TIPC 			*/
 #define ETH_P_LLDP	0x88CC		/* Link Layer Discovery Protocol */
net/dsa/Kconfig +8 -0
index 6b94028b1fcc..f86b30742122 100644
@@ -104,6 +104,14 @@ config NET_DSA_TAG_MTK
 	  Say Y or M if you want to enable support for tagging frames for
 	  Mediatek switches.
 
+config NET_DSA_TAG_MXL_GSW1XX
+	tristate "Tag driver for MaxLinear GSW1xx switches"
+	help
+	  The GSW1xx family of switches supports an 8-byte special tag which
+	  can be used on the CPU port of the switch.
+	  Say Y or M if you want to enable support for tagging frames for
+	  MaxLinear GSW1xx switches.
+
 config NET_DSA_TAG_KSZ
 	tristate "Tag driver for Microchip 8795/937x/9477/9893 families of switches"
 	help
net/dsa/Makefile +1 -0
index 4b011a1d5c87..42d173f5a701 100644
@@ -28,6 +28,7 @@ obj-$(CONFIG_NET_DSA_TAG_HELLCREEK) += tag_hellcreek.o
 obj-$(CONFIG_NET_DSA_TAG_KSZ) += tag_ksz.o
 obj-$(CONFIG_NET_DSA_TAG_LAN9303) += tag_lan9303.o
 obj-$(CONFIG_NET_DSA_TAG_MTK) += tag_mtk.o
+obj-$(CONFIG_NET_DSA_TAG_MXL_GSW1XX) += tag_mxl-gsw1xx.o
 obj-$(CONFIG_NET_DSA_TAG_NONE) += tag_none.o
 obj-$(CONFIG_NET_DSA_TAG_OCELOT) += tag_ocelot.o
 obj-$(CONFIG_NET_DSA_TAG_OCELOT_8021Q) += tag_ocelot_8021q.o
net/dsa/tag_mxl-gsw1xx.c new file +116 -0

116 lines not on this page · raw message

Signature · 1 line
2.51.2
#14 lore raw

PATCH v7 12/12 net: dsa: add driver for MaxLinear GSW1xx switch family

In reply to Daniel Golle

Add driver for the MaxLinear GSW1xx family of Ethernet switch ICs which are based on the same IP as the Lantiq/Intel GSWIP found in the Lantiq VR9 and Intel GRX MIPS router SoCs. The main difference is that instead of using memory-mapped I/O to communicate with the host CPU these ICs are connected via MDIO (or SPI, which isn't supported by this driver). Implement the regmap API to access the switch registers over MDIO to allow reusing lantiq_gswip_common for all core functionality.

The GSW1xx also comes with a SerDes port capable of 1000Base-X, SGMII and 2500Base-X, which can either be used to connect an external PHY or SFP cage, or as the CPU port. Support for the SerDes interface is implemented in this driver using the phylink_pcs interface.

---
v7: no changes

v6: no changes

v5: no changes

v4:
* break out PCS reset into dedicated function
* drop hacky support for reverse-SGMII
* remove again the custom properties for TX and RX inverted SerDes PCS in favor of waiting for generic properties to land

v3:
* avoid disrupting link when calling .pcs_config()
* sort functions and phylink_pcs_ops instance in same order as struct definition
* always set bootstrap override bits and add explanatory comment
* move definitions to separate header file
* add custom properties for TX and RX inverted data on the SerDes interface

v2: remove left-overs of 4k VLAN support (will be added in future)

since RFC: no changes

 drivers/net/dsa/lantiq/Kconfig          |  12 +
 drivers/net/dsa/lantiq/Makefile         |   1 +
 drivers/net/dsa/lantiq/lantiq_gswip.h   |   1 +
 drivers/net/dsa/lantiq/mxl-gsw1xx.c     | 733 ++++++++++++++++++++++++
 drivers/net/dsa/lantiq/mxl-gsw1xx.h     | 126 ++++
 drivers/net/dsa/lantiq/mxl-gsw1xx_pce.h | 154 +++++
 6 files changed, 1027 insertions(+)
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx.c
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx.h
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx_pce.h
drivers/net/dsa/lantiq/Kconfig +12 -0
index 78db82a47d09..4a9771be5d58 100644
@@ -10,3 +10,15 @@ config NET_DSA_LANTIQ_GSWIP
 	help
 	  This enables support for the Lantiq / Intel GSWIP 2.1 found in
 	  the xrx200 / VR9 SoC.
+
+config NET_DSA_MXL_GSW1XX
+	tristate "MaxLinear GSW1xx Ethernet switch support"
+	select NET_DSA_TAG_MXL_GSW1XX
+	select NET_DSA_LANTIQ_COMMON
+	help
+	  This enables support for the MaxLinear GSW1xx family of 1GE switches
+	    GSW120 4 port, 2 PHYs, RGMII & SGMII/2500Base-X
+	    GSW125 4 port, 2 PHYs, RGMII & SGMII/2500Base-X, industrial temperature
+	    GSW140 6 port, 4 PHYs, RGMII & SGMII/2500Base-X
+	    GSW141 6 port, 4 PHYs, RGMII & SGMII
+	    GSW145 6 port, 4 PHYs, RGMII & SGMII/2500Base-X, industrial temperature
drivers/net/dsa/lantiq/Makefile +1 -0
index 65ffa7bb71aa..85fce605310b 100644
@@ -1,2 +1,3 @@
 obj-$(CONFIG_NET_DSA_LANTIQ_GSWIP) += lantiq_gswip.o
 obj-$(CONFIG_NET_DSA_LANTIQ_COMMON) += lantiq_gswip_common.o
+obj-$(CONFIG_NET_DSA_MXL_GSW1XX) += mxl-gsw1xx.o
drivers/net/dsa/lantiq/lantiq_gswip.h +1 -0
index 0c32ec85e127..9c38e51a75e8 100644
@@ -255,6 +255,7 @@ struct gswip_hw_info {
 	unsigned int allowed_cpu_ports;
 	unsigned int mii_ports;
 	int mii_port_reg_offset;
+	bool supports_2500m;
 	const struct gswip_pce_microcode (*pce_microcode)[];
 	size_t pce_microcode_size;
 	enum dsa_tag_protocol tag_protocol;
drivers/net/dsa/lantiq/mxl-gsw1xx.c new file +733 -0

733 lines not on this page · raw message

drivers/net/dsa/lantiq/mxl-gsw1xx.h new file +126 -0

126 lines not on this page · raw message

drivers/net/dsa/lantiq/mxl-gsw1xx_pce.h new file +154 -0

154 lines not on this page · raw message

Signature · 1 line
2.51.2
#15 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

Hi Daniel,

Quoted 8 lines · Daniel Golle

Add driver for the MaxLinear GSW1xx family of Ethernet switch ICs which are based on the same IP as the Lantiq/Intel GSWIP found in the Lantiq VR9 and Intel GRX MIPS router SoCs. The main difference is that instead of using memory-mapped I/O to communicate with the host CPU these ICs are connected via MDIO (or SPI, which isn't supported by this driver). Implement the regmap API to access the switch registers over MDIO to allow reusing lantiq_gswip_common for all core functionality.

Quoted 6 lines

The GSW1xx also comes with a SerDes port capable of 1000Base-X, SGMII and 2500Base-X, which can either be used to connect an external PHY or SFP cage, or as the CPU port. Support for the SerDes interface is implemented in this driver using the phylink_pcs interface.

thank you for the patch!

Finally I was able to run selftest/drivers/net/dsa/local_termination.sh with only 2 unexpected failures on a GSW145 hardware (with TI AM62 host CPU and its CPSW (not in switchdev mode) as CPU interface).

The problems I had in the past were neither related to the GSW145 code, nor to am65-cpsw-nuss, but to the test itself:
https://lore.kernel.org/all/[email protected]/

The remaining failing test cases are:
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address [FAIL]
reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
reception succeeded, but should have failed

So far I didn't notice any problems with untagged read-word IP traffic over GSW145 ports.

Do you have a suggestion what could I check further regarding the failing test cases? As I understood, all of them pass on your side?

Quoted 36 lines

---
v7: no changes

v6: no changes

v5: no changes

v4:
* break out PCS reset into dedicated function
* drop hacky support for reverse-SGMII
* remove again the custom properties for TX and RX inverted SerDes PCS in favor of waiting for generic properties to land

v3:
* avoid disrupting link when calling .pcs_config()
* sort functions and phylink_pcs_ops instance in same order as struct definition
* always set bootstrap override bits and add explanatory comment
* move definitions to separate header file
* add custom properties for TX and RX inverted data on the SerDes interface

v2: remove left-overs of 4k VLAN support (will be added in future)

since RFC: no changes

 drivers/net/dsa/lantiq/Kconfig          |  12 +
 drivers/net/dsa/lantiq/Makefile         |   1 +
 drivers/net/dsa/lantiq/lantiq_gswip.h   |   1 +
 drivers/net/dsa/lantiq/mxl-gsw1xx.c     | 733 ++++++++++++++++++++++++
 drivers/net/dsa/lantiq/mxl-gsw1xx.h     | 126 ++++
 drivers/net/dsa/lantiq/mxl-gsw1xx_pce.h | 154 +++++
 6 files changed, 1027 insertions(+)
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx.c
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx.h
 create mode 100644 drivers/net/dsa/lantiq/mxl-gsw1xx_pce.h
Signature · 3 lines
Alexander Sverdlin
Siemens AG
www.siemens.com
maintainer
#16 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

Quoted 32 lines · Alexander
Quoted 8 lines · Daniel Golle

Add driver for the MaxLinear GSW1xx family of Ethernet switch ICs which are based on the same IP as the Lantiq/Intel GSWIP found in the Lantiq VR9 and Intel GRX MIPS router SoCs. The main difference is that instead of using memory-mapped I/O to communicate with the host CPU these ICs are connected via MDIO (or SPI, which isn't supported by this driver). Implement the regmap API to access the switch registers over MDIO to allow reusing lantiq_gswip_common for all core functionality.

Quoted 6 lines

The GSW1xx also comes with a SerDes port capable of 1000Base-X, SGMII and 2500Base-X, which can either be used to connect an external PHY or SFP cage, or as the CPU port. Support for the SerDes interface is implemented in this driver using the phylink_pcs interface.

thank you for the patch!

Finally I was able to run selftest/drivers/net/dsa/local_termination.sh with only 2 unexpected failures on a GSW145 hardware (with TI AM62 host CPU and its CPSW (not in switchdev mode) as CPU interface).

The problems I had in the past were neither related to the GSW145 code, nor to am65-cpsw-nuss, but to the test itself:
https://lore.kernel.org/all/[email protected]/

The remaining failing test cases are:
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address [FAIL]
reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
reception succeeded, but should have failed

Quoted 5 lines

So far I didn't notice any problems with untagged read-word IP traffic over GSW145 ports.

Do you have a suggestion what could I check further regarding the failing test cases? As I understood, all of them pass on your side?

Could be that due to different revisions of the relevant H/W?

I tend to think we are better off merging the series as-is, and handle the above with follow-up, as needed. Any different opinions?

Thanks,

Paolo

#17 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

Hi Paolo,

Quoted 34 lines · Paolo Abeni
Quoted 34 lines
Quoted 8 lines

Add driver for the MaxLinear GSW1xx family of Ethernet switch ICs which are based on the same IP as the Lantiq/Intel GSWIP found in the Lantiq VR9 and Intel GRX MIPS router SoCs. The main difference is that instead of using memory-mapped I/O to communicate with the host CPU these ICs are connected via MDIO (or SPI, which isn't supported by this driver). Implement the regmap API to access the switch registers over MDIO to allow reusing lantiq_gswip_common for all core functionality.

Quoted 6 lines

The GSW1xx also comes with a SerDes port capable of 1000Base-X, SGMII and 2500Base-X, which can either be used to connect an external PHY or SFP cage, or as the CPU port. Support for the SerDes interface is implemented in this driver using the phylink_pcs interface.

thank you for the patch!

Finally I was able to run selftest/drivers/net/dsa/local_termination.sh with only 2 unexpected failures on a GSW145 hardware (with TI AM62 host CPU and its CPSW (not in switchdev mode) as CPU interface).

The problems I had in the past were neither related to the GSW145 code, nor to am65-cpsw-nuss, but to the test itself:
https://lore.kernel.org/all/[email protected]/

The remaining failing test cases are:
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address   [FAIL] reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti   [FAIL] reception succeeded, but should have failed

So far I didn't notice any problems with untagged read-word IP traffic over GSW145 ports.

Quoted 7 lines
Quoted 2 lines

Do you have a suggestion what could I check further regarding the failing test cases? As I understood, all of them pass on your side?

Could be that due to different revisions of the relevant H/W?

I tend to think we are better off merging the series as-is, and handle the above with follow-up, as needed. Any different opinions?

sounds good to me!

Signature · 3 lines
Alexander Sverdlin
Siemens AG
www.siemens.com
maintainer
#18 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

In reply to Paolo Abeni
Quoted 14 lines · Paolo Abeni
Quoted 13 lines · Alexander

The problems I had in the past were neither related to the GSW145 code, nor to am65-cpsw-nuss, but to the test itself:
https://lore.kernel.org/all/[email protected]/

The remaining failing test cases are:
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address [FAIL]
reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
reception succeeded, but should have failed

So far I didn't notice any problems with untagged read-word IP traffic over GSW145 ports.

Quoted 7 lines
Quoted 2 lines

Do you have a suggestion what could I check further regarding the failing test cases? As I understood, all of them pass on your side?

Could be that due to different revisions of the relevant H/W?

I tend to think we are better off merging the series as-is, and handle the above with follow-up, as needed. Any different opinions?

Yeah, it's a problem with the test.

I too agree with merging as-is. I do have some nitpicks but they don't require resending the 12-patch series.

maintainer
#19 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

In reply to Sverdlin, Alexander
Quoted 11 lines · Alexander

The remaining failing test cases are:
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address [FAIL]
reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
reception succeeded, but should have failed

So far I didn't notice any problems with untagged read-word IP traffic over GSW145 ports.

Do you have a suggestion what could I check further regarding the failing test cases? As I understood, all of them pass on your side?

These failures mean that the test thinks the port implements IFF_UNICAST_FLT, yet it doesn't drop unregistered traffic.

	[ $no_unicast_flt = true ] && should_receive=true || should_receive=false
	check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
		"$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
		$should_receive "$test_name"

But DSA doesn't report IFF_UNICAST_FLT for this switch, because it doesn't fulfill the dsa_switch_supports_uc_filtering() requirements. So should_receive should have been true, and the question becomes why does this code snippet set no_unicast_flt=false:

vlan_over_bridged_port()
{
local no_unicast_flt=true
local vlan_filtering=$1
local skip_ptp=false

# br_manage_promisc() will not force a single vlan_filtering port to # promiscuous mode, so we should still expect unicast filtering to take # place if the device can do it.
if [ $(has_unicast_flt $h2) = yes ] && [ $vlan_filtering = 1 ]; then
no_unicast_flt=false
fi

Because IFF_UNICAST_FLT is not a UAPI-visible property, has_unicast_flt() does an indirect check: it creates a macvlan upper with a different MAC address than the physical interface's, and this results in a dev_uc_add() in the kernel. If the unicast address is non-empty but the device doesn't have IFF_UNICAST_FLT, __dev_set_rx_mode() makes the interface promiscuous, which has_unicast_flt() then tests.

Something along this path is going wrong, because $(has_unicast_flt $h2) returns yes, so $h2 didn't become promiscuous when adding the macvlan upper.

Could it be that $h2 needs to be up for has_unicast_flt() to work, and it's not? I'm looking at __dev_set_rx_mode() in the kernel:

	/* dev_open will call this function so the list will stay sane. */
	if (!(dev->flags&IFF_UP))
		return;

	... the code below is skipped

	if (!(dev->priv_flags & IFF_UNICAST_FLT)) {
		/* Unicast addresses changes may only happen under the rtnl,
		 * therefore calling __dev_set_promiscuity here is safe.
		 */
		if (!netdev_uc_empty(dev) && !dev->uc_promisc) {
			__dev_set_promiscuity(dev, 1, false);
			dev->uc_promisc = true;
		} else if (netdev_uc_empty(dev) && dev->uc_promisc) {
			__dev_set_promiscuity(dev, -1, false);
			dev->uc_promisc = false;
		}
	}
#20 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

Hi Vladimir,

Quoted 37 lines · Vladimir Oltean
Quoted 11 lines

The remaining failing test cases are:
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address   [FAIL] reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti   [FAIL] reception succeeded, but should have failed

So far I didn't notice any problems with untagged read-word IP traffic over GSW145 ports.

Do you have a suggestion what could I check further regarding the failing test cases? As I understood, all of them pass on your side?

These failures mean that the test thinks the port implements IFF_UNICAST_FLT, yet it doesn't drop unregistered traffic.

	[ $no_unicast_flt = true ] && should_receive=true || should_receive=false
	check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
		"$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
		$should_receive "$test_name"

But DSA doesn't report IFF_UNICAST_FLT for this switch, because it doesn't fulfill the dsa_switch_supports_uc_filtering() requirements. So should_receive should have been true, and the question becomes why does this code snippet set no_unicast_flt=false:

vlan_over_bridged_port()
{
local no_unicast_flt=true
local vlan_filtering=$1
local skip_ptp=false

# br_manage_promisc() will not force a single vlan_filtering port to # promiscuous mode, so we should still expect unicast filtering to take # place if the device can do it.
if [ $(has_unicast_flt $h2) = yes ] && [ $vlan_filtering = 1 ]; then
no_unicast_flt=false
fi

Quoted 6 lines

Because IFF_UNICAST_FLT is not a UAPI-visible property, has_unicast_flt() does an indirect check: it creates a macvlan upper with a different MAC address than the physical interface's, and this results in a dev_uc_add() in the kernel. If the unicast address is non-empty but the device doesn't have IFF_UNICAST_FLT, __dev_set_rx_mode() makes the interface promiscuous, which has_unicast_flt() then tests.

here is the corresponding kernel log preceding the failing test cases, maybe it might help?

[  539.836062] mxl-gsw1xx 8000f00.mdio:00 lan1: left allmulticast mode
[  539.845053] am65-cpsw-nuss 8000000.ethernet eth0: left allmulticast mode
[  539.853401] br0: port 1(lan1) entered disabled state
[  545.641001] am65-cpsw-nuss 8000000.ethernet: Removing vlan 1 from vlan filter
[  546.075411] mxl-gsw1xx 8000f00.mdio:00 lan1: Link is Down
[  546.666944] mxl-gsw1xx 8000f00.mdio:00 lan0: Link is Down
[  547.779308] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
[  548.803903] mxl-gsw1xx 8000f00.mdio:00 lan0: configuring for phy/internal link mode
[  549.561829] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
[  550.366300] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
[  550.395032] br0: port 1(lan1) entered blocking state
[  550.401063] br0: port 1(lan1) entered disabled state
[  550.406470] mxl-gsw1xx 8000f00.mdio:00 lan1: entered allmulticast mode
[  550.413868] am65-cpsw-nuss 8000000.ethernet eth0: entered allmulticast mode
[  550.440111] am65-cpsw-nuss 8000000.ethernet: Adding vlan 1 to vlan filter
[  550.465479] am65-cpsw-nuss 8000000.ethernet: Adding vlan 100 to vlan filter
[  552.519232] mxl-gsw1xx 8000f00.mdio:00 lan1: Link is Up - 100Mbps/Full - flow control rx/tx
[  552.530513] br0: port 1(lan1) entered blocking state
[  552.536463] br0: port 1(lan1) entered forwarding state
[  552.999330] mxl-gsw1xx 8000f00.mdio:00 lan0: Link is Up - 100Mbps/Full - flow control rx/tx
[  581.899262] lan1.100: entered promiscuous mode
[  592.995574] lan1.100: left promiscuous mode
[  596.665022] lan1.100: entered allmulticast mode
[  607.789778] lan1.100: left allmulticast mode

--
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to macvlan MAC address [ OK ]
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address [FAIL]
reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, promisc [ OK ]
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
reception succeeded, but should have failed

Signature · 3 lines
Alexander Sverdlin
Siemens AG
www.siemens.com
#21 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

Hi Vladimir,

Quoted 70 lines · Alexander Sverdlin
Quoted 37 lines
Quoted 11 lines

The remaining failing test cases are:
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address   [FAIL] reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti   [FAIL] reception succeeded, but should have failed

So far I didn't notice any problems with untagged read-word IP traffic over GSW145 ports.

Do you have a suggestion what could I check further regarding the failing test cases? As I understood, all of them pass on your side?

These failures mean that the test thinks the port implements IFF_UNICAST_FLT, yet it doesn't drop unregistered traffic.

  [ $no_unicast_flt = true ] && should_receive=true || should_receive=false check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
  "$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
  $should_receive "$test_name"

But DSA doesn't report IFF_UNICAST_FLT for this switch, because it doesn't fulfill the dsa_switch_supports_uc_filtering() requirements. So should_receive should have been true, and the question becomes why does this code snippet set no_unicast_flt=false:

vlan_over_bridged_port()
{
  local no_unicast_flt=true
  local vlan_filtering=$1
  local skip_ptp=false

  # br_manage_promisc() will not force a single vlan_filtering port to

 	# promiscuous mode, so we should still expect unicast filtering to take
 	# place if the device can do it.
 	if [ $(has_unicast_flt $h2) = yes ] && [ $vlan_filtering = 1 ]; then
 		no_unicast_flt=false
 	fi
Quoted 6 lines

Because IFF_UNICAST_FLT is not a UAPI-visible property, has_unicast_flt() does an indirect check: it creates a macvlan upper with a different MAC address than the physical interface's, and this results in a dev_uc_add() in the kernel. If the unicast address is non-empty but the device doesn't have IFF_UNICAST_FLT, __dev_set_rx_mode() makes the interface promiscuous, which has_unicast_flt() then tests.

here is the corresponding kernel log preceding the failing test cases, maybe it might help?

[  539.836062] mxl-gsw1xx 8000f00.mdio:00 lan1: left allmulticast mode
[  539.845053] am65-cpsw-nuss 8000000.ethernet eth0: left allmulticast mode
[  539.853401] br0: port 1(lan1) entered disabled state
[  545.641001] am65-cpsw-nuss 8000000.ethernet: Removing vlan 1 from vlan filter [  546.075411] mxl-gsw1xx 8000f00.mdio:00 lan1: Link is Down
[  546.666944] mxl-gsw1xx 8000f00.mdio:00 lan0: Link is Down
[  547.779308] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode [  548.803903] mxl-gsw1xx 8000f00.mdio:00 lan0: configuring for phy/internal link mode [  549.561829] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode [  550.366300] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode [  550.395032] br0: port 1(lan1) entered blocking state
[  550.401063] br0: port 1(lan1) entered disabled state
[  550.406470] mxl-gsw1xx 8000f00.mdio:00 lan1: entered allmulticast mode
[  550.413868] am65-cpsw-nuss 8000000.ethernet eth0: entered allmulticast mode [  550.440111] am65-cpsw-nuss 8000000.ethernet: Adding vlan 1 to vlan filter
[  550.465479] am65-cpsw-nuss 8000000.ethernet: Adding vlan 100 to vlan filter [  552.519232] mxl-gsw1xx 8000f00.mdio:00 lan1: Link is Up - 100Mbps/Full - flow control rx/tx [  552.530513] br0: port 1(lan1) entered blocking state
[  552.536463] br0: port 1(lan1) entered forwarding state
[  552.999330] mxl-gsw1xx 8000f00.mdio:00 lan0: Link is Up - 100Mbps/Full - flow control rx/tx [  581.899262] lan1.100: entered promiscuous mode
[  592.995574] lan1.100: left promiscuous mode
[  596.665022] lan1.100: entered allmulticast mode

Quoted 8 lines

[  607.789778] lan1.100: left allmulticast mode
--
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to macvlan MAC address   [ OK ]
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address   [FAIL] reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, promisc   [ OK ]
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti   [FAIL] reception succeeded, but should have failed

does the following help?

# dev=lan1

# ip link set $dev up
[ 2005.688205] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
[ 2005.714288] 8021q: adding VLAN 0 to HW filter on device lan1
# ip link add link $dev name macvlan-tmp type macvlan mode private
# ip l show lan1
4: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff
# ip l 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether c0:d6:0a:e6:89:9e brd ff:ff:ff:ff:ff:ff
3: lan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b6 brd ff:ff:ff:ff:ff:ff
4: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff
5: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b8 brd ff:ff:ff:ff:ff:ff
6: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b9 brd ff:ff:ff:ff:ff:ff
7: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:ba brd ff:ff:ff:ff:ff:ff
8: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 96:f1:ca:89:bc:b0 brd ff:ff:ff:ff:ff:ff
60: macvlan-tmp@lan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 9e:07:e8:7c:9d:99 brd ff:ff:ff:ff:ff:ff
# ip link set macvlan-tmp address 00:a0:03:ea:fe:b8
# ip link set macvlan-tmp up
[ 2109.392322] 8021q: adding VLAN 0 to HW filter on device macvlan-tmp
# ip -j -d link show dev $dev | jq -r '.[].promiscuity'
2
# ip -j -d link show dev $dev
[{"ifindex":4,"link":"eth0","ifname":"lan1","flags":["NO-CARRIER","BROADCAST","MULTICAST","PROMISC","UP"],"mtu":1500,"qdisc":"noqueue","operstate":"DOWN","linkmode":"DEFAULT","group":"defau]
# ip -d link show dev $dev
4: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff promiscuity 2 allmulti 0 minmtu 68 maxmtu 2378 
    dsa conduit eth0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro 
Signature · 3 lines
Alexander Sverdlin
Siemens AG
www.siemens.com
maintainer
#22 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

Quoted 114 lines · Alexander

Hi Vladimir,

Quoted 70 lines · Alexander Sverdlin
Quoted 37 lines
Quoted 11 lines

The remaining failing test cases are:
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address   [FAIL] reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti   [FAIL] reception succeeded, but should have failed

So far I didn't notice any problems with untagged read-word IP traffic over GSW145 ports.

Do you have a suggestion what could I check further regarding the failing test cases? As I understood, all of them pass on your side?

These failures mean that the test thinks the port implements IFF_UNICAST_FLT, yet it doesn't drop unregistered traffic.

  [ $no_unicast_flt = true ] && should_receive=true || should_receive=false check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
  "$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
  $should_receive "$test_name"

But DSA doesn't report IFF_UNICAST_FLT for this switch, because it doesn't fulfill the dsa_switch_supports_uc_filtering() requirements. So should_receive should have been true, and the question becomes why does this code snippet set no_unicast_flt=false:

vlan_over_bridged_port()
{
  local no_unicast_flt=true
  local vlan_filtering=$1
  local skip_ptp=false

  # br_manage_promisc() will not force a single vlan_filtering port to

 	# promiscuous mode, so we should still expect unicast filtering to take
 	# place if the device can do it.
 	if [ $(has_unicast_flt $h2) = yes ] && [ $vlan_filtering = 1 ]; then
 		no_unicast_flt=false
 	fi
Quoted 6 lines

Because IFF_UNICAST_FLT is not a UAPI-visible property, has_unicast_flt() does an indirect check: it creates a macvlan upper with a different MAC address than the physical interface's, and this results in a dev_uc_add() in the kernel. If the unicast address is non-empty but the device doesn't have IFF_UNICAST_FLT, __dev_set_rx_mode() makes the interface promiscuous, which has_unicast_flt() then tests.

here is the corresponding kernel log preceding the failing test cases, maybe it might help?

[  539.836062] mxl-gsw1xx 8000f00.mdio:00 lan1: left allmulticast mode
[  539.845053] am65-cpsw-nuss 8000000.ethernet eth0: left allmulticast mode
[  539.853401] br0: port 1(lan1) entered disabled state
[  545.641001] am65-cpsw-nuss 8000000.ethernet: Removing vlan 1 from vlan filter [  546.075411] mxl-gsw1xx 8000f00.mdio:00 lan1: Link is Down
[  546.666944] mxl-gsw1xx 8000f00.mdio:00 lan0: Link is Down
[  547.779308] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode [  548.803903] mxl-gsw1xx 8000f00.mdio:00 lan0: configuring for phy/internal link mode [  549.561829] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode [  550.366300] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode [  550.395032] br0: port 1(lan1) entered blocking state
[  550.401063] br0: port 1(lan1) entered disabled state
[  550.406470] mxl-gsw1xx 8000f00.mdio:00 lan1: entered allmulticast mode
[  550.413868] am65-cpsw-nuss 8000000.ethernet eth0: entered allmulticast mode [  550.440111] am65-cpsw-nuss 8000000.ethernet: Adding vlan 1 to vlan filter
[  550.465479] am65-cpsw-nuss 8000000.ethernet: Adding vlan 100 to vlan filter [  552.519232] mxl-gsw1xx 8000f00.mdio:00 lan1: Link is Up - 100Mbps/Full - flow control rx/tx [  552.530513] br0: port 1(lan1) entered blocking state
[  552.536463] br0: port 1(lan1) entered forwarding state
[  552.999330] mxl-gsw1xx 8000f00.mdio:00 lan0: Link is Up - 100Mbps/Full - flow control rx/tx [  581.899262] lan1.100: entered promiscuous mode
[  592.995574] lan1.100: left promiscuous mode
[  596.665022] lan1.100: entered allmulticast mode

Quoted 8 lines

[  607.789778] lan1.100: left allmulticast mode
--
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to macvlan MAC address   [ OK ]
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address   [FAIL] reception succeeded, but should have failed
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, promisc   [ OK ]
TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti   [FAIL] reception succeeded, but should have failed

does the following help?

# dev=lan1

# ip link set $dev up
[ 2005.688205] mxl-gsw1xx 8000f00.mdio:00 lan1: configuring for phy/internal link mode
[ 2005.714288] 8021q: adding VLAN 0 to HW filter on device lan1
# ip link add link $dev name macvlan-tmp type macvlan mode private
# ip l show lan1
4: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff
# ip l 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether c0:d6:0a:e6:89:9e brd ff:ff:ff:ff:ff:ff
3: lan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b6 brd ff:ff:ff:ff:ff:ff
4: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff
5: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b8 brd ff:ff:ff:ff:ff:ff
6: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b9 brd ff:ff:ff:ff:ff:ff
7: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:ba brd ff:ff:ff:ff:ff:ff
8: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 96:f1:ca:89:bc:b0 brd ff:ff:ff:ff:ff:ff
60: macvlan-tmp@lan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 9e:07:e8:7c:9d:99 brd ff:ff:ff:ff:ff:ff
# ip link set macvlan-tmp address 00:a0:03:ea:fe:b8
# ip link set macvlan-tmp up
[ 2109.392322] 8021q: adding VLAN 0 to HW filter on device macvlan-tmp
Quoted 8 lines
# ip -j -d link show dev $dev | jq -r '.[].promiscuity'
2
# ip -j -d link show dev $dev
[{"ifindex":4,"link":"eth0","ifname":"lan1","flags":["NO-CARRIER","BROADCAST","MULTICAST","PROMISC","UP"],"mtu":1500,"qdisc":"noqueue","operstate":"DOWN","linkmode":"DEFAULT","group":"defau]
# ip -d link show dev $dev
4: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff promiscuity 2 allmulti 0 minmtu 68 maxmtu 2378 
    dsa conduit eth0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro 

It partially does, yes. The promiscuity is 2, which suggests it was already 1 when has_unicast_flt() started to run. The function is not written to expect that to happen. Although I don't yet understand why lan1 originally entered promiscuous mode - that is not in your logs.

This is a separate environment from the selftest with the commands ran manually, no? Because you can just run the selftest with "bash -x".

#23 lore raw

Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

Hi Vladimir,

Quoted 5 lines · Vladimir Oltean
Quoted 4 lines
# ip -d link show dev $dev
4: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
     link/ether 00:a0:03:ea:fe:b7 brd ff:ff:ff:ff:ff:ff promiscuity 2 allmulti 0 minmtu 68 maxmtu 2378 
     dsa conduit eth0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro 
Quoted 7 lines

It partially does, yes. The promiscuity is 2, which suggests it was already 1 when has_unicast_flt() started to run. The function is not written to expect that to happen. Although I don't yet understand why lan1 originally entered promiscuous mode - that is not in your logs.

This is a separate environment from the selftest with the commands ran manually, no? Because you can just run the selftest with "bash -x".

Yes, I tried the above manually.
Let me repeat the test after a clean boot and with "bash -x", not that we are debugging something different from the real test...

Signature · 3 lines
Alexander Sverdlin
Siemens AG
www.siemens.com
#24 lore raw
In reply to Daniel Golle
This series was applied to netdev/net-next.git (main) by Jakub Kicinski <[email protected]>:

Hello:

This series was applied to netdev/net-next.git (main) by Jakub Kicinski <[email protected]>:

Quoted 9 lines · On Mon, 3 Nov 2025 12:16:57 +0000 you wrote:

This patch series extends the existing lantiq_gswip DSA driver to support the MaxLinear GSW1xx family of dedicated Ethernet switch ICs. These switches are based on the same IP as the Lantiq/Intel GSWIP found in VR9 and xRX MIPS router SoCs which are currently supported by the lantiq_gswip driver, but they are dedicated ICs connected via MDIO rather than built-in components of a SoC accessible via memory-mapped I/O.

[...]

Here is the summary with links:
- [net-next,v7,01/12] net: dsa: lantiq_gswip: split into common and MMIO parts

    https://git.kernel.org/netdev/net-next/c/322a1e6f3d68
  - [net-next,v7,02/12] net: dsa: lantiq_gswip: support enable/disable learning
    https://git.kernel.org/netdev/net-next/c/a7d4b05f9d74
  - [net-next,v7,03/12] net: dsa: lantiq_gswip: support Energy Efficient Ethernet
    https://git.kernel.org/netdev/net-next/c/9ec1fc0bf2b0
  - [net-next,v7,04/12] net: dsa: lantiq_gswip: set link parameters also for CPU port
    https://git.kernel.org/netdev/net-next/c/3e5ef3b1709a
  - [net-next,v7,05/12] net: dsa: lantiq_gswip: define and use GSWIP_TABLE_MAC_BRIDGE_VAL1_VALID
    https://git.kernel.org/netdev/net-next/c/0c56a98560c1
  - [net-next,v7,06/12] dt-bindings: net: dsa: lantiq,gswip: add MaxLinear RMII refclk output property
    https://git.kernel.org/netdev/net-next/c/e836824116b5
  - [net-next,v7,07/12] net: dsa: lantiq_gswip: add vendor property to setup MII refclk output
    https://git.kernel.org/netdev/net-next/c/319fd7e9d446
  - [net-next,v7,08/12] dt-bindings: net: dsa: lantiq,gswip: add support for MII delay properties
    https://git.kernel.org/netdev/net-next/c/bea0c1778611
  - [net-next,v7,09/12] net: dsa: lantiq_gswip: allow adjusting MII delays
    https://git.kernel.org/netdev/net-next/c/cdef8e47b638
  - [net-next,v7,10/12] dt-bindings: net: dsa: lantiq,gswip: add support for MaxLinear GSW1xx switches
    https://git.kernel.org/netdev/net-next/c/e1bb4b36a7ae
  - [net-next,v7,11/12] net: dsa: add tagging driver for MaxLinear GSW1xx switch family
    https://git.kernel.org/netdev/net-next/c/c6230446b1a6
  - [net-next,v7,12/12] net: dsa: add driver for MaxLinear GSW1xx switch family
    https://git.kernel.org/netdev/net-next/c/22335939ec90

You are awesome, thank you!

Signature · 2 lines
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html