linux-toradex.git/drivers/net/dsa/Kconfig, branch master Linux kernel for Apalis and Colibri modules net: dsa: add basic initial driver for MxL862xx switches 2026-02-11T10:27:58+00:00 Daniel Golle daniel@makrotopia.org 2026-02-07T03:07:27+00:00 23794bec1cb606fee9e4876f0e86f592e1301f58 Add very basic DSA driver for MaxLinear's MxL862xx switches. In contrast to previous MaxLinear switches the MxL862xx has a built-in processor that runs a sophisticated firmware based on Zephyr RTOS. Interaction between the host and the switch hence is organized using a software API of that firmware rather than accessing hardware registers directly. Add descriptions of the most basic firmware API calls to access the built-in MDIO bus hosting the 2.5GE PHYs, basic port control as well as setting up the CPU port. Implement a very basic DSA driver using that API which is sufficient to get packets flowing between the user ports and the CPU port. The firmware offers all features one would expect from a modern switch hardware, they are going to be added one by one in follow-up patch series. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/ccde07e8cf33d8ae243000013b57cfaa2695e0a9.1770433307.git.daniel@makrotopia.org Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 
Add very basic DSA driver for MaxLinear's MxL862xx switches.

In contrast to previous MaxLinear switches the MxL862xx has a built-in
processor that runs a sophisticated firmware based on Zephyr RTOS.
Interaction between the host and the switch hence is organized using a
software API of that firmware rather than accessing hardware registers
directly.

Add descriptions of the most basic firmware API calls to access the
built-in MDIO bus hosting the 2.5GE PHYs, basic port control as well as
setting up the CPU port.

Implement a very basic DSA driver using that API which is sufficient to
get packets flowing between the user ports and the CPU port.

The firmware offers all features one would expect from a modern switch
hardware, they are going to be added one by one in follow-up patch
series.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/ccde07e8cf33d8ae243000013b57cfaa2695e0a9.1770433307.git.daniel@makrotopia.org
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net: dsa: yt921x: Add DCB/QoS support 2026-02-03T14:09:31+00:00 David Yang mmyangfl@gmail.com 2026-01-31T02:18:51+00:00 d5f778353fd443efd55069b93f3cd0447cfb9276 Set up global DSCP/PCP priority mappings and add related DCB methods. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260131021854.3405036-6-mmyangfl@gmail.com Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 
Set up global DSCP/PCP priority mappings and add related DCB methods.

Signed-off-by: David Yang <mmyangfl@gmail.com>
Link: https://patch.msgid.link/20260131021854.3405036-6-mmyangfl@gmail.com
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net: dsa: yt921x: Add support for Motorcomm YT921x 2025-10-22T01:25:30+00:00 David Yang mmyangfl@gmail.com 2025-10-17T06:08:55+00:00 186623f4aa724c46cbb4dbd5235cf6942215f5b5 Motorcomm YT921x is a series of ethernet switches developed by Shanghai Motorcomm Electronic Technology, including: - YT9215S / YT9215RB / YT9215SC: 5 GbE PHYs - YT9213NB / YT9214NB: 2 GbE PHYs - YT9218N / YT9218MB: 8 GbE PHYs and up to 2 GMACs. Driver verified on a stock wireless router with IPQ5018 + YT9215S. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20251017060859.326450-4-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Motorcomm YT921x is a series of ethernet switches developed by Shanghai
Motorcomm Electronic Technology, including:

  - YT9215S / YT9215RB / YT9215SC: 5 GbE PHYs
  - YT9213NB / YT9214NB: 2 GbE PHYs
  - YT9218N / YT9218MB: 8 GbE PHYs

and up to 2 GMACs.

Driver verified on a stock wireless router with IPQ5018 + YT9215S.

Signed-off-by: David Yang <mmyangfl@gmail.com>
Link: https://patch.msgid.link/20251017060859.326450-4-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: dsa: lantiq_gswip: move to dedicated folder 2025-09-03T00:45:42+00:00 Daniel Golle daniel@makrotopia.org 2025-08-30T02:32:42+00:00 cb477c30512db29325c0503ba96a6158a61b7e7c Move the lantiq_gswip driver to its own folder and update MAINTAINERS file accordingly. This is done ahead of extending the driver to support the MaxLinear GSW1xx series of standalone switch ICs, which includes adding a bunch of files. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de> Link: https://patch.msgid.link/a5923dee9a174501b284dc473bdec9dd89c68de1.1756520811.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Move the lantiq_gswip driver to its own folder and update
MAINTAINERS file accordingly.
This is done ahead of extending the driver to support the MaxLinear
GSW1xx series of standalone switch ICs, which includes adding a bunch
of files.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de>
Link: https://patch.msgid.link/a5923dee9a174501b284dc473bdec9dd89c68de1.1756520811.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: dsa: ks8995: Add basic switch set-up 2025-08-19T00:26:09+00:00 Linus Walleij linus.walleij@linaro.org 2025-08-13T21:43:06+00:00 a7fe8b266f659624309c69208be0410584bb9980 We start to extend the KS8995 driver by simply registering it as a DSA device and implementing a few switch callbacks for STP set-up and such to begin with. No special tags or other advanced stuff: we use DSA_TAG_NONE and rely on the default set-up in the switch with the special DSA tags turned off. This makes the switch wire up properly to all its PHY's and simple bridge traffic works properly. After this the bridge DT bindings are respected, ports and their PHYs get connected to the switch and react appropriately through the phylib when cables are plugged in etc. Tested like this in a hacky OpenWrt image: Bring up conduit interface manually: ixp4xx_eth c8009000.ethernet eth0: eth0: link up, speed 100 Mb/s, full duplex spi-ks8995 spi0.0: enable port 0 spi-ks8995 spi0.0: set KS8995_REG_PC2 for port 0 to 06 spi-ks8995 spi0.0 lan1: configuring for phy/mii link mode spi-ks8995 spi0.0 lan1: Link is Up - 100Mbps/Full - flow control rx/tx PING 169.254.1.1 (169.254.1.1): 56 data bytes 64 bytes from 169.254.1.1: seq=0 ttl=64 time=1.629 ms 64 bytes from 169.254.1.1: seq=1 ttl=64 time=0.951 ms I also tested SSH from the device to the host and it works fine. It also works fine to ping the device from the host and to SSH into the device from the host. This brings the ks8995 driver to a reasonable state where it can be used from the current device tree bindings and the existing device trees in the kernel. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250813-ks8995-to-dsa-v1-4-75c359ede3a5@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
We start to extend the KS8995 driver by simply registering it
as a DSA device and implementing a few switch callbacks for
STP set-up and such to begin with.

No special tags or other advanced stuff: we use DSA_TAG_NONE
and rely on the default set-up in the switch with the special
DSA tags turned off. This makes the switch wire up properly
to all its PHY's and simple bridge traffic works properly.

After this the bridge DT bindings are respected, ports and their
PHYs get connected to the switch and react appropriately through
the phylib when cables are plugged in etc.

Tested like this in a hacky OpenWrt image:

Bring up conduit interface manually:
ixp4xx_eth c8009000.ethernet eth0: eth0: link up,
  speed 100 Mb/s, full duplex

spi-ks8995 spi0.0: enable port 0
spi-ks8995 spi0.0: set KS8995_REG_PC2 for port 0 to 06
spi-ks8995 spi0.0 lan1: configuring for phy/mii link mode
spi-ks8995 spi0.0 lan1: Link is Up - 100Mbps/Full - flow control rx/tx

PING 169.254.1.1 (169.254.1.1): 56 data bytes
64 bytes from 169.254.1.1: seq=0 ttl=64 time=1.629 ms
64 bytes from 169.254.1.1: seq=1 ttl=64 time=0.951 ms

I also tested SSH from the device to the host and it works fine.

It also works fine to ping the device from the host and to SSH
into the device from the host.

This brings the ks8995 driver to a reasonable state where it can
be used from the current device tree bindings and the existing
device trees in the kernel.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250813-ks8995-to-dsa-v1-4-75c359ede3a5@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: dsa: Move KS8995 to the DSA subsystem 2025-08-19T00:26:09+00:00 Linus Walleij linus.walleij@linaro.org 2025-08-13T21:43:03+00:00 60cbe71fdba16d39de24bd71e1638810da5ae7ee By reading the datasheets for the KS8995 it is obvious that this is a 100 Mbit DSA switch. Let us start the refactoring by moving it to the DSA subsystem to preserve development history. Verified that the chip still probes the same after this patch provided CONFIG_HAVE_NET_DSA, CONFIG_NET_DSA and CONFIG_DSA_KS8995 are selected. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250813-ks8995-to-dsa-v1-1-75c359ede3a5@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
By reading the datasheets for the KS8995 it is obvious that this
is a 100 Mbit DSA switch.

Let us start the refactoring by moving it to the DSA subsystem to
preserve development history.

Verified that the chip still probes the same after this patch
provided CONFIG_HAVE_NET_DSA, CONFIG_NET_DSA and CONFIG_DSA_KS8995
are selected.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250813-ks8995-to-dsa-v1-1-75c359ede3a5@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: dsa: rzn1_a5psw: add COMPILE_TEST 2025-07-10T13:41:01+00:00 Rosen Penev rosenp@gmail.com 2025-07-08T01:41:43+00:00 f38ae0c62ec8e549e752be2e23d25c142dca96c5 There's no architecture specific requirement for it to compile. Allows the bots to test compilation properly. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250708014144.2514-2-rosenp@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 
There's no architecture specific requirement for it to compile. Allows
the bots to test compilation properly.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250708014144.2514-2-rosenp@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
dsa: mt7530: Utilize REGMAP_IRQ for interrupt handling 2025-03-05T01:14:23+00:00 Daniel Golle daniel@makrotopia.org 2025-03-01T01:41:18+00:00 254f6b272e3b67bf31c42ee9da62a449d74d1478 Replace the custom IRQ chip handler and mask/unmask functions with REGMAP_IRQ. This significantly simplifies the code and allows for the removal of almost all interrupt-related functions from mt7530.c. Tested on MT7988A built-in switch (MMIO) as well as MT7531AE IC (MDIO). Signed-off-by: Daniel Golle <daniel@makrotopia.org> Acked-by: Chester A. Unal <chester.a.unal@arinc9.com> Link: https://patch.msgid.link/221013c3530b61504599e285c341a993f6188f00.1740792674.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Replace the custom IRQ chip handler and mask/unmask functions with
REGMAP_IRQ. This significantly simplifies the code and allows for the
removal of almost all interrupt-related functions from mt7530.c.

Tested on MT7988A built-in switch (MMIO) as well as MT7531AE IC (MDIO).

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
Link: https://patch.msgid.link/221013c3530b61504599e285c341a993f6188f00.1740792674.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: dsa: vsc73xx: Implement the tag_8021q VLAN operations 2024-07-15T13:55:15+00:00 Pawel Dembicki paweldembicki@gmail.com 2024-07-13T21:16:14+00:00 e3386ec4ec9083522c36ab0ddfc638c90395c741 This patch is a simple implementation of 802.1q tagging in the vsc73xx driver. Currently, devices with DSA_TAG_PROTO_NONE are not functional. The VSC73XX family doesn't provide any tag support for external Ethernet ports. The only option available is VLAN-based tagging, which requires constant hardware VLAN filtering. While the VSC73XX family supports provider bridging, it only supports QinQ without full implementation of 802.1AD. This means it only allows the doubled 0x8100 TPID. In the simple port mode, QinQ is enabled to preserve forwarding of VLAN-tagged frames. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20240713211620.1125910-9-paweldembicki@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
This patch is a simple implementation of 802.1q tagging in the vsc73xx
driver. Currently, devices with DSA_TAG_PROTO_NONE are not functional.
The VSC73XX family doesn't provide any tag support for external Ethernet
ports.

The only option available is VLAN-based tagging, which requires constant
hardware VLAN filtering. While the VSC73XX family supports provider
bridging, it only supports QinQ without full implementation of 802.1AD.
This means it only allows the doubled 0x8100 TPID.

In the simple port mode, QinQ is enabled to preserve forwarding of
VLAN-tagged frames.

Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://patch.msgid.link/20240713211620.1125910-9-paweldembicki@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: dsa: lan9303: imply SMSC_PHY 2024-05-30T00:11:45+00:00 Alexander Sverdlin alexander.sverdlin@siemens.com 2024-05-28T07:31:13+00:00 126913479e88e7e0114efe380d2437cc70d9dc05 Both LAN9303 and LAN9354 have internal PHYs on both external ports. Therefore a configuration without SMSC PHY support is non-practical at least and leads to: LAN9303_MDIO 8000f00.mdio:00: Found LAN9303 rev. 1 mdio_bus 8000f00.mdio:00: deferred probe pending: (reason unknown) Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240528073147.3604083-1-alexander.sverdlin@siemens.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Both LAN9303 and LAN9354 have internal PHYs on both external ports.
Therefore a configuration without SMSC PHY support is non-practical at
least and leads to:

LAN9303_MDIO 8000f00.mdio:00: Found LAN9303 rev. 1
mdio_bus 8000f00.mdio:00: deferred probe pending: (reason unknown)

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240528073147.3604083-1-alexander.sverdlin@siemens.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>