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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html