blaster4385/linux-IllusionX/drivers/irqchip, branch v6.12.10

irqchip/gic: Correct declaration of *percpu_base pointer in union gic_base

2025-01-09T12:33:47Z

[ Upstream commit a1855f1b7c33642c9f7a01991fb763342a312e9b ] percpu_base is used in various percpu functions that expect variable in __percpu address space. Correct the declaration of percpu_base to void __iomem * __percpu *percpu_base; to declare the variable as __percpu pointer. The patch fixes several sparse warnings: irq-gic.c:1172:44: warning: incorrect type in assignment (different address spaces) irq-gic.c:1172:44: expected void [noderef] __percpu *[noderef] __iomem *percpu_base irq-gic.c:1172:44: got void [noderef] __iomem *[noderef] __percpu * ... irq-gic.c:1231:43: warning: incorrect type in argument 1 (different address spaces) irq-gic.c:1231:43: expected void [noderef] __percpu *__pdata irq-gic.c:1231:43: got void [noderef] __percpu *[noderef] __iomem *percpu_base There were no changes in the resulting object files. Signed-off-by: Uros Bizjak Signed-off-by: Thomas Gleixner Acked-by: Marc Zyngier Link: https://lore.kernel.org/all/20241213145809.2918-2-ubizjak@gmail.com Signed-off-by: Sasha Levin

irqchip/gic-v3: Work around insecure GIC integrations

2024-12-27T13:02:06Z

commit 773c05f417fa14e1ac94776619e9c978ec001f0b upstream. It appears that the relatively popular RK3399 SoC has been put together using a large amount of illicit substances, as experiments reveal that its integration of GIC500 exposes the *secure* programming interface to non-secure. This has some pretty bad effects on the way priorities are handled, and results in a dead machine if booting with pseudo-NMI enabled (irqchip.gicv3_pseudo_nmi=1) if the kernel contains 18fdb6348c480 ("arm64: irqchip/gic-v3: Select priorities at boot time"), which relies on the priorities being programmed using the NS view. Let's restore some sanity by going one step further and disable security altogether in this case. This is not any worse, and puts us in a mode where priorities actually make some sense. Huge thanks to Mark Kettenis who initially identified this issue on OpenBSD, and to Chen-Yu Tsai who reported the problem in Linux. Fixes: 18fdb6348c480 ("arm64: irqchip/gic-v3: Select priorities at boot time") Reported-by: Mark Kettenis Reported-by: Chen-Yu Tsai Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Tested-by: Chen-Yu Tsai Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241213141037.3995049-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman

irqchip/gicv3-its: Add workaround for hip09 ITS erratum 162100801

2024-12-14T19:04:09Z

[ Upstream commit f82e62d470cc990ebd9d691f931dd418e4e9cea9 ] When enabling GICv4.1 in hip09, VMAPP fails to clear some caches during the unmap operation, which can causes vSGIs to be lost. To fix the issue, invalidate the related vPE cache through GICR_INVALLR after VMOVP. Suggested-by: Marc Zyngier Co-developed-by: Nianyao Tang Signed-off-by: Nianyao Tang Signed-off-by: Zhou Wang Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Signed-off-by: Sasha Levin

irqchip/stm32mp-exti: CONFIG_STM32MP_EXTI should not default to y when compile-testing

2024-12-14T19:03:16Z

[ Upstream commit 9151299ee5101e03eeed544c1280b0e14b89a8a4 ] Merely enabling compile-testing should not enable additional functionality. Fixes: 0be58e0553812fcb ("irqchip/stm32mp-exti: Allow building as module") Signed-off-by: Geert Uytterhoeven Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/ef5ec063b23522058f92087e072419ea233acfe9.1733243115.git.geert+renesas@glider.be Signed-off-by: Sasha Levin

irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain

2024-12-05T13:02:53Z

commit 12aaf67584cf19dc84615b7aba272fe642c35b8b upstream. Commit fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent") introduced in v6.11-rc1 broke Mavell Armada platforms (and possibly others) by incorrectly switching irq-mvebu-sei to MSI parent. In the above commit, msi_parent_ops is set for the sei->cp_domain, but rather than adding a .select method to mvebu_sei_cp_domain_ops (which is associated with sei->cp_domain), it was added to mvebu_sei_domain_ops which is associated with sei->sei_domain, which doesn't have any msi_parent_ops. This makes the call to msi_lib_irq_domain_select() always fail. This bug manifests itself with the following kernel messages on Armada 8040 based systems: platform f21e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown) platform f41e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown) Move the select callback to mvebu_sei_cp_domain_ops to cure it. Fixes: fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent") Signed-off-by: Russell King (Oracle) Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/E1tE6bh-004CmX-QU@rmk-PC.armlinux.org.uk Signed-off-by: Greg Kroah-Hartman

irqchip/riscv-aplic: Prevent crash when MSI domain is missing

2024-12-05T13:01:23Z

[ Upstream commit 1f181d1cda56c2fbe379c5ace1aa1fac6306669e ] If the APLIC driver is probed before the IMSIC driver, the parent MSI domain will be missing, which causes a NULL pointer dereference in msi_create_device_irq_domain(). Avoid this by deferring probe until the parent MSI domain is available. Use dev_err_probe() to avoid printing an error message when returning -EPROBE_DEFER. Fixes: ca8df97fe679 ("irqchip/riscv-aplic: Add support for MSI-mode") Signed-off-by: Samuel Holland Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20241114200133.3069460-1-samuel.holland@sifive.com Signed-off-by: Sasha Levin

irqchip/gic-v3: Force propagation of the active state with a read-back

2024-11-06T23:22:44Z

Christoffer reports that on some implementations, writing to GICR_ISACTIVER0 (and similar GICD registers) can race badly with a guest issuing a deactivation of that interrupt via the system register interface. There are multiple reasons to this: - this uses an early write-acknoledgement memory type (nGnRE), meaning that the write may only have made it as far as some interconnect by the time the store is considered "done" - the GIC itself is allowed to buffer the write until it decides to take it into account (as long as it is in finite time) The effects are that the activation may not have taken effect by the time the kernel enters the guest, forcing an immediate exit, or that a guest deactivation occurs before the interrupt is active, doing nothing. In order to guarantee that the write to the ISACTIVER register has taken effect, read back from it, forcing the interconnect to propagate the write, and the GIC to process the write before returning the read. Reported-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Acked-by: Christoffer Dall Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241106084418.3794612-1-maz@kernel.org

irqchip/gic-v4: Correctly deal with set_affinity on lazily-mapped VPEs

2024-10-27T16:30:16Z

Zenghui points out that a recent change to the way set_affinity is handled for VPEs has the potential to return an error if the VPE hasn't been mapped yet (because the guest hasn't emited a MAPTI command yet), affecting GICv4.0 implementations that rely on the ITSList feature. Fix this by making the set_affinity succeed in this case, and return early, without trying to touch the HW. Fixes: 1442ee0011983 ("irqchip/gic-v4: Don't allow a VMOVP on a dying VPE") Reported-by: Zenghui Yu Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Reviewed-by: Zenghui Yu Link: https://lore.kernel.org/all/20241027102220.1858558-1-maz@kernel.org Link: https://lore.kernel.org/r/aab45cd3-e5ca-58cf-e081-e32a17f5b4e7@huawei.com

irqchip/renesas-rzg2l: Fix missing put_device

2024-10-15T21:54:35Z

rzg2l_irqc_common_init() calls of_find_device_by_node(), but the corresponding put_device() call is missing. This also gets reported by make coccicheck. Make use of the cleanup interfaces from cleanup.h to call into __free_put_device(), which in turn calls into put_device when leaving function rzg2l_irqc_common_init() and variable "dev" goes out of scope. To prevent that the device is put on successful completion, assign NULL to "dev" to prevent __free_put_device() from calling into put_device() within the successful path. "make coccicheck" will still complain about missing put_device() calls, but those are false positives now. Fixes: 3fed09559cd8 ("irqchip: Add RZ/G2L IA55 Interrupt Controller driver") Signed-off-by: Fabrizio Castro Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20241011172003.1242841-1-fabrizio.castro.jz@renesas.com

irqchip/riscv-intc: Fix SMP=n boot with ACPI

2024-10-15T21:14:25Z

When CONFIG_SMP is disabled, the static array rintc_acpi_data with size NR_CPUS is not sufficient to hold all RINTC structures passed from the firmware. All RINTC structures are required to configure IMSIC/APLIC/PLIC properly irrespective of SMP in the OS. So, allocate dynamic memory based on the number of RINTC structures in MADT to fix this issue. Fixes: f8619b66bdb1 ("irqchip/riscv-intc: Add ACPI support for AIA") Reported-by: Björn Töpel Signed-off-by: Sunil V L Signed-off-by: Thomas Gleixner Tested-by: Alexandre Ghiti Reviewed-by: Anup Patel Link: https://lore.kernel.org/all/20241014065739.656959-1-sunilvl@ventanamicro.com Closes: https://github.com/linux-riscv/linux-riscv/actions/runs/11280997511/job/31375229012