The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Danilo Krummrich <dakr@kernel.org>,
	 "Rafael J. Wysocki" <rafael@kernel.org>,
	driver-core@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] driver core: introduce PROBE_FORCE_ASYNCHRONOUS
Date: Tue, 28 Jul 2026 22:40:29 -0700	[thread overview]
Message-ID: <ammQvUcOF4S_VrgO@google.com> (raw)
In-Reply-To: <2026072717-amicably-tray-4a8b@gregkh>

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@gmail.com>
> > > > ---
> > > > 
> > > > 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).

Thanks.

-- 
Dmitry


Input: serio - use PROBE_FORCE_ASYNCHRONOUS and make port registration synchronous

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Mark serio drivers as using PROBE_FORCE_ASYNCHRONOUS instead of
PROBE_PREFER_ASYNCHRONOUS during registration.

At the same time, rework __serio_register_port() to run synchronously
under serio_mutex instead of queuing a SERIO_REGISTER_PORT event to
kseriod. This ensures port registration happens synchronously while
driver probing is handled asynchronously by the driver core.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/input/serio/serio.c |   46 +++++--------------------------------------
 1 file changed, 5 insertions(+), 41 deletions(-)

diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index dd53c2b7a39d..f47d90f0507b 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -124,7 +124,6 @@ enum serio_event_type {
 	SERIO_RESCAN_PORT,
 	SERIO_RECONNECT_PORT,
 	SERIO_RECONNECT_SUBTREE,
-	SERIO_REGISTER_PORT,
 };
 
 struct serio_event {
@@ -190,11 +189,6 @@ static void serio_handle_event(struct work_struct *work)
 	while ((event = serio_get_event())) {
 
 		switch (event->type) {
-
-		case SERIO_REGISTER_PORT:
-			serio_add_port(event->object);
-			break;
-
 		case SERIO_RECONNECT_PORT:
 			serio_reconnect_port(event->object);
 			break;
@@ -279,30 +273,6 @@ static void serio_remove_pending_events(void *object)
 	}
 }
 
-/*
- * Locate child serio port (if any) that has not been fully registered yet.
- *
- * Children are registered by driver's connect() handler so there can't be a
- * grandchild pending registration together with a child.
- */
-static struct serio *serio_get_pending_child(struct serio *parent)
-{
-	struct serio_event *event;
-	struct serio *serio;
-
-	guard(spinlock_irqsave)(&serio_event_lock);
-
-	list_for_each_entry(event, &serio_event_list, node) {
-		if (event->type == SERIO_REGISTER_PORT) {
-			serio = event->object;
-			if (serio->parent == parent)
-				return serio;
-		}
-	}
-
-	return NULL;
-}
-
 /*
  * Serio port operations
  */
@@ -516,13 +486,6 @@ static void serio_add_port(struct serio *serio)
  */
 static void serio_destroy_port(struct serio *serio)
 {
-	struct serio *child;
-
-	while ((child = serio_get_pending_child(serio)) != NULL) {
-		serio_remove_pending_events(child);
-		put_device(&child->dev);
-	}
-
 	if (serio->stop)
 		serio->stop(serio);
 
@@ -653,13 +616,14 @@ void serio_reconnect(struct serio *serio)
 EXPORT_SYMBOL(serio_reconnect);
 
 /*
- * Submits register request to kseriod for subsequent execution.
- * Note that port registration is always asynchronous.
+ * Synchronously registers serio port.
  */
 int __serio_register_port(struct serio *serio, struct module *owner)
 {
 	serio_init_port(serio);
-	serio_queue_event(serio, owner, SERIO_REGISTER_PORT);
+
+	guard(mutex)(&serio_mutex);
+	serio_add_port(serio);
 
 	return 0;
 }
@@ -778,7 +742,7 @@ int __serio_register_driver(struct serio_driver *drv, struct module *owner, cons
 	 * Mark all serio drivers as using asynchronous probe because serio
 	 * devices are slow and their probing takes long time.
 	 */
-	drv->driver.probe_type = PROBE_PREFER_ASYNCHRONOUS;
+	drv->driver.probe_type = PROBE_FORCE_ASYNCHRONOUS;
 
 	error = driver_register(&drv->driver);
 	if (error) {

  reply	other threads:[~2026-07-29  5:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27  5:31 [PATCH] driver core: introduce PROBE_FORCE_ASYNCHRONOUS Dmitry Torokhov
2026-07-27  5:40 ` Greg Kroah-Hartman
2026-07-27  5:54   ` Dmitry Torokhov
2026-07-27  6:25     ` Greg Kroah-Hartman
2026-07-29  5:40       ` Dmitry Torokhov [this message]
2026-07-29  8:49         ` Greg Kroah-Hartman
2026-07-29 18:24           ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ammQvUcOF4S_VrgO@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=dakr@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox