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:

quoted

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.

quoted

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

-- 
மணிவண்ணன் சதாசிவம்