starfive-tech/linux.git/drivers/irqchip, branch visionfive

irqchip/gic-v5: Remove undue WARN_ON()s in the IRS affinity parsing

2025-08-24T10:54:06+00:00

In gicv5_irs_of_init_affinity() a WARN_ON() is triggered if: 1) a phandle in the "cpus" property does not correspond to a valid OF node 2 a CPU logical id does not exist for a given OF cpu_node #1 is a firmware bug and should be reported as such but does not warrant a WARN_ON() backtrace. #2 is not necessarily an error condition (eg a kernel can be booted with nr_cpus=X limiting the number of cores artificially) and therefore there is no reason to clutter the kernel log with WARN_ON() output when the condition is hit. Rework the IRS affinity parsing code to remove undue WARN_ON()s thus making it less noisy. Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250814094138.1611017-1-lpieralisi@kernel.org

irqchip/gic-v5: Fix kmemleak L2 IST table entries false positives

2025-08-24T10:12:53+00:00

L2 IST table entries are allocated with the kmalloc interface and their physical addresses are programmed in the GIC (either IST base address register or L1 IST table entries) but their virtual addresses are not stored in any kernel data structure because they are not needed at runtime - the L2 IST table entries are managed through system instructions but never dereferenced directly by the driver. This triggers kmemleak false positive reports: unreferenced object 0xffff00080039a000 (size 4096): comm "swapper/0", pid 0, jiffies 4294892296 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): kmemleak_alloc+0x34/0x40 __kmalloc_noprof+0x320/0x464 gicv5_irs_iste_alloc+0x1a4/0x484 gicv5_irq_lpi_domain_alloc+0xe4/0x194 irq_domain_alloc_irqs_parent+0x78/0xd8 gicv5_irq_ipi_domain_alloc+0x180/0x238 irq_domain_alloc_irqs_locked+0x238/0x7d4 __irq_domain_alloc_irqs+0x88/0x114 gicv5_of_init+0x284/0x37c of_irq_init+0x3b8/0xb18 irqchip_init+0x18/0x40 init_IRQ+0x104/0x164 start_kernel+0x1a4/0x3d4 __primary_switched+0x8c/0x94 Instruct kmemleak to ignore L2 IST table memory allocation virtual addresses to prevent these false positive reports. Reported-by: Jinjie Ruan Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Reviewed-by: Jinjie Ruan Reviewed-by: Zenghui Yu Acked-by: Marc Zyngier Link: https://lore.kernel.org/all/20250811135001.1333684-1-lpieralisi@kernel.org Closes: https://lore.kernel.org/lkml/cc611dda-d1e4-4793-9bb2-0eaa47277584@huawei.com/

irqchip/mvebu-gicp: Fix an IS_ERR() vs NULL check in probe()

2025-08-24T10:00:47+00:00

ioremap() never returns error pointers, it returns NULL on error. Fix the check to match. Fixes: 3c3d7dbab2c7 ("irqchip/mvebu-gicp: Clear pending interrupts on init") Signed-off-by: Dan Carpenter Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/aKRGcgMeaXm2TMIC@stanley.mountain

irqchip/atmel-aic[5]: Fix incorrect lock guard conversion

2025-08-23T19:41:07+00:00

Commit b00bee8afaca ("irqchip: Convert generic irqchip locking to guards") replaced calls to irq_gc_lock_irq{save,restore}() with guard(raw_spinlock_irq). However, in irq-atmel-aic5.c and irq-atmel-aic.c, the xlate callback is used in the early boot process, before interrupts are initially enabled. As its destructor enables interrupts, this triggers the warning in start_kernel(): WARNING: CPU: 0 PID: 0 at init/main.c:1024 start_kernel+0x4d0/0x5dc Interrupts were enabled early Fix this by using guard(raw_spinlock_irqsave) instead. [ tglx: Folded the equivivalent fix for atmel-aic ] Fixes: b00bee8afaca ("irqchip: Convert generic irqchip locking to guards") Signed-off-by: Edgar Bonet Signed-off-by: Thomas Gleixner Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/all/280dd506-e1fc-4d2e-bdc4-98dd9dca6138@grenoble.cnrs.fr

irqchip/mvebu-gicp: Use resource_size() for ioremap()

2025-08-06T15:00:40+00:00

0-day reported an off by one in the ioremap() sizing: drivers/irqchip/irq-mvebu-gicp.c:240:45-48: WARNING: Suspicious code. resource_size is maybe missing with gicp -> res Convert it to resource_size(), which does the right thing. Fixes: 3c3d7dbab2c7 ("irqchip/mvebu-gicp: Clear pending interrupts on init") Reported-by: kernel test robot Signed-off-by: Thomas Gleixner Closes: https://lore.kernel.org/oe-kbuild-all/202508062150.mtFQMTXc-lkp@intel.com/

irqchip: Build IMX_MU_MSI only on ARM

2025-08-06T08:35:45+00:00

Compile-testing IMX_MU_MSI on x86 without PCI_MSI support results in a build failure: drivers/gpio/gpio-sprd.c:8: include/linux/gpio/driver.h:41:33: error: field 'msiinfo' has incomplete type drivers/iommu/iommufd/viommu.c:4: include/linux/msi.h:528:33: error: field 'alloc_info' has incomplete type Tighten the dependency further to only allow compile testing on Arm. This could be refined further to allow certain x86 configs. This was submitted before to address a different build failure, which was fixed differently, but the problem has now returned in a different form. Fixes: 70afdab904d2d1e6 ("irqchip: Add IMX MU MSI controller driver") Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250805160952.4006075-1-arnd@kernel.org Link: https://lore.kernel.org/all/20221215164109.761427-1-arnd@kernel.org/

irqchip/gic-v5: Remove IRQD_RESEND_WHEN_IN_PROGRESS for ITS IRQs

2025-08-05T08:43:48+00:00

GICv5 LPI interrupts have an active state hence they cannot retrigger while the interrupt is being handled. Therefore, setting the IRQD_RESEND_WHEN_IN_PROGRESS flag on LPIs is pointless, as the situation this flag caters for cannot happen. Remove it. Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/all/20250801-gic-v5-fixes-6-17-v1-3-4fcedaccf9e6@kernel.org

irqchip/gic-v5: iwb: Fix iounmap probe failure path

2025-08-05T08:43:48+00:00

The 0-day bot reported that on the failure path the driver iounmap()s IWB resources that are managed through devm_ioremap(), which is clearly wrong because the driver would end up unmapping the MMIO resource twice on probing failure. Fix this by removing the error path altogether and by letting devres manage the iounmapping on clean-up. Fixes: 695949d8b16f ("irqchip/gic-v5: Add GICv5 IWB support") Reported-by: kernel test robot Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/all/20250801-gic-v5-fixes-6-17-v1-1-4fcedaccf9e6@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202508010038.N3r4ZmII-lkp@intel.com

irqchip/mvebu-gicp: Clear pending interrupts on init

2025-08-05T08:35:03+00:00

When a kexec'ed kernel boots up, there might be stale unhandled interrupts pending in the interrupt controller. These are delivered as spurious interrupts once the boot CPU enables interrupts. Clear all pending interrupts when the driver is initialized to prevent these spurious interrupts from locking the CPU in an endless loop. Signed-off-by: Elad Nachman Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250803102548.669682-2-enachman@marvell.com

irqchip/msi-lib: Fix fwnode refcount in msi_lib_irq_domain_select()

2025-08-05T08:31:46+00:00

Commit 8b65db1e93a2 ("irqchip/msi-lib: Add IRQ_DOMAIN_FLAG_FWNODE_PARENT handling") added logic in msi_lib_irq_domain_select() to match the domain fwnode against the fwnode parent of the fwspec.fwnode. The fwnode_get_parent() caller must call fwnode_handle_put() on the returned pointer value, lest fwnode refcounting for the parent ends up being out of kilter. Fix this by relying on the fwnode_handle clean-up handlers and by incrementing the fwnode refcount regardless of whether parent matching is used or not (the domain selection code already holds a reference before calling msi_lib_irq_domain_select() but to make the exit path more uniform if IRQ_DOMAIN_FLAG_FWNODE_PARENT is not set fwnode_handle_get() is called again on fwspec.fwnode so that the clean-up code is the same for the two matching patterns). Fixes: 8b65db1e93a2 ("irqchip/msi-lib: Add IRQ_DOMAIN_FLAG_FWNODE_PARENT handling") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250804145553.795065-1-lpieralisi@kernel.org