Messages in this thread | | | Subject | Re: [PATCH] Add documentation on meaning of -EPROBE_DEFER | From | Grant Likely <> | Date | Fri, 27 Mar 2020 23:25:17 +0000 |
| |
On 27/03/2020 18:10, Saravana Kannan wrote: > On Fri, Mar 27, 2020 at 10:01 AM Grant Likely <grant.likely@arm.com> wrote: >> >> Add a bit of documentation on what it means when a driver .probe() hook >> returns the -EPROBE_DEFER error code, including the limitation that >> -EPROBE_DEFER should be returned as early as possible, before the driver >> starts to register child devices. >> >> Also: minor markup fixes in the same file >> >> Signed-off-by: Grant Likely <grant.likely@arm.com> >> Cc: Jonathan Corbet <corbet@lwn.net> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >> Cc: Saravana Kannan <saravanak@google.com> >> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> >> --- >> .../driver-api/driver-model/driver.rst | 32 ++++++++++++++++--- >> 1 file changed, 27 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/driver-api/driver-model/driver.rst b/Documentation/driver-api/driver-model/driver.rst >> index baa6a85c8287..63057d9bc8a6 100644 >> --- a/Documentation/driver-api/driver-model/driver.rst >> +++ b/Documentation/driver-api/driver-model/driver.rst >> @@ -4,7 +4,6 @@ Device Drivers >> >> See the kerneldoc for the struct device_driver. >> >> - >> Allocation >> ~~~~~~~~~~ >> >> @@ -167,9 +166,26 @@ the driver to that device. >> >> A driver's probe() may return a negative errno value to indicate that >> the driver did not bind to this device, in which case it should have >> -released all resources it allocated:: >> +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. >> + >> +.. warning:: >> + -EPROBE_DEFER must not be returned if probe() has already created >> + child devices, even if those child devices are removed again >> + in a cleanup path. If -EPROBE_DEFER is returned after a child >> + device has been registered, it may result in an infinite loop of >> + .probe() calls to the same driver. > > The infinite loop is a current implementation behavior. Not an > intentional choice. So, maybe we can say the behavior is undefined > instead?
If you feel strongly about it, but I don't have any problem with documenting it as the current implementation behaviour, and then changing the text if that ever changes.
g.
| |