Hi Niklas,

On Mon, 2 Feb 2026 at 15:25, Niklas Cassel [off-list ref] wrote:

On Sat, Jan 31, 2026 at 03:08:42PM +0530, Anand Moon wrote:

quoted

quoted

I’ve attempted to reproduce the warning but was unable to trigger it locally.

I have tested with the built-in module
CONFIG_R8169=y
CONFIG_R8169_LEDS=y

As well as the module
CONFIG_R8169=m
CONFIG_R8169_LEDS=y

I'm running with:
CONFIG_R8169=y
CONFIG_PHYLIB=y
CONFIG_REALTEK_PHY=y
CONFIG_REALTEK_PHY_HWMON=y

I feel CONFIG_R8169 should not be built into the kernel image.
Since the driver is registered via module_pci_driver(rtl8169_pci_driver),
it is intended to be loaded as a module. In addition, this driver
requires external firmware
during initialization, which could make a built‑in configuration problematic.
Keeping it modular ensures proper firmware loading and avoids
early‑boot failures.

CONFIG_PCIE_ROCKCHIP_DW=y
CONFIG_PCIE_ROCKCHIP_DW_HOST=y
CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY=y
(PHY for the PCIe 2x)

$ cat /proc/cmdline
root=/dev/nfs nfsroot=192.168.1.10:/srv/nfs/rootfs_rc,nfsvers=4 ip=dhcp earlycon rootwait loglevel=8

Considering that all PHY drivers (for both Ethernet and PCIe),
and drivers (for both Ethernet and PCIe) are built as built-in,
having nfsroot= on the kernel command line should be no issue.

But, perhaps that is the reason why you cannot reproduce it?

Thanks for sharing your setup.

quoted

quoted

Having async probing for the Rockchip PCIe controller driver, which is
used a LOT of rockchip based SoCs, is a good thing, so I don't think it
is right to avoid enabling async probing just because it results in a
splat on a single rockchip based board (rock5b).

Yes, this could help in the module probe pci module.

Earlier, I thought gmac will control the r8169 module, but I was wrong.
Could you please try these changes at your end? These changes are
related to MIMO..

$ git diff ./arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi

b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
index b3e76ad2d869..fb3a8ba4085a 100644

--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi

@@ -477,7 +477,6 @@ &pcie2x1l0 {
 &pcie2x1l2 {
        pinctrl-names = "default";
        pinctrl-0 = <&pcie2_2_rst>;
-       reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
        vpcie3v3-supply = <&vcc3v3_pcie2x1l2>;
        status = "okay";
 };

@@ -535,6 +534,12 @@ pcie3_vcc3v3_en: pcie3-vcc3v3-en {
                };
        };

+       rtl8211f {
+               rtl8211f_0_rst: rtl8211f-0-rst {
+                       rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+               };
+       };
+
        usb {
                usbc0_int: usbc0-int {
                        rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;

@@ -550,6 +555,19 @@ &pwm1 {
        status = "okay";
 };

+&mdio0 {
+       rgmii_phy0: ethernet-phy@1 {
+               /* RTL8211F */
+               compatible = "ethernet-phy-id001c.c916";
+               reg = <0x1>;
+               pinctrl-names = "default";
+               pinctrl-0 = <&rtl8211f_0_rst>;
+               reset-assert-us = <20000>;
+               reset-deassert-us = <100000>;
+               reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>;
+       };
+};
+
 &rknn_core_0 {
        npu-supply = <&vdd_npu_s0>;
        sram-supply = <&vdd_npu_s0>;

I tried your patch above, but I still see the splat.

But as I said, I don't think the splat should be a showstopper.

Thanks for clarifying this issue. I will resubmit once I have
conducted further testing.

Kind regards,
Niklas

Thanks
-Anand