Re: [PATCH v5 2/7] arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on NanoPC-T6

On Fri Sep 11, 2026 at 2:19 PM CEST, Ricardo Pardini wrote:

On 11/09/2026 11:52, Diederik de Haas wrote:

quoted

On Thu Sep 10, 2026 at 10:07 PM CEST, Ricardo Pardini via B4 Relay wrote:

quoted

From: Ricardo Pardini <redacted>

The FriendlyElec NanoPC-T6 carries two on-board Realtek RTL8125 NICs
behind pcie2x1l0 and pcie2x1l2.

Forgot to mention: thanks for this series :-)

quoted

quoted

Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can fill in the MAC
from its ethaddr/eth1addr env. The on-NIC EEPROMs on this board are
not pre-programmed with a unique MAC, so this gives a stable MAC
across boots that both U-Boot and the kernel agree on.

Signed-off-by: Ricardo Pardini <redacted>
---
  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 cfdb5c13f8606..550358a756618 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;
  	};

@@ -644,6 +646,20 @@ &pcie2x1l0 {
  	pinctrl-names = "default";
  	pinctrl-0 = <&pcie2_0_rst>;

The new pinctrl reference is ``pcie_25glan_perstb_b_pin``, so this patch needs
to be rebased.

Indeed; I sent v5 vs v7.3-rc2 which doesn't have your recent series 
fixing those. I've rebased onto next-20260910 which does, will send in a 
v6 - but it's really just fuzz/context changes.

I'll wait a bit until Heiner/Krysztof/Heiko chime in ref the binding and 
its wording as that has been contentious in the previous versions. And 
who knows what Sashiko will find this time.

Agreed, their feedback is more important.

quoted

quoted

  	status = "okay";
+
+	pcie@0,0 {
+		reg = <0x200000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		ranges;
+		device_type = "pci";
+		bus-range = <0x21 0x2f>;
+
+		rtl_eth0: ethernet@0,0 {
+			compatible = "pci10ec,8125";
+			reg = <0x210000 0 0 0 0>;
+		};

Described on page 23 of the schematic titled '2.5G Ethernet B' and ``U12``
(ie RTL8125BG) is connected to LAN2 which has ``ETH2`` as label on the case.

Confirmed.

quoted

quoted

+	};
  };
  
  &pcie2x1l1 {

@@ -660,6 +676,20 @@ &pcie2x1l2 {
  	pinctrl-names = "default";
  	pinctrl-0 = <&pcie2_2_rst>;

The new pinctrl reference is ``pcie_25glan_perstb_pin``.

Will also be fixed by rebasing onto linux-next.

quoted

quoted

  	status = "okay";
+
+	pcie@0,0 {
+		reg = <0x400000 0 0 0 0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		ranges;
+		device_type = "pci";
+		bus-range = <0x41 0x4f>;
+
+		rtl_eth1: ethernet@0,0 {
+			compatible = "pci10ec,8125";
+			reg = <0x410000 0 0 0 0>;
+		};

Described on page 22 of the schematic titled '2.5G Ethernet A' and ``U10``
(ie RTL8125BG) is connected to LAN1 which has ``ETH1`` as label on the case.

So this results in:
ETH1 -> rtl_eth1
ETH2 -> rtl_eth0

This sounds like a recipe for confusion and/or potential future mistakes.
I think using ``rtl_eth1`` and ``rtl_eth2`` would be less confusing, but
I'm fine with another construct which achieves a similar thing.

Yeah, that will result in aliases `ethernet0 = &rtl_eth1;` and 
`ethernet1 = &rtl_eth2;`. It could also be `rtl_lan1`/`rtl_lan2`, or as 
the schematics seems to to use the `_b` suffix, just `rtl_lan` and 
`rtl_lan_b`, I don't mind. Raise if you do, otherwise I'll send v6 as 
you suggested.

I'm not a fan of the `_b` suffix (also not in the schematic; without an
`_a` suffix). Do the aliases have to be 0-based? If not, then `ethernet1`
and `ethernet2` would be my preferred solution. If it needs to be 0-based
then the off-by-one 'confusion' seems like the best solution.

Userspace will be off-by-one vs the printed case labels, thus _some_ 
confusion will remain, but it's already better than the current 
enP2p33s0/enP4p65s0.

Indeed :-)
I triple checked whether my findings were correct before responding.

Thanks to your series, I had a look at NanoPi R5S and found a few issues.
There it's even worse:
PCB/schematic: LAN1=GbE and 'WAN' on the case; LAN2=2.5GbE and LAN1 on the
case; LAN3=2.5GbE and LAN2 on the case. 
And those result in `end0`, `enp1s0` and `enP1p17s0` respectively :-P

Cheers,
  Diederik