From: anish kumar <yesanishhere@gmail.com>
To: corbet@lwn.net
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
anish kumar <yesanishhere@gmail.com>
Subject: [PATCH] drivers: core: Clarify EPROBE_DEFER retry mechanism
Date: Mon, 4 Nov 2024 20:55:35 -0800 [thread overview]
Message-ID: <20241105045535.84071-1-yesanishhere@gmail.com> (raw)
The existing documentation for EPROBE_DEFER explains its purpose
and usage, but does not specify when deferred probes are retried.
This patch adds information about the retry mechanism to provide
a more complete explanation of how EPROBE_DEFER works.
Specifically, it clarifies that:
1. Deferred probes are added to a pending list
2. A successful probe of any device triggers moving all devices
from the pending list to an active list
3. A workqueue processes the active list to retry deferred probes
This additional context helps developers better understand the
behavior and implications of using EPROBE_DEFER in their drivers.
Signed-off-by: anish kumar <yesanishhere@gmail.com>
---
Documentation/driver-api/driver-model/driver.rst | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/driver-api/driver-model/driver.rst b/Documentation/driver-api/driver-model/driver.rst
index 06f818b1d622..c86b948d0dfe 100644
--- a/Documentation/driver-api/driver-model/driver.rst
+++ b/Documentation/driver-api/driver-model/driver.rst
@@ -171,10 +171,13 @@ released all resources it allocated.
Optionally, probe() may return -EPROBE_DEFER if the driver depends on
resources that are not yet available (e.g., supplied by a driver that
hasn't initialized yet). The driver core will put the device onto the
-deferred probe list and will try to call it again later. If a driver
-must defer, it should return -EPROBE_DEFER as early as possible to
-reduce the amount of time spent on setup work that will need to be
-unwound and reexecuted at a later time.
+deferred probe list and will retry again as and when a device or driver
+gets added to the system. A successful probe of any device will trigger
+moving all devices from pending list to active list. A workqueue processes
+the active list to retry deferred probes. If a driver must defer, it
+should return -EPROBE_DEFER as early as possible to reduce the amount
+of time spent on setup work that will need to be unwound and reexecuted
+at a later time.
.. warning::
-EPROBE_DEFER must not be returned if probe() has already created
--
2.39.3 (Apple Git-146)
next reply other threads:[~2024-11-05 4:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-05 4:55 anish kumar [this message]
2024-11-07 17:18 ` anish kumar
2024-11-07 19:12 ` Jonathan Corbet
2024-11-12 20:21 ` Jonathan Corbet
2024-11-12 20:25 ` anish kumar
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=20241105045535.84071-1-yesanishhere@gmail.com \
--to=yesanishhere@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®