Re: [PATCH 2/3] genirq: Export NMI APIs

Doug Anderson <[email protected]> Thu, 30 Jul 2026 14:49:30 -0700
Newsgroups org.kernel.vger.linux-watchdog,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel
Message-ID <CAD=FV=V+nrmtK6FJ2G+LGnvxkLEWMR+2A253-gQ2smxf9LoEWg@mail.gmail.com>
Hi,

On Thu, Jul 30, 2026 at 2:33=E2=80=AFPM Mayank Rungta via B4 Relay
<[email protected]> wrote:
>
> From: Mayank Rungta <[email protected]>
>
> Currently, request_nmi(), free_nmi(), enable_nmi() and disable_nmi_nosync=
()
> are restricted to built-in kernel code because they are not exported to
> loadable modules.
>
> Export these APIs to allow loadable modules to register and manage NMIs.
> This allows watchdog drivers configured as loadable modules to register
> their bark interrupt as an NMI.
>
> Signed-off-by: Mayank Rungta <[email protected]>
> ---
>  kernel/irq/manage.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 2fbff2618a1e..fb0b8da32f4c 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -766,6 +766,7 @@ void disable_nmi_nosync(unsigned int irq)
>  {
>         disable_irq_nosync(irq);
>  }
> +EXPORT_SYMBOL_GPL(disable_nmi_nosync);
>
>  void __enable_irq(struct irq_desc *desc)
>  {
> @@ -833,6 +834,7 @@ void enable_nmi(unsigned int irq)
>  {
>         enable_irq(irq);
>  }
> +EXPORT_SYMBOL_GPL(enable_nmi);
>
>  static int set_irq_wake_real(unsigned int irq, unsigned int on)
>  {
> @@ -2080,6 +2082,7 @@ const void *free_nmi(unsigned int irq, void *dev_id=
)
>
>         return __cleanup_nmi(irq, desc);
>  }
> +EXPORT_SYMBOL_GPL(free_nmi);
>
>  /**
>   * request_threaded_irq - allocate an interrupt line
> @@ -2342,6 +2345,7 @@ int request_nmi(unsigned int irq, irq_handler_t han=
dler,
>
>         return retval;
>  }
> +EXPORT_SYMBOL_GPL(request_nmi);

This seems reasonable to me. One thought I had was that we could
possibly get by with fewer exported symbols by changing
disable_nmi_nosync() and enable_nmi() to "static inline" functions in
the header file. That being said, what Mayank has here feels slightly
better to me.

Reviewed-by: Douglas Anderson <[email protected]>