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

["Danilo Krummrich" <dakr@kernel.org>]

On Fri Mar 13, 2026 at 2:15 PM CET, Robin Murphy wrote:
> On 2026-03-12 12:59 pm, Danilo Krummrich wrote:
>> On Thu Mar 12, 2026 at 1:48 PM CET, Robin Murphy wrote:
>>> On 2026-03-11 9:09 pm, Danilo Krummrich wrote:
>>>>   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...

>> 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?