Messages in this thread | | | From | Andy Shevchenko <> | Date | Sat, 28 Mar 2020 13:13:42 +0200 | Subject | Re: [PATCH] Add documentation on meaning of -EPROBE_DEFER |
| |
On Sat, Mar 28, 2020 at 1:57 AM Saravana Kannan <saravanak@google.com> wrote: > On Fri, Mar 27, 2020 at 4:25 PM Grant Likely <grant.likely@arm.com> wrote: > > 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.
...
> > >> +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?
Why? *Good* documentation must describe the actual behaviour, not hide it.
> > 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. > > Assuming Greg is okay with this doc update, I'm kinda leaning towards > "undefined"
I think it should not distort the reality.
> because if documented as "infinite loop" people might be > hesitant towards removing that behavior.
This is funny argument. Won't we do kernel better?
> But I'll let Greg make the > final call. Not going to NACK for this point.
-- With Best Regards, Andy Shevchenko
| |