[PATCH v3] PCI: dw-rockchip: Enable async probe by default

Niklas Cassel cassel at kernel.org
Wed Mar 11 05:13:34 PDT 2026


On Wed, Mar 11, 2026 at 12:46:03PM +0100, Danilo Krummrich wrote:
> On Wed Mar 11, 2026 at 6:24 AM CET, Manivannan Sadhasivam wrote:
> > I have a contrary view here. If just a single driver or lib doesn't handle async
> > probe, it cannot just force other drivers to not take the advantage of async
> > probe. As I said above, enabling async probe easily saves a few hunderd ms or
> > even more if there are more than one Root Port or Root Complex in an SoC.
> 
> Then the driver or lib has to be fixed / improved first or the driver core has
> to be enabled to deal with a case where PROBE_FORCE_SYNCHRONOUS is requested
> from an async path, etc.
> 
> In any case, applying the patch and breaking things (knowingly?) doesn't seem
> like the correct approach.
> 
> > I strongly agree with you here that the underlying issue should be fixed. But
> > the real impact to end users is not this splat, but not having the boot time
> > optimization that this patch brings in. As an end user, one would want their
> > systems to boot quickly and they wouldn't bother much about a harmless warning
> > splat appearing in the dmesg log.
> 
> You mean quickly booting into a "harmless" potential deadlock condition the
> warning splat tries to make people aware of? :)
> 
> (Or am I missing a subtle detail and we can never actually end up in a deadlock
> for some reason?)

Right now it will print a warning even when trying to load a PHY driver that
is already loaded (e.g. if the PHY driver is built as built-in):
https://github.com/torvalds/linux/blob/v7.0-rc3/drivers/net/phy/phy_device.c#L806-L815

If the PHY driver is built as a module, then I assume that the deadlock
warning is legit.


Kind regards,
Niklas



More information about the Linux-rockchip mailing list