[PATCH 8/8] lib: sbi_irqchip: Allow registering interrupt handlers

[Anup Patel]

On Tue, Feb 10, 2026 at 10:28 PM Raymond Mao <raymondmaoca at gmail.com> wrote:
>
> Hi Anup,
>
> On Tue, Feb 10, 2026 at 11:40 AM Anup Patel <anup at brainfault.org> wrote:
> >
> > On Tue, Feb 10, 2026 at 12:29 AM Ray Mao <raymond.mao at riscstar.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Sat, Feb 7, 2026 at 5:26 AM Anup Patel <anup.patel at oss.qualcomm.com> wrote:
> > >>
> > >> To handle external interrupts in M-mode, the sbi_irqchip framework
> > >> must allow registering interrupt handlers from device drivers.
> > >>
> > >> Signed-off-by: Anup Patel <anup.patel at oss.qualcomm.com>
> > >> ---
> > >>  include/sbi/sbi_irqchip.h |  56 ++++++++++-
> > >>  lib/sbi/sbi_irqchip.c     | 202 +++++++++++++++++++++++++++++++++++++-
> > >>  lib/utils/irqchip/aplic.c |   1 +
> > >>  lib/utils/irqchip/imsic.c |   9 ++
> > >>  lib/utils/irqchip/plic.c  |   1 +
> > >>  5 files changed, 267 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/include/sbi/sbi_irqchip.h b/include/sbi/sbi_irqchip.h
> > >> index d2c47ae8..77b54110 100644
> > >> --- a/include/sbi/sbi_irqchip.h
> > >> +++ b/include/sbi/sbi_irqchip.h
> > >> @@ -18,12 +18,21 @@ struct sbi_scratch;
> > >>
> > >>  /** irqchip hardware device */
> > >>  struct sbi_irqchip_device {
> > >> -       /** Node in the list of irqchip devices */
> > >> +       /** Node in the list of irqchip devices (private) */
> > >>         struct sbi_dlist node;
> > >>
> > >> +       /** Internal data of all hardware interrupts of this irqchip (private) */
> > >> +       struct sbi_irqchip_hwirq_data *hwirqs;
> > >> +
> > >> +       /** List of interrupt handlers */
> > >> +       struct sbi_dlist handler_list;
> > >> +
> > >>         /** Unique ID of this irqchip */
> > >>         u32 id;
> > >>
> > >> +       /** Number of hardware IRQs of this irqchip */
> > >> +       u32 num_hwirq;
> > >> +
> > >>         /** Set of harts targetted by this irqchip */
> > >>         struct sbi_hartmask target_harts;
> > >>
> > >> @@ -32,6 +41,21 @@ struct sbi_irqchip_device {
> > >>
> > >>         /** Process hardware interrupts from this irqchip */
> > >>         int (*process_hwirqs)(struct sbi_irqchip_device *chip);
> > >> +
> > >> +       /** Setup a hardware interrupt of this irqchip */
> > >> +       int (*hwirq_setup)(struct sbi_irqchip_device *chip, u32 hwirq);
> > >> +
> > >> +       /** Cleanup a hardware interrupt of this irqchip */
> > >> +       void (*hwirq_cleanup)(struct sbi_irqchip_device *chip, u32 hwirq);
> > >> +
> > >> +       /** End of hardware interrupt of this irqchip */
> > >> +       void (*hwirq_eoi)(struct sbi_irqchip_device *chip, u32 hwirq);
> > >
> > >
> > > If hwirq_eoi() is an equivalent of claim(), then hwirq should be a pointer of memory, since we need to read and return the IDC_TOPI_ID from CLAIMI.
> > >
> >
> > I think the external interrupt handling flow is not clear
> > to you but let me try to explain.
> >
> > Whenever a hart receives external interrupt:
> >
> > 1) The sbi_trap_handler() is called by low-level handler
> > which in-turn calls sbi_irqchip_process()
> > 2) The sbi_irqchip_process() will in-turn call
> > process_hwirqs() of appropriate driver
> > 3) The process_hwirqs() in-case of APLIC
> > direct-mode will use IDC_TOPI_ID to determine
> > hwirq number and call sbi_irqchip_process_hwirq()
> > to handle it.
> >
> > If we have nested irqchip such as IMSIC+APLIC
> > then process_hwirqs() will be implemented by IMSIC
> > whereas APLIC will use sbi_irqchip_request_handler()
> > to register callback for IMSIC hwirqs. This means
> > sbi_irqchip_process() will call process_hwirqs() of
> > IMSIC and IMSIC will call APLIC interrupt handler
> > via sbi_irqchip_process_hwirq() whereas the APLIC
> > interrupt handler will again call sbi_irqchip_process_hwirq().
> >
> > In other words, we can support any irqchip topology.
> >
>
> I know this flow of interrupt handling, before I planned to read
> TOPI_ID in the eoi hook, but yes, I can do this in process_hwirqs()
> I almost rebased all my work in APLIC on top of your patch series. I
> will push a new version to RISE Gitlab and ping you and Robin.

Thanks Raymond, the intention of this series was to give
you a good starting point to build upon. I will send-out v2
pretty soon addressing comments from Drew and Samuel.

Regards,
Anup