[PATCH v2 0/2] describe PCIe ethernet interfaces and alias ethernet0/1 on NanoPC-T6

[PATCH v2 0/2] describe PCIe ethernet interfaces and alias ethernet0/1 on NanoPC-T6

[Ricardo Pardini via B4 Relay]

This describes the two on-board Realtek RTL8125BG PCIe Ethernet
controllers on the FriendlyElec NanoPC-T6 (RK3588) board and aliases
them to ethernet0/ethernet1.

Many Rockchip boards have on-board RTL8125 PCIe NICs, wired to
pcie2x1l0 and pcie2x1l2. The controllers were already enabled in the
board DT, but the Ethernet function nodes themselves are not
described, so the kernel (and u-boot) has no DT handle on the NICs.

Adding the function nodes lets us:
- expose stable ethernet0/ethernet1 aliases for the two NICs, the
  same way other rk3588 boards alias their GMAC interfaces; and
- let U-Boot's fdt_fixup_ethernet() patch mac-address properties in
  at boot time from its ethaddr/eth1addr environment - useful on
  boards (like this one) whose on-NIC EEPROM is not pre-programmed
  with a unique MAC. The kernel and U-Boot then agree on the MAC,
  which matters for network-boot setups.

Checkpatch warnings:
-  WARNING: DT compatible string "pci10ec,8125" appears un-documented
-  WARNING: DT compatible string vendor "pci10ec" appears un-documented
Both are expected. "pciVVVV,DDDD" is the Open Firmware PCI Bus
Binding spelling, where VVVV/DDDD are the PCI vendor and device IDs
allocated by the PCI-SIG (10ec = Realtek, 8125 = RTL8125). It is not a
DT vendor prefix.

If this is seen as a good thing, it would apply very similarly to
the Radxa Rock 5 series and others.

While at it, rename regulator vcc3v3_pcie2x1l0 to l1, since that is
what is actually powers; since only cosmetic, I did not include
a Fixes tag.

---
Changes in v2:
- fix: pcie2x1l0, not pcie2x1l1; indirectly caught by Sashiko's review [1]
- while-at-it: rename regulator vcc3v3_pcie2x1l0 to l1
- Link to v1: https://patch.msgid.link/20260525-rk3588-dts-rtl-eth-describe-dt-alias-v1-1-a6fcda563ac7@pardini.net

[1] https://sashiko.dev/#/patchset/20260525-rk3588-dts-rtl-eth-describe-dt-alias-v1-1-a6fcda563ac7%40pardini.net

To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Heiko Stuebner <heiko@sntech.de>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>

---
Ricardo Pardini (2):
      arm64: dts: rockchip: describe PCIe Ethernet controllers on NanoPC-T6
      arm64: dts: rockchip: fix PCIe regulator name on NanoPC-T6

 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 36 ++++++++++++++++++++--
 1 file changed, 33 insertions(+), 3 deletions(-)
---
base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
change-id: 20260524-rk3588-dts-rtl-eth-describe-dt-alias-c1ed187b7c50

Best regards,
--  
Ricardo Pardini <ricardo@pardini.net>

[PATCH v2 1/2] arm64: dts: rockchip: describe PCIe Ethernet controllers on NanoPC-T6

[Ricardo Pardini via B4 Relay]

From: Ricardo Pardini <ricardo@pardini.net>

The FriendlyElec NanoPC-T6 carries two on-board Realtek RTL8125BG
(r8169 family, PCI 10ec:8125) NICs, each behind its own RK3588 PCIe2x1
controller (pcie2x1l0 and pcie2x1l2). Both host bridges were already
enabled by the board DT, but the Ethernet function nodes themselves
were not described, leaving the kernel without DT handles on the two
NICs.

Describe the fixed PCI function nodes and attach ethernet0/ethernet1
aliases to them.

Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 ++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
index 84b6b53f016ab..04c4479f08170 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
@@ -20,6 +20,8 @@ / {
 	compatible = "friendlyarm,nanopc-t6", "rockchip,rk3588";
 
 	aliases {
+		ethernet0 = &rtl_eth0;
+		ethernet1 = &rtl_eth1;
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 	};
@@ -635,6 +637,20 @@ &pcie2x1l0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pcie2_0_rst>;
 	status = "okay";
+
+	pcie@0,0 {
+		reg = <0x200000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		ranges;
+		device_type = "pci";
+		bus-range = <0x20 0x2f>;
+
+		rtl_eth0: ethernet@0,0 {
+			compatible = "pci10ec,8125";
+			reg = <0x210000 0 0 0 0>;
+		};
+	};
 };
 
 &pcie2x1l1 {
@@ -651,6 +667,20 @@ &pcie2x1l2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pcie2_2_rst>;
 	status = "okay";
+
+	pcie@0,0 {
+		reg = <0x400000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		ranges;
+		device_type = "pci";
+		bus-range = <0x40 0x4f>;
+
+		rtl_eth1: ethernet@0,0 {
+			compatible = "pci10ec,8125";
+			reg = <0x410000 0 0 0 0>;
+		};
+	};
 };
 
 &pcie30phy {

-- 
2.54.0

[PATCH v2 2/2] arm64: dts: rockchip: fix PCIe regulator name on NanoPC-T6

[Ricardo Pardini via B4 Relay]

From: Ricardo Pardini <ricardo@pardini.net>

The GPIO-switched 3v3 regulator on the NanoPC-T6 is labeled
vcc3v3_pcie2x1l0, but it is wired to and consumed by &pcie2x1l1, and
its enable is the pcie_m2_1_pwren pin - i.e. it powers the M.2 slot on
pcie2x1l1, not pcie2x1l0. The two soldered RTL8125 NICs on pcie2x1l0
and pcie2x1l2 instead share the always-on vcc_3v3_pcie20 rail, so
nothing actually uses an "l0" switched supply.

Rename the label, node name and regulator-name to vcc3v3_pcie2x1l1 so
they match the controller the rail actually supplies.

Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
index 04c4479f08170..7d314df3f947b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
@@ -203,13 +203,13 @@ vbus5v0_usb: regulator-vbus5v0-usb {
 		vin-supply = <&vcc5v0_sys>;
 	};
 
-	vcc3v3_pcie2x1l0: regulator-vcc3v3-pcie2x1l0 {
+	vcc3v3_pcie2x1l1: regulator-vcc3v3-pcie2x1l1 {
 		compatible = "regulator-fixed";
 		enable-active-high;
 		gpio = <&gpio4 RK_PC2 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&pcie_m2_1_pwren>;
-		regulator-name = "vcc3v3_pcie2x1l0";
+		regulator-name = "vcc3v3_pcie2x1l1";
 		regulator-min-microvolt = <3300000>;
 		regulator-max-microvolt = <3300000>;
 		vin-supply = <&vcc5v0_sys>;
@@ -655,7 +655,7 @@ rtl_eth0: ethernet@0,0 {
 
 &pcie2x1l1 {
 	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
-	vpcie3v3-supply = <&vcc3v3_pcie2x1l0>;
+	vpcie3v3-supply = <&vcc3v3_pcie2x1l1>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pcie2_1_rst>;
 	status = "okay";

-- 
2.54.0

Re: [PATCH v2 1/2] arm64: dts: rockchip: describe PCIe Ethernet controllers on NanoPC-T6

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Hardcoded and incorrectly bounded PCI bus numbers in device tree for dynamically enumerable PCI devices.
--

commit 79c9b71b546cb8ecf96eb0ea66c76b17346368b3
Author: Ricardo Pardini <ricardo@pardini.net>

arm64: dts: rockchip: describe PCIe Ethernet controllers on NanoPC-T6

This commit adds device tree nodes describing the two on-board Realtek
RTL8125BG NICs on the NanoPC-T6. It attaches ethernet0 and ethernet1
aliases to these fixed PCI function nodes.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> index 84b6b53f016ab..04c4479f08170 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
[ ... ]
> @@ -635,6 +637,20 @@ &pcie2x1l0 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pcie2_0_rst>;
>  	status = "okay";
> +
> +	pcie@0,0 {
> +		reg = <0x200000 0 0 0 0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +		ranges;
> +		device_type = "pci";
> +		bus-range = <0x20 0x2f>;

[Severity: Medium]
Is this bus-range declaration correct for a bridge?

The first value of a bridge's bus-range is its secondary bus. If the Root
Port is on primary bus 0x20 (as defined by the host bridge), setting the
secondary bus to 0x20 sets it equal to the primary bus, which violates PCI
topology rules. Furthermore, the child device is declared below on bus
0x21, which contradicts this declaration.

> +
> +		rtl_eth0: ethernet@0,0 {
> +			compatible = "pci10ec,8125";
> +			reg = <0x210000 0 0 0 0>;

[Severity: Medium]
Does this hardcode a dynamic PCI bus number?

Using a specific bus number like 0x210000 instead of a relative address like
<0 0 0 0 0> can cause problems with strict parsers or bootloaders (such as
U-Boot) that perform dynamic enumeration. They might fail to match the nodes,
which could prevent device tree aliases from resolving correctly and break
MAC address injection.

> +		};
> +	};
>  };
>  
[ ... ]
> @@ -651,6 +667,20 @@ &pcie2x1l2 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pcie2_2_rst>;
>  	status = "okay";
> +
> +	pcie@0,0 {
> +		reg = <0x400000 0 0 0 0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +		ranges;
> +		device_type = "pci";
> +		bus-range = <0x40 0x4f>;

[Severity: Medium]
Is this bus-range declaration correct for a bridge?

The first value of a bridge's bus-range is its secondary bus. If the Root
Port is on primary bus 0x40 (as defined by the host bridge), setting the
secondary bus to 0x40 sets it equal to the primary bus, which violates PCI
topology rules. Furthermore, the child device is declared below on bus
0x41, which contradicts this declaration.

> +
> +		rtl_eth1: ethernet@0,0 {
> +			compatible = "pci10ec,8125";
> +			reg = <0x410000 0 0 0 0>;

[Severity: Medium]
Does this hardcode a dynamic PCI bus number?

Using a specific bus number like 0x410000 instead of a relative address like
<0 0 0 0 0> can cause problems with strict parsers or bootloaders (such as
U-Boot) that perform dynamic enumeration. They might fail to match the nodes,
which could prevent device tree aliases from resolving correctly and break
MAC address injection.

> +		};
> +	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529-rk3588-dts-rtl-eth-describe-dt-alias-v2-0-49700248143f@pardini.net?part=1