On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokier<jamie@xxxxxxxxxxxxx> wrote: > Grant Likely wrote: >> http://patchwork.ozlabs.org/patch/24152/ >> >> I never actually pushed through and finished it because it turned out >> to be a non-issue for Ethernet devices in the end. However, I can see >> the value. With this approach, a driver can use a >> bus_register_notifier() variant without caring about the device >> registration order, and the drivers notifier callback will get called >> at the appropriate time. >> >> In your example case I could see the framebuffer driver deferring the >> final part of its initialization until the needed i2c device shows up. > > It makes drivers more complicated and larger than necessary, though, > having to add more functions and register more callbacks. > > Something which lets you specify a dependency in a one-line > MODULE_INIT_PREREQS() macro would be much nicer. That would work for some cases, but a lot of cases the problem is not module init order, but rather driver the probe order. ie. In the Ethernet case I was working on the mac cannot be opened before the phy_device is registered. Or another example is GPIOs. An GPIO driven SPI or MDIO bus cannot be probed before all the devices providing the GPIOs are probed (right now GPIOs are 'special' and probed early, but this is ugly and there is no reason it couldn't be handled within the Linux driver model. I could see some form of .probe_prereqs member of a device driver, but what form should it take? Callback? Data structure? The field of prereqs (or rather figuring out the prereqs) is so large that I don't feel confident trying to define something. A callback is probably the most flexible if it could be called after each probe or registration event on other devices. The idea being that if the prereq call fails, then it will be tried again later. Or, thinking further, perhaps instead of a .probe_prereq, just have .probe returns -ETRYAGAIN and make the driver core put the device on the end of the queue of devices to get probed. This could get ugly in the driver core though. Needs more thought.... g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
