On Fri Mar 13, 2026 at 2:15 PM CET, Robin Murphy wrote:

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

quoted

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().

I'm not worried about this one, as it is already special by not being compatible
with deferred probe. I.e. the caller already has to promise that the
corresponding probe() call will never return -EPROBE_DEFER.

This is a much more error prone requirement than just "don't call this from
async" already.

- 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".

Yes, and as mentioned above, EPROBE_DEFER has always been a valid path for
PROBE_FORCE_SYNCHRONOUS, which is why I brought it up as a a workaround in the
first place.

(The reason why I still say "workaround" is because nothing actually needs to be
deferred.)

Anyways, as I mentioned...

quoted

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. 

...plus there are not a lot of PROBE_FORCE_SYNCHRONOUS left anyways.

Do you want to send a patch?