Re: [PATCH] driver core: Make deferred_probe_timeout default a Kconfig option

[Bjorn Andersson]

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