kernel/drivers/irqchip, branch linux-rolling-stable

irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS supports

2026-03-19T15:15:15Z

commit ce9e40a9a5e5cff0b1b0d2fa582b3d71a8ce68e8 upstream. The ITS driver blindly assumes that EventIDs are in abundant supply, to the point where it never checks how many the hardware actually supports. It turns out that some pretty esoteric integrations make it so that only a few bits are available, all the way down to a single bit. Enforce the advertised limitation at the point of allocating the device structure, and hope that the endpoint driver can deal with such limitation. Fixes: 84a6a2e7fc18d ("irqchip: GICv3: ITS: device allocation and configuration") Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Reviewed-by: Robin Murphy Reviewed-by: Zenghui Yu Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260206154816.3582887-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman

irqchip/riscv-aplic: Register syscore operations only once

2026-03-19T15:15:08Z

[ Upstream commit b330fbfd34d7624bec62b99ad88dba2614326a19 ] Since commit 95a8ddde3660 ("irqchip/riscv-aplic: Preserve APLIC states across suspend/resume"), when multiple NUMA nodes exist and AIA is not configured as "none", aplic_probe() is called multiple times. This leads to register_syscore(&aplic_syscore) being invoked repeatedly, causing the following Oops: list_add double add: new=ffffffffb91461f0, prev=ffffffffb91461f0, next=ffffffffb915c408. [] __list_add_valid_or_report+0x60/0xc0 [] register_syscore+0x3e/0x70 [] aplic_probe+0xc6/0x112 Fix this by registering syscore operations only once, using a static variable aplic_syscore_registered to track registration. [ tglx: Trim backtrace properly ] Fixes: 95a8ddde3660 ("irqchip/riscv-aplic: Preserve APLIC states across suspend/resume") Signed-off-by: Jessica Liu Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260310141731145xMwLsyvXl9Gw-m6A4VRYj@zte.com.cn Signed-off-by: Sasha Levin

irqchip/riscv-aplic: Do not clear ACPI dependencies on probe failure

2026-03-19T15:15:08Z

[ Upstream commit 620b6ded72a7f0f77be6ec44d0462bb85729ab7a ] aplic_probe() calls acpi_dev_clear_dependencies() unconditionally at the end, even when the preceding setup (MSI or direct mode) has failed. This is incorrect because if the device failed to probe, it should not be considered as active and should not clear dependencies for other devices waiting on it. Fix this by returning immediately when the setup fails, skipping the ACPI dependency cleanup. Also, explicitly return 0 on success instead of relying on the value of 'rc' to make the success path clear. Fixes: 5122e380c23b ("irqchip/riscv-aplic: Add ACPI support") Signed-off-by: Jessica Liu Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260310141600411Fu8H8-GXOOgKISU48Tjgx@zte.com.cn Signed-off-by: Sasha Levin

irqchip/riscv-aplic: Preserve APLIC states across suspend/resume

2026-03-19T15:15:07Z

[ Upstream commit 95a8ddde36601d0a645475fb080ed118db59c8c3 ] The APLIC states might be reset when the platform enters a low power state, but the register states are not being preserved and restored, which prevents interrupt delivery after the platform resumes. Solve this by adding a syscore ops and a power management notifier to preserve and restore the APLIC states on suspend and resume. [ tglx: Folded the build fix provided by Geert ] Signed-off-by: Nick Hu Signed-off-by: Thomas Gleixner Reviewed-by: Yong-Xuan Wang Reviewed-by: Cyan Yang Reviewed-by: Nutty Liu Reviewed-by: Anup Patel Link: https://patch.msgid.link/20251202-preserve-aplic-imsic-v3-2-1844fbf1fe92@sifive.com Stable-dep-of: 620b6ded72a7 ("irqchip/riscv-aplic: Do not clear ACPI dependencies on probe failure") Signed-off-by: Sasha Levin

irqchip/ls-extirq: Fix devm_of_iomap() error check

2026-03-12T11:09:18Z

[ Upstream commit fe5669e363b129cde285bfb4d45abb72d1d77cfc ] The devm_of_iomap() function returns an ERR_PTR() encoded error code on failure. Replace the incorrect check against NULL with IS_ERR(). Fixes: 05cd654829dd ("irqchip/ls-extirq: Convert to a platform driver to make it work again") Reported-by: Dan Carpenter Signed-off-by: Ioana Ciornei Signed-off-by: Thomas Gleixner Reviewed-by: Herve Codina Link: https://patch.msgid.link/20260224113610.1129022-3-ioana.ciornei@nxp.com Closes: https://lore.kernel.org/all/aYXvfbfT6w0TMsXS@stanley.mountain/ Signed-off-by: Sasha Levin

irqchip/sifive-plic: Fix frozen interrupt due to affinity setting

2026-03-12T11:09:07Z

[ Upstream commit 1072020685f4b81f6efad3b412cdae0bd62bb043 ] PLIC ignores interrupt completion message for disabled interrupt, explained by the specification: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored. This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled(). However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt. This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt's affinity setting. The uart port becomes frozen almost instantaneously. Fix this by checking PLIC's enable bit instead of irqd_irq_disabled(). Fixes: cc9f04f9a84f ("irqchip/sifive-plic: Implement irq_set_affinity() for SMP host") Signed-off-by: Nam Cao Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260212114125.3148067-1-namcao@linutronix.de Signed-off-by: Sasha Levin

irqchip/riscv-imsic: Add a CPU pm notifier to restore the IMSIC on exit

2026-03-04T12:19:42Z

[ Upstream commit f48b4bd0915bf61ac12b8c65c7939ebd03bc8abf ] The IMSIC might be reset when the system enters a low power state, but on exit nothing restores the registers, which prevents interrupt delivery. Solve this by registering a CPU power management notifier, which restores the IMSIC on exit. Signed-off-by: Nick Hu Signed-off-by: Thomas Gleixner Reviewed-by: Yong-Xuan Wang Reviewed-by: Cyan Yang Reviewed-by: Anup Patel Reviewed-by: Nutty Liu Link: https://patch.msgid.link/20251202-preserve-aplic-imsic-v3-1-1844fbf1fe92@sifive.com Signed-off-by: Sasha Levin

irqchip/sifive-plic: Handle number of hardware interrupts correctly

2026-02-26T23:00:49Z

[ Upstream commit 42e025b719c128bdf8ff88584589a1e4a2448c81 ] The driver is handling the number of hardware interrupts inconsistently. The reason is that the firmware enumerates the maximum number of device interrupts, but the actual number of hardware interrupts is one more because hardware interrupt 0 is reserved. There are two loop variants where this matters: 1) Iterating over the device interrupts for (irq = 1; irq < total_irqs; irq++) 2) Iterating over the number of interrupt register groups for (grp = 0; grp < irq_groups; grp++) The current code stores the number of device interrupts and that requires to write the loops as: 1) for (irq = 1; irq <= device_irqs; irq++) 2) for (grp = 0; grp < DIV_ROUND_UP(device_irqs + 1); grp++) But the code gets it wrong all over the place. Just fixing up the conditions and off by ones is not a sustainable solution as the next changes will reintroduce the same bugs over and over. Sanitize it by storing the total number of hardware interrupts during probe and precalculating the number of groups. To future proof it mark priv::total_irqs __private, provide a correct iterator macro and adjust the code to this. Marking it private allows sparse (C=1 build) to catch direct access to this member: drivers/irqchip/irq-sifive-plic.c:270:9: warning: dereference of noderef expression That should prevent at least the most obvious future damage in that area. Fixes: e80f0b6a2cf3 ("irqchip/irq-sifive-plic: Add syscore callbacks for hibernation") Reported-by: Yangyu Chen Signed-off-by: Thomas Gleixner Tested-by: Yangyu Chen Link: https://patch.msgid.link/87ikcd36i9.ffs@tglx Signed-off-by: Sasha Levin

irqchip/ls-extirq: Convert to a platform driver to make it work again

2026-01-27T15:33:32Z

Starting with the blamed commit, the ls-extirq driver stopped working. This is because ls-extirq, being one of the interrupt-map property abusers, does not pass the DT checks added by the referenced commit, making it unable to determine its interrupt parent: irq-ls-extirq: Cannot find parent domain OF: of_irq_init: Failed to init /soc/syscon@1f70000/interrupt-controller@14 ((____ptrval____)), parent 0000000000000000 Instead of reverting the referenced commit, convert the ls-extirq to a platform driver to avoid the irqchip_init() -> of_irq_init() code path completely. As part of the conversion, use the managed resources APIs and dev_err_probe() so that there is no need for a .remove() callback or for complicated error handling. Fixes: 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes without interrupts") Co-developed-by: Alexander Stein Signed-off-by: Alexander Stein Signed-off-by: Ioana Ciornei Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260122134034.3274053-2-ioana.ciornei@nxp.com

irqchip/gic-v3-its: Avoid truncating memory addresses

2026-01-20T09:11:29Z

On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260119201603.2713066-1-arnd@kernel.org