From mboxrd@z Thu Jan 1 00:00:00 1970 From: zhangfei Subject: Re: getting rid of subsys_initcall usage? Date: Wed, 09 Oct 2013 08:58:57 +0800 Message-ID: <5254AA51.706@linaro.org> References: <1376987548-12366-1-git-send-email-zhangfei.gao@linaro.org> <20130828095706.GH4086@katana> <20130830054858.GR7656@atomide.com> <20130830082712.GT7656@atomide.com> <20131008205304.GA29121@katana> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131008205304.GA29121@katana> Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Wolfram Sang , Tony Lindgren Cc: zhangfei gao , Linus Walleij , Baruch Siach , "linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Haojian Zhuang List-Id: linux-i2c@vger.kernel.org On 10/09/2013 04:53 AM, Wolfram Sang wrote: > On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote: >> * zhangfei gao [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. However, this may requires I2C, GPIO, pinctrl all use subsys_initcall. -EPROBE_DEFER still be returned, if pinctrl happen to use module_platform_driver, which is most case in drivers/pinctrl/. 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. > Thanks for clarify the concern.