Re: [PATCH] driver core: Add cmdline option to force probe type

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, May 14, 2026 at 05:49:55PM +0800, Jianlin Lv wrote:
> From: Jianlin Lv <iecedge@gmail.com>
> 
> Device drivers that use asynchronous probing can cause non-deterministic
> device ordering and naming across reboots. A typical example is storage
> drivers (like sd/nvme): asynchronous probing can lead to inconsistent disk
> logical names after reboot. In scenarios where disk naming consistency is
> critical, the probe type should be set to synchronous.
> 
> This patch introduces a driver_probe kernel parameter that overrides any
> driver's hard-coded probe type settings and allows runtime control without
> requiring kernel recompilation:
> 
>   driver_probe=PROBE_TYPE_SYNC,nvme,sd      # Force specific drivers sync
>   driver_probe=PROBE_TYPE_ASYNC,*,usb       # Force all async except usb
>   driver_probe=PROBE_TYPE_SYNC,*            # Force all drivers synchronous
> 
> The implementation replaces the limited driver_async_probe parameter with
> a more flexible interface that can force either synchronous or asynchronous
> probing as needed.
> 
> Signed-off-by: Jianlin Lv <iecedge@gmail.com>
> ---
>  .../admin-guide/kernel-parameters.txt         | 27 +++++--
>  drivers/base/dd.c                             | 71 ++++++++++++++-----
>  2 files changed, 74 insertions(+), 24 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 4d0f545fb3ec..b43a8bd20356 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1377,12 +1377,27 @@ Kernel parameters
>  			it becomes active and is searched during signature
>  			verification.
>  
> -	driver_async_probe=  [KNL]
> -			List of driver names to be probed asynchronously. *
> -			matches with all driver names. If * is specified, the
> -			rest of the listed driver names are those that will NOT
> -			match the *.
> -			Format: <driver_name1>,<driver_name2>...

You can not remove an existing user/kernel api, sorry, that is not
allowed as you just broke all systems that were relying on this :(

thanks,

greg k-h