All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Brian Masney <bmasney@redhat.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Douglas Anderson <dianders@chromium.org>,
	John Stultz <jstultz@google.com>,
	Peter Robinson <pbrobinson@redhat.com>,
	Enric Balletbo i Serra <eballetbo@redhat.com>,
	Steev Klimaszewski <steev@kali.org>,
	Rob Herring <robh@kernel.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	linux-arm-msm@vger.kernel.org,
	Saravana Kannan <saravanak@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Javier Martinez Canillas <javierm@redhat.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Borislav Petkov <bp@suse.de>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Muchun Song <songmuchun@bytedance.com>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-doc@vger.kernel.org
Subject: [PATCH v2 0/4] driver core: Decouple device links enforcing and probe deferral timeouts
Date: Wed, 16 Nov 2022 12:53:44 +0100	[thread overview]
Message-ID: <20221116115348.517599-1-javierm@redhat.com> (raw)

This series is a v2 of patch "driver core: Disable driver deferred probe
timeout by default" [0] but using a slightly different approach after the
feedback I got on v1.

The problem with v1 was that just disabling the probe deferral timeout by
default would cause a regression for drivers that may want to probe even
if their (optional) dependencies are not present yet.

But this was achieved by timing out the probe deferral mechanism, which
calls fw_devlink_drivers_done() in its work queue function handler. There
is not reason to tie the two though, it should be possible to relax the
device links to allow drivers to probe even if their optional suppliers
are not present, while still keep the probe deferral mechanism enabled
so that drivers that have required dependencies are still able to defer
their probe.

This series decouple the two operations by adding a fw_devlink.timeout=
command line parameter. That way, the probe deferral timeout can be set
to -1 by default, reverting to the previous behaviour while still allow
drivers to probe with optional dependencies missing.

Patch #1 is just a cleanup that makes the driver_deferred_probe_timeout
variable static since isn't used outside of its compilation unit.

Patch #2 disables the deferred probe mechanism after late_initcall if
modules are disable. Since there is no point to schedule the timer in
that case.

Patch #3 adds the new "fw_devlink.timeout=" cmdline param, that can be
used to set a timeout for the device links enforcing. The semantics are
quite similar to the existing "deferred_probe_timeout=" cmdline param.

Patch #4 then changes the default value for the probe deferral timeout,
to just disable it by default and make the probe deferral mechanism to
revert to the behaviour that had before. That is, to just try to probe
the drivers indefinitely. But the device link enforcing timeout is set
to 10 seconds, to keep the existing expectations for drivers that want
to probe even if their optional dependencies are not present.

I have tested on my HP X2 Chromebook and the DRM driver that was failing
to probe before now works without any cmdline parameters. I also tested
with different combinations of device links and deferred probe timeouts.

[0]: https://lore.kernel.org/lkml/354820e8-939c-781a-0d76-c1574c43b7f3@redhat.com/T/#t

Best regards,
Javier

Changes in v2:
- Mention in the commit messsage the specific machine and drivers that
  are affected by the issue (Greg).
- Double check the commit message for accuracy (John).
- Add a second workqueue to timeout the devlink enforcing and allow
  drivers to probe even without their optional dependencies available.

Javier Martinez Canillas (4):
  driver core: Make driver_deferred_probe_timeout a static variable
  driver core: Set deferred probe timeout to 0 if modules are disabled
  driver core: Add fw_devlink.timeout param to stop waiting for devlinks
  driver core: Disable driver deferred probe timeout by default

 .../admin-guide/kernel-parameters.txt         |  7 +++
 drivers/base/dd.c                             | 48 +++++++++++++++----
 include/linux/device/driver.h                 |  1 -
 3 files changed, 47 insertions(+), 9 deletions(-)

-- 
2.38.1


             reply	other threads:[~2022-11-16 12:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 11:53 Javier Martinez Canillas [this message]
2022-11-16 11:53 ` [PATCH v2 1/4] driver core: Make driver_deferred_probe_timeout a static variable Javier Martinez Canillas
2022-11-16 12:57   ` Andrew Halaney
2022-11-17 19:14   ` John Stultz
2022-12-12  8:50     ` Javier Martinez Canillas
2022-12-12  8:59       ` Greg Kroah-Hartman
2022-12-12  9:06         ` Javier Martinez Canillas
2022-11-16 12:00 ` [PATCH v2 2/4] driver core: Set deferred probe timeout to 0 if modules are disabled Javier Martinez Canillas
2022-11-16 16:39   ` Andrew Halaney
2022-11-16 16:51     ` Javier Martinez Canillas
2022-11-16 12:01 ` [PATCH v2 3/4] driver core: Add fw_devlink.timeout param to stop waiting for devlinks Javier Martinez Canillas
2022-11-16 16:09   ` Randy Dunlap
2022-11-16 19:05   ` Andrew Halaney
2022-11-17 15:19   ` Andrew Halaney
2022-11-17 18:55     ` Javier Martinez Canillas
2022-11-17 19:07   ` John Stultz
2022-11-17 19:16     ` Javier Martinez Canillas
2022-11-16 12:02 ` [PATCH v2 4/4] driver core: Disable driver deferred probe timeout by default Javier Martinez Canillas
2022-11-16 19:15   ` Andrew Halaney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221116115348.517599-1-javierm@redhat.com \
    --to=javierm@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andersson@kernel.org \
    --cc=ast@kernel.org \
    --cc=bmasney@redhat.com \
    --cc=bp@suse.de \
    --cc=corbet@lwn.net \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=eballetbo@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jstultz@google.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=pbrobinson@redhat.com \
    --cc=quic_neeraju@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    --cc=songmuchun@bytedance.com \
    --cc=steev@kali.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.