Re: [PATCH 01/16] gpio: rcar: use postcore_init()

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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