On Tue, Jun 16, 2009 at 2:06 AM, Mike Frysinger<vapier.adi@xxxxxxxxx> wrote: > On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote: >> James Bottomley wrote: >> Another issue that affects embedded architectures is drivers initialization >> order. There are a lot of cases when you need the drivers to be initialized in >> particular order, and current initcalls scheme does not allow fine grained >> control for it. > > example: device configuration information stored in i2c eeprom (i.e. > dimensions of attached framebuffer), but i2c is not available when > framebuffer layer is setup. framebuffer driver has to be built as a > module and loaded by userspace, or i2c information is read by > bootloader and passed down to the kernel. I experimented a bit with having some infrastructure for waiting for another device to get either registered as part of the phylib stuff I was doing. Here's the patchwork link to the discussion: 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. 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
