Linux RISC-V AIA Support

drivers/irqchip/irq-riscv-imsic-state.c new file +5 -0

+static int __init imsic_parse_fwnode(struct fwnode_handle *fwnode,
+				     struct imsic_global_config *global,
+				     u32 *nr_parent_irqs,
+				     u32 *nr_mmios)
+{

drivers/irqchip/irq-riscv-imsic-state.c new file +5 -0

+	if (rc) {
+		pr_err("%pfwP: number of interrupt identities not found\n", fwnode);
+		return rc;
+	}
+

Quoted 5 lines · Anup Patel

drivers/irqchip/irq-riscv-imsic-state.c new file +5 -0

+static int __init imsic_parse_fwnode(struct fwnode_handle *fwnode,
+                                  struct imsic_global_config *global,
+                                  u32 *nr_parent_irqs,
+                                  u32 *nr_mmios)
+{

...

drivers/irqchip/irq-riscv-imsic-state.c line 614

Quoted 12 lines

drivers/irqchip/irq-riscv-imsic-state.c new file +12 -0

+     /*
+      * Find first bit position of group index.
+      * If not specified assumed the default APLIC-IMSIC configuration.
+      */
+     rc = of_property_read_u32(to_of_node(fwnode), "riscv,group-index-shift",
+                               &global->group_index_shift);
+     if (rc)
+             global->group_index_shift = IMSIC_MMIO_PAGE_SHIFT * 2;
+
+     /* Find number of interrupt identities */
+     rc = of_property_read_u32(to_of_node(fwnode), "riscv,num-ids",
+                               &global->nr_ids);

Will here check if the pass-in interrupt identity number is (multi-64 -1) && between [63, 2047]?
Per spec AIA v1.0, Sec. 3.1 Interrupt files and interrupt identities:
"The number of interrupt identities supported by an interrupt file (and hence the number of active
bits in each array) is one less than a multiple of 64, and may be a minimum of 63 and a maximum
of 2047."

Quoted 6 lines

drivers/irqchip/irq-riscv-imsic-state.c new file +5 -0

+     if (rc) {
+             pr_err("%pfwP: number of interrupt identities not found\n", fwnode);
+             return rc;
+     }
+

...

Quoted 24 lines · Eric Cheng

Quoted 5 lines · Anup Patel

drivers/irqchip/irq-riscv-imsic-state.c new file +5 -0

+static int __init imsic_parse_fwnode(struct fwnode_handle *fwnode,
+                                  struct imsic_global_config *global,
+                                  u32 *nr_parent_irqs,
+                                  u32 *nr_mmios)
+{

...

drivers/irqchip/irq-riscv-imsic-state.c line 614

Quoted 12 lines

drivers/irqchip/irq-riscv-imsic-state.c new file +12 -0

+     /*
+      * Find first bit position of group index.
+      * If not specified assumed the default APLIC-IMSIC configuration.
+      */
+     rc = of_property_read_u32(to_of_node(fwnode), "riscv,group-index-shift",
+                               &global->group_index_shift);
+     if (rc)
+             global->group_index_shift = IMSIC_MMIO_PAGE_SHIFT * 2;
+
+     /* Find number of interrupt identities */
+     rc = of_property_read_u32(to_of_node(fwnode), "riscv,num-ids",
+                               &global->nr_ids);

Quoted 8 lines

Will here check if the pass-in interrupt identity number is (multi-64 -1) && between [63, 2047]?
Per spec AIA v1.0, Sec. 3.1 Interrupt files and interrupt identities:
"The number of interrupt identities supported by an interrupt file (and hence the number of active
bits in each array) is one less than a multiple of 64, and may be a minimum of 63 and a maximum
of 2047."

There is already a check on global->nr_ids to ensure the above is satisfied. Please see further below in imsic_parse_fwnode() function.

Quoted 9 lines

Quoted 6 lines

drivers/irqchip/irq-riscv-imsic-state.c new file +5 -0

+     if (rc) {
+             pr_err("%pfwP: number of interrupt identities not found\n", fwnode);
+             return rc;
+     }
+

...

Regards,
Anup

drivers/irqchip/irq-riscv-aplic-main.c +3 -0

+static const struct of_device_id aplic_match[] = {
+ { .compatible = "riscv,aplic" },
+ {}

Quoted 4 lines

drivers/irqchip/irq-riscv-aplic-main.c +3 -0

+static const struct of_device_id aplic_match[] = {
+ { .compatible = "riscv,aplic" },
+ {}

drivers/irqchip/irq-riscv-aplic-main.c line 211

Quoted 10 lines

drivers/irqchip/irq-riscv-aplic-main.c +10 -0

+};
+
+static struct platform_driver aplic_driver = {
+ .driver = {
+  .name  = "riscv-aplic",
+  .of_match_table = aplic_match,
+ },
+ .probe = aplic_probe,
+};
+builtin_platform_driver(aplic_driver);

Dear Anup Patel and all concerned,

I am writing to inquire about the historical rationale behind defining the APLIC driver's initialization priority using builtin_platform_driver in the current implementation.

In our environment, we are encountering an issue where this priority level causes ACPI-based PCIe enumeration to be executed in the system_unbound_wq work queue. This parallel execution model results in PCIe devices being enumerated in an arbitrary order rather than strictly following the sequence defined in the ACPI DSDT table.

The random enumeration order is adversely affecting customer experience, particularly in scenarios where device ordering is critical for proper system operation or application compatibility.

We are considering modifying the APLIC driver's initialization priority to ensure PCIe enumeration occurs sequentially according to the DSDT specification. However, before proceeding with such changes, we wanted to consult with you regarding:

1. Were there specific technical considerations that led to the current priority selection?
2. Are there any potential side effects or broader impacts that we might have overlooked?
3. Would you support such a priority adjustment, or do you have alternative suggestions to address the enumeration order issue?

We greatly appreciate your insights and expertise on this matter, as it will help us make an informed decision while maintaining system stability and compatibility.

Thank you for your time and consideration.

Quoted 37 lines

Quoted 4 lines

drivers/irqchip/irq-riscv-aplic-main.c +3 -0

+static const struct of_device_id aplic_match[] = {
+ { .compatible = "riscv,aplic" },
+ {}

drivers/irqchip/irq-riscv-aplic-main.c line 211

Quoted 10 lines

drivers/irqchip/irq-riscv-aplic-main.c +10 -0

+};
+
+static struct platform_driver aplic_driver = {
+ .driver = {
+  .name  = "riscv-aplic",
+  .of_match_table = aplic_match,
+ },
+ .probe = aplic_probe,
+};
+builtin_platform_driver(aplic_driver);

Dear Anup Patel and all concerned,

I am writing to inquire about the historical rationale behind defining the APLIC driver's initialization priority using builtin_platform_driver in the current implementation.

In our environment, we are encountering an issue where this priority level causes ACPI-based PCIe enumeration to be executed in the system_unbound_wq work queue. This parallel execution model results in PCIe devices being enumerated in an arbitrary order rather than strictly following the sequence defined in the ACPI DSDT table.

The random enumeration order is adversely affecting customer experience, particularly in scenarios where device ordering is critical for proper system operation or application compatibility.

We are considering modifying the APLIC driver's initialization priority to ensure PCIe enumeration occurs sequentially according to the DSDT specification. However, before proceeding with such changes, we wanted to consult with you regarding:

1. Were there specific technical considerations that led to the current priority selection?
2. Are there any potential side effects or broader impacts that we might have overlooked?
3. Would you support such a priority adjustment, or do you have alternative suggestions to address the enumeration order issue?

Quoted 5 lines

We greatly appreciate your insights and expertise on this matter, as it will help us make an informed decision while maintaining system stability and compatibility.

Thank you for your time and consideration.

IRQ subsystem maintainers rejected the idea of relying on initcalls to enforce probe order because initcalls do not guarantee ordering. The Linux driver model instead ensures probe order through device dependencies. Since PCI INTx depends on the APLIC being probed first, the PCI host bridge probe cannot occur until after the APLIC probe completes. This requirement and behavior are the same for both DT and ACPI. In DT, the driver model uses fw_devlink to establish probe ordering, while in ACPI this is handled through either an explicit _DEP or, on RISC-V, the GSI mapping.
Typically, this dependency appears in the DSDT only for the PCI host bridge. Individual PCIe devices are enumerated through the standard PCI scan once the host bridge has been probed. Therefore, I’m not sure what you meant by a probe sequence defined in the DSDT for PCIe devices. Regards,
Sunil

2. But the OS enumerates them in random order upon each boot (first boot sequence ≠ second boot sequence) first boot sequence ~ # dmesg |grep -i "PCI Root"

[ 8794.588531] ACPI: PCI Root Bridge [PC08] (domain 0006 [bus 80-ff])
[ 8794.624478] ACPI: PCI Root Bridge [PC06] (domain 0005 [bus 00-ff])
[ 8794.672741] ACPI: PCI Root Bridge [PC10] (domain 0008 [bus 00-ff])
[ 8794.696680] ACPI: PCI Root Bridge [PC07] (domain 0006 [bus 00-7f])
[ 8794.728234] ACPI: PCI Root Bridge [PC11] (domain 0009 [bus 00-ff])
[ 8794.755098] ACPI: PCI Root Bridge [PC09] (domain 0007 [bus 00-ff])
second boot sequence ~ # dmesg |grep -i "PCI Root"
[ 8794.588531] ACPI: PCI Root Bridge [PC09] (domain 0007 [bus 00-ff])
[ 8794.624478] ACPI: PCI Root Bridge [PC06] (domain 0005 [bus 00-ff])
[ 8794.672741] ACPI: PCI Root Bridge [PC08] (domain 0006 [bus 80-ff])
[ 8794.696680] ACPI: PCI Root Bridge [PC11] (domain 0009 [bus 00-ff])
[ 8794.728234] ACPI: PCI Root Bridge [PC07] (domain 0006 [bus 00-7f])
[ 8794.755098] ACPI: PCI Root Bridge [PC10] (domain 0008 [bus 00-ff])

This creates a critical issue: when NVMe devices are connected to these host bridges, the unpredictable kernel scanning sequence causes device identifiers (e.g., /dev/nvme0n1, /dev/nvme1n1) to change across reboots. In server environments, such device naming instability is unacceptable as it breaks storage configuration reliability and consistency.

Quoted 43 lines

Quoted 37 lines

Quoted 4 lines

drivers/irqchip/irq-riscv-aplic-main.c +3 -0

+static const struct of_device_id aplic_match[] = {
+ { .compatible = "riscv,aplic" },
+ {}

drivers/irqchip/irq-riscv-aplic-main.c line 211

Quoted 10 lines

drivers/irqchip/irq-riscv-aplic-main.c +10 -0

+};
+
+static struct platform_driver aplic_driver = {
+ .driver = {
+  .name  = "riscv-aplic",
+  .of_match_table = aplic_match,
+ },
+ .probe = aplic_probe,
+};
+builtin_platform_driver(aplic_driver);

Dear Anup Patel and all concerned,

I am writing to inquire about the historical rationale behind defining the APLIC driver's initialization priority using builtin_platform_driver in the current implementation.

In our environment, we are encountering an issue where this priority level causes ACPI-based PCIe enumeration to be executed in the system_unbound_wq work queue. This parallel execution model results in PCIe devices being enumerated in an arbitrary order rather than strictly following the sequence defined in the ACPI DSDT table.

The random enumeration order is adversely affecting customer experience, particularly in scenarios where device ordering is critical for proper system operation or application compatibility.

We are considering modifying the APLIC driver's initialization priority to ensure PCIe enumeration occurs sequentially according to the DSDT specification. However, before proceeding with such changes, we wanted to consult with you regarding:

1. Were there specific technical considerations that led to the current priority selection?
2. Are there any potential side effects or broader impacts that we might have overlooked?
3. Would you support such a priority adjustment, or do you have alternative suggestions to address the enumeration order issue?

Quoted 5 lines

We greatly appreciate your insights and expertise on this matter, as it will help us make an informed decision while maintaining system stability and compatibility.

Thank you for your time and consideration.

Quoted 15 lines

IRQ subsystem maintainers rejected the idea of relying on initcalls to enforce probe order because initcalls do not guarantee ordering. The Linux driver model instead ensures probe order through device dependencies. Since PCI INTx depends on the APLIC being probed first, the PCI host bridge probe cannot occur until after the APLIC probe completes. This requirement and behavior are the same for both DT and ACPI. In DT, the driver model uses fw_devlink to establish probe ordering, while in ACPI this is handled through either an explicit _DEP or, on RISC-V, the GSI mapping.
Typically, this dependency appears in the DSDT only for the PCI host bridge. Individual PCIe devices are enumerated through the standard PCI scan once the host bridge has been probed. Therefore, I’m not sure what you meant by a probe sequence defined in the DSDT for PCIe devices. Regards,
Sunil

I understand the scenario you described with a single PCI host bridge, where devices are enumerated through standard PCIe scanning after the host bridge completes probing. However, in ARM and RISC-V architectures, systems often have multiple PCI host bridges. We're currently facing an issue in a 6-host-bridge system where all bridges depend on the APLIC driver. They must wait until the APLIC driver completes and callsacpi_dev_clear_dependenciesto resolve dependencies, after which they're sequentially added to the system_unbound_wq work queue. However, during execution in the work queue, these 6 host bridges undergo parallel enumeration, preventing them from following the order defined in the firmware's ACPI DSDT table. Specifically:
1. The ACPI DSDT table declares the 6 host bridges in a fixed sequence

Device(PC06) {
    Name(_HID, "PNP0A08")
    Name(_CID, "PNP0A03")
    Name(_UID, 0x6)
   ......
}
Device(PC07) {
    Name(_HID, "PNP0A08")
    Name(_CID, "PNP0A03")
    Name(_UID, 0x7)
    ......
}
Device(PC08) {
    Name(_HID, "PNP0A08")
    Name(_CID, "PNP0A03")
    Name(_UID, 0x8)
    .....
}
...
Device(PC11) {
    Name(_HID, "PNP0A08")
    Name(_CID, "PNP0A03")
    Name(_UID, 0xB)

......
}

2. But the OS enumerates them in random order upon each boot (first boot sequence ≠ second boot sequence) first boot sequence ~ # dmesg |grep -i "PCI Root"

[ 8794.588531] ACPI: PCI Root Bridge [PC08] (domain 0006 [bus 80-ff])
[ 8794.624478] ACPI: PCI Root Bridge [PC06] (domain 0005 [bus 00-ff])
[ 8794.672741] ACPI: PCI Root Bridge [PC10] (domain 0008 [bus 00-ff])
[ 8794.696680] ACPI: PCI Root Bridge [PC07] (domain 0006 [bus 00-7f])
[ 8794.728234] ACPI: PCI Root Bridge [PC11] (domain 0009 [bus 00-ff])
[ 8794.755098] ACPI: PCI Root Bridge [PC09] (domain 0007 [bus 00-ff])
second boot sequence ~ # dmesg |grep -i "PCI Root"
[ 8794.588531] ACPI: PCI Root Bridge [PC09] (domain 0007 [bus 00-ff])
[ 8794.624478] ACPI: PCI Root Bridge [PC06] (domain 0005 [bus 00-ff])
[ 8794.672741] ACPI: PCI Root Bridge [PC08] (domain 0006 [bus 80-ff])
[ 8794.696680] ACPI: PCI Root Bridge [PC11] (domain 0009 [bus 00-ff])
[ 8794.728234] ACPI: PCI Root Bridge [PC07] (domain 0006 [bus 00-7f])
[ 8794.755098] ACPI: PCI Root Bridge [PC10] (domain 0008 [bus 00-ff])

This creates a critical issue: when NVMe devices are connected to these host bridges, the unpredictable kernel scanning sequence causes device identifiers (e.g., /dev/nvme0n1, /dev/nvme1n1) to change across reboots. In server environments, such device naming instability is unacceptable as it breaks storage configuration reliability and consistency.

So far, we've only observed this disorderly enumeration in RISC-V multi-host-bridge scenarios, where APLIC dependency leads to enumeration via system_unbound_wq. We'd like to consult kernel experts:
1. Has the impact of enumeration disorder in multi-host-bridge scenarios been considered?
2. Are there viable solutions to address the random enumeration caused by system_unbound_wq?

We've noticed that PCIe enumeration order tends to vary across system reboots (for example: first boot showed PC08->PC06->PC10->PC07->PC11->PC09, while second boot showed PC09->PC06->PC08->PC11->PC07->PC10), even though the ACPI firmware consistently reports the root bridge sequence as PC06->PC07->PC08->PC09->PC10->PC11.

In our testing, we found that adjusting the registration priority of the aplic driver seems to help ensure the interrupt controller initializes before PCI enumeration, leading to more consistent device ordering.

Quoted 8 lines

We've noticed that PCIe enumeration order tends to vary across system reboots (for example: first boot showed PC08->PC06->PC10->PC07->PC11->PC09, while second boot showed PC09->PC06->PC08->PC11->PC07->PC10), even though the ACPI firmware consistently reports the root bridge sequence as PC06->PC07->PC08->PC09->PC10->PC11.

In our testing, we found that adjusting the registration priority of the aplic driver seems to help ensure the interrupt controller initializes before PCI enumeration, leading to more consistent device ordering.

The ACPI table does not provide a sequence, it provides a collection and it's nowhere written in stone that this collection has to be processed in order.
If you want a sequence then put dependencies into the table and be done with it, no?

The RISC-V AIA specification is ratified as-per the RISC-V international process. The latest ratified AIA specifcation can be found at:
https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf

At a high-level, the AIA specification adds three things:
1) AIA CSRs
- Improved local interrupt support
2) Incoming Message Signaled Interrupt Controller (IMSIC)
- Per-HART MSI controller
- Support MSI virtualization
- Support IPI along with virtualization
3) Advanced Platform-Level Interrupt Controller (APLIC)
- Wired interrupt controller
- In MSI-mode, converts wired interrupt into MSIs (i.e. MSI generator)
- In Direct-mode, injects external interrupts directly into HARTs

For an overview of the AIA specification, refer the AIA virtualization talk at KVM Forum 2022:
https://static.sched.com/hosted_files/kvmforum2022/a1/AIA_Virtualization_in_KVM_RISCV_final.pdf
https://www.youtube.com/watch?v=r071dL8Z0yo

To test this series, use QEMU v7.2 (or higher) and OpenSBI v1.2 (or higher).

This series depends upon per-device MSI domain (and few other) patches merged by Thomas (tglx) which are available in irq/msi branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

These patches can also be found in the riscv_aia_v16 branch at:
https://github.com/avpatel/linux.git

Changes since v15:
- Dropped PATCH1 since it is already merged by Thomas (tglx) and available in his irq/msi branch at git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
- Simplified aplic_msi_irq_eoi() in PATCH7 based on the section "4.9.2 Special consideration for level-sensitive interrupt sources" of the RISC-V AIA specification and also provided handler name.

Changes since v14:
- Dropped 9 patches which are already merged by Thomas (tglx) and available in his irq/msi branch at git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
- Added new PATCH1 which adds changes missed out in merging AIA support for RISC-V INTC.
- Added a separate cpuhp state for IMSIC driver in PATCH3 which ensures that cpuhp notifiers of IMSIC are called as early as possible.
- Removed redundant barriers in PATCH3.
- Addressed few other nit comments.

Changes since v13:
- Split PATCH1 into six granular patches
- Addressed nit comments from Thomas and Bjorn

Changes since v12:
- Rebased on Linux-6.8-rc5
- Dropped per-device MSI domain patches which are already merged by Thomas (tglx)
- Addressed nit comments from Thomas and Clement
- Added a new patch2 to fix lock dependency warning
- Replaced local sync IPI in the IMSIC driver with per-CPU timer
- Simplified locking in the IMSIC driver to avoid lock dependency issues
- Added a dirty bitmap in the IMSIC driver to optimize per-CPU local sync loop

Changes since v11:
- Rebased on Linux-6.8-rc1
- Included kernel/irq related patches from "genirq, irqchip: Convert ARM MSI handling to per device MSI domains" series by Thomas. (PATCH7, PATCH8, PATCH9, PATCH14, PATCH16, PATCH17, PATCH18, PATCH19,

    PATCH20, PATCH21, PATCH22, PATCH23, and PATCH32 of
    https://lore.kernel.org/linux-arm-kernel/[email protected]/)

- Updated APLIC MSI-mode driver to use the new WIRED_TO_MSI mechanism.
- Updated IMSIC driver to support per-device MSI domains for PCI and platform devices.

Changes since v10:
- Rebased on Linux-6.6-rc7
- Dropped PATCH3 of v10 series since this has been merged by MarcZ for Linux-6.6-rc7
- Changed the IMSIC ID management strategy from 1-n approach to x86-style 1-1 approach

Changes since v9:
- Rebased on Linux-6.6-rc4
- Use builtin_platform_driver() in PATCH5, PATCH9, and PATCH12

Changes since v8:
- Rebased on Linux-6.6-rc3
- Dropped PATCH2 of v8 series since we won't be requiring riscv_get_intc_hartid() based on Marc Z's comments on ACPI AIA support.
- Addressed Saravana's comments in PATCH3 of v8 series
- Update PATCH9 and PATCH13 of v8 series based on comments from Sunil

Changes since v7:
- Rebased on Linux-6.6-rc1
- Addressed comments on PATCH1 of v7 series and split it into two PATCHes
- Use DEFINE_SIMPLE_PROP() in PATCH2 of v7 series

Changes since v6:
- Rebased on Linux-6.5-rc4
- Updated PATCH2 to use IS_ENABLED(CONFIG_SPARC) instead of !IS_ENABLED(CONFIG_OF_IRQ)
- Added new PATCH4 to fix syscore registration in PLIC driver
- Update PATCH5 to convert PLIC driver into full-blown platform driver with a re-written probe function.

Changes since v5:
- Rebased on Linux-6.5-rc2
- Updated the overall series to ensure that only IPI, timer, and INTC drivers are probed very early whereas rest of the interrupt controllers (such as PLIC, APLIC, and IMISC) are probed as regular platform drivers.
- Renamed riscv_fw_parent_hartid() to riscv_get_intc_hartid()
- New PATCH1 to add fw_devlink support for msi-parent DT property
- New PATCH2 to ensure all INTC suppliers are initialized which in-turn fixes the probing issue for PLIC, APLIC and IMSIC as platform driver
- New PATCH3 to use platform driver probing for PLIC
- Re-structured the IMSIC driver into two separate drivers: early and platform. The IMSIC early driver (PATCH7) only initialized IMSIC state and provides IPIs whereas the IMSIC platform driver (PATCH8) is probed provides MSI domain for platform devices.
- Re-structure the APLIC platform driver into three separe sources: main, direct mode, and MSI mode.

Changes since v4:
- Rebased on Linux-6.5-rc1
- Added "Dependencies" in the APLIC bindings (PATCH6 in v4)
- Dropped the PATCH6 which was changing the IOMMU DMA domain APIs
- Dropped use of IOMMU DMA APIs in the IMSIC driver (PATCH4)

Changes since v3:
- Rebased on Linux-6.4-rc6
- Dropped PATCH2 of v3 series instead we now set FWNODE_FLAG_BEST_EFFORT via IRQCHIP_DECLARE()
- Extend riscv_fw_parent_hartid() to support both DT and ACPI in PATCH1
- Extend iommu_dma_compose_msi_msg() instead of adding iommu_dma_select_msi() in PATCH6
- Addressed Conor's comments in PATCH3
- Addressed Conor's and Rob's comments in PATCH7

Changes since v2:
- Rebased on Linux-6.4-rc1
- Addressed Rob's comments on DT bindings patches 4 and 8.
- Addessed Marc's comments on IMSIC driver PATCH5
- Replaced use of OF apis in APLIC and IMSIC drivers with FWNODE apis this makes both drivers easily portable for ACPI support. This also removes unnecessary indirection from the APLIC and IMSIC drivers.
- PATCH1 is a new patch for portability with ACPI support
- PATCH2 is a new patch to fix probing in APLIC drivers for APLIC-only systems.
- PATCH7 is a new patch which addresses the IOMMU DMA domain issues pointed out by SiFive

Changes since v1:
- Rebased on Linux-6.2-rc2
- Addressed comments on IMSIC DT bindings for PATCH4
- Use raw_spin_lock_irqsave() on ids_lock for PATCH5
- Improved MMIO alignment checks in PATCH5 to allow MMIO regions with holes.
- Addressed comments on APLIC DT bindings for PATCH6
- Fixed warning splat in aplic_msi_write_msg() caused by zeroed MSI message in PATCH7
- Dropped DT property riscv,slow-ipi instead will have module parameter in future.

Anup Patel (9):
dt-bindings: interrupt-controller: Add RISC-V incoming MSI controller
irqchip: Add RISC-V incoming MSI controller early driver irqchip/riscv-imsic: Add device MSI domain support for platform
devices
irqchip/riscv-imsic: Add device MSI domain support for PCI devices
dt-bindings: interrupt-controller: Add RISC-V advanced PLIC
irqchip: Add RISC-V advanced PLIC driver for direct-mode irqchip/riscv-aplic: Add support for MSI-mode
RISC-V: Select APLIC and IMSIC drivers
MAINTAINERS: Add entry for RISC-V AIA drivers

 .../interrupt-controller/riscv,aplic.yaml     | 172 ++++
 .../interrupt-controller/riscv,imsics.yaml    | 172 ++++
 MAINTAINERS                                   |  14 +
 arch/riscv/Kconfig                            |   2 +
 drivers/irqchip/Kconfig                       |  25 +
 drivers/irqchip/Makefile                      |   3 +
 drivers/irqchip/irq-riscv-aplic-direct.c      | 326 +++++++
 drivers/irqchip/irq-riscv-aplic-main.c        | 211 +++++
 drivers/irqchip/irq-riscv-aplic-main.h        |  52 ++
 drivers/irqchip/irq-riscv-aplic-msi.c         | 257 ++++++
 drivers/irqchip/irq-riscv-imsic-early.c       | 201 ++++
 drivers/irqchip/irq-riscv-imsic-platform.c    | 374 ++++++++
 drivers/irqchip/irq-riscv-imsic-state.c       | 865 ++++++++++++++++++
 drivers/irqchip/irq-riscv-imsic-state.h       | 108 +++
 include/linux/cpuhotplug.h                    |   1 +
 include/linux/irqchip/riscv-aplic.h           | 145 +++
 include/linux/irqchip/riscv-imsic.h           |  87 ++
 17 files changed, 3015 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
 create mode 100644 drivers/irqchip/irq-riscv-aplic-direct.c
 create mode 100644 drivers/irqchip/irq-riscv-aplic-main.c
 create mode 100644 drivers/irqchip/irq-riscv-aplic-main.h
 create mode 100644 drivers/irqchip/irq-riscv-aplic-msi.c
 create mode 100644 drivers/irqchip/irq-riscv-imsic-early.c
 create mode 100644 drivers/irqchip/irq-riscv-imsic-platform.c
 create mode 100644 drivers/irqchip/irq-riscv-imsic-state.c
 create mode 100644 drivers/irqchip/irq-riscv-imsic-state.h
 create mode 100644 include/linux/irqchip/riscv-aplic.h
 create mode 100644 include/linux/irqchip/riscv-imsic.h

--
2.34.1

Can this series be considered for Linux-6.9 ?

The RISC-V AIA specification is ratified as-per the RISC-V international process. The latest ratified AIA specifcation can be found at:
https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf

Quoted 3 lines · Anup Patel

The RISC-V AIA specification is ratified as-per the RISC-V international process. The latest ratified AIA specifcation can be found at:
https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf

It's been a been a long ride, and I got in late (v10)... Thanks for the hard work, Anup!

Note that Alex' text-patching/IPI series [1] needs to go into the RV tree at roughly the same time as AIA.

I've not caught any regressions for kselftests on qemu for this version (with Alex' series applied). I have not run it on real hardware.

For the series:

Tested-by Björn Töpel <[email protected]>

Reviewed-by Björn Töpel <[email protected]>