Re: [PATCH] driver core: introduce PROBE_FORCE_ASYNCHRONOUS

[Greg Kroah-Hartman]

On Tue, Jul 28, 2026 at 10:40:29PM -0700, Dmitry Torokhov wrote:
> On Mon, Jul 27, 2026 at 08:25:51AM +0200, Greg Kroah-Hartman wrote:
> > On Sun, Jul 26, 2026 at 10:54:54PM -0700, Dmitry Torokhov wrote:
> > > On Mon, Jul 27, 2026 at 07:40:57AM +0200, Greg Kroah-Hartman wrote:
> > > > On Sun, Jul 26, 2026 at 10:31:41PM -0700, Dmitry Torokhov wrote:
> > > > > Add PROBE_FORCE_ASYNCHRONOUS probe type enum and update
> > > > > driver_allows_async_probing() to allow asynchronous probing for drivers
> > > > > marked with this type.
> > > > > 
> > > > > While PROBE_PREFER_ASYNCHRONOUS exists, it represents a temporary opt-in
> > > > > preference. Subsystems that require asynchronous probing (such as slow
> > > > > legacy buses) need a dedicated probe type to guarantee asynchronous
> > > > > execution.
> > > > > 
> > > > > Assisted-by: Antigravity:gemini-3.5-flash
> > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
> > > > > ---
> > > > > 
> > > > > I am planning to rework serio and gameport subsystems to rely on
> > > > > asynchronous probing instead of rolling their own implementations.
> > > > 
> > > > What do you mean?  Why doesn't the PROBE_PREFER_ASYNCHRONOUS work for
> > > > you for those subsystems?
> > > 
> > > It shows the intent. It is not "preference" anymore, it is a "must". If
> > > we ever introduce switch to make probing synchronous for some reason it
> > > should not affect drivers that must be probed asynchronously.
> > 
> > I'm sorry, but I don't understand.
> 
> PROBE_PREFER_ASYNCHRONOUS says that the driver prefers to be probe
> asynchronously but it can also be probed synchronously if needed.
> 
> PROBE_FORCE_ASYNCHRONOUS indicates that the driver *must* be probed
> asynchronously, or the kernel will break.
> 
> Currently there is no difference in behavior, but it documents the
> intent.
> 
> > And as there's no users for this, we
> > really can't take it until we see those users at the same time :)
> 
> I am planning to use it in serio and gameport bus implementations that
> currently roll their own asynchronous registration which is quite ugly.
> Because we have nested serio ports probing *must* be done asynchronously
> or it will deadlock.
> 
> I would like to merge the new constant early so that I do not have
> dependency when I am ready to merge input changes.
> 
> Below is how it will look like (just a small part of a WIP series).

Ok, this makes sense, but you need to also add documentation for this
new value to the comment block right above where you defined it :)


Wait, in looking at the tree, I don't see how this differs from
"prefer".  I don't see how "prefer" can be overloaded to NOT do async
probing.  Am I just missing the logic somewhere?

thanks,

greg k-h