On Mon, Dec 19, 2011 at 5:48 PM, Vladimir Zapolskiy <vladimir.zapolskiy@xxxxxxxxx> wrote: > On 12/19/2011 06:22 PM, ext Felipe Balbi wrote: >> On Mon, Dec 19, 2011 at 05:45:30PM +0200, Vladimir Zapolskiy wrote: >>> Note, that all of the touched drivers have subsys_initcall() >>> initialization, >>> which basically doesn't have any special load order meaning, if a driver >>> is >>> compiled as module. >> >> >> Yes and that's because they should all be module_init() instead. We have >> to stop this hackery of forcing certain loading by sticking *_initcall() >> on drivers and making everything built-in. This is utterly wrong and we >> need another way to force dependency between modules. If MUSB needs an >> I2C transceiver to be loaded before it, you need to find a better way to >> tell that to the kernel (or to userland). > > > What is your raw idea of making proper order of module loading? I don't know what is proper for musb, but Grant Likely has been floating patches allowing drivers to return -EPROBE_DEFER in .probe() and they will be retried later, repeatedly, until their dependencies are met. See topic: "[RFC PATCH v3] drivercore: Add driver probe deferral mechanism" Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html