[ +driver-core maintainers - async probe question below ]

On 2026-03-10 3:30 pm, Manivannan Sadhasivam wrote:

Hi Robin,

On Tue, Mar 10, 2026 at 01:41:56PM +0000, Robin Murphy wrote:

quoted

Hi Mani,

On 2026-03-04 6:48 am, Manivannan Sadhasivam wrote:

quoted

On Thu, 26 Feb 2026 15:40:23 +0530, Anand Moon wrote:

quoted

Rockchip DWC PCIe driver currently performs synchronous link training for
combo PHYs (PCIe 3.0/2.0 and SATA 3.0) during boot. This process waits for
the link to be fully established, adding several milliseconds to the boot
sequence. To optimize boot time, this change enables asynchronous probing,
allowing link establishment to proceed in the background while the kernel
continues probing other devices.

[...]

Applied, thanks!

[1/1] PCI: dw-rockchip: Enable async probe by default
        commit: ec392abc95932838bf7e3d659d358f4df9ff5a0a

This appears to have the side-effect that calling pci_host_probe() from
async context can effectively force async probe for the endpoint drivers
as well, but some drivers are not OK with that, as our CI has just
flagged up.

Thanks for reporting!

quoted

(And as for that particular warning, ISTR last time I looked into it
another context, the opinion of the MDIO/phy maintainers seemed to be
"don't force async probe".)

This was discussed during v2 [1] and concluded that the async probe benefits
outweigh the unharmful splat from phylib. I also agree with the above conclusion
that this splat should not prevent us from enabling async probe for PCI
controller drivers. It can easily save a few 100ms during boot.

The problem is not an "unharmful splat" from one driver on one board - 
that's *a* symptom, and the fact that it happens to be a relatively 
benign one does not dismiss the problem that forcing async probe upon 
drivers that are not designed to support async probe cannot in general 
be assumed to be safe, so is not OK. It's one thing if a user brings it 
upon themselves by explicitly using the "driver_async_probe=" option, 
but it's very different if some other driver starts doing it for them.

Looking closer, it seems like the fundamental issue might be when we've 
got this far (simplified for clarity):

- async_run_entry_fn
   - rockchip_pcie_probe
     - pci_host_probe
      - pci_bus_add_device
        - device_initial_probe
          - __device_attach_driver

wherein we then reach the "if (data->check_async && async_allowed != 
data->want_async)" condition, at which point check_async is true (from 
device_initial_probe()), while async_allowed and want_async are *both* 
false, but that leads us to actually go ahead and call 
driver_probe_device() for the child device despite being in async 
context. That doesn't seem right to me - I'm guessing it maybe wasn't 
anticipated to have bus drivers calling device_initial_probe() from 
within async in the first place?

It may not strictly be the fault of this patch - clearly 91703041697c 
("PCI: Allow built-in drivers to use async initial probing") is 
implicated in this too - but the fact is that it *has* exposed a bug 
that needs fixing one way or another, it can't just be left hanging and 
impacting end users.

Thanks,
Robin.

- Mani

[1] https://lore.kernel.org/linux-pci/aYHVlS1nbCMMyF04@ryzen (local)