Re: [PATCH v2 5/5] watchdog: qcom: Register pretimeout interrupt as NMI

[Doug Anderson]

Hi,

On Fri, Aug 28, 2026 at 6:00 PM Mayank Rungta <mrungta@xxxxxxxxxx> wrote:
>
> When a system is completely unresponsive due to an interrupt storm or
> deadlocked CPU cores with standard interrupts disabled, a standard
> watchdog pretimeout bark interrupt will fail to execute, preventing the
> pretimeout governor from capturing CPU backtraces before the hardware
> reset bite.
>
> Attempt to request the Qualcomm watchdog pretimeout bark interrupt as an
> NMI (or pseudo-NMI) using request_nmi(). If NMI registration is not
> supported on the platform (e.g. pseudo-NMIs are disabled), gracefully
> fall back to a standard interrupt via devm_request_irq().
>
> When NMI is used, register a devres cleanup action to free the NMI upon
> driver unbind, and use enable_nmi() and disable_nmi() during start and
> stop.
>
> Assisted-by: Antigravity:gemini
> Signed-off-by: Mayank Rungta <mrungta@xxxxxxxxxx>
> ---
>  drivers/watchdog/qcom-wdt.c | 52 +++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 48 insertions(+), 4 deletions(-)

Sashiko had some feedback here [1]. I think the right resolution is to
not try to enable/disable the NMI when the watchdog is
enabled/disabled, just like we do for normal IRQs.

For NMIs:
* We're forced to start out in "disabled" state (NOAUTOEN).
* We're forced to disable before we free or we get a WARN_ON.

None of those are really problems, though. After we request the NMI,
there's no problem enabling it right away, is there? Then, if we do
that, we can make qcom_wdt_free_nmi() unconditionally call
disable_nmi() before calling free_nmi(). Now everything is nice and
symmetric and simpler.

[1] https://lore.kernel.org/all/20260829011545.3873A1F000E9@xxxxxxxxxxxxxxx/


-Doug