Re: Representing Embedded Architectures at the Kernel Summit

[Jamie Lokier <jamie@shareable.org>]

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.

I can see the callbacks being useful, and necessary, for drivers which
need to interleave their initialisation.  E.g. need to initialise an
external framebuffer chip before you can use it's I2C GPIOs, but then
need to initialise an I2C driver before you can read the framebuffer
parameters to finish setting up the framebuffer.

-- Jamie