[PATCH 3/7] firmware: Add RNMI/RNME handler infrastructure

[Evgeny Voevodin]

On Fri, Apr 10, 2026 at 1:09 AM Anup Patel <anup at brainfault.org> wrote:
> > > Drop these platform callbacks from this patch. We will be
> > > extending sbi_irqchip to support NMIs. For NME, we will
> > > can simply crash.
> >
> > Agreed. I'll remove the platform callbacks. For RNMI, I'll
> > route through sbi_irqchip once that support is in place. For
> > RNME, I'll simplify to just print diagnostics and hang.

Hi Anup,

I've been rebasing and reworking the Smrnmi series based on our
discussion. I can remove the platform runtime callbacks
(ops->rnmi_handler / ops->rnme_handler) as agreed, and I can still
have the initial Smrnmi infrastructure in place: platforms install
trap handlers for RNMI/RNME vectors, detect the extension from
device tree, and initialize MNSCRATCH.

However, without irqchip NMI support there's no way for platforms
to actually handle NMIs once they fire. The default RNMI handler
would just log and hang. This means NMIs would need to stay
disabled (NMIE=0) until that support lands, even on platforms that
are otherwise ready for Smrnmi.

I couldn't find ongoing work on irqchip NMI support, so I wanted
to check how you'd like to proceed:

1. Ship the Smrnmi infrastructure with NMIs effectively disabled
   (log and hang). Platforms carry local patches for NMI handling
   until irqchip NMI support lands.

2. Keep ops->rnmi_handler as a temporary bridge, marked for
   migration to irqchip.

3. Include a minimal irqchip NMI extension in this series: a
   standalone registration API (sbi_irqchip_register_nmi_handler /
   sbi_irqchip_process_nmi) with a simple static callback -- not
   tied to a specific irqchip device since NMI is a system-level
   event. Platforms would register their NMI handler during
   irqchip_init, and sbi_trap_rnmi_handler would dispatch
   through it.

Thanks,
Evgeny