The "drivers in question" aren't necessarily all i2c_adapter drivers,
or even *only* i2c_adapter drivers (they could expose an i2c_adapter
interface as a secondary function).
I think I introduced the term "system bus driver", but you didn't read
it the way I meant it. To elaborate a bit: "system bus" as in "a bus
used for system bringup and management". On PCs, the main such bus is
PCI but there are little fragments of other stuff too. Many smaller
embedded systems use I2C for that (and don't have PCI). The drivers
relevant are both (a) the bus driver itself, e.g. i2c_adapter or its
PCI analogue, and (b) drivers for devices on that bus.
So while (a) having i2c and some i2c_adapter drivers at subsys_initcall
is an essential first step, the *link order* issue comes up in two other
ways: (b1) drivers "outside the I2C tree and *before* it in link order"
that may need to be subsys_initcall too, thus depending on core I2C
stuff being available, and (b2) some other subsystems may need to rely
on I2C in their bringup, such as by enabling a specific power domain
and the chips using it.
But even given that, I2C is currently sequenced *late* for systems where
it serves as a system control/management bus; see (b1) and (b2) above.
Not really; those particular i2c_adapter drivers don't actually get used
early in system bringup. They aren't subsys_initcall, and neither of
the (b1) or (b2) cases apply. Moving those adapters doesn't imply moving
those other subsystems.
Example: USB subsystem is initialized early (subsystem_init). From then
on, drivers can register freely -- including i2c-tiny-usb. The usbcore
code remembers them, and then when the HCDs (analogues: i2c_adapter) start
to connect, usb devices enumerate and get bound to devices as needed. So
it doesn't matter *when* i2c-tiny-usb does its module_init(), so long as
it's after usbcore does its subsys_initcall.
Likewise for PCI. As I said earlier, GPIO is already covered (has to
be usable before initcalls could be run, etc). I think i2c-parport
should behave OK too, and i2c-parport-light.
I think you're looking at this wrong. First, as I noted already,
most of those drivers don't have this issue. Second, if there *are*
such issues, they'd be bus-specific issues to resolve, not reasons
to avoid fixing the (b1) and (b2) problems by moving I2C earlier.
- Dave
--
