getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver)

[Tony Lindgren]

* Tony Lindgren <tony at atomide.com> [131008 15:19]:
> * Wolfram Sang <wsa at the-dreams.de> [131008 14:01]:
> > On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote:
> > > * zhangfei gao <zhangfei.gao at gmail.com> [130829 23:36]:
> > > > What about concerns from Wolfram:
> > > > " Other people might be
> > > > depending on subsys_initcall to get I2C active before they want to
> > > > activate, say, PMICs. So, I fear regressions, since deferred probing
> > > > might not be available in the needed places to avoid these regressions."
> > > 
> > > There should not be any reason to get a PMIC activated
> > > early on. The system should be booting already at that point,
> > > and the PMIC related init can be done later on.
> > 
> > Okay, here is a more concrete example:
> > 
> > Consider the amplifier driver 'sound/soc/codecs/max9768.c'. Back then, unaware
> > of deferred probing, I wrote the following code to get the GPIOs (which are
> > optional):
> > 
> > 	err = gpio_request_one(pdata->mute_gpio, GPIOF_INIT_HIGH, "MAX9768 Mute");
> > 	max9768->mute_gpio = err ?: pdata->mute_gpio;
> > 
> > And later in the process:
> > 
> >         if (gpio_is_valid(max9768->mute_gpio)) {
> >                 ret = snd_soc_add_codec_controls(codec, max9768_mute,
> >                                 ARRAY_SIZE(max9768_mute));
> >                 if (ret)
> >                         return ret;
> >         }
> > 
> > So, the mute control will only be added if the gpio_request succeeded. On that
> > particular board, the mute GPIO was wired to an I2C GPIO controller. If I now
> > change the I2C (or GPIO) driver from subsys_initcall to module_init, then the
> > gpio_request in the amplifier driver could hit -EPROBE_DEFER and the mute
> > control will then disappear. Yes, the driver can be fixed easily, yet I fear a
> > number of regressions like this. Instead of people digging into why things
> > disappear after a kernel update, I wonder if there is a way to guide users if
> > this happens. I didn't have time for that, though, sadly. Still, it makes me
> > wonder how easily we could shift from subsys_initcall to module_init, although
> > I'd really love to get away from subsys_initcall in device drivers.
> 
> Well it should be pretty trivial to update drivers to use deferred
> probing. Maybe some spatch to check for that in driver probes would
> help getting an idea how many might be affected?
> 
> Anyways, it should be fixed as otherwise we'll just dig ourselves
> deeper into the mess of things not working as loadable modules.

BTW, another place where things can go wrong is if there's an irqchip
driver that is being set up at module_init time. If an interrupt client
driver does irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0), the
resources may not have been initialize for the DT case as those are
populated triggered by of_platform_populate().

The fix there is to use irq = irq_of_parse_and_map(pdev->dev.of_node, 0)
instead. Or somehow make of_platform_populate() support -EPROBE_DEFER.

Just FYI,

Tony

Tony