[PATCH v1 1/4] i2c: mux: Add i2c-arbitrator 'mux' driver

[Doug Anderson]

Stephen,

On Wed, Feb 13, 2013 at 4:41 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> OK, going to go with i2c-arbitrator-cros-ec.  Hopefully that sounds OK.
>
> That seems fine. The mechanism seems potentially a little more generic
> than just for cros-ec though, but I guess there's no harm naming it
> after the first implementation. That why "compatible" allows multiple
> entries anyway.

Yup, that was my thought.


>>> You should be able to replace all that with:
>>>
>>> module_platform_driver(&i2c_arbitrator_driver);
>>
>> Sigh.  Yeah, I had that.  ...but it ends up getting initted
>> significantly later in the init process and that was uncovering bugs
>> in other drivers where they weren't expressing their dependencies
>> properly.  I was going to try to fix those bugs separately but it
>> seemed to make some sense to prioritize this bus a little bit anyway
>> by using subsys_initcall().  ...but maybe that's just wrong.
>>
>> Unless you think it's a bug or terrible form to use subsys_initcall()
>> I'd rather leave that.  Is that OK?
>
> It's certainly a bug if it doesn't work correctly as
> module_platform_driver(). It'll have to be fixed sometime.
>
> I don't think it's a big enough issue for me to object to the patch
> providing it gets fixed sometime, but I've certainly seem other people
> push back harder on using subsys_initcall for expressing dependencies;
> it's not very extensible - what happens if there's another bug in some
> other driver that requires an even earlier level of initcall?

I don't like it either.  I'll give it a few hours tomorrow and
hopefully I can track down the problem.  If I can't track it down or
if I come up with a really good justification for why it's needed I'll
leave it with subsys_initcall() unless someone gives me a big nak.

-Doug