[PATCH net-next 0/2] net: dsa: mxl-gsw1xx: reset the switch through reset-gpios

[PATCH net-next 0/2] net: dsa: mxl-gsw1xx: reset the switch through reset-gpios

[Joseph Telaak via B4 Relay]

The GSW1xx driver never resets the switch, and the MDIO core does not
handle reset-gpios for non-PHY devices, so the driver works with whatever
the bootloader configured. On the GL.iNet GL-SFT1200 (SiFlower SF19A2890 +
GSW150) the bootloader leaves the internal PHYs one MDIO address too high,
and the WAN port has no PHY.

Patch 1 allows reset-gpios in the binding for the standalone switches.
Patch 2 pulses it at probe.

This is separate from commit 82e2c7db0830 ("net: dsa: mxl-gsw1xx: force
internal PHYs into a known reset state"), which only programs the PHY
bits of RST_REQ. On this board that commit is applied, and the PHYs still
sit at the shifted addresses; only a hardware reset of the switch moves
them back.

Tested on a GL.iNet GL-SFT1200 (Intel GSW150 / PEB7084 at SMI address
0x1f, reset on an active-low SoC GPIO), on the 6.18 backport that OpenWrt
carries: after a warm reboot and after a cold power-on, all three ports
find their PHYs at addresses 0 to 2 and link at 1 Gbit/s. Without the
patch, port 0 fails with -ENODEV after every boot.

The board's device tree goes to OpenWrt; there is no in-tree user yet.

---
Joseph Telaak (2):
      dt-bindings: net: dsa: lantiq,gswip: add reset-gpios
      net: dsa: mxl-gsw1xx: reset the switch through reset-gpios

 .../devicetree/bindings/net/dsa/lantiq,gswip.yaml        |  6 ++++++
 drivers/net/dsa/lantiq/mxl-gsw1xx.c                      | 16 ++++++++++++++++
 drivers/net/dsa/lantiq/mxl-gsw1xx.h                      |  4 ++++
 3 files changed, 26 insertions(+)
---
base-commit: 4dd16e31135ea8437a720222df34e8745f385d6d
change-id: 20261102-mxl-gsw1xx-reset-37ac836b31fe

Best regards,
--  
Joseph Telaak <joseph@telaak.dev>

[PATCH net-next 1/2] dt-bindings: net: dsa: lantiq,gswip: add reset-gpios

[Joseph Telaak via B4 Relay]

From: Joseph Telaak <joseph@telaak.dev>

The standalone GSW1xx switches have a hardware reset input, and boards
wire it to a SoC GPIO. Allow describing it. The SoC-integrated GSWIP
variants have no such pin.

Signed-off-by: Joseph Telaak <joseph@telaak.dev>
---
 Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
index 49af5573e4..9a74ea2a6d 100644
--- a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
@@ -40,6 +40,11 @@ properties:
       - const: mdio
       - const: mii
 
+  reset-gpios:
+    maxItems: 1
+    description:
+      GPIO connected to the hardware reset input of a standalone switch.
+
   mdio:
     $ref: /schemas/net/mdio.yaml#
     unevaluatedProperties: false
@@ -173,6 +178,7 @@ allOf:
         mdio:
           required:
             - compatible
+        reset-gpios: false
     else:
       properties:
         reg:

-- 
Git-155)

[PATCH net-next 2/2] net: dsa: mxl-gsw1xx: reset the switch through reset-gpios

[Joseph Telaak via B4 Relay]

From: Joseph Telaak <joseph@telaak.dev>

The switch keeps the configuration the bootloader left in it, and the
driver never resets it. The MDIO core asserts and releases reset-gpios
only for PHY devices, so a reset line described on the switch node has
no effect either.

On the GL.iNet GL-SFT1200 the bootloader leaves each internal PHY of
the GSW150 one MDIO address above its port. Port 0 then fails with
"failed to connect to PHY: -ENODEV", and the PHY that answers at a
port's address belongs to the neighbouring port. After a hardware reset
every PHY is back at its port's address and all ports work.

Request the reset GPIO in the driver and pulse it before the first
register access. The timing follows the vendor driver: asserted for
2 ms, then 100 ms before the switch is accessed.

Signed-off-by: Joseph Telaak <joseph@telaak.dev>
---
 drivers/net/dsa/lantiq/mxl-gsw1xx.c | 16 ++++++++++++++++
 drivers/net/dsa/lantiq/mxl-gsw1xx.h |  4 ++++
 2 files changed, 20 insertions(+)

diff --git a/drivers/net/dsa/lantiq/mxl-gsw1xx.c b/drivers/net/dsa/lantiq/mxl-gsw1xx.c
index a26f78e1a4..8767c8cf1d 100644
--- a/drivers/net/dsa/lantiq/mxl-gsw1xx.c
+++ b/drivers/net/dsa/lantiq/mxl-gsw1xx.c
@@ -11,6 +11,7 @@
 
 #include <linux/bits.h>
 #include <linux/delay.h>
+#include <linux/gpio/consumer.h>
 #include <linux/jiffies.h>
 #include <linux/module.h>
 #include <linux/of_device.h>
@@ -719,6 +720,7 @@ static int gsw1xx_serdes_pcs_init(struct gsw1xx_priv *priv)
 static int gsw1xx_probe(struct mdio_device *mdiodev)
 {
 	struct device *dev = &mdiodev->dev;
+	struct gpio_desc *reset_gpio;
 	struct gsw1xx_priv *priv;
 	u32 version, val;
 	u8 shellver;
@@ -737,6 +739,20 @@ static int gsw1xx_probe(struct mdio_device *mdiodev)
 	if (!priv->gswip.hw_info)
 		return -EINVAL;
 
+	/* The MDIO core handles reset-gpios only for PHYs. Reset the switch
+	 * here, so it does not run with whatever the bootloader configured.
+	 */
+	reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(reset_gpio))
+		return dev_err_probe(dev, PTR_ERR(reset_gpio),
+				     "failed to get reset GPIO\n");
+
+	if (reset_gpio) {
+		fsleep(GSW1XX_RESET_ASSERT_US);
+		gpiod_set_value_cansleep(reset_gpio, 0);
+		fsleep(GSW1XX_RESET_DEASSERT_US);
+	}
+
 	priv->gswip.gswip = gsw1xx_regmap_init(priv, "switch",
 					       GSW1XX_SWITCH_BASE, 0xfff);
 	if (IS_ERR(priv->gswip.gswip))
diff --git a/drivers/net/dsa/lantiq/mxl-gsw1xx.h b/drivers/net/dsa/lantiq/mxl-gsw1xx.h
index 81bc00eabb..684bb135bc 100644
--- a/drivers/net/dsa/lantiq/mxl-gsw1xx.h
+++ b/drivers/net/dsa/lantiq/mxl-gsw1xx.h
@@ -19,6 +19,10 @@
 
 #define GSW1XX_SYS_CLK_FREQ			340000000
 
+/* Hardware reset timing, as the vendor driver for the GSW150 does it */
+#define GSW1XX_RESET_ASSERT_US			2000
+#define GSW1XX_RESET_DEASSERT_US		100000
+
 /* SMDIO switch register base address */
 #define GSW1XX_SMDIO_BADR			0x1f
 #define  GSW1XX_SMDIO_BADR_UNKNOWN		-1

-- 
Git-155)

Re: [PATCH net-next 2/2] net: dsa: mxl-gsw1xx: reset the switch through reset-gpios

[Daniel Golle]

On Wed, Nov 04, 2026 at 02:15:48AM -0500, Joseph Telaak via B4 Relay wrote:
> From: Joseph Telaak <joseph@telaak.dev>
> 
> The switch keeps the configuration the bootloader left in it, and the
> driver never resets it. The MDIO core asserts and releases reset-gpios
> only for PHY devices, so a reset line described on the switch node has
> no effect either.
> 
> On the GL.iNet GL-SFT1200 the bootloader leaves each internal PHY of
> the GSW150 one MDIO address above its port. Port 0 then fails with
> "failed to connect to PHY: -ENODEV", and the PHY that answers at a
> port's address belongs to the neighbouring port. After a hardware reset
> every PHY is back at its port's address and all ports work.
> 
> Request the reset GPIO in the driver and pulse it before the first
> register access. The timing follows the vendor driver: asserted for
> 2 ms, then 100 ms before the switch is accessed.

Any good reason to open-code this instead of using reset-gpio
(CONFIG_RESET_GPIO)?

Re: [PATCH net-next 2/2] net: dsa: mxl-gsw1xx: reset the switch through reset-gpios

[Joseph Telaak]

On Wed, Nov 04, 2026 at 07:38:30AM +0000, Daniel Golle wrote:
> Any good reason to open-code this instead of using reset-gpio
> (CONFIG_RESET_GPIO)?

Thanks for pointing that out. v2 will use the reset controller API, so
reset-gpios is handled by reset-gpio.

On Wed, Nov 4, 2026 at 2:38 AM Daniel Golle <daniel@makrotopia.org> wrote:
>
> On Wed, Nov 04, 2026 at 02:15:48AM -0500, Joseph Telaak via B4 Relay wrote:
> > From: Joseph Telaak <joseph@telaak.dev>
> >
> > The switch keeps the configuration the bootloader left in it, and the
> > driver never resets it. The MDIO core asserts and releases reset-gpios
> > only for PHY devices, so a reset line described on the switch node has
> > no effect either.
> >
> > On the GL.iNet GL-SFT1200 the bootloader leaves each internal PHY of
> > the GSW150 one MDIO address above its port. Port 0 then fails with
> > "failed to connect to PHY: -ENODEV", and the PHY that answers at a
> > port's address belongs to the neighbouring port. After a hardware reset
> > every PHY is back at its port's address and all ports work.
> >
> > Request the reset GPIO in the driver and pulse it before the first
> > register access. The timing follows the vendor driver: asserted for
> > 2 ms, then 100 ms before the switch is accessed.
>
> Any good reason to open-code this instead of using reset-gpio
> (CONFIG_RESET_GPIO)?
>