Hi Linus, On Tuesday 19 November 2013 10:57:43 Linus Walleij wrote: > On Mon, Nov 18, 2013 at 3:00 PM, Laurent Pinchart wrote: > > I'm not against moving the gpio-rcar initialization to postcore or subsys > > initcall, but in that case I believe we should standardize (or at least > > try > > to) this across the GPIO drivers. We currently have > > > > $ cat drivers/gpio/gpio-*.c | grep _initcall | grep '^[a-z]' | sed > > 's/(.*//' | sort | uniq -c > > 2 arch_initcall > > 1 core_initcall > > 1 device_initcall > > 1 late_initcall > > 11 postcore_initcall > > 2 pure_initcall > > 31 subsys_initcall > > > > $ cat drivers/gpio/gpio-*.c | grep 'module_.*_driver' | sed 's/(.*//' | > > sort | uniq -c > > 3 module_i2c_driver > > 4 module_pci_driver > > 23 module_platform_driver > > 1 module_spi_driver > > > > Linus, do you have any guidelines on this ? > > The general guideline, as everybody should be aware ;-) is that we > should always use module_init(), i.e. device_initcall() and let deferred > probe handle any dependencies. Thought so, good :-) > The only exception would be things like timers and interrupt controllers... I wouldn't be against moving regulators and gpios one level up in the initcall order, given that they provide resources used by a very large number of drivers. That would be an optimization only though, and not a work around broken probe deferral paths. > Usually not relying on deferred probe is a sign of bugs in the deferral > probe path. > > I know "my" drivers have this problem too, I would prefer that we try to fix > the root issue instead of trying to shovel initcalls around. Sounds good to me. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
