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

Manivannan Sadhasivam mani at kernel.org
Fri Mar 13 07:05:45 PDT 2026


On Thu, Mar 12, 2026 at 01:59:52PM +0100, 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.
> 
> 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.
> 

FWIW, I'd love to handle this corner case in the driver core and not spawn a
workqueue/thread in the bus drivers as we would end up duplicating it all over
defeating the purpose of PROBE_PREFER_ASYNCHRONOUS flag.

- Mani

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



More information about the Linux-rockchip mailing list