[PATCH 00/15] arm64: dts: mediatek: Add Openwrt One AP functionality

[PATCH 00/15] arm64: dts: mediatek: Add Openwrt One AP functionality

[Sjoerd Simons]

This series add various peripherals to the Openwrt One, to make it
actually useful an access point:

* Pcie express (tested with nvme storage)
* Wired network interfaces
* Wireless network interfaces (2.4g, 5ghz wifi)
* Status leds
* SPI NOR for factory data

Unsurprisingly the series is a mix of dt binding updates, extensions of
the mt7981b and the openwrt one dtb. All driver support required is
already available.

Sadly during testing i've found various quirks requiring kernel
arguments. Documenting those here both as note to self and making it
easier for others to test :)

* fw_devlink=permissive: the nvmem fixed-layout doesn't create a layout
  device, so doesn't trigger fw_devlink
* clk_ignore_unused: Needed when building CONFIG_NET_MEDIATEK_SOC as a
  module. If the ethernet related clocks (gp1/gp2) get disabled the
  mac ends up in a weird state causing it not to function correctly.
* pcie_aspm: ASPM is forced to enabled in 6.18-rc1, unfortunately
  enabling ASPM L1.1 ends up triggering unrecoverable AERs.

Patches are against the mediatek trees for-next branch

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
Sjoerd Simons (15):
      arm64: dts: mediatek: mt7981b: Add labels to commonly referenced nodes
      arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux
      arm64: dts: mediatek: mt7981b: Add reserved memory for TF-A
      dt-bindings: mfd: syscon: Add mt7981-topmisc
      dt-bindings: pci: mediatek-pcie-gen3: Add MT7981 PCIe compatible
      dt-bindings: phy: mediatek,tphy: Add support for MT7981
      arm64: dts: mediatek: mt7981b: Add PCIe and USB support
      arm64: dts: mediatek: mt7981b-openwrt-one: Enable PCIe and USB
      dt-bindings: net: mediatek,net: Correct bindings for MT7981
      arm64: dts: mediatek: mt7981b: Add Ethernet and WiFi offload support
      arm64: dts: mediatek: mt7981b-openwrt-one: Enable SPI NOR
      arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet
      arm64: dts: mediatek: mt7981b: Add wifi memory region
      arm64: dts: mediatek: mt7981b-openwrt-one: Enable wifi
      arm64: dts: mediatek: mt7981b-openwrt-one: Enable leds

 Documentation/devicetree/bindings/mfd/syscon.yaml  |   1 +
 .../devicetree/bindings/net/mediatek,net.yaml      |  16 +-
 .../bindings/pci/mediatek-pcie-gen3.yaml           |   1 +
 .../devicetree/bindings/phy/mediatek,tphy.yaml     |   1 +
 .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 276 +++++++++++++++++++++
 arch/arm64/boot/dts/mediatek/mt7981b.dtsi          | 258 ++++++++++++++++++-
 6 files changed, 538 insertions(+), 15 deletions(-)
---
base-commit: de8df7a4c881bd0df691458680ab1e22d63d60f4
change-id: 20251016-openwrt-one-network-40bc9ac1b25c

Best regards,
-- 
Sjoerd Simons <sjoerd@collabora.com>

[PATCH 01/15] arm64: dts: mediatek: mt7981b: Add labels to commonly referenced nodes

[Sjoerd Simons]

Add labels to various device nodes in the MT7981B DTSI, similar to other
mediatek dtsi files.

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
index 58c99f2a25218..6b024156fa7c5 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
@@ -14,14 +14,14 @@ cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		cpu@0 {
+		cpu0: cpu@0 {
 			compatible = "arm,cortex-a53";
 			reg = <0x0>;
 			device_type = "cpu";
 			enable-method = "psci";
 		};
 
-		cpu@1 {
+		cpu1: cpu@1 {
 			compatible = "arm,cortex-a53";
 			reg = <0x1>;
 			device_type = "cpu";
@@ -29,7 +29,7 @@ cpu@1 {
 		};
 	};
 
-	oscillator-40m {
+	clk40m: oscillator-40m {
 		compatible = "fixed-clock";
 		clock-frequency = <40000000>;
 		clock-output-names = "clkxtal";
@@ -82,7 +82,7 @@ apmixedsys: clock-controller@1001e000 {
 			#clock-cells = <1>;
 		};
 
-		pwm@10048000 {
+		pwm: pwm@10048000 {
 			compatible = "mediatek,mt7981-pwm";
 			reg = <0 0x10048000 0 0x1000>;
 			clocks = <&infracfg CLK_INFRA_PWM_STA>,
@@ -127,7 +127,7 @@ uart2: serial@11004000 {
 			status = "disabled";
 		};
 
-		i2c@11007000 {
+		i2c0: i2c@11007000 {
 			compatible = "mediatek,mt7981-i2c";
 			reg = <0 0x11007000 0 0x1000>,
 			      <0 0x10217080 0 0x80>;
@@ -142,7 +142,7 @@ i2c@11007000 {
 			status = "disabled";
 		};
 
-		spi@11009000 {
+		spi2: spi@11009000 {
 			compatible = "mediatek,mt7981-spi-ipm", "mediatek,spi-ipm";
 			reg = <0 0x11009000 0 0x1000>;
 			interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
@@ -156,7 +156,7 @@ spi@11009000 {
 			status = "disabled";
 		};
 
-		spi@1100a000 {
+		spi0: spi@1100a000 {
 			compatible = "mediatek,mt7981-spi-ipm", "mediatek,spi-ipm";
 			reg = <0 0x1100a000 0 0x1000>;
 			interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
@@ -170,7 +170,7 @@ spi@1100a000 {
 			status = "disabled";
 		};
 
-		spi@1100b000 {
+		spi1: spi@1100b000 {
 			compatible = "mediatek,mt7981-spi-ipm", "mediatek,spi-ipm";
 			reg = <0 0x1100b000 0 0x1000>;
 			interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
@@ -184,7 +184,7 @@ spi@1100b000 {
 			status = "disabled";
 		};
 
-		thermal@1100c800 {
+		thermal: thermal@1100c800 {
 			compatible = "mediatek,mt7981-thermal",
 				     "mediatek,mt7986-thermal";
 			reg = <0 0x1100c800 0 0x800>;
@@ -231,7 +231,7 @@ pio: pinctrl@11d00000 {
 			#interrupt-cells = <2>;
 		};
 
-		efuse@11f20000 {
+		efuse: efuse@11f20000 {
 			compatible = "mediatek,mt7981-efuse", "mediatek,efuse";
 			reg = <0 0x11f20000 0 0x1000>;
 			#address-cells = <1>;
@@ -246,14 +246,14 @@ thermal_calibration: thermal-calib@274 {
 			};
 		};
 
-		clock-controller@15000000 {
+		ethsys: clock-controller@15000000 {
 			compatible = "mediatek,mt7981-ethsys", "syscon";
 			reg = <0 0x15000000 0 0x1000>;
 			#clock-cells = <1>;
 			#reset-cells = <1>;
 		};
 
-		wifi@18000000 {
+		wifi: wifi@18000000 {
 			compatible = "mediatek,mt7981-wmac";
 			reg = <0 0x18000000 0 0x1000000>,
 			      <0 0x10003000 0 0x1000>,

-- 
2.51.0

Re: [PATCH 01/15] arm64: dts: mediatek: mt7981b: Add labels to commonly referenced nodes

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Add labels to various device nodes in the MT7981B DTSI, similar to other
> mediatek dtsi files.
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

If you're not using the labels, it makes no sense to have them.

Please add them in the same commit(s) in which you actually assign phandles to the
nodes that need labels.

Cheers,
Angelo

> ---
>   arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 24 ++++++++++++------------
>   1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> index 58c99f2a25218..6b024156fa7c5 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> @@ -14,14 +14,14 @@ cpus {
>   		#address-cells = <1>;
>   		#size-cells = <0>;
>   
> -		cpu@0 {
> +		cpu0: cpu@0 {
>   			compatible = "arm,cortex-a53";
>   			reg = <0x0>;
>   			device_type = "cpu";
>   			enable-method = "psci";
>   		};
>   
> -		cpu@1 {
> +		cpu1: cpu@1 {
>   			compatible = "arm,cortex-a53";
>   			reg = <0x1>;
>   			device_type = "cpu";
> @@ -29,7 +29,7 @@ cpu@1 {
>   		};
>   	};
>   
> -	oscillator-40m {
> +	clk40m: oscillator-40m {
>   		compatible = "fixed-clock";
>   		clock-frequency = <40000000>;
>   		clock-output-names = "clkxtal";
> @@ -82,7 +82,7 @@ apmixedsys: clock-controller@1001e000 {
>   			#clock-cells = <1>;
>   		};
>   
> -		pwm@10048000 {
> +		pwm: pwm@10048000 {
>   			compatible = "mediatek,mt7981-pwm";
>   			reg = <0 0x10048000 0 0x1000>;
>   			clocks = <&infracfg CLK_INFRA_PWM_STA>,
> @@ -127,7 +127,7 @@ uart2: serial@11004000 {
>   			status = "disabled";
>   		};
>   
> -		i2c@11007000 {
> +		i2c0: i2c@11007000 {
>   			compatible = "mediatek,mt7981-i2c";
>   			reg = <0 0x11007000 0 0x1000>,
>   			      <0 0x10217080 0 0x80>;
> @@ -142,7 +142,7 @@ i2c@11007000 {
>   			status = "disabled";
>   		};
>   
> -		spi@11009000 {
> +		spi2: spi@11009000 {
>   			compatible = "mediatek,mt7981-spi-ipm", "mediatek,spi-ipm";
>   			reg = <0 0x11009000 0 0x1000>;
>   			interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
> @@ -156,7 +156,7 @@ spi@11009000 {
>   			status = "disabled";
>   		};
>   
> -		spi@1100a000 {
> +		spi0: spi@1100a000 {
>   			compatible = "mediatek,mt7981-spi-ipm", "mediatek,spi-ipm";
>   			reg = <0 0x1100a000 0 0x1000>;
>   			interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
> @@ -170,7 +170,7 @@ spi@1100a000 {
>   			status = "disabled";
>   		};
>   
> -		spi@1100b000 {
> +		spi1: spi@1100b000 {
>   			compatible = "mediatek,mt7981-spi-ipm", "mediatek,spi-ipm";
>   			reg = <0 0x1100b000 0 0x1000>;
>   			interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
> @@ -184,7 +184,7 @@ spi@1100b000 {
>   			status = "disabled";
>   		};
>   
> -		thermal@1100c800 {
> +		thermal: thermal@1100c800 {
>   			compatible = "mediatek,mt7981-thermal",
>   				     "mediatek,mt7986-thermal";
>   			reg = <0 0x1100c800 0 0x800>;
> @@ -231,7 +231,7 @@ pio: pinctrl@11d00000 {
>   			#interrupt-cells = <2>;
>   		};
>   
> -		efuse@11f20000 {
> +		efuse: efuse@11f20000 {
>   			compatible = "mediatek,mt7981-efuse", "mediatek,efuse";
>   			reg = <0 0x11f20000 0 0x1000>;
>   			#address-cells = <1>;
> @@ -246,14 +246,14 @@ thermal_calibration: thermal-calib@274 {
>   			};
>   		};
>   
> -		clock-controller@15000000 {
> +		ethsys: clock-controller@15000000 {
>   			compatible = "mediatek,mt7981-ethsys", "syscon";
>   			reg = <0 0x15000000 0 0x1000>;
>   			#clock-cells = <1>;
>   			#reset-cells = <1>;
>   		};
>   
> -		wifi@18000000 {
> +		wifi: wifi@18000000 {
>   			compatible = "mediatek,mt7981-wmac";
>   			reg = <0 0x18000000 0 0x1000000>,
>   			      <0 0x10003000 0 0x1000>,
> 

[PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[Sjoerd Simons]

Add explicit pinctrl configuration for UART0 on the OpenWrt One board,

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
index 968b91f55bb27..f836059d7f475 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
@@ -22,6 +22,17 @@ memory@40000000 {
 	};
 };
 
+&pio {
+	uart0_pins: uart0-pins {
+		mux {
+			function = "uart";
+			groups = "uart0";
+		};
+	};
+};
+
 &uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins>;
 	status = "okay";
 };

-- 
2.51.0

Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[Daniel Golle]

On Thu, Oct 16, 2025 at 12:08:38PM +0200, Sjoerd Simons wrote:
> Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> index 968b91f55bb27..f836059d7f475 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> @@ -22,6 +22,17 @@ memory@40000000 {
>  	};
>  };
>  
> +&pio {
> +	uart0_pins: uart0-pins {
> +		mux {
> +			function = "uart";
> +			groups = "uart0";
> +		};
> +	};
> +};
> +
>  &uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pins>;
>  	status = "okay";
>  };

As there is only a single possible pinctrl configuration for uart0,
both the pinmux definition as well as the pinctrl properties should go
into mt7981b.dtsi rather than in the board's dts.

Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[AngeloGioacchino Del Regno]

Il 16/10/25 14:38, Daniel Golle ha scritto:
> On Thu, Oct 16, 2025 at 12:08:38PM +0200, Sjoerd Simons wrote:
>> Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
>>
>> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
>> ---
>>   arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>> index 968b91f55bb27..f836059d7f475 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>> @@ -22,6 +22,17 @@ memory@40000000 {
>>   	};
>>   };
>>   
>> +&pio {
>> +	uart0_pins: uart0-pins {
>> +		mux {
>> +			function = "uart";
>> +			groups = "uart0";
>> +		};
>> +	};
>> +};
>> +
>>   &uart0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0_pins>;
>>   	status = "okay";
>>   };
> 
> As there is only a single possible pinctrl configuration for uart0,
> both the pinmux definition as well as the pinctrl properties should go
> into mt7981b.dtsi rather than in the board's dts.

If there's really one single possible pin configuration for the UART0 pins,
as in, those pins *do not* have a GPIO mode, then yes I agree.

If those pins can be as well configured as GPIOs, this goes to board DTS.

Cheers,
Angelo

Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[Daniel Golle]

On Thu, Oct 16, 2025 at 04:29:14PM +0200, AngeloGioacchino Del Regno wrote:
> Il 16/10/25 14:38, Daniel Golle ha scritto:
> > On Thu, Oct 16, 2025 at 12:08:38PM +0200, Sjoerd Simons wrote:
> > > Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
> > > 
> > > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> > > ---
> > >   arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
> > >   1 file changed, 11 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > index 968b91f55bb27..f836059d7f475 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > @@ -22,6 +22,17 @@ memory@40000000 {
> > >   	};
> > >   };
> > > +&pio {
> > > +	uart0_pins: uart0-pins {
> > > +		mux {
> > > +			function = "uart";
> > > +			groups = "uart0";
> > > +		};
> > > +	};
> > > +};
> > > +
> > >   &uart0 {
> > > +	pinctrl-names = "default";
> > > +	pinctrl-0 = <&uart0_pins>;
> > >   	status = "okay";
> > >   };
> > 
> > As there is only a single possible pinctrl configuration for uart0,
> > both the pinmux definition as well as the pinctrl properties should go
> > into mt7981b.dtsi rather than in the board's dts.
> 
> If there's really one single possible pin configuration for the UART0 pins,
> as in, those pins *do not* have a GPIO mode, then yes I agree.
> 
> If those pins can be as well configured as GPIOs, this goes to board DTS.

I respectfully disagree and will explain below.

All pinmux pins on the MediaTek platform also allow being configured as
GPIOs. However, if you configure those as GPIOs the consequence is that
you cannot use UART0 any more at all. So using UART0 at all always
implies using exactly those pins, there is no alternative to that.

Hence every board with every possible uses of pins 32 and 33 (there is
only RX and TX for UART0, RTS/CTS flow-control is not possible) can be
represented without needing to configure the pinctrl for uart0 on the
board level. There isn't going to be any variation on the board-level
when it comes to uart0. Either it is enabled (status = "okay";), and
that will always imply using the 'uart0' group in mode 'uart', or, in
case any of the two pins of uart0 is used for something else that means
uart0 cannot be enabled. Simple as that.

Hence there is no need to duplicate that pinctrl settings on each and
every board, as controlling the 'status' property on the board-level
already gives 100% freedom.

(Sidenote: As even the BootROM already uses those two pins as UART for
debug output, it is very unlikely that anyone would actually use them
for anything else in production. Apart from being used as GPIOs you can
also use pins 32 and 33 as an I2C target for external debug access to the
registers of either the sgmii0_phy, sgmii1_phy or u3_phy. However, that
doesn't matter in terms of the debate above, as the crucial point there
is that using uart0 always implies using group 'uart0' in 'uart' mode.)

Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[AngeloGioacchino Del Regno]

Il 16/10/25 18:37, Daniel Golle ha scritto:
> On Thu, Oct 16, 2025 at 04:29:14PM +0200, AngeloGioacchino Del Regno wrote:
>> Il 16/10/25 14:38, Daniel Golle ha scritto:
>>> On Thu, Oct 16, 2025 at 12:08:38PM +0200, Sjoerd Simons wrote:
>>>> Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
>>>>
>>>> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
>>>> ---
>>>>    arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
>>>>    1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>>>> index 968b91f55bb27..f836059d7f475 100644
>>>> --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>>>> +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>>>> @@ -22,6 +22,17 @@ memory@40000000 {
>>>>    	};
>>>>    };
>>>> +&pio {
>>>> +	uart0_pins: uart0-pins {
>>>> +		mux {
>>>> +			function = "uart";
>>>> +			groups = "uart0";
>>>> +		};
>>>> +	};
>>>> +};
>>>> +
>>>>    &uart0 {
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&uart0_pins>;
>>>>    	status = "okay";
>>>>    };
>>>
>>> As there is only a single possible pinctrl configuration for uart0,
>>> both the pinmux definition as well as the pinctrl properties should go
>>> into mt7981b.dtsi rather than in the board's dts.
>>
>> If there's really one single possible pin configuration for the UART0 pins,
>> as in, those pins *do not* have a GPIO mode, then yes I agree.
>>
>> If those pins can be as well configured as GPIOs, this goes to board DTS.
> 
> I respectfully disagree and will explain below.
> 

Thanks a lot for taking the time to write all this - explains everything,
and even too much :) :)

Though, there's something funny here! The following snippet of "main" text
does explain stuff that is interesting, but that I (not other people, so
thanks again for saying all this) know already, but.....

> All pinmux pins on the MediaTek platform also allow being configured as
> GPIOs. However, if you configure those as GPIOs the consequence is that
> you cannot use UART0 any more at all. So using UART0 at all always
> implies using exactly those pins, there is no alternative to that.
> 
> Hence every board with every possible uses of pins 32 and 33 (there is
> only RX and TX for UART0, RTS/CTS flow-control is not possible) can be
> represented without needing to configure the pinctrl for uart0 on the
> board level. There isn't going to be any variation on the board-level
> when it comes to uart0. Either it is enabled (status = "okay";), and
> that will always imply using the 'uart0' group in mode 'uart', or, in
> case any of the two pins of uart0 is used for something else that means
> uart0 cannot be enabled. Simple as that.
> 
> Hence there is no need to duplicate that pinctrl settings on each and
> every board, as controlling the 'status' property on the board-level
> already gives 100% freedom.
> 

...all of this is not justifying your point.

> (Sidenote: As even the BootROM already uses those two pins as UART for
> debug output,

Funny thing is, your side note is what *fully* justifies your disagreement
and it's also what triggers me to say that you're right, lol :)

Okay then, I am fine with this commit now and I can renew my

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Cheers!
Angelo

> it is very unlikely that anyone would actually use them
> for anything else in production. Apart from being used as GPIOs you can
> also use pins 32 and 33 as an I2C target for external debug access to the
> registers of either the sgmii0_phy, sgmii1_phy or u3_phy. However, that
> doesn't matter in terms of the debate above, as the crucial point there
> is that using uart0 always implies using group 'uart0' in 'uart' mode.)

Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[Daniel Golle]

On Mon, Oct 20, 2025 at 12:23:14PM +0200, AngeloGioacchino Del Regno wrote:
> Il 16/10/25 18:37, Daniel Golle ha scritto:
> > On Thu, Oct 16, 2025 at 04:29:14PM +0200, AngeloGioacchino Del Regno wrote:
> > > Il 16/10/25 14:38, Daniel Golle ha scritto:
> > > > On Thu, Oct 16, 2025 at 12:08:38PM +0200, Sjoerd Simons wrote:
> > > > > Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
> > > > > 
> > > > > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> > > > > ---
> > > > >    arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
> > > > >    1 file changed, 11 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > > > index 968b91f55bb27..f836059d7f475 100644
> > > > > --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > > > +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > > > @@ -22,6 +22,17 @@ memory@40000000 {
> > > > >    	};
> > > > >    };
> > > > > +&pio {
> > > > > +	uart0_pins: uart0-pins {
> > > > > +		mux {
> > > > > +			function = "uart";
> > > > > +			groups = "uart0";
> > > > > +		};
> > > > > +	};
> > > > > +};
> > > > > +
> > > > >    &uart0 {
> > > > > +	pinctrl-names = "default";
> > > > > +	pinctrl-0 = <&uart0_pins>;
> > > > >    	status = "okay";
> > > > >    };
> > > > 
> > > > As there is only a single possible pinctrl configuration for uart0,
> > > > both the pinmux definition as well as the pinctrl properties should go
> > > > into mt7981b.dtsi rather than in the board's dts.
> > > 
> > > If there's really one single possible pin configuration for the UART0 pins,
> > > as in, those pins *do not* have a GPIO mode, then yes I agree.
> > > 
> > > If those pins can be as well configured as GPIOs, this goes to board DTS.
> > 
> > I respectfully disagree and will explain below.
> > 
> 
> Thanks a lot for taking the time to write all this - explains everything,
> and even too much :) :)
> 
> Though, there's something funny here! The following snippet of "main" text
> does explain stuff that is interesting, but that I (not other people, so
> thanks again for saying all this) know already, but.....
> 
> > All pinmux pins on the MediaTek platform also allow being configured as
> > GPIOs. However, if you configure those as GPIOs the consequence is that
> > you cannot use UART0 any more at all. So using UART0 at all always
> > implies using exactly those pins, there is no alternative to that.
> > 
> > Hence every board with every possible uses of pins 32 and 33 (there is
> > only RX and TX for UART0, RTS/CTS flow-control is not possible) can be
> > represented without needing to configure the pinctrl for uart0 on the
> > board level. There isn't going to be any variation on the board-level
> > when it comes to uart0. Either it is enabled (status = "okay";), and
> > that will always imply using the 'uart0' group in mode 'uart', or, in
> > case any of the two pins of uart0 is used for something else that means
> > uart0 cannot be enabled. Simple as that.
> > 
> > Hence there is no need to duplicate that pinctrl settings on each and
> > every board, as controlling the 'status' property on the board-level
> > already gives 100% freedom.
> > 
> 
> ...all of this is not justifying your point.

So what is the rule then? I understand the logic of describing the
pins eg. for uart1 only on board-level as there are actual alternatives
regarding the pins to be used, and if also including RTS/CTS pins.
Hence, for uart1, there are several possible pingroups which can be
used. What would be the argument to keep a pinctrl description for
which the SoC doesn't offer any alternatives to be on the board-level?
There is nothing to be decided by the board, literally 0 freedom.

> 
> > (Sidenote: As even the BootROM already uses those two pins as UART for
> > debug output,
> 
> Funny thing is, your side note is what *fully* justifies your disagreement
> and it's also what triggers me to say that you're right, lol :)
> 
> Okay then, I am fine with this commit now and I can renew my
> 
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Note that the patch you have just added your Reviewed-by:-tag to does
*not* add the uart0 pinctrl on SoC-level but board-level, so different
from what I argued for above. Did you mean to add Reviewed-by: for that
(which contraticts what you just wrote) or rather to the to-be-submitted
v2 of this series which includes the change to move the uart0 pinctrl
to mt7981b.dtsi?

Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[AngeloGioacchino Del Regno]

Il 20/10/25 14:28, Daniel Golle ha scritto:
> On Mon, Oct 20, 2025 at 12:23:14PM +0200, AngeloGioacchino Del Regno wrote:
>> Il 16/10/25 18:37, Daniel Golle ha scritto:
>>> On Thu, Oct 16, 2025 at 04:29:14PM +0200, AngeloGioacchino Del Regno wrote:
>>>> Il 16/10/25 14:38, Daniel Golle ha scritto:
>>>>> On Thu, Oct 16, 2025 at 12:08:38PM +0200, Sjoerd Simons wrote:
>>>>>> Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
>>>>>>
>>>>>> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
>>>>>> ---
>>>>>>     arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
>>>>>>     1 file changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>>>>>> index 968b91f55bb27..f836059d7f475 100644
>>>>>> --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>>>>>> +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
>>>>>> @@ -22,6 +22,17 @@ memory@40000000 {
>>>>>>     	};
>>>>>>     };
>>>>>> +&pio {
>>>>>> +	uart0_pins: uart0-pins {
>>>>>> +		mux {
>>>>>> +			function = "uart";
>>>>>> +			groups = "uart0";
>>>>>> +		};
>>>>>> +	};
>>>>>> +};
>>>>>> +
>>>>>>     &uart0 {
>>>>>> +	pinctrl-names = "default";
>>>>>> +	pinctrl-0 = <&uart0_pins>;
>>>>>>     	status = "okay";
>>>>>>     };
>>>>>
>>>>> As there is only a single possible pinctrl configuration for uart0,
>>>>> both the pinmux definition as well as the pinctrl properties should go
>>>>> into mt7981b.dtsi rather than in the board's dts.
>>>>
>>>> If there's really one single possible pin configuration for the UART0 pins,
>>>> as in, those pins *do not* have a GPIO mode, then yes I agree.
>>>>
>>>> If those pins can be as well configured as GPIOs, this goes to board DTS.
>>>
>>> I respectfully disagree and will explain below.
>>>
>>
>> Thanks a lot for taking the time to write all this - explains everything,
>> and even too much :) :)
>>
>> Though, there's something funny here! The following snippet of "main" text
>> does explain stuff that is interesting, but that I (not other people, so
>> thanks again for saying all this) know already, but.....
>>
>>> All pinmux pins on the MediaTek platform also allow being configured as
>>> GPIOs. However, if you configure those as GPIOs the consequence is that
>>> you cannot use UART0 any more at all. So using UART0 at all always
>>> implies using exactly those pins, there is no alternative to that.
>>>
>>> Hence every board with every possible uses of pins 32 and 33 (there is
>>> only RX and TX for UART0, RTS/CTS flow-control is not possible) can be
>>> represented without needing to configure the pinctrl for uart0 on the
>>> board level. There isn't going to be any variation on the board-level
>>> when it comes to uart0. Either it is enabled (status = "okay";), and
>>> that will always imply using the 'uart0' group in mode 'uart', or, in
>>> case any of the two pins of uart0 is used for something else that means
>>> uart0 cannot be enabled. Simple as that.
>>>
>>> Hence there is no need to duplicate that pinctrl settings on each and
>>> every board, as controlling the 'status' property on the board-level
>>> already gives 100% freedom.
>>>
>>
>> ...all of this is not justifying your point.
> 
> So what is the rule then? I understand the logic of describing the
> pins eg. for uart1 only on board-level as there are actual alternatives
> regarding the pins to be used, and if also including RTS/CTS pins.
> Hence, for uart1, there are several possible pingroups which can be
> used. What would be the argument to keep a pinctrl description for
> which the SoC doesn't offer any alternatives to be on the board-level?
> There is nothing to be decided by the board, literally 0 freedom.
> 

As you described - the BootROM is using those two pins as UART0.

Should you want those pins to be used as GPIOs, you'd at least get HW glitches in
early boot phases, or you'd render emergency download mode unusable - which is not
a good idea, not practical, and also, well, almost a stupid thing to do from the
hardware perspective.

This means that it is very, very, very unlikely (to the point that it's practically
impossible) that those pins can ever be used for anything else that is not *the*
one of the two functions that are supported for them (which is UART0 in this case).

In this case, adding the pins at the board level would only create unnecessary
duplication and nothing else, because, well, noone could possibly ever use those
for anything else, again.

That's the criteria.

If the BootROM didn't use those pins, and those could support both GPIO mode and
HW function mode (any: uart0, 1, 2...n, spi, i2c, whatever else), even though it
is likely for boards to use them for one specific function, there is nothing that
stops a HW engineer to decide to route those elsewhere and use them as a GPIO
instead, so that's not a SoC configuration, but rather a HW implementation decision
at the PCB level.

See it like this (although this is an oversimplified view):
  - SoC DT describes the SoC (the chip) - in this case the MT7981B chip
  - Board DT describes decisions that were taken by the HW engineer that developed
    the PCB on which the MT7981B was placed.

Clearly, if there's a board design (usually, a "base project") that has derivatives
(for example, a device with eMMC, one with UFS, one with both, one with two SFP,
one with one SFP and one soldered ethernet chip on a non-exposed SFP interface,
etc) it is ok to have a "board-common" dtsi and specific board variants on top,
like it is done with some bananapi and some genio boards.

Lots of text here - yet oversimplified. There is much more to say, but I think
(and hope) that this is enough to make you understand the main point (of course
feel free to throw more questions if what I wrote doesn't fully satisfy you).

>>
>>> (Sidenote: As even the BootROM already uses those two pins as UART for
>>> debug output,
>>
>> Funny thing is, your side note is what *fully* justifies your disagreement
>> and it's also what triggers me to say that you're right, lol :)
>>
>> Okay then, I am fine with this commit now and I can renew my
>>
>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> 
> Note that the patch you have just added your Reviewed-by:-tag to does
> *not* add the uart0 pinctrl on SoC-level but board-level, so different
> from what I argued for above.

Ewwww I'm doing too may things at once. Pretty crazy days around here :)))

 >> Did you mean to add Reviewed-by: for that
> (which contraticts what you just wrote) or rather to the to-be-submitted
> v2 of this series which includes the change to move the uart0 pinctrl
> to mt7981b.dtsi?

Yeah. Sorry.

I repeat then, so that this is clear: you are right, the pinctrl for UART0 on the
MT7981B SoC must go to mt7981b.dtsi and *not* to mt7981b-openwrt-one.

Cheers,
Angelo

Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

[Daniel Golle]

On Mon, Oct 20, 2025 at 04:02:58PM +0200, AngeloGioacchino Del Regno wrote:
> Il 20/10/25 14:28, Daniel Golle ha scritto:
> > On Mon, Oct 20, 2025 at 12:23:14PM +0200, AngeloGioacchino Del Regno wrote:
> > > Il 16/10/25 18:37, Daniel Golle ha scritto:
> > > > On Thu, Oct 16, 2025 at 04:29:14PM +0200, AngeloGioacchino Del Regno wrote:
> > > > > Il 16/10/25 14:38, Daniel Golle ha scritto:
> > > > > > On Thu, Oct 16, 2025 at 12:08:38PM +0200, Sjoerd Simons wrote:
> > > > > > > Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
> > > > > > > 
> > > > > > > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> > > > > > > ---
> > > > > > >     arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
> > > > > > >     1 file changed, 11 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > > > > > index 968b91f55bb27..f836059d7f475 100644
> > > > > > > --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > > > > > +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > > > > > @@ -22,6 +22,17 @@ memory@40000000 {
> > > > > > >     	};
> > > > > > >     };
> > > > > > > +&pio {
> > > > > > > +	uart0_pins: uart0-pins {
> > > > > > > +		mux {
> > > > > > > +			function = "uart";
> > > > > > > +			groups = "uart0";
> > > > > > > +		};
> > > > > > > +	};
> > > > > > > +};
> > > > > > > +
> > > > > > >     &uart0 {
> > > > > > > +	pinctrl-names = "default";
> > > > > > > +	pinctrl-0 = <&uart0_pins>;
> > > > > > >     	status = "okay";
> > > > > > >     };
> > > > > > 
> > > > > > As there is only a single possible pinctrl configuration for uart0,
> > > > > > both the pinmux definition as well as the pinctrl properties should go
> > > > > > into mt7981b.dtsi rather than in the board's dts.
> > > > > 
> > > > > If there's really one single possible pin configuration for the UART0 pins,
> > > > > as in, those pins *do not* have a GPIO mode, then yes I agree.
> > > > > 
> > > > > If those pins can be as well configured as GPIOs, this goes to board DTS.
> > > > 
> > > > I respectfully disagree and will explain below.
> > > > 
> > > 
> > > Thanks a lot for taking the time to write all this - explains everything,
> > > and even too much :) :)
> > > 
> > > Though, there's something funny here! The following snippet of "main" text
> > > does explain stuff that is interesting, but that I (not other people, so
> > > thanks again for saying all this) know already, but.....
> > > 
> > > > All pinmux pins on the MediaTek platform also allow being configured as
> > > > GPIOs. However, if you configure those as GPIOs the consequence is that
> > > > you cannot use UART0 any more at all. So using UART0 at all always
> > > > implies using exactly those pins, there is no alternative to that.
> > > > 
> > > > Hence every board with every possible uses of pins 32 and 33 (there is
> > > > only RX and TX for UART0, RTS/CTS flow-control is not possible) can be
> > > > represented without needing to configure the pinctrl for uart0 on the
> > > > board level. There isn't going to be any variation on the board-level
> > > > when it comes to uart0. Either it is enabled (status = "okay";), and
> > > > that will always imply using the 'uart0' group in mode 'uart', or, in
> > > > case any of the two pins of uart0 is used for something else that means
> > > > uart0 cannot be enabled. Simple as that.
> > > > 
> > > > Hence there is no need to duplicate that pinctrl settings on each and
> > > > every board, as controlling the 'status' property on the board-level
> > > > already gives 100% freedom.
> > > > 
> > > 
> > > ...all of this is not justifying your point.
> > 
> > So what is the rule then? I understand the logic of describing the
> > pins eg. for uart1 only on board-level as there are actual alternatives
> > regarding the pins to be used, and if also including RTS/CTS pins.
> > Hence, for uart1, there are several possible pingroups which can be
> > used. What would be the argument to keep a pinctrl description for
> > which the SoC doesn't offer any alternatives to be on the board-level?
> > There is nothing to be decided by the board, literally 0 freedom.
> > 
> 
> As you described - the BootROM is using those two pins as UART0.
> 
> Should you want those pins to be used as GPIOs, you'd at least get HW glitches in
> early boot phases, or you'd render emergency download mode unusable - which is not
> a good idea, not practical, and also, well, almost a stupid thing to do from the
> hardware perspective.

No, that's not a problem. During reset the pinctrl/gpio controller is always
reset to the default and no matter how the pins were used in Linux before the
reset. Hence debug output and also emrgency download mode always works.
The only disadvantage of use the pins differently is that the bootrom output
on one of them cannot be prevented -- but in case that's not a problem (eg.
because the pin is later used as an input rather than output) it can totally
be done, though it would be stupid as it would render the debug UART unusable.
Yet, I'd consider it a possible choice of a board designer.

> 
> This means that it is very, very, very unlikely (to the point that it's practically
> impossible) that those pins can ever be used for anything else that is not *the*
> one of the two functions that are supported for them (which is UART0 in this case).
> 
> In this case, adding the pins at the board level would only create unnecessary
> duplication and nothing else, because, well, noone could possibly ever use those
> for anything else, again.
> 
> That's the criteria.

So this criteria, avoiding unnecessary duplication, is also what I thought and
is very true for the argument I presented before which somehow wasn't what has
convinced you: That using uart0 in any possible way **always** implied using
the uart0 pingroup in uart mode, because there aren't any other pins which can
be used for uart0. In this sense, if uart0 is used at all, it is **not** the
choice of the board designer which pins to use for that -- there simply is only
that one single option.

> 
> If the BootROM didn't use those pins, and those could support both GPIO mode and
> HW function mode (any: uart0, 1, 2...n, spi, i2c, whatever else), even though it
> is likely for boards to use them for one specific function, there is nothing that
> stops a HW engineer to decide to route those elsewhere and use them as a GPIO
> instead, so that's not a SoC configuration, but rather a HW implementation decision
> at the PCB level.

That's exactly my point: There isn't any other option to route uart0 to. Only
those two pins. The other alternative functions of those pins (apart from GPIO)
are rather esoteric debugging features (I2C access to SoC internals).

> 
> See it like this (although this is an oversimplified view):
>  - SoC DT describes the SoC (the chip) - in this case the MT7981B chip
>  - Board DT describes decisions that were taken by the HW engineer that developed
>    the PCB on which the MT7981B was placed.

So the choice of a HW engineer regarding uart0 is simply whether uart0
is used or not. If uart0 is used, the HW engineer doesn't have any choice
regarding which pins they would like to use for the uart0 RX and TX lines,
the SoC design dictates exactly one option for that.

> 
> Clearly, if there's a board design (usually, a "base project") that has derivatives
> (for example, a device with eMMC, one with UFS, one with both, one with two SFP,
> one with one SFP and one soldered ethernet chip on a non-exposed SFP interface,
> etc) it is ok to have a "board-common" dtsi and specific board variants on top,
> like it is done with some bananapi and some genio boards.
> 
> Lots of text here - yet oversimplified. There is much more to say, but I think
> (and hope) that this is enough to make you understand the main point (of course
> feel free to throw more questions if what I wrote doesn't fully satisfy you).
> 
> > > 
> > > > (Sidenote: As even the BootROM already uses those two pins as UART for
> > > > debug output,
> > > 
> > > Funny thing is, your side note is what *fully* justifies your disagreement
> > > and it's also what triggers me to say that you're right, lol :)
> > > 
> > > Okay then, I am fine with this commit now and I can renew my
> > > 
> > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > 
> > Note that the patch you have just added your Reviewed-by:-tag to does
> > *not* add the uart0 pinctrl on SoC-level but board-level, so different
> > from what I argued for above.
> 
> Ewwww I'm doing too may things at once. Pretty crazy days around here :)))
> 
> >> Did you mean to add Reviewed-by: for that
> > (which contraticts what you just wrote) or rather to the to-be-submitted
> > v2 of this series which includes the change to move the uart0 pinctrl
> > to mt7981b.dtsi?
> 
> Yeah. Sorry.
> 
> I repeat then, so that this is clear: you are right, the pinctrl for UART0 on the
> MT7981B SoC must go to mt7981b.dtsi and *not* to mt7981b-openwrt-one.

Thank you, that should make it clear to Sjoerd as well (who may skip and ignore
all of our debating :).

[PATCH 03/15] arm64: dts: mediatek: mt7981b: Add reserved memory for TF-A

[Sjoerd Simons]

Add memory range handled by ARM Trusted Firmware

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
index 6b024156fa7c5..b477375078ccd 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
@@ -41,6 +41,18 @@ psci {
 		method = "smc";
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/* 192 KiB reserved for ARM Trusted Firmware (BL31) */
+		secmon_reserved: secmon@43000000 {
+			reg = <0 0x43000000 0 0x30000>;
+			no-map;
+		};
+	};
+
 	soc {
 		compatible = "simple-bus";
 		ranges;

-- 
2.51.0

Re: [PATCH 03/15] arm64: dts: mediatek: mt7981b: Add reserved memory for TF-A

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Add memory range handled by ARM Trusted Firmware
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

> ---
>   arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> index 6b024156fa7c5..b477375078ccd 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> @@ -41,6 +41,18 @@ psci {
>   		method = "smc";
>   	};
>   
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		/* 192 KiB reserved for ARM Trusted Firmware (BL31) */
> +		secmon_reserved: secmon@43000000 {
> +			reg = <0 0x43000000 0 0x30000>;
> +			no-map;
> +		};
> +	};
> +
>   	soc {
>   		compatible = "simple-bus";
>   		ranges;
> 

[PATCH 04/15] dt-bindings: mfd: syscon: Add mt7981-topmisc

[Sjoerd Simons]

This hardware block amongst other things includes a multiplexer for a
high-speed Combo-Phy. This binding allows exposing the multiplexer

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index 657c38175fba2..51511078c4c3b 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -193,6 +193,7 @@ properties:
           - mediatek,mt2701-pctl-a-syscfg
           - mediatek,mt2712-pctl-a-syscfg
           - mediatek,mt6397-pctl-pmic-syscfg
+          - mediatek,mt7981-topmisc
           - mediatek,mt7988-topmisc
           - mediatek,mt8135-pctl-a-syscfg
           - mediatek,mt8135-pctl-b-syscfg

-- 
2.51.0

Re: [PATCH 04/15] dt-bindings: mfd: syscon: Add mt7981-topmisc

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> This hardware block amongst other things includes a multiplexer for a
> high-speed Combo-Phy. This binding allows exposing the multiplexer
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH 04/15] dt-bindings: mfd: syscon: Add mt7981-topmisc

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH 05/15] dt-bindings: pci: mediatek-pcie-gen3: Add MT7981 PCIe compatible

[Sjoerd Simons]

Add compatible string for MediaTek MT7981 PCIe Gen3 controller.
The MT7981 PCIe controller is compatible with the MT8192 PCIe
controller.

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
index 0278845701ce8..4db700fc36ba7 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -48,6 +48,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - mediatek,mt7981-pcie
               - mediatek,mt7986-pcie
               - mediatek,mt8188-pcie
               - mediatek,mt8195-pcie

-- 
2.51.0

Re: [PATCH 05/15] dt-bindings: pci: mediatek-pcie-gen3: Add MT7981 PCIe compatible

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Add compatible string for MediaTek MT7981 PCIe Gen3 controller.
> The MT7981 PCIe controller is compatible with the MT8192 PCIe
> controller.
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH 05/15] dt-bindings: pci: mediatek-pcie-gen3: Add MT7981 PCIe compatible

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 52 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 05/15] dt-bindings: pci: mediatek-pcie-gen3: Add MT7981 PCIe compatible

[Bjorn Helgaas]

On Thu, Oct 16, 2025 at 12:08:41PM +0200, Sjoerd Simons wrote:
> Add compatible string for MediaTek MT7981 PCIe Gen3 controller.
> The MT7981 PCIe controller is compatible with the MT8192 PCIe
> controller.

In subject,
s/pci: mediatek-pcie-gen3:/PCI: mediatek-gen3:/

Note that previous commits to this file use subject lines like this:

  0106b6c114cf ("dt-bindings: PCI: mediatek-gen3: Add support for MT6991/MT8196")
  a1360a6a72b9 ("dt-bindings: PCI: mediatek-gen3: Add mediatek,pbus-csr phandle array property")

git log --oneline Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml

[PATCH 06/15] dt-bindings: phy: mediatek,tphy: Add support for MT7981

[Sjoerd Simons]

Add a compatible string for Filogic 820, this chip integrates a MediaTek
generic T-PHY version 2

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
index b2218c1519391..ff5c77ef11765 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
@@ -80,6 +80,7 @@ properties:
               - mediatek,mt2712-tphy
               - mediatek,mt6893-tphy
               - mediatek,mt7629-tphy
+              - mediatek,mt7981-tphy
               - mediatek,mt7986-tphy
               - mediatek,mt8183-tphy
               - mediatek,mt8186-tphy

-- 
2.51.0

Re: [PATCH 06/15] dt-bindings: phy: mediatek,tphy: Add support for MT7981

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Add a compatible string for Filogic 820, this chip integrates a MediaTek
> generic T-PHY version 2
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Re: [PATCH 06/15] dt-bindings: phy: mediatek,tphy: Add support for MT7981

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On Thu, Oct 16, 2025 at 12:08:42PM +0200, Sjoerd Simons wrote:
> Add a compatible string for Filogic 820, this chip integrates a MediaTek
> generic T-PHY version 2
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

> ---
>  Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> index b2218c1519391..ff5c77ef11765 100644
> --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> @@ -80,6 +80,7 @@ properties:
>                - mediatek,mt2712-tphy
>                - mediatek,mt6893-tphy
>                - mediatek,mt7629-tphy
> +              - mediatek,mt7981-tphy
>                - mediatek,mt7986-tphy
>                - mediatek,mt8183-tphy
>                - mediatek,mt8186-tphy
> 
> -- 
> 2.51.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH 07/15] arm64: dts: mediatek: mt7981b: Add PCIe and USB support

[Sjoerd Simons]

Add device tree nodes for PCIe controller and USB3 XHCI host
controller on MT7981B SoC. Both controllers share the USB3 PHY
which can be configured for either USB3 or PCIe operation.

The USB3 XHCI controller supports USB 2.0 and USB 3.0 SuperSpeed
operation. The PCIe controller is compatible with PCIe Gen2
specifications.

Also add the topmisc syscon node required for USB/PCIe PHY
multiplexing.

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 82 +++++++++++++++++++++++++++++++
 1 file changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
index b477375078ccd..13950fe6e8766 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
@@ -2,6 +2,7 @@
 
 #include <dt-bindings/clock/mediatek,mt7981-clk.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/phy/phy.h>
 #include <dt-bindings/reset/mt7986-resets.h>
 
 / {
@@ -221,6 +222,57 @@ auxadc: adc@1100d000 {
 			status = "disabled";
 		};
 
+		xhci: usb@11200000 {
+			compatible = "mediatek,mt7986-xhci", "mediatek,mtk-xhci";
+			reg = <0 0x11200000 0 0x2e00>,
+			      <0 0x11203e00 0 0x0100>;
+			reg-names = "mac", "ippc";
+			clocks = <&infracfg CLK_INFRA_IUSB_SYS_CK>,
+				 <&infracfg CLK_INFRA_IUSB_CK>,
+				 <&infracfg CLK_INFRA_IUSB_133_CK>,
+				 <&infracfg CLK_INFRA_IUSB_66M_CK>,
+				 <&topckgen CLK_TOP_U2U3_XHCI_SEL>;
+			clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck", "xhci_ck";
+			interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
+			phys = <&u2port0 PHY_TYPE_USB2>,
+			       <&u3port0 PHY_TYPE_USB3>;
+			status = "disabled";
+		};
+
+		pcie: pcie@11280000 {
+			compatible = "mediatek,mt7981-pcie",
+				     "mediatek,mt8192-pcie";
+			reg = <0 0x11280000 0 0x4000>;
+			reg-names = "pcie-mac";
+			ranges = <0x82000000 0 0x20000000
+				  0x0 0x20000000 0 0x10000000>;
+			bus-range = <0x00 0xff>;
+			clocks = <&infracfg CLK_INFRA_IPCIE_CK>,
+				 <&infracfg CLK_INFRA_IPCIE_PIPE_CK>,
+				 <&infracfg CLK_INFRA_IPCIER_CK>,
+				 <&infracfg CLK_INFRA_IPCIEB_CK>;
+			clock-names = "pl_250m", "tl_26m", "peri_26m", "top_133m";
+			device_type = "pci";
+			phys = <&u3port0 PHY_TYPE_PCIE>;
+			phy-names = "pcie-phy";
+			interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0 0 0 1 &pcie_intc 0>,
+					<0 0 0 2 &pcie_intc 1>,
+					<0 0 0 3 &pcie_intc 2>,
+					<0 0 0 4 &pcie_intc 3>;
+			#address-cells = <3>;
+			#interrupt-cells = <1>;
+			#size-cells = <2>;
+			status = "disabled";
+
+			pcie_intc: interrupt-controller {
+				interrupt-controller;
+				#address-cells = <0>;
+				#interrupt-cells = <1>;
+			};
+		};
+
 		pio: pinctrl@11d00000 {
 			compatible = "mediatek,mt7981-pinctrl";
 			reg = <0 0x11d00000 0 0x1000>,
@@ -243,6 +295,36 @@ pio: pinctrl@11d00000 {
 			#interrupt-cells = <2>;
 		};
 
+		topmisc: topmisc@11d10000 {
+			compatible = "mediatek,mt7981-topmisc", "syscon";
+			reg = <0 0x11d10000 0 0x10000>;
+			#clock-cells = <1>;
+		};
+
+		usb_phy: t-phy@11e10000 {
+			compatible = "mediatek,mt7981-tphy",
+				     "mediatek,generic-tphy-v2";
+			ranges = <0 0 0x11e10000 0x1700>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			status = "disabled";
+
+			u2port0: usb-phy@0 {
+				reg = <0x0 0x700>;
+				clocks = <&topckgen CLK_TOP_USB_FRMCNT_SEL>;
+				clock-names = "ref";
+				#phy-cells = <1>;
+			};
+
+			u3port0: usb-phy@700 {
+				reg = <0x700 0x900>;
+				clocks = <&topckgen CLK_TOP_USB3_PHY_SEL>;
+				clock-names = "ref";
+				#phy-cells = <1>;
+				mediatek,syscon-type = <&topmisc 0x218 0>;
+			};
+		};
+
 		efuse: efuse@11f20000 {
 			compatible = "mediatek,mt7981-efuse", "mediatek,efuse";
 			reg = <0 0x11f20000 0 0x1000>;

-- 
2.51.0

Re: [PATCH 07/15] arm64: dts: mediatek: mt7981b: Add PCIe and USB support

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Add device tree nodes for PCIe controller and USB3 XHCI host
> controller on MT7981B SoC. Both controllers share the USB3 PHY
> which can be configured for either USB3 or PCIe operation.
> 
> The USB3 XHCI controller supports USB 2.0 and USB 3.0 SuperSpeed
> operation. The PCIe controller is compatible with PCIe Gen2
> specifications.
> 
> Also add the topmisc syscon node required for USB/PCIe PHY
> multiplexing.
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> ---
>   arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 82 +++++++++++++++++++++++++++++++
>   1 file changed, 82 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> index b477375078ccd..13950fe6e8766 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> @@ -2,6 +2,7 @@
>   
>   #include <dt-bindings/clock/mediatek,mt7981-clk.h>
>   #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/phy/phy.h>
>   #include <dt-bindings/reset/mt7986-resets.h>
>   
>   / {
> @@ -221,6 +222,57 @@ auxadc: adc@1100d000 {
>   			status = "disabled";
>   		};
>   
> +		xhci: usb@11200000 {
> +			compatible = "mediatek,mt7986-xhci", "mediatek,mtk-xhci";
> +			reg = <0 0x11200000 0 0x2e00>,
> +			      <0 0x11203e00 0 0x0100>;

reg fits in one line.

> +			reg-names = "mac", "ippc";
> +			clocks = <&infracfg CLK_INFRA_IUSB_SYS_CK>,
> +				 <&infracfg CLK_INFRA_IUSB_CK>,
> +				 <&infracfg CLK_INFRA_IUSB_133_CK>,
> +				 <&infracfg CLK_INFRA_IUSB_66M_CK>,
> +				 <&topckgen CLK_TOP_U2U3_XHCI_SEL>;
> +			clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck", "xhci_ck";
> +			interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> +			phys = <&u2port0 PHY_TYPE_USB2>,
> +			       <&u3port0 PHY_TYPE_USB3>;

phys fits in one line.

Other than that, looks good; after applying the proposed changes:

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

[PATCH 08/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable PCIe and USB

[Sjoerd Simons]

Enable the PCIe controller and USB3 XHCI host on the OpenWrt One
board. The USB controller is configured for USB 2.0 only mode, as the
shared USB3/PCIe PHY is dedicated to PCIe functionality on this board.

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
index f836059d7f475..b6ca628ee72fd 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
@@ -20,9 +20,40 @@ memory@40000000 {
 		reg = <0 0x40000000 0 0x40000000>;
 		device_type = "memory";
 	};
+
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-3.3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+	reg_5v: regulator-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+};
+
+&pcie {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie_pins>;
+	status = "okay";
 };
 
 &pio {
+	pcie_pins: pcie-pins {
+		mux {
+			function = "pcie";
+			groups = "pcie_pereset";
+		};
+	};
+
 	uart0_pins: uart0-pins {
 		mux {
 			function = "uart";
@@ -36,3 +67,15 @@ &uart0 {
 	pinctrl-0 = <&uart0_pins>;
 	status = "okay";
 };
+
+&usb_phy {
+	status = "okay";
+};
+
+&xhci {
+	phys = <&u2port0 PHY_TYPE_USB2>;
+	vusb33-supply = <&reg_3p3v>;
+	vbus-supply = <&reg_5v>;
+	mediatek,u3p-dis-msk = <0x01>;
+	status = "okay";
+};

-- 
2.51.0

[PATCH 09/15] dt-bindings: net: mediatek,net: Correct bindings for MT7981

[Sjoerd Simons]

Different SoCs have different numbers of Wireless Ethernet
Dispatch (WED) units:
- MT7981: Has 1 WED unit
- MT7986: Has 2 WED units
- MT7988: Has 2 WED units

Update the binding to reflect these hardware differences. The MT7981
also uses infracfg for PHY switching, so allow that property.

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 Documentation/devicetree/bindings/net/mediatek,net.yaml | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
index b45f67f92e80d..453e6bb34094a 100644
--- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
@@ -112,7 +112,7 @@ properties:
 
   mediatek,wed:
     $ref: /schemas/types.yaml#/definitions/phandle-array
-    minItems: 2
+    minItems: 1
     maxItems: 2
     items:
       maxItems: 1
@@ -338,12 +338,14 @@ allOf:
             - const: netsys0
             - const: netsys1
 
-        mediatek,infracfg: false
-
         mediatek,sgmiisys:
           minItems: 2
           maxItems: 2
 
+        mediatek,wed:
+          minItems: 1
+          maxItems: 1
+
   - if:
       properties:
         compatible:
@@ -385,6 +387,10 @@ allOf:
           minItems: 2
           maxItems: 2
 
+        mediatek,wed:
+          minItems: 2
+          maxItems: 2
+
   - if:
       properties:
         compatible:
@@ -429,6 +435,10 @@ allOf:
             - const: xgp2
             - const: xgp3
 
+        mediatek,wed:
+          minItems: 2
+          maxItems: 2
+
 patternProperties:
   "^mac@[0-2]$":
     type: object

-- 
2.51.0

Re: [PATCH 09/15] dt-bindings: net: mediatek,net: Correct bindings for MT7981

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Different SoCs have different numbers of Wireless Ethernet
> Dispatch (WED) units:
> - MT7981: Has 1 WED unit
> - MT7986: Has 2 WED units
> - MT7988: Has 2 WED units
> 
> Update the binding to reflect these hardware differences. The MT7981
> also uses infracfg for PHY switching, so allow that property.
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> ---
>   Documentation/devicetree/bindings/net/mediatek,net.yaml | 16 +++++++++++++---
>   1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> index b45f67f92e80d..453e6bb34094a 100644
> --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
> +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> @@ -112,7 +112,7 @@ properties:
>   
>     mediatek,wed:
>       $ref: /schemas/types.yaml#/definitions/phandle-array
> -    minItems: 2
> +    minItems: 1

If minItems is 1 here

>       maxItems: 2
>       items:
>         maxItems: 1
> @@ -338,12 +338,14 @@ allOf:
>               - const: netsys0
>               - const: netsys1
>   
> -        mediatek,infracfg: false
> -
>           mediatek,sgmiisys:
>             minItems: 2
>             maxItems: 2
>   
> +        mediatek,wed:
> +          minItems: 1

You just need maxItems here.

> +          maxItems: 1
> +
>     - if:
>         properties:
>           compatible:
> @@ -385,6 +387,10 @@ allOf:
>             minItems: 2
>             maxItems: 2
>   
> +        mediatek,wed:
> +          minItems: 2
> +          maxItems: 2
> +
>     - if:
>         properties:
>           compatible:
> @@ -429,6 +435,10 @@ allOf:
>               - const: xgp2
>               - const: xgp3
>   
> +        mediatek,wed:
> +          minItems: 2
> +          maxItems: 2

Analogously, you should be needing just minItems here if I'm not wrong.

Cheers,
Angelo

> +
>   patternProperties:
>     "^mac@[0-2]$":
>       type: object
> 

Re: [PATCH 09/15] dt-bindings: net: mediatek,net: Correct bindings for MT7981

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]

On Thu, Oct 16, 2025 at 01:29:01PM +0200, AngeloGioacchino Del Regno wrote:
> Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> > Different SoCs have different numbers of Wireless Ethernet
> > Dispatch (WED) units:
> > - MT7981: Has 1 WED unit
> > - MT7986: Has 2 WED units
> > - MT7988: Has 2 WED units
> > 
> > Update the binding to reflect these hardware differences. The MT7981
> > also uses infracfg for PHY switching, so allow that property.
> > 
> > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> > ---
> >   Documentation/devicetree/bindings/net/mediatek,net.yaml | 16 +++++++++++++---
> >   1 file changed, 13 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> > index b45f67f92e80d..453e6bb34094a 100644
> > --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
> > +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> > @@ -112,7 +112,7 @@ properties:
> >     mediatek,wed:
> >       $ref: /schemas/types.yaml#/definitions/phandle-array
> > -    minItems: 2
> > +    minItems: 1
> 
> If minItems is 1 here
> 
> >       maxItems: 2
> >       items:
> >         maxItems: 1
> > @@ -338,12 +338,14 @@ allOf:
> >               - const: netsys0
> >               - const: netsys1
> > -        mediatek,infracfg: false
> > -
> >           mediatek,sgmiisys:
> >             minItems: 2
> >             maxItems: 2
> > +        mediatek,wed:
> > +          minItems: 1
> 
> You just need maxItems here.
> 
> > +          maxItems: 1
> > +
> >     - if:
> >         properties:
> >           compatible:
> > @@ -385,6 +387,10 @@ allOf:
> >             minItems: 2
> >             maxItems: 2
> > +        mediatek,wed:
> > +          minItems: 2
> > +          maxItems: 2
> > +
> >     - if:
> >         properties:
> >           compatible:
> > @@ -429,6 +435,10 @@ allOf:
> >               - const: xgp2
> >               - const: xgp3
> > +        mediatek,wed:
> > +          minItems: 2
> > +          maxItems: 2
> 
> Analogously, you should be needing just minItems here if I'm not wrong.

Yeah, you don't need to duplicate constraints that are copies of the
outermost one set in the definition. I dunno how it is actually done by
the schema tools, but I like to think of it that every constraint that's
possible is applied at the same time.

pw-bot: changes-requested

> 
> Cheers,
> Angelo
> 
> > +
> >   patternProperties:
> >     "^mac@[0-2]$":
> >       type: object
> > 
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH 10/15] arm64: dts: mediatek: mt7981b: Add Ethernet and WiFi offload support

[Sjoerd Simons]

Add device tree nodes for the Ethernet subsystem on MT7981B SoC,
including:
- Ethernet MAC controller with dual GMAC support
- Wireless Ethernet Dispatch (WED)
- SGMII PHY controllers for high-speed Ethernet interfaces
- Reserved memory regions for WiFi offload processor

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 133 ++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
index 13950fe6e8766..c85fa0ddf2da8 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
@@ -2,6 +2,7 @@
 
 #include <dt-bindings/clock/mediatek,mt7981-clk.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/phy/phy.h>
 #include <dt-bindings/reset/mt7986-resets.h>
 
@@ -47,11 +48,36 @@ reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
+		wo_boot: wo-boot@15194000 {
+			reg = <0 0x15194000 0 0x1000>;
+			no-map;
+		};
+
+		wo_ilm0: wo-ilm@151e0000 {
+			reg = <0 0x151e0000 0 0x8000>;
+			no-map;
+		};
+
+		wo_dlm0: wo-dlm@151e8000 {
+			reg = <0 0x151e8000 0 0x2000>;
+			no-map;
+		};
+
 		/* 192 KiB reserved for ARM Trusted Firmware (BL31) */
 		secmon_reserved: secmon@43000000 {
 			reg = <0 0x43000000 0 0x30000>;
 			no-map;
 		};
+
+		wo_emi0: wo-emi@47d80000 {
+			reg = <0 0x47d80000 0 0x40000>;
+			no-map;
+		};
+
+		wo_data: wo-data@47dc0000 {
+			reg = <0 0x47dc0000 0 0x240000>;
+			no-map;
+		};
 	};
 
 	soc {
@@ -107,6 +133,18 @@ pwm: pwm@10048000 {
 			#pwm-cells = <2>;
 		};
 
+		sgmiisys0: syscon@10060000 {
+			compatible = "mediatek,mt7981-sgmiisys_0", "syscon";
+			reg = <0 0x10060000 0 0x1000>;
+			#clock-cells = <1>;
+		};
+
+		sgmiisys1: syscon@10070000 {
+			compatible = "mediatek,mt7981-sgmiisys_1", "syscon";
+			reg = <0 0x10070000 0 0x1000>;
+			#clock-cells = <1>;
+		};
+
 		uart0: serial@11002000 {
 			compatible = "mediatek,mt7981-uart", "mediatek,mt6577-uart";
 			reg = <0 0x11002000 0 0x100>;
@@ -338,6 +376,10 @@ soc-uuid@140 {
 			thermal_calibration: thermal-calib@274 {
 				reg = <0x274 0xc>;
 			};
+
+			phy_calibration: phy-calib@8dc {
+				reg = <0x8dc 0x10>;
+			};
 		};
 
 		ethsys: clock-controller@15000000 {
@@ -347,6 +389,97 @@ ethsys: clock-controller@15000000 {
 			#reset-cells = <1>;
 		};
 
+		wed: wed@15010000 {
+			compatible = "mediatek,mt7981-wed",
+				     "syscon";
+			reg = <0 0x15010000 0 0x1000>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
+			memory-region = <&wo_emi0>, <&wo_ilm0>, <&wo_dlm0>,
+					<&wo_data>, <&wo_boot>;
+			memory-region-names = "wo-emi", "wo-ilm", "wo-dlm",
+					      "wo-data", "wo-boot";
+			mediatek,wo-ccif = <&wo_ccif0>;
+		};
+
+		eth: ethernet@15100000 {
+			compatible = "mediatek,mt7981-eth";
+			reg = <0 0x15100000 0 0x40000>;
+			assigned-clocks = <&topckgen CLK_TOP_NETSYS_2X_SEL>,
+					  <&topckgen CLK_TOP_SGM_325M_SEL>;
+			assigned-clock-parents = <&topckgen CLK_TOP_CB_NET2_800M>,
+						 <&topckgen CLK_TOP_CB_SGM_325M>;
+			clocks = <&ethsys CLK_ETH_FE_EN>,
+				 <&ethsys CLK_ETH_GP2_EN>,
+				 <&ethsys CLK_ETH_GP1_EN>,
+				 <&ethsys CLK_ETH_WOCPU0_EN>,
+				 <&topckgen CLK_TOP_SGM_REG>,
+				 <&sgmiisys0 CLK_SGM0_TX_EN>,
+				 <&sgmiisys0 CLK_SGM0_RX_EN>,
+				 <&sgmiisys0 CLK_SGM0_CK0_EN>,
+				 <&sgmiisys0 CLK_SGM0_CDR_CK0_EN>,
+				 <&sgmiisys1 CLK_SGM1_TX_EN>,
+				 <&sgmiisys1 CLK_SGM1_RX_EN>,
+				 <&sgmiisys1 CLK_SGM1_CK1_EN>,
+				 <&sgmiisys1 CLK_SGM1_CDR_CK1_EN>,
+				 <&topckgen CLK_TOP_NETSYS_SEL>,
+				 <&topckgen CLK_TOP_NETSYS_500M_SEL>;
+			clock-names = "fe", "gp2", "gp1", "wocpu0",
+				      "sgmii_ck",
+				      "sgmii_tx250m", "sgmii_rx250m",
+				      "sgmii_cdr_ref", "sgmii_cdr_fb",
+				      "sgmii2_tx250m", "sgmii2_rx250m",
+				      "sgmii2_cdr_ref", "sgmii2_cdr_fb",
+				      "netsys0", "netsys1";
+			interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "fe0", "fe1", "fe2", "fe3", "pdma0",
+					  "pdma1", "pdma2", "pdma3";
+			sram = <&eth_sram>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,ethsys = <&ethsys>;
+			mediatek,sgmiisys = <&sgmiisys0>, <&sgmiisys1>;
+			mediatek,infracfg = <&topmisc>;
+			mediatek,wed = <&wed>;
+			status = "disabled";
+
+			mdio_bus: mdio-bus {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				int_gbe_phy: ethernet-phy@0 {
+					compatible = "ethernet-phy-ieee802.3-c22";
+					reg = <0>;
+					phy-mode = "gmii";
+					phy-is-integrated;
+					nvmem-cells = <&phy_calibration>;
+					nvmem-cell-names = "phy-cal-data";
+				};
+			};
+		};
+
+		eth_sram: sram@15140000 {
+			compatible = "mmio-sram";
+			reg = <0 0x15140000 0 0x40000>;
+			ranges = <0 0x15140000 0 0x40000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
+
+		wo_ccif0: syscon@151a5000 {
+			compatible = "mediatek,mt7986-wo-ccif", "syscon";
+			reg = <0 0x151a5000 0 0x1000>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
 		wifi: wifi@18000000 {
 			compatible = "mediatek,mt7981-wmac";
 			reg = <0 0x18000000 0 0x1000000>,

-- 
2.51.0

Re: [PATCH 10/15] arm64: dts: mediatek: mt7981b: Add Ethernet and WiFi offload support

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Add device tree nodes for the Ethernet subsystem on MT7981B SoC,
> including:
> - Ethernet MAC controller with dual GMAC support
> - Wireless Ethernet Dispatch (WED)
> - SGMII PHY controllers for high-speed Ethernet interfaces
> - Reserved memory regions for WiFi offload processor
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> ---
>   arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 133 ++++++++++++++++++++++++++++++
>   1 file changed, 133 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> index 13950fe6e8766..c85fa0ddf2da8 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi

..snip..

> @@ -347,6 +389,97 @@ ethsys: clock-controller@15000000 {
>   			#reset-cells = <1>;
>   		};
>   
> +		wed: wed@15010000 {
> +			compatible = "mediatek,mt7981-wed",
> +				     "syscon";
> +			reg = <0 0x15010000 0 0x1000>;
> +			interrupt-parent = <&gic>;

That's redundant: gic is already the default interrupt parent for this node.

> +			interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
> +			memory-region = <&wo_emi0>, <&wo_ilm0>, <&wo_dlm0>,
> +					<&wo_data>, <&wo_boot>;
> +			memory-region-names = "wo-emi", "wo-ilm", "wo-dlm",
> +					      "wo-data", "wo-boot";
> +			mediatek,wo-ccif = <&wo_ccif0>;
> +		};
> +

..snip..

> +
> +		eth_sram: sram@15140000 {
> +			compatible = "mmio-sram";
> +			reg = <0 0x15140000 0 0x40000>;
> +			ranges = <0 0x15140000 0 0x40000>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +		};
> +
> +		wo_ccif0: syscon@151a5000 {
> +			compatible = "mediatek,mt7986-wo-ccif", "syscon";
> +			reg = <0 0x151a5000 0 0x1000>;
> +			interrupt-parent = <&gic>;

ditto.

> +			interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>;
> +		};
> +
>   		wifi: wifi@18000000 {
>   			compatible = "mediatek,mt7981-wmac";
>   			reg = <0 0x18000000 0 0x1000000>,
> 

Everything else looks good.

Cheers,
Angelo

Re: [PATCH 10/15] arm64: dts: mediatek: mt7981b: Add Ethernet and WiFi offload support

[Daniel Golle]

On Thu, Oct 16, 2025 at 12:08:46PM +0200, Sjoerd Simons wrote:
> Add device tree nodes for the Ethernet subsystem on MT7981B SoC,
> including:
> - Ethernet MAC controller with dual GMAC support
> - Wireless Ethernet Dispatch (WED)
> - SGMII PHY controllers for high-speed Ethernet interfaces
> - Reserved memory regions for WiFi offload processor
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 133 ++++++++++++++++++++++++++++++
>  1 file changed, 133 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> index 13950fe6e8766..c85fa0ddf2da8 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> @@ -2,6 +2,7 @@
>  
>  #include <dt-bindings/clock/mediatek,mt7981-clk.h>
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/leds/common.h>
>  #include <dt-bindings/phy/phy.h>
>  #include <dt-bindings/reset/mt7986-resets.h>
>  
> @@ -47,11 +48,36 @@ reserved-memory {
>  		#size-cells = <2>;
>  		ranges;
>  
> +		wo_boot: wo-boot@15194000 {
> +			reg = <0 0x15194000 0 0x1000>;
> +			no-map;
> +		};
> +
> +		wo_ilm0: wo-ilm@151e0000 {
> +			reg = <0 0x151e0000 0 0x8000>;
> +			no-map;
> +		};
> +
> +		wo_dlm0: wo-dlm@151e8000 {
> +			reg = <0 0x151e8000 0 0x2000>;
> +			no-map;
> +		};
> +
>  		/* 192 KiB reserved for ARM Trusted Firmware (BL31) */
>  		secmon_reserved: secmon@43000000 {
>  			reg = <0 0x43000000 0 0x30000>;
>  			no-map;
>  		};
> +
> +		wo_emi0: wo-emi@47d80000 {
> +			reg = <0 0x47d80000 0 0x40000>;
> +			no-map;
> +		};
> +
> +		wo_data: wo-data@47dc0000 {
> +			reg = <0 0x47dc0000 0 0x240000>;
> +			no-map;
> +		};
>  	};
>  
>  	soc {
> @@ -107,6 +133,18 @@ pwm: pwm@10048000 {
>  			#pwm-cells = <2>;
>  		};
>  
> +		sgmiisys0: syscon@10060000 {
> +			compatible = "mediatek,mt7981-sgmiisys_0", "syscon";
> +			reg = <0 0x10060000 0 0x1000>;
> +			#clock-cells = <1>;
> +		};
> +
> +		sgmiisys1: syscon@10070000 {
> +			compatible = "mediatek,mt7981-sgmiisys_1", "syscon";
> +			reg = <0 0x10070000 0 0x1000>;
> +			#clock-cells = <1>;
> +		};
> +
>  		uart0: serial@11002000 {
>  			compatible = "mediatek,mt7981-uart", "mediatek,mt6577-uart";
>  			reg = <0 0x11002000 0 0x100>;
> @@ -338,6 +376,10 @@ soc-uuid@140 {
>  			thermal_calibration: thermal-calib@274 {
>  				reg = <0x274 0xc>;
>  			};
> +
> +			phy_calibration: phy-calib@8dc {
> +				reg = <0x8dc 0x10>;
> +			};
>  		};
>  
>  		ethsys: clock-controller@15000000 {
> @@ -347,6 +389,97 @@ ethsys: clock-controller@15000000 {
>  			#reset-cells = <1>;
>  		};
>  
> +		wed: wed@15010000 {
> +			compatible = "mediatek,mt7981-wed",
> +				     "syscon";
> +			reg = <0 0x15010000 0 0x1000>;
> +			interrupt-parent = <&gic>;
> +			interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
> +			memory-region = <&wo_emi0>, <&wo_ilm0>, <&wo_dlm0>,
> +					<&wo_data>, <&wo_boot>;
> +			memory-region-names = "wo-emi", "wo-ilm", "wo-dlm",
> +					      "wo-data", "wo-boot";
> +			mediatek,wo-ccif = <&wo_ccif0>;
> +		};
> +
> +		eth: ethernet@15100000 {
> +			compatible = "mediatek,mt7981-eth";
> +			reg = <0 0x15100000 0 0x40000>;
> +			assigned-clocks = <&topckgen CLK_TOP_NETSYS_2X_SEL>,
> +					  <&topckgen CLK_TOP_SGM_325M_SEL>;
> +			assigned-clock-parents = <&topckgen CLK_TOP_CB_NET2_800M>,
> +						 <&topckgen CLK_TOP_CB_SGM_325M>;
> +			clocks = <&ethsys CLK_ETH_FE_EN>,
> +				 <&ethsys CLK_ETH_GP2_EN>,
> +				 <&ethsys CLK_ETH_GP1_EN>,
> +				 <&ethsys CLK_ETH_WOCPU0_EN>,
> +				 <&topckgen CLK_TOP_SGM_REG>,
> +				 <&sgmiisys0 CLK_SGM0_TX_EN>,
> +				 <&sgmiisys0 CLK_SGM0_RX_EN>,
> +				 <&sgmiisys0 CLK_SGM0_CK0_EN>,
> +				 <&sgmiisys0 CLK_SGM0_CDR_CK0_EN>,
> +				 <&sgmiisys1 CLK_SGM1_TX_EN>,
> +				 <&sgmiisys1 CLK_SGM1_RX_EN>,
> +				 <&sgmiisys1 CLK_SGM1_CK1_EN>,
> +				 <&sgmiisys1 CLK_SGM1_CDR_CK1_EN>,
> +				 <&topckgen CLK_TOP_NETSYS_SEL>,
> +				 <&topckgen CLK_TOP_NETSYS_500M_SEL>;
> +			clock-names = "fe", "gp2", "gp1", "wocpu0",
> +				      "sgmii_ck",
> +				      "sgmii_tx250m", "sgmii_rx250m",
> +				      "sgmii_cdr_ref", "sgmii_cdr_fb",
> +				      "sgmii2_tx250m", "sgmii2_rx250m",
> +				      "sgmii2_cdr_ref", "sgmii2_cdr_fb",
> +				      "netsys0", "netsys1";
> +			interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "fe0", "fe1", "fe2", "fe3", "pdma0",
> +					  "pdma1", "pdma2", "pdma3";
> +			sram = <&eth_sram>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			mediatek,ethsys = <&ethsys>;
> +			mediatek,sgmiisys = <&sgmiisys0>, <&sgmiisys1>;
> +			mediatek,infracfg = <&topmisc>;
> +			mediatek,wed = <&wed>;
> +			status = "disabled";
> +
> +			mdio_bus: mdio-bus {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				int_gbe_phy: ethernet-phy@0 {
> +					compatible = "ethernet-phy-ieee802.3-c22";
> +					reg = <0>;
> +					phy-mode = "gmii";
> +					phy-is-integrated;
> +					nvmem-cells = <&phy_calibration>;
> +					nvmem-cell-names = "phy-cal-data";

Please also define the two LEDs here with their corresponding (only)
pinctrl options for each of them, with 'status = "disabled";'. This
makes it easier for boards to make use of the Ethernet PHY leds by just
referencing the LED and setting the status to 'okay'.

> +				};
> +			};
> +		};
> +
> +		eth_sram: sram@15140000 {
> +			compatible = "mmio-sram";
> +			reg = <0 0x15140000 0 0x40000>;
> +			ranges = <0 0x15140000 0 0x40000>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +		};
> +
> +		wo_ccif0: syscon@151a5000 {
> +			compatible = "mediatek,mt7986-wo-ccif", "syscon";
> +			reg = <0 0x151a5000 0 0x1000>;
> +			interrupt-parent = <&gic>;
> +			interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>;
> +		};
> +
>  		wifi: wifi@18000000 {
>  			compatible = "mediatek,mt7981-wmac";
>  			reg = <0 0x18000000 0 0x1000000>,
> 
> -- 
> 2.51.0
> 

Re: [PATCH 10/15] arm64: dts: mediatek: mt7981b: Add Ethernet and WiFi offload support

[AngeloGioacchino Del Regno]

Il 16/10/25 18:47, Daniel Golle ha scritto:
> On Thu, Oct 16, 2025 at 12:08:46PM +0200, Sjoerd Simons wrote:
>> Add device tree nodes for the Ethernet subsystem on MT7981B SoC,
>> including:
>> - Ethernet MAC controller with dual GMAC support
>> - Wireless Ethernet Dispatch (WED)
>> - SGMII PHY controllers for high-speed Ethernet interfaces
>> - Reserved memory regions for WiFi offload processor
>>
>> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
>> ---
>>   arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 133 ++++++++++++++++++++++++++++++
>>   1 file changed, 133 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
>> index 13950fe6e8766..c85fa0ddf2da8 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi

..snip..

>> +
>> +			mdio_bus: mdio-bus {
>> +				#address-cells = <1>;
>> +				#size-cells = <0>;
>> +
>> +				int_gbe_phy: ethernet-phy@0 {
>> +					compatible = "ethernet-phy-ieee802.3-c22";
>> +					reg = <0>;
>> +					phy-mode = "gmii";
>> +					phy-is-integrated;
>> +					nvmem-cells = <&phy_calibration>;
>> +					nvmem-cell-names = "phy-cal-data";
> 
> Please also define the two LEDs here with their corresponding (only)
> pinctrl options for each of them, with 'status = "disabled";'. This
> makes it easier for boards to make use of the Ethernet PHY leds by just
> referencing the LED and setting the status to 'okay'.
> 

Sorry Daniel, definitely no. The LEDs really are board specific.

Try to convince me otherwise, but for this one I really doubt that you can.

Cheers,
Angelo

Re: [PATCH 10/15] arm64: dts: mediatek: mt7981b: Add Ethernet and WiFi offload support

[Daniel Golle]

On Mon, Oct 20, 2025 at 12:27:53PM +0200, AngeloGioacchino Del Regno wrote:
> Il 16/10/25 18:47, Daniel Golle ha scritto:
> > On Thu, Oct 16, 2025 at 12:08:46PM +0200, Sjoerd Simons wrote:
> > > Add device tree nodes for the Ethernet subsystem on MT7981B SoC,
> > > including:
> > > - Ethernet MAC controller with dual GMAC support
> > > - Wireless Ethernet Dispatch (WED)
> > > - SGMII PHY controllers for high-speed Ethernet interfaces
> > > - Reserved memory regions for WiFi offload processor
> > > 
> > > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> > > ---
> > >   arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 133 ++++++++++++++++++++++++++++++
> > >   1 file changed, 133 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> > > index 13950fe6e8766..c85fa0ddf2da8 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> > > +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> 
> ..snip..
> 
> > > +
> > > +			mdio_bus: mdio-bus {
> > > +				#address-cells = <1>;
> > > +				#size-cells = <0>;
> > > +
> > > +				int_gbe_phy: ethernet-phy@0 {
> > > +					compatible = "ethernet-phy-ieee802.3-c22";
> > > +					reg = <0>;
> > > +					phy-mode = "gmii";
> > > +					phy-is-integrated;
> > > +					nvmem-cells = <&phy_calibration>;
> > > +					nvmem-cell-names = "phy-cal-data";
> > 
> > Please also define the two LEDs here with their corresponding (only)
> > pinctrl options for each of them, with 'status = "disabled";'. This
> > makes it easier for boards to make use of the Ethernet PHY leds by just
> > referencing the LED and setting the status to 'okay'.
> > 
> 
> Sorry Daniel, definitely no. The LEDs really are board specific.
> 
> Try to convince me otherwise, but for this one I really doubt that you can.

You are right, the LEDs themselves are board-specific and may not even
be present.

However, the LED controller is always present because it is part of the
PHY which is built-into the SoC. And the pinctrl property which I'd like
to see described on SoC-level is a property of the LED controller rather
than the LED itself. Sadly the device tree node doesn't make the
distinction between LED and LED controller, so I understand you your
argument as well.

Re: [PATCH 10/15] arm64: dts: mediatek: mt7981b: Add Ethernet and WiFi offload support

[Sjoerd Simons]

On Thu, 2025-10-16 at 17:47 +0100, Daniel Golle wrote:
> On Thu, Oct 16, 2025 at 12:08:46PM +0200, Sjoerd Simons wrote:
> > Add device tree nodes for the Ethernet subsystem on MT7981B SoC,
> > including:
> > - Ethernet MAC controller with dual GMAC support
> > - Wireless Ethernet Dispatch (WED)
> > - SGMII PHY controllers for high-speed Ethernet interfaces
> > - Reserved memory regions for WiFi offload processor
> > 
> > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> > ---
> >  arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 133 ++++++++++++++++++++++++++++++
> >  1 file changed, 133 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> > index 13950fe6e8766..c85fa0ddf2da8 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi

[snip]
> > 			mdio_bus: mdio-bus {
> > +				#address-cells = <1>;
> > +				#size-cells = <0>;
> > +
> > +				int_gbe_phy: ethernet-phy@0 {
> > +					compatible = "ethernet-phy-ieee802.3-c22";
> > +					reg = <0>;
> > +					phy-mode = "gmii";
> > +					phy-is-integrated;
> > +					nvmem-cells = <&phy_calibration>;
> > +					nvmem-cell-names = "phy-cal-data";
> 
> Please also define the two LEDs here with their corresponding (only)
> pinctrl options for each of them, with 'status = "disabled";'. This
> makes it easier for boards to make use of the Ethernet PHY leds by just
> referencing the LED and setting the status to 'okay'.

I left those out on purpose as i can't easily validate them. They're probably better to be added once
someone adds a board using the hw led control.

> 
-- 
Sjoerd Simons
Collabora Ltd.

[PATCH 11/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable SPI NOR

[Sjoerd Simons]

The openwrt one has a SPI NOR flash which from factory is used for:
* Recovery system
* WiFi eeprom data
* ethernet Mac addresses

Describe this following the same partitions as the openwrt configuration
uses.

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 83 ++++++++++++++++++++++
 1 file changed, 83 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
index b6ca628ee72fd..9878009385cc6 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
@@ -3,6 +3,7 @@
 /dts-v1/;
 
 #include "mt7981b.dtsi"
+#include "dt-bindings/pinctrl/mt65xx.h"
 
 / {
 	compatible = "openwrt,one", "mediatek,mt7981b";
@@ -54,6 +55,25 @@ mux {
 		};
 	};
 
+	spi2_flash_pins: spi2-pins {
+		mux {
+			function = "spi";
+			groups = "spi2";
+		};
+
+		conf-pu {
+			bias-pull-up = <MTK_PUPD_SET_R1R0_11>;
+			drive-strength = <MTK_DRIVE_8mA>;
+			pins = "SPI2_CS", "SPI2_WP";
+		};
+
+		conf-pd {
+			bias-pull-down = <MTK_PUPD_SET_R1R0_11>;
+			drive-strength = <MTK_DRIVE_8mA>;
+			pins = "SPI2_CLK", "SPI2_MOSI", "SPI2_MISO";
+		};
+	};
+
 	uart0_pins: uart0-pins {
 		mux {
 			function = "uart";
@@ -62,6 +82,69 @@ mux {
 	};
 };
 
+&spi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2_flash_pins>;
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				reg = <0x00000 0x40000>;
+				label = "bl2-nor";
+			};
+
+			partition@40000 {
+				reg = <0x40000 0xc0000>;
+				label = "factory";
+				read-only;
+
+				nvmem-layout {
+					compatible = "fixed-layout";
+					#address-cells = <1>;
+					#size-cells = <1>;
+
+					eeprom_factory_0: eeprom@0 {
+						reg = <0x0 0x1000>;
+					};
+
+					macaddr_factory_4: macaddr@4 {
+						reg = <0x4 0x6>;
+						compatible = "mac-base";
+						#nvmem-cell-cells = <1>;
+					};
+
+					macaddr_factory_24: macaddr@24 {
+						reg = <0x24 0x6>;
+						compatible = "mac-base";
+						#nvmem-cell-cells = <1>;
+					};
+				};
+			};
+
+			partition@100000 {
+				reg = <0x100000 0x80000>;
+				label = "fip-nor";
+			};
+
+			partition@180000 {
+				reg = <0x180000 0xc80000>;
+				label = "recovery";
+			};
+		};
+	};
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins>;

-- 
2.51.0

Re: [PATCH 11/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable SPI NOR

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> The openwrt one has a SPI NOR flash which from factory is used for:
> * Recovery system
> * WiFi eeprom data
> * ethernet Mac addresses
> 
> Describe this following the same partitions as the openwrt configuration
> uses.
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> ---
>   .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 83 ++++++++++++++++++++++
>   1 file changed, 83 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> index b6ca628ee72fd..9878009385cc6 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> @@ -3,6 +3,7 @@
>   /dts-v1/;
>   
>   #include "mt7981b.dtsi"
> +#include "dt-bindings/pinctrl/mt65xx.h"
>   
>   / {
>   	compatible = "openwrt,one", "mediatek,mt7981b";
> @@ -54,6 +55,25 @@ mux {
>   		};
>   	};
>   
> +	spi2_flash_pins: spi2-pins {
> +		mux {
> +			function = "spi";
> +			groups = "spi2";
> +		};
> +
> +		conf-pu {
> +			bias-pull-up = <MTK_PUPD_SET_R1R0_11>;
> +			drive-strength = <MTK_DRIVE_8mA>;

drive-strength = <8>;

> +			pins = "SPI2_CS", "SPI2_WP";
> +		};
> +
> +		conf-pd {
> +			bias-pull-down = <MTK_PUPD_SET_R1R0_11>;
> +			drive-strength = <MTK_DRIVE_8mA>;

ditto

> +			pins = "SPI2_CLK", "SPI2_MOSI", "SPI2_MISO";
> +		};
> +	};
> +
>   	uart0_pins: uart0-pins {
>   		mux {
>   			function = "uart";
> @@ -62,6 +82,69 @@ mux {
>   	};
>   };
>   
> +&spi2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi2_flash_pins>;
> +	status = "okay";
> +
> +	flash@0 {
> +		compatible = "jedec,spi-nor";
> +		reg = <0>;
> +		spi-max-frequency = <40000000>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			partition@0 {
> +				reg = <0x00000 0x40000>;
> +				label = "bl2-nor";
> +			};
> +
> +			partition@40000 {
> +				reg = <0x40000 0xc0000>;
> +				label = "factory";
> +				read-only;
> +
> +				nvmem-layout {
> +					compatible = "fixed-layout";
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +
> +					eeprom_factory_0: eeprom@0 {

wifi_calibration:

> +						reg = <0x0 0x1000>;
> +					};
> +
> +					macaddr_factory_4: macaddr@4 {

macaddr_factory_gmac1?

You're not using this in the later commit where you enable ethernet nodes,
did you miss adding that to gmac1 or what is this used for?

> +						reg = <0x4 0x6>;
> +						compatible = "mac-base";
> +						#nvmem-cell-cells = <1>;
> +					};
> +
> +					macaddr_factory_24: macaddr@24 {

macaddr_factory_gmac0 ?


Cheers,
Angelo

Re: [PATCH 11/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable SPI NOR

[Sjoerd Simons]

On Thu, 2025-10-16 at 13:28 +0200, AngeloGioacchino Del Regno wrote:
> Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> > The openwrt one has a SPI NOR flash which from factory is used for:
> > * Recovery system
> > * WiFi eeprom data
> > * ethernet Mac addresses
> > 
> > Describe this following the same partitions as the openwrt configuration
> > uses.
> > 
> > Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> > ---
> >   .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 83 ++++++++++++++++++++++
> >   1 file changed, 83 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > index b6ca628ee72fd..9878009385cc6 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > @@ -3,6 +3,7 @@
> >   /dts-v1/;
> >   
> >   #include "mt7981b.dtsi"
> > +#include "dt-bindings/pinctrl/mt65xx.h"
> >   
> >   / {
> >   	compatible = "openwrt,one", "mediatek,mt7981b";
> > @@ -54,6 +55,25 @@ mux {
> >   		};
> >   	};
> >   
> > +	spi2_flash_pins: spi2-pins {
> > +		mux {
> > +			function = "spi";
> > +			groups = "spi2";
> > +		};
> > +
> > +		conf-pu {
> > +			bias-pull-up = <MTK_PUPD_SET_R1R0_11>;
> > +			drive-strength = <MTK_DRIVE_8mA>;
> 
> drive-strength = <8>;
> 
> > +			pins = "SPI2_CS", "SPI2_WP";
> > +		};
> > +
> > +		conf-pd {
> > +			bias-pull-down = <MTK_PUPD_SET_R1R0_11>;
> > +			drive-strength = <MTK_DRIVE_8mA>;
> 
> ditto
> 
> > +			pins = "SPI2_CLK", "SPI2_MOSI", "SPI2_MISO";
> > +		};
> > +	};
> > +
> >   	uart0_pins: uart0-pins {
> >   		mux {
> >   			function = "uart";
> > @@ -62,6 +82,69 @@ mux {
> >   	};
> >   };
> >   
> > +&spi2 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&spi2_flash_pins>;
> > +	status = "okay";
> > +
> > +	flash@0 {
> > +		compatible = "jedec,spi-nor";
> > +		reg = <0>;
> > +		spi-max-frequency = <40000000>;
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +
> > +		partitions {
> > +			compatible = "fixed-partitions";
> > +			#address-cells = <1>;
> > +			#size-cells = <1>;
> > +
> > +			partition@0 {
> > +				reg = <0x00000 0x40000>;
> > +				label = "bl2-nor";
> > +			};
> > +
> > +			partition@40000 {
> > +				reg = <0x40000 0xc0000>;
> > +				label = "factory";
> > +				read-only;
> > +
> > +				nvmem-layout {
> > +					compatible = "fixed-layout";
> > +					#address-cells = <1>;
> > +					#size-cells = <1>;
> > +
> > +					eeprom_factory_0: eeprom@0 {
> 
> wifi_calibration:
> 
> > +						reg = <0x0 0x1000>;
> > +					};
> > +
> > +					macaddr_factory_4: macaddr@4 {
> 
> macaddr_factory_gmac1?
> 
> You're not using this in the later commit where you enable ethernet nodes,
> did you miss adding that to gmac1 or what is this used for?

gmac1 gets its mac from u-boot, passed in through device-tree; Haven't checked where u-boot gets it
from yet. I did spot it at offset 0x2a in this factory data, so that seems likely candidate.

However this particular mac is used by the wifi phy. I discovered after sending this patch the kernel
driver loads it directly from the "eeprom" area, so we could potentially drop this node. 

As mentioned in the commit message, I kept the same layouts as openwrt uses. Though i'd be fine to
minimize the nvmem cells just to what's referenced in the dtb.

> > +						reg = <0x4 0x6>;
> > +						compatible = "mac-base";
> > +						#nvmem-cell-cells = <1>;
> > +					};
> > +
> > +					macaddr_factory_24: macaddr@24 {
> 
> macaddr_factory_gmac0 ?


That seems nicer, will add that in V2 (same for the previous naming suggestion)



-- 
Sjoerd Simons
Collabora Ltd.

[PATCH 12/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet

[Sjoerd Simons]

Enable the Ethernet subsystem on OpenWrt One board with dual-MAC
configuration:
- GMAC0: Connected to external Airoha EN8811H 2.5GbE PHY via SGMII
  (2500base-x mode) for WAN connectivity with LED indicators
- GMAC1: Connected to internal MT7981 1GbE PHY (GMII mode) for LAN

Ethernet aliases are defined to provide consistent network interface
naming (ethernet0 = LAN, ethernet1 = WAN).

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 58 ++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
index 9878009385cc6..6e6e4f1515f67 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
@@ -3,6 +3,8 @@
 /dts-v1/;
 
 #include "mt7981b.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
 #include "dt-bindings/pinctrl/mt65xx.h"
 
 / {
@@ -10,6 +12,8 @@ / {
 	model = "OpenWrt One";
 
 	aliases {
+		ethernet0 = &gmac1;
+		ethernet1 = &gmac0;
 		serial0 = &uart0;
 	};
 
@@ -41,6 +45,56 @@ reg_5v: regulator-5v {
 	};
 };
 
+&eth {
+	status = "okay";
+
+	gmac0: mac@0 {
+		compatible = "mediatek,eth-mac";
+		reg = <0>;
+		nvmem-cells = <&macaddr_factory_24 0>;
+		nvmem-cell-names = "mac-address";
+		phy-mode = "2500base-x";
+		phy-handle = <&phy15>;
+	};
+
+	gmac1: mac@1 {
+		compatible = "mediatek,eth-mac";
+		reg = <1>;
+		phy-mode = "gmii";
+		phy-handle = <&int_gbe_phy>;
+	};
+};
+
+&mdio_bus {
+	phy15: ethernet-phy@f {
+		compatible = "ethernet-phy-id03a2.a411";
+		reg = <0xf>;
+		interrupt-parent = <&pio>;
+		interrupts = <38 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&pio 39 GPIO_ACTIVE_LOW>;
+		reset-assert-us = <10000>;
+		reset-deassert-us = <20000>;
+		airoha,pnswap-rx;
+
+		leds {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			led@0 {
+				reg = <0>;
+				function = LED_FUNCTION_WAN;
+				color = <LED_COLOR_ID_AMBER>;
+			};
+
+			led@1 {
+				reg = <1>;
+				function = LED_FUNCTION_WAN;
+				color = <LED_COLOR_ID_GREEN>;
+			};
+		};
+	};
+};
+
 &pcie {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pcie_pins>;
@@ -145,6 +199,10 @@ partition@180000 {
 	};
 };
 
+&sgmiisys0 {
+	mediatek,pnswap;
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins>;

-- 
2.51.0

Re: [PATCH 12/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet

[Andrew Lunn]

> +&mdio_bus {
> +	phy15: ethernet-phy@f {
> +		compatible = "ethernet-phy-id03a2.a411";
> +		reg = <0xf>;
> +		interrupt-parent = <&pio>;
> +		interrupts = <38 IRQ_TYPE_EDGE_FALLING>;

This is probably wrong. PHY interrupts are generally level, not edge.

	Andrew

Re: [PATCH 12/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet

[Sjoerd Simons]

On Fri, 2025-10-17 at 19:31 +0200, Andrew Lunn wrote:
> > +&mdio_bus {
> > +	phy15: ethernet-phy@f {
> > +		compatible = "ethernet-phy-id03a2.a411";
> > +		reg = <0xf>;
> > +		interrupt-parent = <&pio>;
> > +		interrupts = <38 IRQ_TYPE_EDGE_FALLING>;
> 
> This is probably wrong. PHY interrupts are generally level, not edge.

Sadly i can't find a datasheet for the PHY, so can't really validate that easily. Maybe Eric can
comment here as the author of the relevant PHY driver.

I'd note that the mt7986a-bananapi-bpi-r3-mini dts has the same setup for this PHY, however that's
ofcourse not authoritative.

-- 
Sjoerd Simons <sjoerd@collabora.com>

Re: [PATCH 12/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet

[Andrew Lunn]

On Tue, Oct 21, 2025 at 10:21:31PM +0200, Sjoerd Simons wrote:
> On Fri, 2025-10-17 at 19:31 +0200, Andrew Lunn wrote:
> > > +&mdio_bus {
> > > +	phy15: ethernet-phy@f {
> > > +		compatible = "ethernet-phy-id03a2.a411";
> > > +		reg = <0xf>;
> > > +		interrupt-parent = <&pio>;
> > > +		interrupts = <38 IRQ_TYPE_EDGE_FALLING>;
> > 
> > This is probably wrong. PHY interrupts are generally level, not edge.
> 
> Sadly i can't find a datasheet for the PHY, so can't really validate that easily.

What PHY is it? Look at the .handle_interrupt function in the
driver. If the hardware supports a single interrupt bit, it could in
theory support edge. However, as soon as you have multiple bits, you
need level, to avoid races where an interrupt happens while you are
clearing other interrupts.

	 Andrew

Re: [PATCH 12/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet

[Sjoerd Simons]

On Tue, 2025-10-21 at 22:40 +0200, Andrew Lunn wrote:
> On Tue, Oct 21, 2025 at 10:21:31PM +0200, Sjoerd Simons wrote:
> > On Fri, 2025-10-17 at 19:31 +0200, Andrew Lunn wrote:
> > > > +&mdio_bus {
> > > > +	phy15: ethernet-phy@f {
> > > > +		compatible = "ethernet-phy-id03a2.a411";
> > > > +		reg = <0xf>;
> > > > +		interrupt-parent = <&pio>;
> > > > +		interrupts = <38 IRQ_TYPE_EDGE_FALLING>;
> > > 
> > > This is probably wrong. PHY interrupts are generally level, not edge.
> > 
> > Sadly i can't find a datasheet for the PHY, so can't really validate that
> > easily.
> 
> What PHY is it? Look at the .handle_interrupt function in the
> driver. If the hardware supports a single interrupt bit, it could in
> theory support edge. However, as soon as you have multiple bits, you
> need level, to avoid races where an interrupt happens while you are
> clearing other interrupts.

ethernet-phy-id03a2.a411 is Airoha EN8811H (air_en8811h driver). Handle
interrupt there seems to just be a general interrupt clear followed by a
`phy_trigger_machine`. It doesn't seem to read specific interrupt status. 

Testing with IRQ_TYPE_LEVEL_LOW does seem to work as expected and results in
detecting 4 interrupts rather then just 1 with edges when enabling the
interface. However I'm not sure what can be concluded from that if anything :)..
 
I can stick a scope on the line in the coming days to see how the interrupt line
behaves if interrupts aren't cleared, which may clarify things.
 

-- 
Sjoerd Simons
Collabora

Re: [PATCH 12/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet

[Eric Woudstra]

On 10/21/25 10:21 PM, Sjoerd Simons wrote:
> On Fri, 2025-10-17 at 19:31 +0200, Andrew Lunn wrote:
>>> +&mdio_bus {
>>> +	phy15: ethernet-phy@f {
>>> +		compatible = "ethernet-phy-id03a2.a411";
>>> +		reg = <0xf>;
>>> +		interrupt-parent = <&pio>;
>>> +		interrupts = <38 IRQ_TYPE_EDGE_FALLING>;
>>
>> This is probably wrong. PHY interrupts are generally level, not edge.
> 
> Sadly i can't find a datasheet for the PHY, so can't really validate that easily. Maybe Eric can
> comment here as the author of the relevant PHY driver.
> 
> I'd note that the mt7986a-bananapi-bpi-r3-mini dts has the same setup for this PHY, however that's
> ofcourse not authoritative.
> 

Lucien would have access to the correct information about the interrupt.

Re: [PATCH 12/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet

[Sjoerd Simons]

On Tue, 2025-10-28 at 12:14 +0100, Eric Woudstra wrote:
> 
> 
> On 10/21/25 10:21 PM, Sjoerd Simons wrote:
> > On Fri, 2025-10-17 at 19:31 +0200, Andrew Lunn wrote:
> > > > +&mdio_bus {
> > > > +	phy15: ethernet-phy@f {
> > > > +		compatible = "ethernet-phy-id03a2.a411";
> > > > +		reg = <0xf>;
> > > > +		interrupt-parent = <&pio>;
> > > > +		interrupts = <38 IRQ_TYPE_EDGE_FALLING>;
> > > 
> > > This is probably wrong. PHY interrupts are generally level, not edge.
> > 
> > Sadly i can't find a datasheet for the PHY, so can't really validate that
> > easily. Maybe Eric can
> > comment here as the author of the relevant PHY driver.
> > 
> > I'd note that the mt7986a-bananapi-bpi-r3-mini dts has the same setup for
> > this PHY, however that's
> > ofcourse not authoritative.
> > 
> 
> Lucien would have access to the correct information about the interrupt.

Thanks! For what it's worth i got around to putting a scope on the line last
night. It looks like the interrupt line is pulled down until cleared, so it
appears it's indeed a Level interrupt as Andrew guessed. But would be great to
have this confirmed based on the documentation :)

-- 
Sjoerd Simons <sjoerd@collabora.com>
Collabora

Re: [PATCH 12/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable Ethernet

[Lucien.Jheng]

Hi

Sjoerd Simons 於 2025/10/28 下午 09:24 寫道:
> On Tue, 2025-10-28 at 12:14 +0100, Eric Woudstra wrote:
>>
>> On 10/21/25 10:21 PM, Sjoerd Simons wrote:
>>> On Fri, 2025-10-17 at 19:31 +0200, Andrew Lunn wrote:
>>>>> +&mdio_bus {
>>>>> +	phy15: ethernet-phy@f {
>>>>> +		compatible = "ethernet-phy-id03a2.a411";
>>>>> +		reg = <0xf>;
>>>>> +		interrupt-parent = <&pio>;
>>>>> +		interrupts = <38 IRQ_TYPE_EDGE_FALLING>;
>>>> This is probably wrong. PHY interrupts are generally level, not edge.
>>> Sadly i can't find a datasheet for the PHY, so can't really validate that
>>> easily. Maybe Eric can
>>> comment here as the author of the relevant PHY driver.
>>>
>>> I'd note that the mt7986a-bananapi-bpi-r3-mini dts has the same setup for
>>> this PHY, however that's
>>> ofcourse not authoritative.
>>>
>> Lucien would have access to the correct information about the interrupt.
> Thanks! For what it's worth i got around to putting a scope on the line last
> night. It looks like the interrupt line is pulled down until cleared, so it
> appears it's indeed a Level interrupt as Andrew guessed. But would be great to
> have this confirmed based on the documentation :)

The Airoha EN8811H Interrupt behavior is as follows:

When the line side link changes (up→ down or down → up), GPIO 8 will 
output low.

After you clear the interrupt, GPIO 8 will go high. Regarding the 
documentation, let me check where I can put it.

If you have any questions about the EN8811H, please feel free to discuss 
with me.

[PATCH 13/15] arm64: dts: mediatek: mt7981b: Add wifi memory region

[Sjoerd Simons]

Add required memory region for the builtin wifi block. Disable the block
by default as it won't function properly without at least pin muxing.

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
index c85fa0ddf2da8..fbccb63227e89 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
@@ -69,6 +69,11 @@ secmon_reserved: secmon@43000000 {
 			no-map;
 		};
 
+		wmcpu_emi: wmcpu-reserved@47c80000 {
+			reg = <0 0x47c80000 0 0x100000>;
+			no-map;
+		};
+
 		wo_emi0: wo-emi@47d80000 {
 			reg = <0 0x47d80000 0 0x40000>;
 			no-map;
@@ -494,6 +499,8 @@ wifi: wifi@18000000 {
 			clock-names = "mcu", "ap2conn";
 			resets = <&watchdog MT7986_TOPRGU_CONSYS_SW_RST>;
 			reset-names = "consys";
+			memory-region = <&wmcpu_emi>;
+			status = "disabled";
 		};
 	};
 

-- 
2.51.0

Re: [PATCH 13/15] arm64: dts: mediatek: mt7981b: Add wifi memory region

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Add required memory region for the builtin wifi block. Disable the block
> by default as it won't function properly without at least pin muxing.
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

You should split this commit in two:
  - Add wifi memory region
  - Disable wifi by default

Regarding the second commit, you have to re-enable the wifi node in all of
the currently supported MT7981b devices, including:
  - Xiaomi AX3000T
  - Cudy WR3000 V1

While I agree that without pin muxing the wifi may not properly work, it is
unclear whether the aforementioned devices are pre-setting the pinmux in the
bootloader before booting Linux.

In case those do, you'd be "breaking" WiFi on two routers here.

Cheers,
Angelo

[PATCH 14/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable wifi

[Sjoerd Simons]

Enable Dual-band WiFI 6 functionality on the Openwrt One

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
index 6e6e4f1515f67..4d1653c336e71 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
@@ -134,6 +134,22 @@ mux {
 			groups = "uart0";
 		};
 	};
+
+	wifi_dbdc_pins: wifi-dbdc-pins {
+		mux {
+			function = "eth";
+			groups = "wf0_mode1";
+		};
+
+		conf {
+			pins = "WF_HB1", "WF_HB2", "WF_HB3", "WF_HB4",
+			       "WF_HB0", "WF_HB0_B", "WF_HB5", "WF_HB6",
+			       "WF_HB7", "WF_HB8", "WF_HB9", "WF_HB10",
+			       "WF_TOP_CLK", "WF_TOP_DATA", "WF_XO_REQ",
+			       "WF_CBA_RESETB", "WF_DIG_RESETB";
+			drive-strength = <MTK_DRIVE_4mA>;
+		};
+	};
 };
 
 &spi2 {
@@ -213,6 +229,14 @@ &usb_phy {
 	status = "okay";
 };
 
+&wifi {
+	nvmem-cells = <&eeprom_factory_0>;
+	nvmem-cell-names = "eeprom";
+	pinctrl-names = "dbdc";
+	pinctrl-0 = <&wifi_dbdc_pins>;
+	status = "okay";
+};
+
 &xhci {
 	phys = <&u2port0 PHY_TYPE_USB2>;
 	vusb33-supply = <&reg_3p3v>;

-- 
2.51.0

Re: [PATCH 14/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable wifi

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> Enable Dual-band WiFI 6 functionality on the Openwrt One
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

[PATCH 15/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable leds

[Sjoerd Simons]

The Openwrt One has 3 status leds at the front (red, white, green) as
well as 2 software controlled leds for the LAN jack (amber, green).

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
---
 .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 57 ++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
index 4d1653c336e71..0c0878488ae98 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
@@ -43,6 +43,50 @@ reg_5v: regulator-5v {
 		regulator-boot-on;
 		regulator-always-on;
 	};
+
+	pwm-leds {
+		compatible = "pwm-leds";
+
+		led-0 {
+			color = <LED_COLOR_ID_WHITE>;
+			default-brightness = <0>;
+			function = LED_FUNCTION_STATUS;
+			max-brightness = <255>;
+			pwms = <&pwm 0 10000>;
+		};
+
+		led-1 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-brightness = <0>;
+			function = LED_FUNCTION_STATUS;
+			max-brightness = <255>;
+			pwms = <&pwm 1 10000>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&pio 9 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-1 {
+			color = <LED_COLOR_ID_AMBER>;
+			function = LED_FUNCTION_LAN;
+			gpios = <&pio 34 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "netdev";
+		};
+
+		led-2 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_LAN;
+			gpios = <&pio 35 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "netdev";
+		};
+	};
 };
 
 &eth {
@@ -109,6 +153,13 @@ mux {
 		};
 	};
 
+	pwm_pins: pwm-pins {
+		mux {
+			function = "pwm";
+			groups = "pwm0_0", "pwm1_1";
+		};
+	};
+
 	spi2_flash_pins: spi2-pins {
 		mux {
 			function = "spi";
@@ -152,6 +203,12 @@ conf {
 	};
 };
 
+&pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm_pins>;
+	status = "okay";
+};
+
 &spi2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&spi2_flash_pins>;

-- 
2.51.0

Re: [PATCH 15/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable leds

[AngeloGioacchino Del Regno]

Il 16/10/25 12:08, Sjoerd Simons ha scritto:
> The Openwrt One has 3 status leds at the front (red, white, green) as
> well as 2 software controlled leds for the LAN jack (amber, green).
> 
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> ---
>   .../boot/dts/mediatek/mt7981b-openwrt-one.dts      | 57 ++++++++++++++++++++++
>   1 file changed, 57 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> index 4d1653c336e71..0c0878488ae98 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> @@ -43,6 +43,50 @@ reg_5v: regulator-5v {
>   		regulator-boot-on;
>   		regulator-always-on;
>   	};
> +
> +	pwm-leds {

Please keep the nodes ordered by name.

Cheers,
Angelo

> +		compatible = "pwm-leds";
> +
> +		led-0 {
> +			color = <LED_COLOR_ID_WHITE>;
> +			default-brightness = <0>;
> +			function = LED_FUNCTION_STATUS;
> +			max-brightness = <255>;
> +			pwms = <&pwm 0 10000>;
> +		};
> +
> +		led-1 {
> +			color = <LED_COLOR_ID_GREEN>;
> +			default-brightness = <0>;
> +			function = LED_FUNCTION_STATUS;
> +			max-brightness = <255>;
> +			pwms = <&pwm 1 10000>;
> +		};
> +	};
> +
> +	gpio-leds {
> +		compatible = "gpio-leds";
> +
> +		led-0 {
> +			color = <LED_COLOR_ID_RED>;
> +			function = LED_FUNCTION_STATUS;
> +			gpios = <&pio 9 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		led-1 {
> +			color = <LED_COLOR_ID_AMBER>;
> +			function = LED_FUNCTION_LAN;
> +			gpios = <&pio 34 GPIO_ACTIVE_LOW>;
> +			linux,default-trigger = "netdev";
> +		};
> +
> +		led-2 {
> +			color = <LED_COLOR_ID_GREEN>;
> +			function = LED_FUNCTION_LAN;
> +			gpios = <&pio 35 GPIO_ACTIVE_LOW>;
> +			linux,default-trigger = "netdev";
> +		};
> +	};
>   };
>   
>   &eth {
> @@ -109,6 +153,13 @@ mux {
>   		};
>   	};
>   
> +	pwm_pins: pwm-pins {
> +		mux {
> +			function = "pwm";
> +			groups = "pwm0_0", "pwm1_1";
> +		};
> +	};
> +
>   	spi2_flash_pins: spi2-pins {
>   		mux {
>   			function = "spi";
> @@ -152,6 +203,12 @@ conf {
>   	};
>   };
>   
> +&pwm {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pwm_pins>;
> +	status = "okay";
> +};
> +
>   &spi2 {
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&spi2_flash_pins>;
> 

Re: [PATCH 15/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable leds

[Andrew Lunn]

On Thu, Oct 16, 2025 at 12:08:51PM +0200, Sjoerd Simons wrote:
> The Openwrt One has 3 status leds at the front (red, white, green) as
> well as 2 software controlled leds for the LAN jack (amber, green).

A previous patch in this series added 2 PHY LEDs. Are they connected
to a LAN jack? Are there multiple RJ45 connectors? Is it clear from
/sys/class/leds what LED is what?

	Andrew

Re: [PATCH 15/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable leds

[Sjoerd Simons]

Hey,

On Fri, 2025-10-17 at 19:35 +0200, Andrew Lunn wrote:
> On Thu, Oct 16, 2025 at 12:08:51PM +0200, Sjoerd Simons wrote:
> > The Openwrt One has 3 status leds at the front (red, white, green) as
> > well as 2 software controlled leds for the LAN jack (amber, green).
> 
> A previous patch in this series added 2 PHY LEDs. Are they connected
> to a LAN jack? Are there multiple RJ45 connectors? Is it clear from
> /sys/class/leds what LED is what?

Yeah there are two RJ45 jacks. One referred to as WAN in the openwrt one
documentation (2.5G), which uses phy integrated leds. One referred to as LAN,
which for some reason is using software controlled leds rather then the phy's
led controller, which this patch adds support for.

When applying this set you'll get:
```
root@openwrt-debian:/sys/class/leds# ls -1                                     
amber:lan                                                                      
green:lan                                                                      
green:status                                                                   
mdio-bus:0f:amber:wan                                                          
mdio-bus:0f:green:wan                                                          
mt76-phy0                                                                      
mt76-phy1                                                                      
red:status                                                                     
white:status                       
```

Which is hopefully clear enough



-- 
Sjoerd Simons <sjoerd@collabora.com>
Collabora

Re: [PATCH 15/15] arm64: dts: mediatek: mt7981b-openwrt-one: Enable leds

[Andrew Lunn]

On Wed, Oct 22, 2025 at 09:26:11AM +0200, Sjoerd Simons wrote:
> Hey,
> 
> On Fri, 2025-10-17 at 19:35 +0200, Andrew Lunn wrote:
> > On Thu, Oct 16, 2025 at 12:08:51PM +0200, Sjoerd Simons wrote:
> > > The Openwrt One has 3 status leds at the front (red, white, green) as
> > > well as 2 software controlled leds for the LAN jack (amber, green).
> > 
> > A previous patch in this series added 2 PHY LEDs. Are they connected
> > to a LAN jack? Are there multiple RJ45 connectors? Is it clear from
> > /sys/class/leds what LED is what?
> 
> Yeah there are two RJ45 jacks. One referred to as WAN in the openwrt one
> documentation (2.5G), which uses phy integrated leds. One referred to as LAN,
> which for some reason is using software controlled leds rather then the phy's
> led controller, which this patch adds support for.
> 
> When applying this set you'll get:
> ```
> root@openwrt-debian:/sys/class/leds# ls -1                                     
> amber:lan                                                                      
> green:lan                                                                      
> green:status                                                                   
> mdio-bus:0f:amber:wan                                                          
> mdio-bus:0f:green:wan                                                          
> mt76-phy0                                                                      
> mt76-phy1                                                                      
> red:status                                                                     
> white:status                       
> ```
> 
> Which is hopefully clear enough

You can also get to the LEDs associated to a MAC via
/sys/class/net/eth42/leds, or a subdirectory.

Please could you expand the commit message with more details of the
different RJ45 connectors, and how the different LEDs map to them.

Thanks

	Andrew