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) {
next prev parent reply other threads:[~2026-07-29 5:40 UTC|newest]
Thread overview: 6+ 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.