Re: Representing Embedded Architectures at the Kernel Summit

[Jamie Lokier <jamie@shareable.org>]

Grant Likely wrote:
> On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokier<jamie@shareable.org> wrote:
> > 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.

Both of those cases look like a simple module init order problem.

I'm not seeing how it's a probe order problem.  Even if you can probe
PHYs independently first, how are they going to be bound to the
ethernet MACs, other than by dodgy defaults?

In any of your examples, is the "modprobe" symbol dependency order
insufficient, when they are external modules?

If the problem is simply that "modprobe" can calculate dependencies
but linked-in modules don't, maybe the solution is to use the symbolic
dependencies to calculate a linked-in driver initialisation order.

If it's a probe order problem, where there aren't symbolic
dependencies, then MODULE_PROVIDE("gpio") and MODULE_REQUIRE("gpio")
or something like that might handle those cases, except for tricky
ones like a GPIO-driven I2C bus which controls a GPIO chip.

-- Jamie