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
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
