From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: bartosz.golaszewski@oss.qualcomm.com, marco.crivellari@suse.com,
arnd@arndb.de, tony@atomide.com, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, brgl@kernel.org
Subject: Re: [PATCH] Input: gpio-keys - do not BUG() on requested wakeirqs
Date: Thu, 5 Nov 2026 08:46:22 -0800 [thread overview]
Message-ID: <auyyyQN6_GIqeDox@google.com> (raw)
In-Reply-To: <20261105071952.33c39dd8@kemnade.info>
On Thu, Nov 05, 2026 at 07:19:52AM +0100, Andreas Kemnade wrote:
> On Wed, 04 Nov 2026 14:28:15 -0800
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> > Hi Andreas,
> >
> > On Wed, Nov 04, 2026 at 05:03:05PM +0100, Andreas Kemnade wrote:
> > > Having the IRQ handler called when enabled IRQs arrive should be considered
> > > as a feature not as a bug. So do not BUG() there when this happens.
> > >
> > > Fixes: 3717194f24922 ("Input: gpio-keys - add system suspend support for dedicated wakeirqs")
> > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > > ---
> > > drivers/input/keyboard/gpio_keys.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> > > index fbc31c5db3db..f1c31c5366f0 100644
> > > --- a/drivers/input/keyboard/gpio_keys.c
> > > +++ b/drivers/input/keyboard/gpio_keys.c
> > > @@ -412,7 +412,7 @@ static irqreturn_t gpio_keys_gpio_isr(int irq, void *dev_id)
> > > {
> > > struct gpio_button_data *bdata = dev_id;
> > >
> > > - BUG_ON(irq != bdata->irq);
> > > + BUG_ON((irq != bdata->irq) && (irq != bdata->wakeirq));
> > >
> > > if (bdata->button->wakeup) {
> > > const struct gpio_keys_button *button = bdata->button;
> >
> > Doesn't gpio_keys_irq_isr() have the same issue when a wakeirq is
> > configured for an interrupt-only button?
> >
> yes, it has.
>
> > Also, neither gpio_keys_gpio_isr() nor gpio_keys_irq_isr() uses the irq
> > argument for anything else, so instead of expanding the condition, could
> > we simply drop the BUG_ON() from both handlers?
> >
> Sure, was just unsure about the intention of escalating things so much here.
> I think we should trust the interrupt system a bit.
Will you be sending a new patch?
--
Dmitry
prev parent reply other threads:[~2026-11-05 16:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 16:03 [PATCH] Input: gpio-keys - do not BUG() on requested wakeirqs Andreas Kemnade
2026-11-04 22:28 ` Dmitry Torokhov
2026-11-05 6:19 ` Andreas Kemnade
2026-11-05 16:46 ` Dmitry Torokhov [this message]
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=auyyyQN6_GIqeDox@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=andreas@kemnade.info \
--cc=arnd@arndb.de \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=tony@atomide.com \
/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.