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

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> [131008 14:01]:
> On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote:
> > * zhangfei gao <zhangfei.gao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [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.

Regards,

Tony