Stephen, On Wed, Feb 13, 2013 at 4:41 PM, Stephen Warren <swar...@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 _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss