[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:
> Clearly, for RNME, the existing _trap_handler() can be re-used
> because _trap_handler() depends on same set of CSRs and mret
> instruction.
>
> I agree that code path RNME should be different from RNMI but
> that does not mean we need three separate low-level handlers.
>
> Further, the Smrnmi spec also states the following:
> "For example, some implementations might use the address specified
> in mtvec as the RNMI exception trap handler."
>
> This means on platforms where mtvec points to the RNMI exception
> trap handler address, we will have to anyway re-use _trap_handler()
> and sbi_trap_handler() for RNMI exception handling.

Thanks, I see your point about reusing _trap_handler/_hyp for RNME.
Initially I thought that providing platform flexibility to handle
RNME explicitly would be beneficial, but I agree -- we can reuse
the existing trap handling machinery since RNME is fundamentally
a regular M-mode trap entering at a different address.

I'll remove _rnme_handler in v2 but will keep the platform callback
for setting up RNMI/RNME vectors, since these are implementation-
defined and each platform needs to initialize them. I'll replace
the _rnme_handler argument with the trap handler address (read
from mtvec) so the platform can program NMEVEC appropriately.

Thanks,
Evgeny