Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration
From: Saravana Kannan <hidden>
Date: 2022-05-13 17:26:46
Also in:
linux-gpio, linux-iommu, linux-pm, lkml
On Fri, May 13, 2022 at 6:58 AM Rob Herring [off-list ref] wrote:
On Fri, Apr 29, 2022 at 5:09 PM Saravana Kannan [off-list ref] wrote:quoted
The deferred probe timer that's used for this currently starts at late_initcall and runs for driver_deferred_probe_timeout seconds. The assumption being that all available drivers would be loaded and registered before the timer expires. This means, the driver_deferred_probe_timeout has to be pretty large for it to cover the worst case. But if we set the default value for it to cover the worst case, it would significantly slow down the average case. For this reason, the default value is set to 0. Also, with CONFIG_MODULES=y and the current default values of driver_deferred_probe_timeout=0 and fw_devlink=on, devices with missing drivers will cause their consumer devices to always defer their probes. This is because device links created by fw_devlink defer the probe even before the consumer driver's probe() is called. Instead of a fixed timeout, if we extend an unexpired deferred probe timer on every successful driver registration, with the expectation more modules would be loaded in the near future, then the default value of driver_deferred_probe_timeout only needs to be as long as the worst case time difference between two consecutive module loads. So let's implement that and set the default value to 10 seconds when CONFIG_MODULES=y.We had to revert a non-zero timeout before (issue with NFS root IIRC). Does fw_devlink=on somehow fix that?
If it's the one where ip autoconfig was timing out, then John Stultz fixed it by fixing wait_for_device_probe(). https://lore.kernel.org/all/20200422203245.83244-4-john.stultz@linaro.org/ (local) If you are referring to some other issue, then I'd need more details. -Saravana