From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA31126E165 for ; Mon, 30 Mar 2026 19:13:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774898026; cv=none; b=DT1vOAZSI+g5jL6agdSGD2WkzkR34y6vBXzvEPB6GnjfpkwW1DGdncZwtoQvmXo5W44YwoioXhNBH+ayj6xeapNy1mHcIb5jIRNX1YILnl+ETfWJx+66PZWDEaxhMkvJRUazAtn+I06nUbM/tqdjKLrICKeYVh3PPwZS7iDSvXA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774898026; c=relaxed/simple; bh=TvrcdqKMMQDtXAPTJ2HqvUlUHyQjCYftV4zcxBpfSGY=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=j0Mbj1r5h9iZ/tO7U/gLPkebplNExwztT7tmHa5n2Pt4lpSZ1FXzBAZZiDY3OeR1Rl2TEtcePj2LURIsLsR0PMf36o6VQJklMJ5uJQzMf0kpZA9G/0/D+hPSxkaBx5+HxCar6fIgJqcR+8uxoD9+tf6+Vtvmd/AbcbHfmi3J7Hg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d8m0D/00; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="d8m0D/00" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37021C4CEF7; Mon, 30 Mar 2026 19:13:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774898025; bh=TvrcdqKMMQDtXAPTJ2HqvUlUHyQjCYftV4zcxBpfSGY=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=d8m0D/00pn85TGs0dlCymyzg4nywekXiQJdhJhP9x9gJQhUkQrzOc4OULHrYWbD0w OnCa491/c87Qkq+wY/kLY0OhyyviDwVHIJpgDEg6ej2S6Jrj2bOFMXJ7TSKOIdiKBa TdnLFfn0Qd+SMqR7+9w+dRZzRSvUjuL3XgptZx0vD1t2B8jY6lDljf+et3BWgwf3Nz dfT/Ghdg/PHvRbm5q9orlqkANiNF2Byzb4LPh0UNUCrgNmKwEuF8l7nPwkyH+7tZKa F8wiy9YzYyrS3psIKtEryZ9RV9jNOTW2WH7C97QEbF5OtQlWVB3tXlG8VGAKCur9ot UQwbpC+MZT+EQ== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 30 Mar 2026 21:13:42 +0200 Message-Id: Subject: Re: [PATCH v2 resend] driver core: Make deferred_probe_timeout default a Kconfig option Cc: "Greg Kroah-Hartman" , "Rafael J . Wysocki" , "Rob Herring" , "Bjorn Andersson" , , "Saravana Kannan" To: "Hans de Goede" From: "Danilo Krummrich" References: <20260314084916.10868-1-johannes.goede@oss.qualcomm.com> In-Reply-To: <20260314084916.10868-1-johannes.goede@oss.qualcomm.com> On Sat Mar 14, 2026 at 9:49 AM CET, 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. > > While at it document that a value of -1 can be used to disable the timeou= t > (wait indefinitely). > > Acked-by: Saravana Kannan > Signed-off-by: Hans de Goede Applied to driver-core-testing, thanks! [ Drop deferred_probe_timeout documentation change in kernel-parameters.txt. - Danilo ] Sorry for the delay -- I dropped the documentation change as I think it des= erves a separate patch and I think that just adding "Set to -1 to wait indefinite= ly." at the end doesn't read very well. (Also, I think every negative value will result in waiting indefinitely.) I also upgraded Saravana's ACK (which already was conditional on this chang= e before) to an RB, as offered in [1]. deferred_probe_timeout=3D [KNL] Debugging option to set a timeout in seconds for deferred probe to give up waiting on dependencies to probe. Only specific dependencies (subsystems or drivers) that have opted in will be ignored. A timeout of 0 will timeout at the end of initcalls. If the time 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. Set to -1 to wait indefinitely. Maybe something like this? deferred_probe_timeout=3D [KNL] Debugging option to set a timeout in seconds for deferred probe to give up waiting on dependencies to probe. Only specific dependencies (subsystems or drivers) that have opted in will be ignored. A timeout of 0 will timeout at the end of initcalls; a negative value is treated as an infinite timeout value. If the timeout 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. [1] https://lore.kernel.org/all/CACRMN=3DeacrCNQodiYZJ-XH8rA6ZTEKNGrGi3JTrj= FFGfMgSh5g@mail.gmail.com/