Message-ID: <CANAwSgTQ-cdyzd2WjHMYCY33p7um3CpjMeTzRO7vcd0fTF6X9Q@mail.gmail.com>
Date: Sat, 31 Jan 2026 15:08:42 +0530
From: Anand Moon <linux.amoon@...il.com>
To: Niklas Cassel <cassel@...nel.org>
Cc: Grimmauld <grimmauld@...mmauld.de>, 
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, 
	Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof Wilczyński <kw@...ux.com>, 
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Heiko Stuebner <heiko@...ech.de>, 
	linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] PCI: dw-rockchip: Enable async probe by default

Hi Niklas/ Grimmauld,

On Fri, 30 Jan 2026 at 15:55, Niklas Cassel <cassel@...nel.org> wrote:
>
> Hello Grimmauld,
>
> On Thu, Jan 29, 2026 at 03:06:59PM +0100, Grimmauld wrote:
> > Hello Anand,
> >
> > I have tested this patch.
> > Hardware/Kernel information:
> > - radxa rock 5c lite
> > - rk3588s CPU, arm64
> > - defconfig NixOS kernel
> > - picked onto 6.18.7
> > - DT: rockchip/rk3588s-rock-5c.dtb
> > - tested both uboot (mainline) and edk2 (vendor)
> >
> > On Fri, Aug 09, 2024 at 01:06:09PM +0530, Anand Moon wrote:
> > > Rockchip DWC PCIe driver currently waits for the combo PHY link
> > > (PCIe 3.0, PCIe 2.0, and SATA 3.0) to be established link training
> > > during boot, it also waits for the link to be up, which could consume
> > > several milliseconds during boot.
> >
> > I found that without this patch, USB 3 ports as well as the PCIe connector seemingly stay uninitialized during boot on my hardware.
> > This manifests in a bootable USB flash drive loading initrd from bootloader (both uboot and edk2) perfectly, but then fails to mount the rootfs from the drive.
> > In effect, boot is not just slower than it should be, it just does not boot all the way at all.
> > In that scenario, the devfs entries corresponding to the flash drive are simply missing, same for the sysfs where i would expect the USB device listed.
> > Replugging the USB flash drive during initrd does seem to fix that, but is tedious and not viable for a server.
> > Similarly, booting from m.2 SSD attached via PCIe fails the same way, with rootfs timing out despite the bootloader correctly reading initrd on the same drive.
> > Fwiw, replugging the SSD does not work like it does for USB flash drives, and is even worse of an idea.
> > USB 2 ports as well as SD card boots correctly, even without your patch.
> > Without your patch, i am seeing "deferred probe pending" in dmesg before boot gets stuck, which was the hint which made me find your patch.
> > I am not sure whether that is the actual cause or just a symptom for why drives are not recognized during boot, and am not quite sure how to debug this further.
> >
> > > To optimize boot time, this commit allows asynchronous probing.
> > > This change enables the PCIe link establishment to occur in the
> > > background while other devices are being probed.
> >
> > With this patch, booting from SSD or USB 3 port works flawlessly, and i have not seen any regressions with SD card or USB 2 boot, nor any other hardware component.
> > This setup has worked for multiple boots without fail, both with traditional ext4 and zfs rootfs being loaded from USB 3 and PCIe.
> > Because i require this patch to run my rock 5c from SSD, i am currently running a custom patched kernel, but would highly appreciate this patch making its way to mainline eventually.
> > There might well be something else going on here. The proposed patch may not be the "proper" fix to the issues i am seeing, but it does at least work.
> >
> > I have NOT tested boot from eMMC (either with or without this patch), though i have no reason to believe it would be impacted.
> >
> > I am happy to provide more info as needed. First time posting to the LKML, i hope i am doing this right...
> >
> > Tested-by: Grimmauld <grimmauld@...mmauld.de>
Thanks for testing this patch.
>
> I tested this patch again on the latest kernel, and it still results in
> the "requesting loading a module with wait allowed while being called from
> async context can result in a deadlock" warning from the modules code.
> (With the calling code being phylib.)
> See the phylib splat that I previously reported in this thread.
>
I’ve attempted to reproduce the warning but was unable to trigger it locally.

> Note that I've built the network PHY driver that phylib wants to load
> (CONFIG_REALTEK_PHY=y) as built-in. As long as the PHY driver is built
> as built-in, I don't think that the problem the modules code is warning
> about can happen. (But I also don't understand why it is trying to load
> a module when the driver is built as built-in in the first place...)
>
But both CONFIG_PHYLIB and CONFIG_REALTEK_PHY are selected as buildin
for R8169 module.

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

> Anyway, my networking is working perfectly fine even with the splat.
>
>
> 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>;

>
> Kind regards,
> Niklas

Thanks
-Anand

Powered by blists - more mailing lists