Re: [PATCH] driver core: introduce PROBE_FORCE_ASYNCHRONOUS

On Wed, Jul 29, 2026 at 10:49:16AM +0200, Greg Kroah-Hartman wrote:
> 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 <[email protected]>
> > > > > > ---
> > > > > > 
> > > > > > 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?

As I mentioned, the current behavior for "prefer" and "force" is the
same. It is more about documenting expectations/requirements than
behavior of the current implementation.

Thanks.

-- 
Dmitry