Re: [PATCH] driver core: introduce PROBE_FORCE_ASYNCHRONOUS

On Wed, Jul 29, 2026 at 11:24:48AM -0700, Dmitry Torokhov wrote:
> 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.

But you aren't changing anything here at all, just adding a new enum
that does the same thing as the existing one.  So I'm really confused...