[PATCH v3] PCI: dw-rockchip: Enable async probe by default
Manivannan Sadhasivam
mani at kernel.org
Wed Mar 11 05:28:26 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? :)
>
Hmm, I overlooked the built-as-module part where the deadlock could be possible
as indicated by the comment about the WARN_ON_ONCE().
But what is the path forward here? Do you want the phylib to fix the
request_module() call or fix the driver core instead?
I can drop this patch in the meantime. But holding this prolong wouldn't help.
- Mani
--
மணிவண்ணன் சதாசிவம்
More information about the Linux-rockchip
mailing list