From: Linus Walleij <linus.walleij@linaro.org>
To: Alexander Stein <alexander.stein@systec-electronic.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Alexandre Courbot <gnurou@gmail.com>,
Linux Input <linux-input@vger.kernel.org>
Subject: Re: gpio irqchip initialization race
Date: Fri, 1 Apr 2016 10:43:30 +0200 [thread overview]
Message-ID: <CACRpkdbfidnokJ2WyagdcEycDu3dXKVon2z4TKM7KhNg_Hyf9w@mail.gmail.com> (raw)
In-Reply-To: <44236018.b6N0xPzKYW@ws-stein>
On Fri, Apr 1, 2016 at 10:28 AM, Alexander Stein
<alexander.stein@systec-electronic.com> wrote:
> I suspect this depends on the time when gpio-keys is being probed. It will not
> be probed (or actually deferred) before mcp23s08_probe_one calls
> gpiochip_add_data as the parent GPIo controller to buttons is not present yet.
> I guess those error messages raise when gpio-keys is probed after
> gpiochip_add_data but before gpiochip_irqchip_add or
> gpiochip_set_chained_irqchip (in mcp23s08_irq_setup).
>
> The comment to _gpiochip_irqchip_add states the gpiochip has to be registered
> when calling. So to me this opens a rather small window where childs to
> gpiochip can be probed (parent is registered) but registering an interrupt
> will fail as the parent IRQ setup has not finished yet.
> Any suggestions how to fix that?
If that is what is happening it is indeed a very annoying race condition.
Strange we haven't seen it before!
So the problem doesn't exist when just using the gpiolib API or
the irqchip side independently, as we have been careful to make sure
that at least in modern drivers, these two are orthogonal.
I think the problem is that gpio-keys is calling gpio_to_irq(), and at that
point between gpiochip_add_data() but before gpiochip_irqchip_add()
it gets a bogus IRQ when it should be getting -EPROBE_DEFER.
I think we need to make sure that for drivers using gpiolib_irqchip_add()
-EPROBE_DEFER is returned for gpio[d]_to_irq() for this interrim
period.
What happens if you just apply this oneliner?
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index b747c76fd2b1..838643d2d976 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2004,7 +2004,7 @@ int gpiod_to_irq(const struct gpio_desc *desc)
VALIDATE_DESC(desc);
chip = desc->gdev->chip;
offset = gpio_chip_hwgpio(desc);
- return chip->to_irq ? chip->to_irq(chip, offset) : -ENXIO;
+ return chip->to_irq ? chip->to_irq(chip, offset) : -EPROBE_DEFER;
}
EXPORT_SYMBOL_GPL(gpiod_to_irq);
Yours,
Linus Walleij
next parent reply other threads:[~2016-04-01 8:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <44236018.b6N0xPzKYW@ws-stein>
2016-04-01 8:43 ` Linus Walleij [this message]
2016-04-01 8:47 ` gpio irqchip initialization race Linus Walleij
2016-04-01 8:56 ` Alexander Stein
2016-04-01 11:29 ` Linus Walleij
2016-04-01 12:45 ` Alexander Stein
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=CACRpkdbfidnokJ2WyagdcEycDu3dXKVon2z4TKM7KhNg_Hyf9w@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=alexander.stein@systec-electronic.com \
--cc=dmitry.torokhov@gmail.com \
--cc=gnurou@gmail.com \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-input@vger.kernel.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).