Re: [PATCH] driver core: introduce PROBE_FORCE_ASYNCHRONOUS
Greg Kroah-Hartman <[email protected]> Mon, 27 Jul 2026 08:25:51 +0200
| Newsgroups | dev.linux.lists.driver-core,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <2026072717-amicably-tray-4a8b@gregkh> |
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. And as there's no users for this, we really can't take it until we see those users at the same time :) thanks, greg k-h