net: dsa: lantiq_gswip: Add support for MaxLinear GSW1xx switch family
Subsystems (5)
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
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
@@ -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
@@ -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
@@ -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.
PATCH v7 2/12 net: dsa: lantiq_gswip: support enable/disable learning
In reply to Daniel GolleSwitch 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
@@ -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
PATCH v7 3/12 net: dsa: lantiq_gswip: support Energy Efficient Ethernet
In reply to Daniel GolleIntroduce 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
@@ -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
PATCH v7 4/12 net: dsa: lantiq_gswip: set link parameters also for CPU port
In reply to Daniel GolleOn 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
@@ -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
PATCH v7 5/12 net: dsa: lantiq_gswip: define and use GSWIP_TABLE_MAC_BRIDGE_VAL1_VALID
In reply to Daniel GolleWhen 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
@@ -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
@@ -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
PATCH v7 6/12 dt-bindings: net: dsa: lantiq,gswip: add MaxLinear RMII refclk output property
In reply to Daniel GolleAdd 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
@@ -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
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.
Signed-off-by Daniel Golle <[email protected]>Reviewed-by Alexander Sverdlin <[email protected]>---
Best regards,
Krzysztof
PATCH v7 7/12 net: dsa: lantiq_gswip: add vendor property to setup MII refclk output
In reply to Daniel GolleRead 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
@@ -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
PATCH v7 8/12 dt-bindings: net: dsa: lantiq,gswip: add support for MII delay properties
In reply to Daniel GolleAdd 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
@@ -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
PATCH v7 9/12 net: dsa: lantiq_gswip: allow adjusting MII delays
In reply to Daniel GolleCurrently 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
@@ -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
PATCH v7 10/12 dt-bindings: net: dsa: lantiq,gswip: add support for MaxLinear GSW1xx switches
In reply to Daniel GolleExtend 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
@@ -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 = <ð0>; + + 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
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.
Signed-off-by Daniel Golle <[email protected]>---
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
PATCH v7 11/12 net: dsa: add tagging driver for MaxLinear GSW1xx switch family
In reply to Daniel GolleAdd 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
@@ -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
@@ -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 31enum 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
@@ -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
@@ -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
@@ -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
PATCH v7 12/12 net: dsa: add driver for MaxLinear GSW1xx switch family
In reply to Daniel GolleAdd 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
@@ -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
@@ -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
@@ -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
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_commonfor 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_pcsinterface.Signed-off-by Daniel Golle <[email protected]>
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 changesv6: 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 landv3:
* avoid disrupting link when calling .pcs_config()
* sort functions andphylink_pcs_opsinstance 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 interfacev2: 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
Paolo Abeni
maintainerRe: [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_commonfor 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_pcsinterface.Signed-off-by Daniel Golle <[email protected]>thank you for the patch!
Finally I was able to run
selftest/drivers/net/dsa/local_termination.shwith 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
Sverdlin, Alexander
Tested-byRe: [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_commonfor 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_pcsinterface.Signed-off-by Daniel Golle <[email protected]>thank you for the patch!
Finally I was able to run
selftest/drivers/net/dsa/local_termination.shwith 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 failedSo 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
Vladimir Oltean
maintainerRe: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family
In reply to Paolo AbeniQuoted 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 failedSo 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.
Vladimir Oltean
maintainerRe: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family
In reply to Sverdlin, AlexanderQuoted 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 failedSo 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;
}
}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 failedSo 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_FLTfor this switch, because it doesn't fulfill thedsa_switch_supports_uc_filtering()requirements. Soshould_receiveshould 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 singlevlan_filteringport 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_FLTis 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 adev_uc_add()in the kernel. If the unicast address is non-empty but the device doesn't haveIFF_UNICAST_FLT,__dev_set_rx_mode()makes the interface promiscuous, whichhas_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
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 failedSo 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_FLTfor this switch, because it doesn't fulfill thedsa_switch_supports_uc_filtering()requirements. Soshould_receiveshould 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 singlevlan_filteringport 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 fiQuoted 6 lines
Because
IFF_UNICAST_FLTis 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 adev_uc_add()in the kernel. If the unicast address is non-empty but the device doesn't haveIFF_UNICAST_FLT,__dev_set_rx_mode()makes the interface promiscuous, whichhas_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
Vladimir Oltean
maintainerRe: [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 failedSo 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_FLTfor this switch, because it doesn't fulfill thedsa_switch_supports_uc_filtering()requirements. Soshould_receiveshould 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 singlevlan_filteringport 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 fiQuoted 6 lines
Because
IFF_UNICAST_FLTis 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 adev_uc_add()in the kernel. If the unicast address is non-empty but the device doesn't haveIFF_UNICAST_FLT,__dev_set_rx_mode()makes the interface promiscuous, whichhas_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 modeQuoted 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 faileddoes 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".
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
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_gswipDSA 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 thelantiq_gswipdriver, 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