[PATCH] drivers: core: Clarify EPROBE_DEFER retry mechanism

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
---
 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)





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux