kernel/drivers/irqchip, branch linux-6.9.y

irqchip/loongson-liointc: Set different ISRs for different cores

2024-07-05T07:38:13Z

commit a9c3ee5d0fdb069b54902300df6ac822027f3b0a upstream. The liointc hardware provides separate Interrupt Status Registers (ISR) for each core. The current code uses always the ISR of core #0, which works during boot because by default all interrupts are routed to core #0. When the interrupt routing changes in the firmware configuration then this causes interrupts to be lost because they are not configured in the corresponding core. Use the core index to access the correct ISR instead of a hardcoded 0. [ tglx: Massaged changelog ] Fixes: 0858ed035a85 ("irqchip/loongson-liointc: Add ACPI init support") Co-developed-by: Tianli Xiong Signed-off-by: Tianli Xiong Signed-off-by: Huacai Chen Signed-off-by: Thomas Gleixner Cc: Link: https://lore.kernel.org/r/20240622043338.1566945-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman

irqchip/loongson-eiointc: Use early_cpu_to_node() instead of cpu_to_node()

2024-07-05T07:38:12Z

commit 2d64eaeeeda5659d52da1af79d237269ba3c2d2c upstream. Multi-bridge machines required that all eiointc controllers in the system are initialized, otherwise the system does not boot. The initialization happens on the boot CPU during early boot and relies on cpu_to_node() for identifying the individual nodes. That works when the number of possible CPUs is large enough, but with a command line limit, e.g. "nr_cpus=$N" for kdump, but fails when the CPUs of the secondary nodes are not covered. During early ACPI enumeration all CPU to node mappings are recorded up to CONFIG_NR_CPUS. These are accessible via early_cpu_to_node() even in the case that "nr_cpus=N" truncates the number of possible CPUs and only provides the possible CPUs via cpu_to_node() translation. Change the node lookup in the driver to use early_cpu_to_node() so that even with a limitation on the number of possible CPUs all eointc instances are initialized. This can't obviously cure the case where CONFIG_NR_CPUS is too small. [ tglx: Massaged changelog ] Fixes: 64cc451e45e1 ("irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent") Signed-off-by: Huacai Chen Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240623034113.1808727-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman

irqchip/loongson: Select GENERIC_IRQ_EFFECTIVE_AFF_MASK if SMP for IRQ_LOONGARCH_CPU

2024-07-05T07:38:00Z

[ Upstream commit 42a7d887664b02a747ef5d479f6fd01081564af8 ] An interrupt's effective affinity can only be different from its configured affinity if there are multiple CPUs. Make it clear that this option is only meaningful when SMP is enabled. Otherwise, there exists "WARNING: unmet direct dependencies detected for GENERIC_IRQ_EFFECTIVE_AFF_MASK" when make menuconfig if CONFIG_SMP is not set on LoongArch. Signed-off-by: Tiezhu Yang Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20240326121130.16622-3-yangtiezhu@loongson.cn Signed-off-by: Sasha Levin

irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()

2024-06-21T12:40:30Z

commit b97e8a2f7130a4b30d1502003095833d16c028b3 upstream. its_vlpi_prop_update() calls lpi_write_config() which obtains the mapping information for a VLPI without lock held. So it could race with its_vlpi_unmap(). Since all calls from its_irq_set_vcpu_affinity() require the same lock to be held, hoist the locking there instead of sprinkling the locking all over the place. This bug was discovered using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. [ tglx: Use guard() instead of goto ] Fixes: 015ec0386ab6 ("irqchip/gic-v3-its: Add VLPI configuration handling") Suggested-by: Marc Zyngier Signed-off-by: Hagar Hemdan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20240531162144.28650-1-hagarhem@amazon.com Signed-off-by: Greg Kroah-Hartman

irqchip/sifive-plic: Chain to parent IRQ after handlers are ready

2024-06-21T12:40:30Z

commit e306a894bd511804ba9db7c00ca9cc05b55df1f2 upstream. Now that the PLIC uses a platform driver, the driver is probed later in the boot process, where interrupts from peripherals might already be pending. As a result, plic_handle_irq() may be called as early as the call to irq_set_chained_handler() completes. But this call happens before the per-context handler is completely set up, so there is a window where plic_handle_irq() can see incomplete per-context state and crash. Avoid this by delaying the call to irq_set_chained_handler() until all handlers from all PLICs are initialized. Fixes: 8ec99b033147 ("irqchip/sifive-plic: Convert PLIC driver into a platform driver") Reported-by: Geert Uytterhoeven Signed-off-by: Samuel Holland Signed-off-by: Thomas Gleixner Tested-by: Geert Uytterhoeven Reviewed-by: Anup Patel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240529215458.937817-1-samuel.holland@sifive.com Closes: https://lore.kernel.org/r/CAMuHMdVYFFR7K5SbHBLY-JHhb7YpgGMS_hnRWm8H0KD-wBo+4A@mail.gmail.com/ Signed-off-by: Greg Kroah-Hartman

irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails

2024-06-16T11:51:09Z

commit 0110c4b110477bb1f19b0d02361846be7ab08300 upstream. When riscv_intc_init_common() fails, the firmware node allocated is not freed. Add the missing free(). Fixes: 7023b9d83f03 ("irqchip/riscv-intc: Add ACPI support") Signed-off-by: Sunil V L Signed-off-by: Thomas Gleixner Reviewed-by: Anup Patel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240527081113.616189-1-sunilvl@ventanamicro.com Signed-off-by: Greg Kroah-Hartman

irqchip/loongson-pch-msi: Fix off-by-one on allocation error path

2024-05-30T07:44:19Z

[ Upstream commit b327708798809328f21da8dc14cc8883d1e8a4b3 ] When pch_msi_parent_domain_alloc() returns an error, there is an off-by-one in the number of interrupts to be freed. Fix it by passing the number of successfully allocated interrupts, instead of the relative index of the last allocated one. Fixes: 632dcc2c75ef ("irqchip: Add Loongson PCH MSI controller") Signed-off-by: Zenghui Yu Signed-off-by: Thomas Gleixner Reviewed-by: Jiaxun Yang Link: https://lore.kernel.org/r/20240327142334.1098-1-yuzenghui@huawei.com Signed-off-by: Sasha Levin

irqchip/alpine-msi: Fix off-by-one in allocation error path

2024-05-30T07:44:18Z

[ Upstream commit ff3669a71afa06208de58d6bea1cc49d5e3fcbd1 ] When alpine_msix_gic_domain_alloc() fails, there is an off-by-one in the number of interrupts to be freed. Fix it by passing the number of successfully allocated interrupts, instead of the relative index of the last allocated one. Fixes: 3841245e8498 ("irqchip/alpine-msi: Fix freeing of interrupts on allocation error path") Signed-off-by: Zenghui Yu Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20240327142305.1048-1-yuzenghui@huawei.com Signed-off-by: Sasha Levin

irqchip/gic-v3-its: Prevent double free on error

2024-04-25T12:30:46Z

The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Zenghui Yu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibaba.com

irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1

2024-04-09T09:11:18Z

As per the GICv4.1 spec (Arm IHI 0069H, 5.3.19): "A VMAPP with {V, Alloc}=={0, x} is self-synchronizing, This means the ITS command queue does not show the command as consumed until all of its effects are completed." Furthermore, VSYNC is allowed to deliver an SError when referencing a non existent VPE. By these definitions, a VMAPP followed by a VSYNC is a bug, as the later references a VPE that has been unmapped by the former. Fix it by eliding the VSYNC in this scenario. Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP") Signed-off-by: Nianyao Tang Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Zenghui Yu Link: https://lore.kernel.org/r/20240406022737.3898763-1-tangnianyao@huawei.com