[PATCH v2 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Stephen Warren]

On 02/15/2013 10:25 AM, Doug Anderson wrote:
> Stephen,
> 
> New version will come shortly with fixes below...
> 
> 
> On Fri, Feb 15, 2013 at 8:39 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 02/14/2013 05:21 PM, Doug Anderson wrote:
>>> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
>>> that the Embedded Controller (EC) on the ARM Chromebook expects to use
>>> for bus multimastering.  This i2c-arbitrator-cros-ec driver could also
>>> be used in other places where standard I2C bus arbitration can't be
>>> used and two extra GPIOs are available for arbitration.
...
>>> +subsys_initcall(i2c_arbitrator_init);
>>
>> You mentioned that you only saw problems using
>> module_init/module_platform_driver in your downstream tree, so the
>> problem doesn't affect upstream. Presumably those problems would be
>> fixed when upstreaming any other drivers into the mainline kernel. I'd
>> still be tempted to just use module_platform_driver here. But, I guess
>> I'm fine with the patch either way; I'll leave the call to Wolfram.
> 
> I take it you thought my "since this provides a bus it should be a
> subsystem" argument was BS?

I think subsystem and bus are different things. A driver for a specific
device provides a bus, and happens to use the facilities (or be part of)
a specific subsystem. Generally the subsystem isn't actually the bus
itself (although perhaps something like PCI could be an exception).

Admittedly I have no history/experience really with what the different
initcall levels are really intended for, but my suspicion is that
subsys_initcall is intended for whole subsystems to initialize their
infra-structure before handling drivers or serving requests out to other
code. But, who knows.

Either way though, I believe that upstream, no driver should be relying
on specific initcall levels in order to get dependencies/initialization
ordering correct.