From: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
To: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Cc: zhangfei gao
<zhangfei.gao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Zhangfei Gao
<zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>,
"linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Haojian Zhuang
<haojian.zhuang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver)
Date: Tue, 8 Oct 2013 22:53:04 +0200 [thread overview]
Message-ID: <20131008205304.GA29121@katana> (raw)
In-Reply-To: <20130830082712.GT7656-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]
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.
Regards,
Wolfram
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: wsa@the-dreams.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver)
Date: Tue, 8 Oct 2013 22:53:04 +0200 [thread overview]
Message-ID: <20131008205304.GA29121@katana> (raw)
In-Reply-To: <20130830082712.GT7656@atomide.com>
On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote:
> * zhangfei gao <zhangfei.gao@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.
Regards,
Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131008/2d209bf9/attachment.sig>
next prev parent reply other threads:[~2013-10-08 20:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-20 8:32 [PATCH RESEND] i2c: designware: use module_platform_driver Zhangfei Gao
2013-08-20 8:32 ` Zhangfei Gao
[not found] ` <1376987548-12366-1-git-send-email-zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-08-28 9:57 ` getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver) Wolfram Sang
2013-08-28 9:57 ` Wolfram Sang
2013-08-29 8:58 ` Linus Walleij
2013-08-29 8:58 ` Linus Walleij
[not found] ` <CACRpkdb1p1=3a0PM+r2ZrMN+ECv5BAZFdv2omDK5npaer4ddcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-29 10:55 ` zhangfei gao
2013-08-29 10:55 ` zhangfei gao
[not found] ` <CAMj5BkhQkwb+T9VepN7UrWNRSgtv=Dw-Sa-gv0orOANo55iqNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-29 17:11 ` Linus Walleij
2013-08-29 17:11 ` Linus Walleij
2013-08-30 5:48 ` Tony Lindgren
2013-08-30 5:48 ` Tony Lindgren
[not found] ` <20130830054858.GR7656-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2013-08-30 6:29 ` zhangfei gao
2013-08-30 6:29 ` zhangfei gao
[not found] ` <CAMj5BkiDExikXi3JcVhO7RN8_82eGYhq3i6oPf5Wbipy=N+iHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-30 8:27 ` Tony Lindgren
2013-08-30 8:27 ` Tony Lindgren
[not found] ` <20130830082712.GT7656-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2013-09-12 1:12 ` zhangfei gao
2013-09-12 1:12 ` zhangfei gao
[not found] ` <CAMj5BkgqBCh0316NmoP_XMXvJTVQxxvUvs63wZfS_TvNLdqAfg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-08 2:46 ` zhangfei gao
2013-10-08 2:46 ` zhangfei gao
[not found] ` <CAMj5Bki+BS=3sWCRdrDOEKpt6Bj+4vm0zKCJ4YBAudcqbAZySw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-08 5:26 ` Wolfram Sang
2013-10-08 5:26 ` Wolfram Sang
2013-10-08 20:53 ` Wolfram Sang [this message]
2013-10-08 20:53 ` Wolfram Sang
2013-10-08 22:10 ` Tony Lindgren
2013-10-08 22:10 ` Tony Lindgren
[not found] ` <20131008221056.GW8313-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2013-10-17 23:34 ` Tony Lindgren
2013-10-17 23:34 ` Tony Lindgren
2013-10-18 7:32 ` Wolfram Sang
2013-10-18 7:32 ` Wolfram Sang
2013-10-09 0:58 ` getting rid of subsys_initcall usage? zhangfei
2013-10-09 0:58 ` zhangfei
2013-08-30 1:51 ` zhangfei
2013-08-30 1:51 ` zhangfei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131008205304.GA29121@katana \
--to=wsa-z923lk4zbo2bacvfa/9k2g@public.gmane.org \
--cc=baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org \
--cc=haojian.zhuang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
--cc=zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=zhangfei.gao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.