Re: Representing Embedded Architectures at the Kernel Summit

[Marcel Holtmann <marcel@holtmann.org>]

Hi Jamie,

> > > 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.

for the loading order so far I have always added a dummy symbol to
ensure that loading of modules are in the right order. Seems to be a
good enough approach.

Regards

Marcel