Documentation/admin-guide/kernel-parameters.txt | 2 +- drivers/base/Kconfig | 9 +++++++++ drivers/base/dd.c | 9 ++++----- 3 files changed, 14 insertions(+), 6 deletions(-)
Code using driver_deferred_probe_check_state() differs from most
EPROBE_DEFER handling in the kernel. Where other EPROBE_DEFER handling
(e.g. clks, gpios and regulators) waits indefinitely for suppliers to
show up, code using driver_deferred_probe_check_state() will fail
after the deferred_probe_timeout.
This is a problem for generic distro kernels which want to support many
boards using a single kernel build. These kernels want as much drivers to
be modular as possible. The initrd also should be as small as possible,
so the initrd will *not* have drivers not needing to get the rootfs.
Combine this with waiting for a full-disk encryption password in
the initrd and it is pretty much guaranteed that the default 10s timeout
will be hit, causing probe() failures when drivers on the rootfs happen
to get modprobe-d before other rootfs modules providing their suppliers.
Make the default timeout configurable from Kconfig to allow distro kernel
configs where many of the supplier drivers are modules to set the default
through Kconfig and allow using a value of -1 to disable the timeout
(wait indefinitely).
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
drivers/base/Kconfig | 9 +++++++++
drivers/base/dd.c | 9 ++++-----
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1058f2a6d6a8..80d300c4e16b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1250,7 +1250,7 @@ Kernel parameters
out hasn't expired, it'll be restarted by each
successful driver registration. This option will also
dump out devices still on the deferred probe list after
- retrying.
+ retrying. Set to -1 to wait indefinitely.
delayacct [KNL] Enable per-task delay accounting
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 1786d87b29e2..f7d385cbd3ba 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -73,6 +73,15 @@ config DEVTMPFS_SAFE
with the PROT_EXEC flag. This can break, for example, non-KMS
video drivers.
+config DRIVER_DEFERRED_PROBE_TIMEOUT
+ int "Default value for deferred_probe_timeout"
+ default 0 if !MODULES
+ default 10 if MODULES
+ help
+ Set the default value for the deferred_probe_timeout kernel parameter.
+ See Documentation/admin-guide/kernel-parameters.txt for a description
+ of the deferred_probe_timeout kernel parameter.
+
config STANDALONE
bool "Select only drivers that don't need compile-time external firmware"
default y
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index bea8da5f8a3a..e57144aa168d 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -257,11 +257,7 @@ static int deferred_devs_show(struct seq_file *s, void *data)
}
DEFINE_SHOW_ATTRIBUTE(deferred_devs);
-#ifdef CONFIG_MODULES
-static int driver_deferred_probe_timeout = 10;
-#else
-static int driver_deferred_probe_timeout;
-#endif
+static int driver_deferred_probe_timeout = CONFIG_DRIVER_DEFERRED_PROBE_TIMEOUT;
static int __init deferred_probe_timeout_setup(char *str)
{
@@ -323,6 +319,9 @@ static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_
void deferred_probe_extend_timeout(void)
{
+ if (driver_deferred_probe_timeout < 0)
+ return;
+
/*
* If the work hasn't been queued yet or if the work expired, don't
* start a new one.
--
2.52.0Hi all,
On 4-Feb-26 16:00, Hans de Goede wrote:
> Code using driver_deferred_probe_check_state() differs from most
> EPROBE_DEFER handling in the kernel. Where other EPROBE_DEFER handling
> (e.g. clks, gpios and regulators) waits indefinitely for suppliers to
> show up, code using driver_deferred_probe_check_state() will fail
> after the deferred_probe_timeout.
>
> This is a problem for generic distro kernels which want to support many
> boards using a single kernel build. These kernels want as much drivers to
> be modular as possible. The initrd also should be as small as possible,
> so the initrd will *not* have drivers not needing to get the rootfs.
>
> Combine this with waiting for a full-disk encryption password in
> the initrd and it is pretty much guaranteed that the default 10s timeout
> will be hit, causing probe() failures when drivers on the rootfs happen
> to get modprobe-d before other rootfs modules providing their suppliers.
>
> Make the default timeout configurable from Kconfig to allow distro kernel
> configs where many of the supplier drivers are modules to set the default
> through Kconfig and allow using a value of -1 to disable the timeout
> (wait indefinitely).
>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> drivers/base/Kconfig | 9 +++++++++
> drivers/base/dd.c | 9 ++++-----
> 3 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1058f2a6d6a8..80d300c4e16b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1250,7 +1250,7 @@ Kernel parameters
> out hasn't expired, it'll be restarted by each
> successful driver registration. This option will also
> dump out devices still on the deferred probe list after
> - retrying.
> + retrying. Set to -1 to wait indefinitely.
>
> delayacct [KNL] Enable per-task delay accounting
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 1786d87b29e2..f7d385cbd3ba 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -73,6 +73,15 @@ config DEVTMPFS_SAFE
> with the PROT_EXEC flag. This can break, for example, non-KMS
> video drivers.
>
> +config DRIVER_DEFERRED_PROBE_TIMEOUT
> + int "Default value for deferred_probe_timeout"
> + default 0 if !MODULES
> + default 10 if MODULES
> + help
> + Set the default value for the deferred_probe_timeout kernel parameter.
> + See Documentation/admin-guide/kernel-parameters.txt for a description
> + of the deferred_probe_timeout kernel parameter.
> +
> config STANDALONE
> bool "Select only drivers that don't need compile-time external firmware"
> default y
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index bea8da5f8a3a..e57144aa168d 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -257,11 +257,7 @@ static int deferred_devs_show(struct seq_file *s, void *data)
> }
> DEFINE_SHOW_ATTRIBUTE(deferred_devs);
>
> -#ifdef CONFIG_MODULES
> -static int driver_deferred_probe_timeout = 10;
> -#else
> -static int driver_deferred_probe_timeout;
> -#endif
> +static int driver_deferred_probe_timeout = CONFIG_DRIVER_DEFERRED_PROBE_TIMEOUT;
>
> static int __init deferred_probe_timeout_setup(char *str)
> {
> @@ -323,6 +319,9 @@ static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_
>
> void deferred_probe_extend_timeout(void)
> {
> + if (driver_deferred_probe_timeout < 0)
> + return;
> +
> /*
> * If the work hasn't been queued yet or if the work expired, don't
> * start a new one.
I just realized that this last bit adding the < 0 check is not necessary.
The work never gets scheduled if driver_deferred_probe_timeout < 0 so
the existing "if (cancel_delayed_work(&deferred_probe_timeout_work))"
check is enough to not re-schedule in this case.
I'll drop this for v2. Note I'm waiting with sending a v2 for a bit
on case there are more remarks.
Regards,
Hans
On Wed, Feb 04, 2026 at 04:00:45PM +0100, Hans de Goede wrote:
Thanks for posting this, Hans. Let's loop in Saravana and Rob as well,
who looked at this subject in the past.
> Code using driver_deferred_probe_check_state() differs from most
> EPROBE_DEFER handling in the kernel. Where other EPROBE_DEFER handling
> (e.g. clks, gpios and regulators) waits indefinitely for suppliers to
> show up, code using driver_deferred_probe_check_state() will fail
> after the deferred_probe_timeout.
>
> This is a problem for generic distro kernels which want to support many
> boards using a single kernel build. These kernels want as much drivers to
> be modular as possible. The initrd also should be as small as possible,
> so the initrd will *not* have drivers not needing to get the rootfs.
>
This problem manifests itself in the upstream kernel, for upstream
developers as well.
On some platforms we have intermittent boot failures even when testing
with a minimal ramdisk (with kernel modules overlaid), because of the
non-deterministic module loading order it might take time before we get
the providers lined up.
Another concrete issue is that the Qualcomm CPUfreq driver, while
builtin, on many targets has dependencies on drivers that we today mark
as modules. So with a decently sized ramdisk we don't have time to
unpack the ramdisk before things start breaking.
The typical symptom I see when this happens is that the SMMU fails to
find its power-domain provider, in some cases the result is
non-functional system, but often the hardware state ends up such that
the board resets...
> Combine this with waiting for a full-disk encryption password in
> the initrd and it is pretty much guaranteed that the default 10s timeout
> will be hit, causing probe() failures when drivers on the rootfs happen
> to get modprobe-d before other rootfs modules providing their suppliers.
>
Indeed, LUKS is a challenge, performing any form of debugging of what
kernel modules you forgot to inject into your ramdisk is impossible.
> Make the default timeout configurable from Kconfig to allow distro kernel
> configs where many of the supplier drivers are modules to set the default
> through Kconfig and allow using a value of -1 to disable the timeout
> (wait indefinitely).
>
The timeout mechanism was introduced to handle those exceptional cases
where distro-kernels are missing specific provider drivers but still
want to roll the dice and try to reach a functional user space to allow
the user to correct the issue.
There's clearly many situations where that will not work in today's
kernel - and as we evolve sync_state, this problem is going to grow.
I therefor would, once again, like to see the default value to be "no
timeout". We can keep the option for the user to opt-in to the
alternative (riskier) path. For this the command line option would
suffice, but with a new default.
The added Kconfig option of course would allow distributions to set the
default to -1, but I'd prefer to provide a sane default value.
Regards,
Bjorn
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> drivers/base/Kconfig | 9 +++++++++
> drivers/base/dd.c | 9 ++++-----
> 3 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1058f2a6d6a8..80d300c4e16b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1250,7 +1250,7 @@ Kernel parameters
> out hasn't expired, it'll be restarted by each
> successful driver registration. This option will also
> dump out devices still on the deferred probe list after
> - retrying.
> + retrying. Set to -1 to wait indefinitely.
>
> delayacct [KNL] Enable per-task delay accounting
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 1786d87b29e2..f7d385cbd3ba 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -73,6 +73,15 @@ config DEVTMPFS_SAFE
> with the PROT_EXEC flag. This can break, for example, non-KMS
> video drivers.
>
> +config DRIVER_DEFERRED_PROBE_TIMEOUT
> + int "Default value for deferred_probe_timeout"
> + default 0 if !MODULES
> + default 10 if MODULES
> + help
> + Set the default value for the deferred_probe_timeout kernel parameter.
> + See Documentation/admin-guide/kernel-parameters.txt for a description
> + of the deferred_probe_timeout kernel parameter.
> +
> config STANDALONE
> bool "Select only drivers that don't need compile-time external firmware"
> default y
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index bea8da5f8a3a..e57144aa168d 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -257,11 +257,7 @@ static int deferred_devs_show(struct seq_file *s, void *data)
> }
> DEFINE_SHOW_ATTRIBUTE(deferred_devs);
>
> -#ifdef CONFIG_MODULES
> -static int driver_deferred_probe_timeout = 10;
> -#else
> -static int driver_deferred_probe_timeout;
> -#endif
> +static int driver_deferred_probe_timeout = CONFIG_DRIVER_DEFERRED_PROBE_TIMEOUT;
>
> static int __init deferred_probe_timeout_setup(char *str)
> {
> @@ -323,6 +319,9 @@ static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_
>
> void deferred_probe_extend_timeout(void)
> {
> + if (driver_deferred_probe_timeout < 0)
> + return;
> +
> /*
> * If the work hasn't been queued yet or if the work expired, don't
> * start a new one.
> --
> 2.52.0
>
Hi Bjorn,
Thank you for your comments.
On 4-Feb-26 22:52, Bjorn Andersson wrote:
> On Wed, Feb 04, 2026 at 04:00:45PM +0100, Hans de Goede wrote:
>
> Thanks for posting this, Hans. Let's loop in Saravana and Rob as well,
> who looked at this subject in the past.
>
>> Code using driver_deferred_probe_check_state() differs from most
>> EPROBE_DEFER handling in the kernel. Where other EPROBE_DEFER handling
>> (e.g. clks, gpios and regulators) waits indefinitely for suppliers to
>> show up, code using driver_deferred_probe_check_state() will fail
>> after the deferred_probe_timeout.
>>
>> This is a problem for generic distro kernels which want to support many
>> boards using a single kernel build. These kernels want as much drivers to
>> be modular as possible. The initrd also should be as small as possible,
>> so the initrd will *not* have drivers not needing to get the rootfs.
>>
>
> This problem manifests itself in the upstream kernel, for upstream
> developers as well.
>
> On some platforms we have intermittent boot failures even when testing
> with a minimal ramdisk (with kernel modules overlaid), because of the
> non-deterministic module loading order it might take time before we get
> the providers lined up.
>
> Another concrete issue is that the Qualcomm CPUfreq driver, while
> builtin, on many targets has dependencies on drivers that we today mark
> as modules. So with a decently sized ramdisk we don't have time to
> unpack the ramdisk before things start breaking.
>
>
> The typical symptom I see when this happens is that the SMMU fails to
> find its power-domain provider, in some cases the result is
> non-functional system, but often the hardware state ends up such that
> the board resets...
>
>> Combine this with waiting for a full-disk encryption password in
>> the initrd and it is pretty much guaranteed that the default 10s timeout
>> will be hit, causing probe() failures when drivers on the rootfs happen
>> to get modprobe-d before other rootfs modules providing their suppliers.
>>
>
> Indeed, LUKS is a challenge, performing any form of debugging of what
> kernel modules you forgot to inject into your ramdisk is impossible.
>
>> Make the default timeout configurable from Kconfig to allow distro kernel
>> configs where many of the supplier drivers are modules to set the default
>> through Kconfig and allow using a value of -1 to disable the timeout
>> (wait indefinitely).
>>
>
> The timeout mechanism was introduced to handle those exceptional cases
> where distro-kernels are missing specific provider drivers but still
> want to roll the dice and try to reach a functional user space to allow
> the user to correct the issue.
>
> There's clearly many situations where that will not work in today's
> kernel - and as we evolve sync_state, this problem is going to grow.
>
>
> I therefor would, once again, like to see the default value to be "no
> timeout". We can keep the option for the user to opt-in to the
> alternative (riskier) path. For this the command line option would
> suffice, but with a new default.
>
>
> The added Kconfig option of course would allow distributions to set the
> default to -1, but I'd prefer to provide a sane default value.
AFAICT when this was discussed before opinions on this were divided.
Which is why I've chosen to just make the default configurable so
that distros/people can chose.
I'm not necessarily against making -1 the default, but I think that
might be a hard to sell to some people.
Note that if this lands you can always make the default -1 for
qcom specific defconfigs.
Regards,
Hans
>> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 2 +-
>> drivers/base/Kconfig | 9 +++++++++
>> drivers/base/dd.c | 9 ++++-----
>> 3 files changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 1058f2a6d6a8..80d300c4e16b 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1250,7 +1250,7 @@ Kernel parameters
>> out hasn't expired, it'll be restarted by each
>> successful driver registration. This option will also
>> dump out devices still on the deferred probe list after
>> - retrying.
>> + retrying. Set to -1 to wait indefinitely.
>>
>> delayacct [KNL] Enable per-task delay accounting
>>
>> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
>> index 1786d87b29e2..f7d385cbd3ba 100644
>> --- a/drivers/base/Kconfig
>> +++ b/drivers/base/Kconfig
>> @@ -73,6 +73,15 @@ config DEVTMPFS_SAFE
>> with the PROT_EXEC flag. This can break, for example, non-KMS
>> video drivers.
>>
>> +config DRIVER_DEFERRED_PROBE_TIMEOUT
>> + int "Default value for deferred_probe_timeout"
>> + default 0 if !MODULES
>> + default 10 if MODULES
>> + help
>> + Set the default value for the deferred_probe_timeout kernel parameter.
>> + See Documentation/admin-guide/kernel-parameters.txt for a description
>> + of the deferred_probe_timeout kernel parameter.
>> +
>> config STANDALONE
>> bool "Select only drivers that don't need compile-time external firmware"
>> default y
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index bea8da5f8a3a..e57144aa168d 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -257,11 +257,7 @@ static int deferred_devs_show(struct seq_file *s, void *data)
>> }
>> DEFINE_SHOW_ATTRIBUTE(deferred_devs);
>>
>> -#ifdef CONFIG_MODULES
>> -static int driver_deferred_probe_timeout = 10;
>> -#else
>> -static int driver_deferred_probe_timeout;
>> -#endif
>> +static int driver_deferred_probe_timeout = CONFIG_DRIVER_DEFERRED_PROBE_TIMEOUT;
>>
>> static int __init deferred_probe_timeout_setup(char *str)
>> {
>> @@ -323,6 +319,9 @@ static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_
>>
>> void deferred_probe_extend_timeout(void)
>> {
>> + if (driver_deferred_probe_timeout < 0)
>> + return;
>> +
>> /*
>> * If the work hasn't been queued yet or if the work expired, don't
>> * start a new one.
>> --
>> 2.52.0
>>
On Thu, Feb 5, 2026 at 1:17 AM Hans de Goede
<johannes.goede@oss.qualcomm.com> wrote:
>
> Hi Bjorn,
>
> Thank you for your comments.
>
> On 4-Feb-26 22:52, Bjorn Andersson wrote:
> > On Wed, Feb 04, 2026 at 04:00:45PM +0100, Hans de Goede wrote:
> >
> > Thanks for posting this, Hans. Let's loop in Saravana and Rob as well,
> > who looked at this subject in the past.
Thanks for looping me in Bjorn.
> >
> >> Code using driver_deferred_probe_check_state() differs from most
> >> EPROBE_DEFER handling in the kernel. Where other EPROBE_DEFER handling
> >> (e.g. clks, gpios and regulators) waits indefinitely for suppliers to
> >> show up, code using driver_deferred_probe_check_state() will fail
> >> after the deferred_probe_timeout.
> >>
> >> This is a problem for generic distro kernels which want to support many
> >> boards using a single kernel build. These kernels want as much drivers to
> >> be modular as possible. The initrd also should be as small as possible,
> >> so the initrd will *not* have drivers not needing to get the rootfs.
> >>
> >
> > This problem manifests itself in the upstream kernel, for upstream
> > developers as well.
> >
> > On some platforms we have intermittent boot failures even when testing
> > with a minimal ramdisk (with kernel modules overlaid), because of the
> > non-deterministic module loading order it might take time before we get
> > the providers lined up.
> >
> > Another concrete issue is that the Qualcomm CPUfreq driver, while
> > builtin, on many targets has dependencies on drivers that we today mark
> > as modules. So with a decently sized ramdisk we don't have time to
> > unpack the ramdisk before things start breaking.
> >
> >
> > The typical symptom I see when this happens is that the SMMU fails to
> > find its power-domain provider, in some cases the result is
> > non-functional system, but often the hardware state ends up such that
> > the board resets...
> >
> >> Combine this with waiting for a full-disk encryption password in
> >> the initrd and it is pretty much guaranteed that the default 10s timeout
> >> will be hit, causing probe() failures when drivers on the rootfs happen
> >> to get modprobe-d before other rootfs modules providing their suppliers.
> >>
> >
> > Indeed, LUKS is a challenge, performing any form of debugging of what
> > kernel modules you forgot to inject into your ramdisk is impossible.
> >
> >> Make the default timeout configurable from Kconfig to allow distro kernel
> >> configs where many of the supplier drivers are modules to set the default
> >> through Kconfig and allow using a value of -1 to disable the timeout
> >> (wait indefinitely).
> >>
> >
> > The timeout mechanism was introduced to handle those exceptional cases
> > where distro-kernels are missing specific provider drivers but still
> > want to roll the dice and try to reach a functional user space to allow
> > the user to correct the issue.
> >
> > There's clearly many situations where that will not work in today's
> > kernel - and as we evolve sync_state, this problem is going to grow.
> >
> >
> > I therefor would, once again, like to see the default value to be "no
> > timeout". We can keep the option for the user to opt-in to the
> > alternative (riskier) path. For this the command line option would
> > suffice, but with a new default.
> >
> >
> > The added Kconfig option of course would allow distributions to set the
> > default to -1, but I'd prefer to provide a sane default value.
>
> AFAICT when this was discussed before opinions on this were divided.
Yeah, IMHO, no timeout should be the default value. But as Hans
mentioned, getting a consensus on that seems impossible.
>
> Which is why I've chosen to just make the default configurable so
> that distros/people can chose.
I'm okay with this patch. I was going to say that you don't need a
separate -1 and we already have an option to wait indefinitely. But
looks like you figured that out yourself (but didn't cc me). So, if
you drop the changes to the doc and fix fix up the code to just use
the config value (and not touch the rest of the code), then:
Acked-by: Saravana Kannan <saravanak@kernel.org>
-Saravana
>
> I'm not necessarily against making -1 the default, but I think that
> might be a hard to sell to some people.
>
> Note that if this lands you can always make the default -1 for
> qcom specific defconfigs.
>
> Regards,
>
> Hans
>
>
>
>
> >> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> >> ---
> >> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> >> drivers/base/Kconfig | 9 +++++++++
> >> drivers/base/dd.c | 9 ++++-----
> >> 3 files changed, 14 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index 1058f2a6d6a8..80d300c4e16b 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -1250,7 +1250,7 @@ Kernel parameters
> >> out hasn't expired, it'll be restarted by each
> >> successful driver registration. This option will also
> >> dump out devices still on the deferred probe list after
> >> - retrying.
> >> + retrying. Set to -1 to wait indefinitely.
> >>
> >> delayacct [KNL] Enable per-task delay accounting
> >>
> >> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> >> index 1786d87b29e2..f7d385cbd3ba 100644
> >> --- a/drivers/base/Kconfig
> >> +++ b/drivers/base/Kconfig
> >> @@ -73,6 +73,15 @@ config DEVTMPFS_SAFE
> >> with the PROT_EXEC flag. This can break, for example, non-KMS
> >> video drivers.
> >>
> >> +config DRIVER_DEFERRED_PROBE_TIMEOUT
> >> + int "Default value for deferred_probe_timeout"
> >> + default 0 if !MODULES
> >> + default 10 if MODULES
> >> + help
> >> + Set the default value for the deferred_probe_timeout kernel parameter.
> >> + See Documentation/admin-guide/kernel-parameters.txt for a description
> >> + of the deferred_probe_timeout kernel parameter.
> >> +
> >> config STANDALONE
> >> bool "Select only drivers that don't need compile-time external firmware"
> >> default y
> >> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> >> index bea8da5f8a3a..e57144aa168d 100644
> >> --- a/drivers/base/dd.c
> >> +++ b/drivers/base/dd.c
> >> @@ -257,11 +257,7 @@ static int deferred_devs_show(struct seq_file *s, void *data)
> >> }
> >> DEFINE_SHOW_ATTRIBUTE(deferred_devs);
> >>
> >> -#ifdef CONFIG_MODULES
> >> -static int driver_deferred_probe_timeout = 10;
> >> -#else
> >> -static int driver_deferred_probe_timeout;
> >> -#endif
> >> +static int driver_deferred_probe_timeout = CONFIG_DRIVER_DEFERRED_PROBE_TIMEOUT;
> >>
> >> static int __init deferred_probe_timeout_setup(char *str)
> >> {
> >> @@ -323,6 +319,9 @@ static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_
> >>
> >> void deferred_probe_extend_timeout(void)
> >> {
> >> + if (driver_deferred_probe_timeout < 0)
> >> + return;
> >> +
> >> /*
> >> * If the work hasn't been queued yet or if the work expired, don't
> >> * start a new one.
> >> --
> >> 2.52.0
> >>
>
On Thu, Feb 05, 2026 at 10:17:40AM +0100, Hans de Goede wrote: > On 4-Feb-26 22:52, Bjorn Andersson wrote: > > On Wed, Feb 04, 2026 at 04:00:45PM +0100, Hans de Goede wrote: [..] > >> Make the default timeout configurable from Kconfig to allow distro kernel > >> configs where many of the supplier drivers are modules to set the default > >> through Kconfig and allow using a value of -1 to disable the timeout > >> (wait indefinitely). > >> > > > > The timeout mechanism was introduced to handle those exceptional cases > > where distro-kernels are missing specific provider drivers but still > > want to roll the dice and try to reach a functional user space to allow > > the user to correct the issue. > > > > There's clearly many situations where that will not work in today's > > kernel - and as we evolve sync_state, this problem is going to grow. > > > > > > I therefor would, once again, like to see the default value to be "no > > timeout". We can keep the option for the user to opt-in to the > > alternative (riskier) path. For this the command line option would > > suffice, but with a new default. > > > > > > The added Kconfig option of course would allow distributions to set the > > default to -1, but I'd prefer to provide a sane default value. > > AFAICT when this was discussed before opinions on this were divided. > > Which is why I've chosen to just make the default configurable so > that distros/people can chose. > > I'm not necessarily against making -1 the default, but I think that > might be a hard to sell to some people. > > Note that if this lands you can always make the default -1 for > qcom specific defconfigs. > There's no such thing as "qcom specific defconfig", people should use the one defconfig. But as you say, I will now have the possibility of trying to take this argument to the distributions instead... And for anyone booting the upstream kernel on a Qualcomm board (including developers as well as e.g. kernelci.org), we just need to make sure they are aware that they must pass deferred_probe_timeout= on their command line, if they want a reliable outcome. In other words, I remain convinced that having broken-by-default settings upstream is bad. Regards, Bjorn
© 2016 - 2026 Red Hat, Inc.