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: 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