On Sat, Mar 28, 2020 at 1:57 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > On Fri, Mar 27, 2020 at 4:25 PM Grant Likely <grant.likely@xxxxxxx> wrote: > > On 27/03/2020 18:10, Saravana Kannan wrote: > > > On Fri, Mar 27, 2020 at 10:01 AM Grant Likely <grant.likely@xxxxxxx> 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
