On 2026-03-12 12:59 pm, Danilo Krummrich wrote:

On Thu Mar 12, 2026 at 1:48 PM CET, Robin Murphy wrote:

quoted

On 2026-03-11 9:09 pm, Danilo Krummrich wrote:

quoted

  From a driver-core perspective I think we're rather limited on what we can do;
we are already in async context at this point and can't magically go back to
initcall context.

So, the only thing I can think of is to kick off work on a workqueue, which in
the end would be the same as the deferred probe handling.

Hmm, in fact, isn't the deferred probe mechanism itself actually quite
appropriate?

Yes, I've also mentioned this in [1], including the fact that it technically
even complies with the guarantees given by PROBE_FORCE_SYNCHRONOUS. I.e. the
documentation says:

	Use this to annotate drivers that need their probe routines to run
	synchronously with driver and device registration (with the exception of
	-EPROBE_DEFER handling - re-probing always ends up being done
	asynchronously).

However, I'm still not sure how I feel about this, since I consider this to be
more like a workaround that just moves things to a "more approprite" async
context.

I guess the underlying problem there is that there are at least 3 
different significant aspects to what "synchronous" can mean:

- literally in the context or device/driver registration as documented. 
Off-hand I'm not really sure what useful property may be *specific* to 
those conditions that a driver might rely on, other than for 
super-special cases like platform_driver_probe().

- serialised, i.e. probes of multiple devices won't happen concurrently 
on multiple threads. This is probably the one hiding the most driver 
bugs, e.g. internal shared/global state without sufficient 
synchronisation. I guess this falls out as a side-effect of the first 
condition, but AFAICS it *can* also still provided by deferred probe 
(given that it's a single work item iterating a list one-by-one)

- in some regular thread context that isn't liable to have issues 
synchronising against other async_func workers (i.e. the request_module 
case). Again, deferred can't have a problem here, or it wouldn't have 
worked properly in general for the last decade.

So it's not that we'd be relying on some dubious "deferred is always 
synchronous" assumption - AFAICS deferred *can* launch async if the 
driver permits it - more just ratifying that deferred is still able to 
effectively honour all the useful properties of PROBE_FORCE_SYNCHRONOUS 
other than "during registration of the thing". And where people do want 
the semantics for a platform_driver_probe()-like thing, then I think 
it's reasonable to say that they should definitely never be invoking 
that from the probe routine of some other driver which permits async itself.

Thanks,
Robin.

On the other hand, eventually we want everything to work with
PROBE_PREFER_ASYNCHRONOUS, so maybe it's also good enough for the time being.

[1] https://lore.kernel.org/driver-core/DGZJBMG2Y738.2MU5LXVGEDD47@kernel.org/ (local)