Received-SPF: pass (google.com: domain of linux-kernel+bounces-96264-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu, 7 Mar 2024 21:39:27 +0000
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: linux-kernel@vger.kernel.org, javier@dowhile0.org,
	Andrew Halaney <ahalaney@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v3] driver core: Don't set a deferred probe timeout if
 modules are disabled
Message-ID: <2024030722-explicit-juror-9ba7@gregkh>
References: <20240227231001.648698-1-javierm@redhat.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240227231001.648698-1-javierm@redhat.com>

On Wed, Feb 28, 2024 at 12:09:02AM +0100, Javier Martinez Canillas wrote:
> There is no point to schedule the workqueue to timeout the deferred probe,
> if all the initcalls are done and modules are not enabled. The default for
> this case is already 0 but can be overridden by the deferred_probe_timeout
> parameter. Let's just skip this and avoid queuing work that is not needed.

As the option is already there to set the timeout to 0, why confuse
things by trying to tie this to if modules are enabled or not?  And even
if you do want to do that, where did you now document this new system
behavior?

thanks,

greg k-h