Re: [BUG] Deferred probing in driver model is racy, resulting in lost probes

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Sat, Sep 15, 2012 at 09:03:04AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Aug 18, 2012 at 03:58:56PM +0100, Russell King - ARM Linux wrote:
> > Okay, so EPROBE_DEFER seems to work when I build everything into the
> > kernel, but when I build a pile of ASoC drivers as modules, it fails
> > every time I've tried booting the platform so far.
> 
> Ugh, sorry for the delay in this, but this is really Grant's area, as he
> added this feature.
> 
> Actually, for some reason, I thought this was only supposed to work for
> built-in drivers, not for modules at all.  The fact that it works for
> them some times seems like an additional feature :)

It has to work for modules because there's no way to tell modprobe about
these kinds of dependencies - the modules make no direct reference to
their dependent drivers.

Think of a driver making use of gpiolib.  It makes reference only to
GPIO functions defined by gpiolib, which then redirects them to the
appropriate driver.

If upon requesting the GPIOs, it finds that the GPIOs it should be
using aren't there yet, it would decide to return -EPROBE_DEFER.
There is no direct reference to the GPIO module (which could be some
I2C peripheral also built as a module).

If you happen to have udev setup to automatically load all modules for
devices, this provides a definite case where EPROBE_DEFER sorts out the
probe ordering in this case - in theory, when the GPIO driver module
gets loaded, the GPIO-using driver will reprobe and hopefully initialize.

So, I think there's a valid use case by this for modules - in any case,
we can't really treat built-in drivers differently from modular drivers
unless we want them scattered with #ifdef MODULE...#endif stuff.