linux-kernel - Re: [PATCH v2] PCI: dw-rockchip: Enable async probe by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANAwSgSR7AYCvMXSo5UskTF3LJToOnPV9JE4XBAUzrCbWGKD_w@mail.gmail.com>
Date: Mon, 2 Feb 2026 23:35:48 +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,

On Mon, 2 Feb 2026 at 15:25, Niklas Cassel <cassel@...nel.org> wrote:
>
> On Sat, Jan 31, 2026 at 03:08:42PM +0530, Anand Moon wrote:
> > >
> > 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.
>
>
> > >
> > > 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