[PATCH 0/3] arm64: dts: marvell: Add Sophos XGS 107w NPU

[PATCH 0/3] arm64: dts: marvell: Add Sophos XGS 107w NPU

[Nicolo Giuliani via B4 Relay]

The Sophos XGS 87/107 desktop firewalls pair an AMD x86 host with a
separate network processing unit (NPU): a Marvell Armada CN9130 SoC with
its own eMMC and SPI NOR flash. The NPU serves the eight RJ45 ports and
the SFP cage through a Marvell 88E6193X switch on its MDIO bus, which is
connected to the SoC by a 10GBASE-R link, and reaches the x86 host over
PCIe.

This series adds the Sophos vendor prefix, the compatible string of the
NPU board and a device tree that describes the NPU as a standalone system:
UART console, eMMC, SPI NOR flash, the PCA9555 GPIO expander of the port
LEDs, the SFP cage and the switch with its ports. The LEDs, the USB ports
and the PCIe link to the x86 host (the CN9130 acts as a PCIe endpoint
towards it, which needs endpoint support that is not part of this series)
are not described.

The reset line of the switch is not passed to the mv88e6xxx driver as
reset-gpios, because the 88E6193X needs about two seconds after a reset,
much longer than the driver waits. The boot loader resets it instead.
The details are in patch 3.

Tested on an XGS 107w with Linux 6.18: boot from eMMC, eMMC and SPI NOR
access, the mvpp2 link to the switch at 10 Gb/s, the 88E6193X probing with
its eight user ports, and 936 Mbit/s through a front port. The SFP cage
and the PCA9555 outputs are untested.

dt_binding_check passes for vendor-prefixes.yaml and armada-7k-8k.yaml,
and CHECK_DTBS=y on marvell/cn9130-sophos-xgs107w.dtb reports no warning
specific to this board.

Based on the mvebu/dt branch of the mvebu tree (008e9faade).

Signed-off-by: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>
---
Nicolo Giuliani (3):
      dt-bindings: vendor-prefixes: Add Sophos
      dt-bindings: arm: marvell: Add Sophos XGS 107w NPU
      arm64: dts: marvell: Add Sophos XGS 107w NPU board

 .../bindings/arm/marvell/armada-7k-8k.yaml         |   9 +
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 arch/arm64/boot/dts/marvell/Makefile               |   1 +
 .../boot/dts/marvell/cn9130-sophos-xgs107w.dts     | 209 +++++++++++++++++++++
 4 files changed, 221 insertions(+)
---
base-commit: 008e9faadef8c0aaa9b8a3ff05a2126e3c5b08b7
change-id: 20260919-send-dt-6bbd08a470d2

Best regards,
--  
Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>

[PATCH 1/3] dt-bindings: vendor-prefixes: Add Sophos

[Nicolo Giuliani via B4 Relay]

From: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>

Add the "sophos" vendor prefix for Sophos Ltd., a vendor of network
security appliances. It is used by the compatible string of the XGS 87/107
firewalls, documented in a following patch.

Assisted-by: LLM
Signed-off-by: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index ba20029693..3dd9d9b8ab 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1595,6 +1595,8 @@ patternProperties:
     description: Sony Corporation
   "^sophgo,.*":
     description: Sophgo Technology Inc.
+  "^sophos,.*":
+    description: Sophos Ltd.
   "^sourceparts,.*":
     description: Source Parts Inc.
   "^spacemit,.*":

-- 
2.48.1

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Sophos

[Krzysztof Kozlowski]

On Sat, Sep 19, 2026 at 09:44:17PM +0200, Nicolo Giuliani wrote:
> Add the "sophos" vendor prefix for Sophos Ltd., a vendor of network
> security appliances. It is used by the compatible string of the XGS 87/107
> firewalls, documented in a following patch.

Drop the second sentence.

With this:
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

[PATCH 2/3] dt-bindings: arm: marvell: Add Sophos XGS 107w NPU

[Nicolo Giuliani via B4 Relay]

From: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>

The Sophos XGS 87/107 desktop firewalls combine an AMD x86 host with a
separate network processing unit (NPU). The NPU is a Marvell Armada CN9130
SoC with its own eMMC and SPI NOR flash, connected to the x86 host over
PCIe. It serves the front panel ports through a Marvell 88E6193X switch.

Document the compatible string of the NPU board, with the CN9130 SoC
compatibles as fallbacks.

Assisted-by: LLM
Signed-off-by: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>
---
 Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
index 7e77310da6..2e114139f1 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
@@ -136,4 +136,13 @@ properties:
           - const: solidrun,cn9132-sr-cex7
           - const: marvell,cn9130
 
+      - description:
+          Sophos XGS 87/107 network processing unit (Armada CN9130 SoC
+          with an 88E6193X switch)
+        items:
+          - const: sophos,xgs107w-npu
+          - const: marvell,cn9130
+          - const: marvell,armada-ap807-quad
+          - const: marvell,armada-ap807
+
 additionalProperties: true

-- 
2.48.1

Re: [PATCH 2/3] dt-bindings: arm: marvell: Add Sophos XGS 107w NPU

[Krzysztof Kozlowski]

On Sat, Sep 19, 2026 at 09:44:18PM +0200, Nicolo Giuliani wrote:
> The Sophos XGS 87/107 desktop firewalls combine an AMD x86 host with a
> separate network processing unit (NPU). The NPU is a Marvell Armada CN9130
> SoC with its own eMMC and SPI NOR flash, connected to the x86 host over
> PCIe. It serves the front panel ports through a Marvell 88E6193X switch.
> 
> Document the compatible string of the NPU board, with the CN9130 SoC
> compatibles as fallbacks.
> 
> Assisted-by: LLM
> Signed-off-by: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>
> ---
>  Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> index 7e77310da6..2e114139f1 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> @@ -136,4 +136,13 @@ properties:
>            - const: solidrun,cn9132-sr-cex7
>            - const: marvell,cn9130
>  

Looks like you add to the end of the file, not in correct spot.

> +      - description:
> +          Sophos XGS 87/107 network processing unit (Armada CN9130 SoC
> +          with an 88E6193X switch)
> +        items:
> +          - const: sophos,xgs107w-npu
> +          - const: marvell,cn9130

Why is cn9130 used once as final compatible and once as not?

> +          - const: marvell,armada-ap807-quad
> +          - const: marvell,armada-ap807

Best regards,
Krzysztof

R: [PATCH 2/3] dt-bindings: arm: marvell: Add Sophos XGS 107w NPU

[Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it]

Hi Krzysztof,

Thanks for the review.

> Looks like you add to the end of the file, not in correct spot.

In v2 the entry is next to the other CN9130 board entries, before the SolidRun ones, instead of at the end of the list.

> Why is cn9130 used once as final compatible and once as not?

I understood this as the difference between my entry (marvell,cn9130 followed by the AP807 compatibles) and the SolidRun CN9130 boards above it (marvell,cn9130 last). In v2 the entry and the device tree both use "sophos,xgs107w-npu", "marvell,cn9130", like the SolidRun boards, so cn9130 is always the last compatible. If you meant something else, please tell me before I send v2.

I will send v2 as a new thread after the 24 hours have passed, with your Acked-by on patch 1.

Thanks,
Nicolo Giuliani

________________________________________
Da: Krzysztof Kozlowski <krzk@kernel.org>
Inviato: domenica 20 settembre 2026 20:27
A: Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it
Cc: Rob Herring; Krzysztof Kozlowski; Conor Dooley; Andrew Lunn; Gregory Clement; Sebastian Hesselbarth; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Oggetto: Re: [PATCH 2/3] dt-bindings: arm: marvell: Add Sophos XGS 107w NPU

On Sat, Sep 19, 2026 at 09:44:18PM +0200, Nicolo Giuliani wrote:
> The Sophos XGS 87/107 desktop firewalls combine an AMD x86 host with a
> separate network processing unit (NPU). The NPU is a Marvell Armada CN9130
> SoC with its own eMMC and SPI NOR flash, connected to the x86 host over
> PCIe. It serves the front panel ports through a Marvell 88E6193X switch.
>
> Document the compatible string of the NPU board, with the CN9130 SoC
> compatibles as fallbacks.
>
> Assisted-by: LLM
> Signed-off-by: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>
> ---
>  Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> index 7e77310da6..2e114139f1 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> @@ -136,4 +136,13 @@ properties:
>            - const: solidrun,cn9132-sr-cex7
>            - const: marvell,cn9130
>

Looks like you add to the end of the file, not in correct spot.

> +      - description:
> +          Sophos XGS 87/107 network processing unit (Armada CN9130 SoC
> +          with an 88E6193X switch)
> +        items:
> +          - const: sophos,xgs107w-npu
> +          - const: marvell,cn9130

Why is cn9130 used once as final compatible and once as not?

> +          - const: marvell,armada-ap807-quad
> +          - const: marvell,armada-ap807

Best regards,
Krzysztof

[PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

[Nicolo Giuliani via B4 Relay]

From: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>

Add a device tree for the network processing unit (NPU) of the Sophos
XGS 87/107 desktop firewalls. The appliance pairs an AMD x86 host with the
NPU, a Marvell Armada CN9130 SoC with its own eMMC and SPI NOR flash that
runs independently of the host and serves the front panel ports.

The eight RJ45 ports and the SFP cage are connected through a Marvell
88E6193X switch on the MDIO bus of the SoC, at address 2. Switch port 0
is the CPU port, a 10GBASE-R link to the first mvpp2 port. Ports 1 to 8
are the RJ45 ports, which use the internal PHYs of the switch, and
port 9 is the SFP cage, connected over 1000BASE-X.

Describe the UART console, the eMMC, the SPI NOR flash that holds the boot
loader and its environment (read-only), the PCA9555 GPIO expander that
drives the port LEDs, the SFP cage and the switch with its ports. The LEDs
themselves, the PCIe link to the x86 host and the USB ports are not
described.

The reset line of the switch (CP GPIO2 pin 17) is deliberately not given
to the mv88e6xxx driver as reset-gpios. The 88E6193X needs about two
seconds after a reset before it can be used, much longer than the driver
waits, so the probe would time out. The boot loader resets the switch
before it starts the kernel.

Tested on an XGS 107w with Linux 6.18: boot from eMMC, eMMC and SPI NOR
access, the mvpp2 link to the switch at 10 Gb/s, the 88E6193X probing with
its eight user ports, and 936 Mbit/s through a front port. The SFP cage
and the PCA9555 outputs are untested.

Assisted-by: LLM
Signed-off-by: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>
---
 arch/arm64/boot/dts/marvell/Makefile               |   1 +
 .../boot/dts/marvell/cn9130-sophos-xgs107w.dts     | 209 +++++++++++++++++++++
 2 files changed, 210 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 09d1544041..81f892715b 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -34,5 +34,6 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += cn9131-cf-solidwan.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += cn9132-clearfog.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += cn9130-sophos-xgs107w.dtb
 
 subdir-y	+= mmp
diff --git a/arch/arm64/boot/dts/marvell/cn9130-sophos-xgs107w.dts b/arch/arm64/boot/dts/marvell/cn9130-sophos-xgs107w.dts
new file mode 100644
index 0000000000..d98d8da10e
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/cn9130-sophos-xgs107w.dts
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree for the network processing unit (NPU) of the Sophos XGS 87/107
+ * firewalls: a Marvell CN9130 SoC with a Marvell 88E6193X switch.
+ *
+ * The x86 host on the same board is not described here.
+ */
+
+/dts-v1/;
+
+#include "cn9130.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	model = "Sophos XGS 107w (CN9130 NPU)";
+	compatible = "sophos,xgs107w-npu", "marvell,cn9130",
+		     "marvell,armada-ap807-quad", "marvell,armada-ap807";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	aliases {
+		ethernet0 = &cp0_eth0;
+		i2c0 = &cp0_i2c0;
+		i2c1 = &cp0_i2c1;
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x80000000>;
+	};
+
+	reserved-memory {
+		/* OP-TEE, reserved by the firmware */
+		tee@4400000 {
+			reg = <0x0 0x4400000 0x0 0x1000000>;
+			no-map;
+		};
+	};
+
+	/* Front-panel SFP cage "F1", wired to switch port 9 */
+	sfp: sfp {
+		compatible = "sff,sfp";
+		i2c-bus = <&cp0_i2c1>;
+		los-gpios = <&cp0_gpio1 1 GPIO_ACTIVE_HIGH>;
+		tx-fault-gpios = <&cp0_gpio1 2 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios = <&cp0_gpio1 3 GPIO_ACTIVE_LOW>;
+		tx-disable-gpios = <&cp0_gpio1 7 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+/* eMMC on the AP */
+&ap_sdhci0 {
+	bus-width = <8>;
+	non-removable;
+	mmc-ddr-1_8v;
+	status = "okay";
+};
+
+/*
+ * The MPP pin muxing is left as configured by the boot loader; the pin
+ * controller node only exists to back the GPIO banks.
+ */
+&cp0_syscon0 {
+	cp0_pinctrl: pinctrl {
+		compatible = "marvell,cp115-standalone-pinctrl";
+	};
+};
+
+&cp0_i2c0 {
+	clock-frequency = <100000>;
+	status = "okay";
+
+	/* Drives the port speed LEDs, which are not described yet */
+	gpio@20 {
+		compatible = "nxp,pca9555";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+};
+
+&cp0_i2c1 {
+	/* SFP EEPROM (0x50/0x51) */
+	clock-frequency = <100000>;
+	status = "okay";
+};
+
+/* 4 MB SPI NOR with U-Boot and its environment, read-only on purpose */
+&cp0_spi0 {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "u-boot";
+				reg = <0x0 0x3f0000>;
+				read-only;
+			};
+
+			partition@3f0000 {
+				label = "u-boot-env";
+				reg = <0x3f0000 0x10000>;
+				read-only;
+			};
+		};
+	};
+};
+
+&cp0_ethernet {
+	status = "okay";
+};
+
+/* 10G link to switch port 0 */
+&cp0_eth0 {
+	phy-mode = "10gbase-r";
+	phys = <&cp0_comphy4 0>;
+	managed = "in-band-status";
+	status = "okay";
+};
+
+&cp0_mdio {
+	status = "okay";
+
+	switch@2 {
+		compatible = "marvell,mv88e6190";
+		reg = <2>;
+		/*
+		 * The reset line of the switch is CP GPIO2 pin 17. It is not
+		 * described as reset-gpios: the 88E6193X needs about two
+		 * seconds after a reset before it can be used, much longer
+		 * than the driver waits, and the probe would time out. The
+		 * boot loader resets the switch before starting the kernel.
+		 */
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				ethernet = <&cp0_eth0>;
+				phy-mode = "10gbase-r";
+				managed = "in-band-status";
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "p1";
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "p2";
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "p3";
+			};
+
+			port@4 {
+				reg = <4>;
+				label = "p4";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "p5";
+			};
+
+			port@6 {
+				reg = <6>;
+				label = "p6";
+			};
+
+			port@7 {
+				reg = <7>;
+				label = "p7";
+			};
+
+			port@8 {
+				reg = <8>;
+				label = "p8";
+			};
+
+			port@9 {
+				reg = <9>;
+				label = "sfp";
+				phy-mode = "1000base-x";
+				managed = "in-band-status";
+				sfp = <&sfp>;
+			};
+		};
+	};
+};

-- 
2.48.1

Re: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt: intentional omission of physical reset-gpios to workaround driver bug
--

commit 3bbda9294c3060f49dfc25ff724a945a54bd4560
Author: Nicolo Giuliani <nicolo.giuliani6@studio.unibo.it>

arm64: dts: marvell: Add Sophos XGS 107w NPU board

This commit adds a device tree for the network processing unit (NPU) of the
Sophos XGS 87/107 desktop firewalls. It describes the Marvell Armada CN9130
SoC, along with the UART, eMMC, SPI NOR flash, SFP cage, and a Marvell
88E6193X switch.

> diff --git a/arch/arm64/boot/dts/marvell/cn9130-sophos-xgs107w.dts b/arch/arm64/boot/dts/marvell/cn9130-sophos-xgs107w.dts
> new file mode 100644
> index 0000000000000..d98d8da10e637
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/cn9130-sophos-xgs107w.dts

[ ... ]

> +&cp0_mdio {
> +	status = "okay";
> +
> +	switch@2 {
> +		compatible = "marvell,mv88e6190";
> +		reg = <2>;
> +		/*
> +		 * The reset line of the switch is CP GPIO2 pin 17. It is not
> +		 * described as reset-gpios: the 88E6193X needs about two
> +		 * seconds after a reset before it can be used, much longer
> +		 * than the driver waits, and the probe would time out. The
> +		 * boot loader resets the switch before starting the kernel.
> +		 */

[Severity: Medium]
Is it appropriate to deliberately omit the physically present reset-gpios
property to work around a Linux driver timeout limitation?

Device Tree is intended to be an OS-independent description of the hardware
topology. By intentionally omitting this connection in switch@2, the kernel
is unable to reset the switch natively (for instance, during a driver reload
or system reboot).

Would it be better to accurately describe the hardware by including the
reset-gpios property here, and instead fix the timeout in the mv88e6xxx
driver or use standard delay properties like reset-deassert-us to handle
the two-second requirement?

> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260919-send-dt-v1-0-365615a74ef3@studio.unibo.it?part=3

Re: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

[Andrew Lunn]

> The reset line of the switch (CP GPIO2 pin 17) is deliberately not given
> to the mv88e6xxx driver as reset-gpios. The 88E6193X needs about two
> seconds after a reset before it can be used, much longer than the driver
> waits, so the probe would time out.

The obvious question is, why is your 88E6193X special?

I've seen issues when there is an EEPROM attached and it has a lot of
content to setup the switch. But that goes against using DSA, where
you want Linux to control the switch, not a fixed configuration.

> +&cp0_i2c0 {
> +	clock-frequency = <100000>;
> +	status = "okay";
> +
> +	/* Drives the port speed LEDs, which are not described yet */
> +	gpio@20 {

Which port?

> +&cp0_i2c1 {
> +	/* SFP EEPROM (0x50/0x51) */

The addresses are not that simple. When a copper module is inserted,
other addresses are used. The SFP driver assumes it has access to all
addresses on the bus.


  Andrew

R: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

[Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it]

Hi Andrew,

Thanks for the review.

> The reset line of the switch (CP GPIO2 pin 17) is deliberately not given
> to the mv88e6xxx driver as reset-gpios. The 88E6193X needs about two
> seconds after a reset before it can be used, much longer than the driver
> waits, so the probe would time out.
>
> The obvious question is, why is your 88E6193X special?

I don't think it is. I saw the probe time out when I started the kernel with kexec from the vendor Linux, so nothing had reset the switch before the driver did. When the boot loader resets the switch first, which is how the board normally boots, probing with reset-gpios works on this board (Linux 6.18). I have not been able to test a driver-only reset yet, because the boot loader always resets the switch first, so I cannot say what made the difference. I have not checked whether an EEPROM is attached. v2 describes reset-gpios and drops the comment.

> +&cp0_i2c0 {
> [...]
> +     gpio@20 {
>
> Which port?

It is the LED expander of the eight RJ45 ports (two pins per port). Nothing uses it yet, so I dropped the node from v2. It can come back together with the LED nodes.

> +&cp0_i2c1 {
> +     /* SFP EEPROM (0x50/0x51) */
>
> The addresses are not that simple. When a copper module is inserted,
> other addresses are used. The SFP driver assumes it has access to all
> addresses on the bus.

Thanks, I had not considered copper modules. I removed the comment; the node now only enables the I2C bus of the SFP cage.

I will send v2 as a new thread after more feedback.

Thanks,
Nicolo Giuliani

________________________________________
Da: Andrew Lunn <andrew@lunn.ch>
Inviato: domenica 20 settembre 2026 00:23
A: Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it
Cc: Rob Herring; Krzysztof Kozlowski; Conor Dooley; Gregory Clement; Sebastian Hesselbarth; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Oggetto: Re: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

> The reset line of the switch (CP GPIO2 pin 17) is deliberately not given
> to the mv88e6xxx driver as reset-gpios. The 88E6193X needs about two
> seconds after a reset before it can be used, much longer than the driver
> waits, so the probe would time out.

The obvious question is, why is your 88E6193X special?

I've seen issues when there is an EEPROM attached and it has a lot of
content to setup the switch. But that goes against using DSA, where
you want Linux to control the switch, not a fixed configuration.

> +&cp0_i2c0 {
> +     clock-frequency = <100000>;
> +     status = "okay";
> +
> +     /* Drives the port speed LEDs, which are not described yet */
> +     gpio@20 {

Which port?

> +&cp0_i2c1 {
> +     /* SFP EEPROM (0x50/0x51) */

The addresses are not that simple. When a copper module is inserted,
other addresses are used. The SFP driver assumes it has access to all
addresses on the bus.


  Andrew

Re: R: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

[Andrew Lunn]

On Sun, Sep 20, 2026 at 08:48:20AM +0000, Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it wrote:
> Hi Andrew,
> 
> Thanks for the review.
> 
> > The reset line of the switch (CP GPIO2 pin 17) is deliberately not given
> > to the mv88e6xxx driver as reset-gpios. The 88E6193X needs about two
> > seconds after a reset before it can be used, much longer than the driver
> > waits, so the probe would time out.
> >
> > The obvious question is, why is your 88E6193X special?
> 
> I don't think it is.

So please fix the driver to accept that the 88E6193X is much slower
than any other Marvell device.


I saw the probe time out when I started the kernel with kexec from the vendor Linux, so nothing had reset the switch before the driver did. When the boot loader resets the switch first, which is how the board normally boots, probing with reset-gpios works on this board (Linux 6.18). I have not been able to test a driver-only reset yet, because the boot loader always resets the switch first, so I cannot say what made the difference. I have not checked whether an EEPROM is attached. v2 describes reset-gpios and drops the comment.
> 
> > +&cp0_i2c0 {
> > [...]
> > +     gpio@20 {
> >
> > Which port?
> 
> It is the LED expander of the eight RJ45 ports (two pins per port). Nothing uses it yet, so I dropped the node from v2. It can come back together with the LED nodes.

Doesn't the 88E6193X have LED controllers of its own? Why do you need
additional LEDs?

	Andrew

R: R: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

[Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it]

Hi Andrew,

On the reset:

> So please fix the driver to accept that the 88E6193X is much slower
> than any other Marvell device.

I don't want to guess here. Before I send v2 I will measure how long the switch needs after a reset done only by the driver (re-probing the driver on a running board, so that no boot loader reset comes first) and report the number in this thread. If it is longer than what the driver waits, I will send a driver patch and keep reset-gpios in the device tree. If it is not, reset-gpios goes into the device tree with no driver change. Either way the comment about the boot loader reset goes away.

On the LEDs:

> Doesn't the 88E6193X have LED controllers of its own? Why do you need
> additional LEDs?

It does, and the vendor firmware also programs the switch's LED control. The GPIO expander is a separate set of per-port lines that the vendor firmware uses for the speed indication. I have not verified which physical LED each of them lights, so v2 has neither LED nor expander nodes. I will come back with LED nodes only once I know what is wired to what, and I will use the switch's own LED controller wherever it can do the job.

Thanks,
Nicolo Giuliani

________________________________________
Da: Andrew Lunn <andrew@lunn.ch>
Inviato: domenica 20 settembre 2026 17:14
A: Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it
Cc: Rob Herring; Krzysztof Kozlowski; Conor Dooley; Gregory Clement; Sebastian Hesselbarth; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Oggetto: Re: R: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

On Sun, Sep 20, 2026 at 08:48:20AM +0000, Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it wrote:
> Hi Andrew,
>
> Thanks for the review.
>
> > The reset line of the switch (CP GPIO2 pin 17) is deliberately not given
> > to the mv88e6xxx driver as reset-gpios. The 88E6193X needs about two
> > seconds after a reset before it can be used, much longer than the driver
> > waits, so the probe would time out.
> >
> > The obvious question is, why is your 88E6193X special?
>
> I don't think it is.

So please fix the driver to accept that the 88E6193X is much slower
than any other Marvell device.


I saw the probe time out when I started the kernel with kexec from the vendor Linux, so nothing had reset the switch before the driver did. When the boot loader resets the switch first, which is how the board normally boots, probing with reset-gpios works on this board (Linux 6.18). I have not been able to test a driver-only reset yet, because the boot loader always resets the switch first, so I cannot say what made the difference. I have not checked whether an EEPROM is attached. v2 describes reset-gpios and drops the comment.
>
> > +&cp0_i2c0 {
> > [...]
> > +     gpio@20 {
> >
> > Which port?
>
> It is the LED expander of the eight RJ45 ports (two pins per port). Nothing uses it yet, so I dropped the node from v2. It can come back together with the LED nodes.

Doesn't the 88E6193X have LED controllers of its own? Why do you need
additional LEDs?

        Andrew

R: R: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

[Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it]

Hi Andrew,

As promised, the measurement of a driver-only reset.

On a running board (Linux 6.18) I unbound and re-bound the mv88e6xxx driver with reset-gpios (CP GPIO2 pin 17) in the device tree, so the only reset before the probe was the one done by the driver, with no boot loader reset in front of it. The switch was detected again and probed with all its ports in about one second, well within what the driver waits. So the 88E6193X is not slower than the other devices, and I will not send a driver patch. What I wrote in v1 (two seconds) was wrong.

I still do not know why the probe timed out when I booted through kexec from the vendor Linux, where nothing had reset the switch before the driver. I could not reproduce that failure with a reset done by the driver. v2 has reset-gpios and no comment about a boot loader reset.

The other points of your review are addressed in v2: no LED expander node, no comment about the SFP EEPROM addresses. I will send v2 as a new thread after the 24 hours have passed.

Thanks,
Nicolo Giuliani

________________________________________
Da: Andrew Lunn <andrew@lunn.ch>
Inviato: domenica 20 settembre 2026 17:14
A: Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it
Cc: Rob Herring; Krzysztof Kozlowski; Conor Dooley; Gregory Clement; Sebastian Hesselbarth; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Oggetto: Re: R: [PATCH 3/3] arm64: dts: marvell: Add Sophos XGS 107w NPU board

On Sun, Sep 20, 2026 at 08:48:20AM +0000, Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it wrote:
> Hi Andrew,
>
> Thanks for the review.
>
> > The reset line of the switch (CP GPIO2 pin 17) is deliberately not given
> > to the mv88e6xxx driver as reset-gpios. The 88E6193X needs about two
> > seconds after a reset before it can be used, much longer than the driver
> > waits, so the probe would time out.
> >
> > The obvious question is, why is your 88E6193X special?
>
> I don't think it is.

So please fix the driver to accept that the 88E6193X is much slower
than any other Marvell device.


I saw the probe time out when I started the kernel with kexec from the vendor Linux, so nothing had reset the switch before the driver did. When the boot loader resets the switch first, which is how the board normally boots, probing with reset-gpios works on this board (Linux 6.18). I have not been able to test a driver-only reset yet, because the boot loader always resets the switch first, so I cannot say what made the difference. I have not checked whether an EEPROM is attached. v2 describes reset-gpios and drops the comment.
>
> > +&cp0_i2c0 {
> > [...]
> > +     gpio@20 {
> >
> > Which port?
>
> It is the LED expander of the eight RJ45 ports (two pins per port). Nothing uses it yet, so I dropped the node from v2. It can come back together with the LED nodes.

Doesn't the 88E6193X have LED controllers of its own? Why do you need
additional LEDs?

        Andrew