All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Linus Walleij <linusw@kernel.org>, Liang Hao <haohlliang@gmail.com>
Cc: hoan@os.amperecomputing.com, brgl@kernel.org,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpio: dwapb: Add robust error handling in interrupt handler
Date: Fri, 03 Jul 2026 23:40:50 +0200	[thread overview]
Message-ID: <875x2vlpjx.ffs@fw13> (raw)
In-Reply-To: <CAD++jL=Z-xKOpFLXa_fyoJ2K4vXnDPsHMsy2EUM1_Paaic-GMg@mail.gmail.com>

On Fri, Jul 03 2026 at 23:21, Linus Walleij wrote:
> On Fri, Jul 3, 2026 at 3:49 PM Liang Hao <haohlliang@gmail.com> wrote:
>
>> The current interrupt handler silently continues if an interrupt
>> handling fails, which may lead to interrupt storms. Add proper
>> error handling to gracefully recover from failed interrupt
>> handling.
>>
>> When generic_handle_irq() fails, the following recovery actions are
>> taken:
>>   - Write EOI to clear the pending interrupt
>>   - Mask the interrupt to prevent immediate re-triggering
>>   - Disable the interrupt to stop further interrupts on this line

This completely fails to explain WHY generic_handle_irq() fails.

There are only two reasons for that:

      1) The interrupt descriptor is not available (EINVAL)

      2) The platform mandates that the interrupt has to be handled in
         hard interrupt context (EPERM). This also emits a warning.

There is also zero information whether the irq mapping lookup returns a
valid interrupt in this scenario, so it's hard to tell what's really
going on.

As there is no mention of the warning I assume that's #1. Which means
this is papering over some underlying problem in that driver. Looking at
the counter measures makes it entirely clear:

    EOI, mask, disable

If there is no interrupt descriptor then the driver failed to mask and
disable the interrupt line at some point.

So this is just a lazy debugging aid for something which is not supposed
to happen in a sane and production ready driver.

Thanks,

        tglx





  reply	other threads:[~2026-07-03 21:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 13:48 [PATCH] gpio: dwapb: Add robust error handling in interrupt handler Liang Hao
2026-07-03 21:21 ` Linus Walleij
2026-07-03 21:40   ` Thomas Gleixner [this message]
2026-07-05  7:46     ` haohlliang
2026-07-05  7:47     ` [PATCH v4] gpio: dwapb: Mask interrupts at hardware initialization Liang Hao
2026-07-05  9:34       ` Thomas Gleixner
2026-07-07 12:32       ` Bartosz Golaszewski

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=875x2vlpjx.ffs@fw13 \
    --to=tglx@kernel.org \
    --cc=brgl@kernel.org \
    --cc=haohlliang@gmail.com \
    --cc=hoan@os.amperecomputing.com \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@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 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.