linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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>

  parent reply	other threads:[~2013-10-08 20:53 UTC|newest]

Thread overview: 17+ 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-28  9:57 ` getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver) Wolfram Sang
2013-08-29  8:58   ` Linus Walleij
2013-08-29 10:55     ` zhangfei gao
2013-08-29 17:11       ` Linus Walleij
2013-08-30  5:48       ` Tony Lindgren
2013-08-30  6:29         ` zhangfei gao
2013-08-30  8:27           ` Tony Lindgren
2013-09-12  1:12             ` zhangfei gao
2013-10-08  2:46               ` zhangfei gao
2013-10-08  5:26                 ` Wolfram Sang
2013-10-08 20:53             ` Wolfram Sang [this message]
2013-10-08 22:10               ` Tony Lindgren
2013-10-17 23:34                 ` Tony Lindgren
2013-10-18  7:32                 ` Wolfram Sang
2013-10-09  0:58               ` getting rid of subsys_initcall usage? 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@the-dreams.de \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).