Re: [PATCH 5.4 39/84] driver core: Set deferred_probe_timeout to a longer default if CONFIG_MODULES is set
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2024-02-28 07:07:37
Also in:
linux-patches, stable
On Tue, Feb 27, 2024 at 11:38:01AM -0800, John Stultz wrote:
On Tue, Feb 27, 2024 at 5:27 AM Greg Kroah-Hartman [off-list ref] wrote:quoted
5.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: John Stultz <redacted> [ Upstream commit e2cec7d6853712295cef5377762165a489b2957f ] When using modules, its common for the modules not to be loaded until quite late by userland. With the current code, driver_deferred_probe_check_state() will stop returning EPROBE_DEFER after late_initcall, which can cause module dependency resolution to fail after that. So allow a longer window of 30 seconds (picked somewhat arbitrarily, but influenced by the similar regulator core timeout value) in the case where modules are enabled. Cc: linux-pm@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Walleij <redacted> Cc: Thierry Reding <redacted> Cc: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Bjorn Andersson <redacted> Cc: Saravana Kannan <redacted> Cc: Todd Kjos <redacted> Cc: Len Brown <redacted> Cc: Pavel Machek <redacted> Cc: Ulf Hansson <redacted> Cc: Kevin Hilman <khilman@kernel.org> Cc: "Rafael J. Wysocki" <redacted> Cc: Rob Herring <robh@kernel.org> Reviewed-by: Bjorn Andersson <redacted> Reviewed-by: Rafael J. Wysocki <redacted> Signed-off-by: John Stultz <redacted> Link: https://lore.kernel.org/r/20200225050828.56458-3-john.stultz@linaro.org (local) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/base/dd.c | 9 +++++++++ 1 file changed, 9 insertions(+)This change ended up being reverted upstream in ce68929f07de Is there some specific reason it got selected to be pulled into -stable?
It was an attempt to sync up with what had been added to the 4.19.y tree but not newer kernels. I'll go drop this from 5.4.y now, thanks for noticing the revert, my scripts did not pick that up :( Also, this is in the 4.19.y tree, but in a different form, and one that no one seemed to have problems with, so I'll leave it alone there for now. thanks, greg k-h