Re: Representing Embedded Architectures at the Kernel Summit

[Grant Likely <grant.likely@secretlab.ca>]

On Tue, Jun 16, 2009 at 2:07 PM, Jamie Lokier<jamie@shareable.org> wrote:
> 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?

In both cases the driver is waiting for a specific instance, but has
no idea which driver will provide that service.

For the Ethernet example:  Both the MAC driver and the MDIO bus driver
are registered independently (say via either the platform bus).  The
MDIO bus driver creates a new mdio_bus instance and registers a
phy_device for each child on the bus.  The pdata for the MAC driver
only contains the address of the phy, but it does not know which
driver handles the MDIO bus and it does not know what driver will
handle the phy.  All the MAC cares about dereferencing the phy address
to get a pointer to the phy_device structure which only works after
the MDIO bus is probed and the correct phy_device is registered..
Module dependencies won't help here because the MAC cannot know what
module to depend against.  Plus, in some cases, the MAC will be used
without a PHY, in which case it cannot depend on any phy modules.

For the GPIO example, same thing.  Something like the i2c-gpio driver
doesn't know anything about which device provides the GPIO signals.
It is only handled GPIO numbers for each signal and it cannot be
probed before all the required GPIOs are registered with the system.
Again module dependencies don't work because the driver doesn't know
which GPIO driver it will get bound against at run time.

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

Ugh.... it feels too coarse grained to me.  It solves some of the
problems, but still requires playing dirty tricks for the tricky cases
which scuttles the whole lot.  ie. your i2c GPIO chip example.
Another driver wired to one of those 2nd level GPIOs and using
MODULE_REQUIRE("gpio") would immediately be defeated and would need
some other method to indicate the dependency.  Plus there is the
question when stuff is loaded as modules as to how does the kernel
know when MODULE_PROVIDE("gpio") is complete?  What if I load the gpio
driver after the gpio-i2c driver?  I'd much rather define the
dependency at the resource level, not module level because that is
what the driver is actually needing.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.