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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
