- 11 Jul, 2023 1 commit
-
-
Lorenzo Pieralisi authored
GIC700 erratum 2941627 may cause GIC-700 missing SPIs wake requests when SPIs are deactivated while targeting a sleeping CPU - ie a CPU for which the redistributor: GICR_WAKER.ProcessorSleep == 1 This runtime situation can happen if an SPI that has been activated on a core is retargeted to a different core, it becomes pending and the target core subsequently enters a power state quiescing the respective redistributor. When this situation is hit, the de-activation carried out on the core that activated the SPI (through either ICC_EOIR1_EL1 or ICC_DIR_EL1 register writes) does not trigger a wake requests for the sleeping GIC redistributor even if the SPI is pending. Work around the erratum by de-activating the SPI using the redistributor GICD_ICACTIVER register if the runtime conditions require it (ie the IRQ was retargeted between activation and de-activation). Signed-off-by:
Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230704155034.148262-1-lpieralisi@kernel.org
-
- 03 Jul, 2023 3 commits
-
-
Sebastian Reichel authored
Commit a8707f55 ("irqchip/gic-v3: Add Rockchip 3588001 erratum workaround") mentioned RK3588S (the slimmed down variant of RK3588) being affected, but did not check for its compatible value. Thus the quirk is not applied on RK3588S. Since the GIC ITS node got added to the upstream DT, boards using RK3588S are no longer booting without this quirk being applied. Fixes: 06cdac8e ("arm64: dts: rockchip: add GIC ITS support to rk3588") Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Marc Zyngier authored
We normally rely on the irq_to_cpuid_[un]lock() primitives to make sure nothing will change col->idx while performing a LPI invalidation. However, these primitives do not cover VPE doorbells, and we have some open-coded locking for that. Unfortunately, this locking is pretty bogus. Instead, extend the above primitives to cover VPE doorbells and convert the whole thing to it. Fixes: f3a05921 ("irqchip/gic-v4.1: Ensure mutual exclusion between vPE affinity change and RD access") Reported-by:
Kunkun Jiang <jiangkunkun@huawei.com> Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20230617073242.3199746-1-maz@kernel.org
-
Jonas Gorski authored
The irq to block mapping is fixed, and interrupts from the first block will always be routed to the first parent IRQ. But the parent interrupts themselves can be routed to any available CPU. This is used by the bootloader to map the first parent interrupt to the boot CPU, regardless wether the boot CPU is the first one or the second one. When booting from the second CPU, the assumption that the first block's IRQ is mapped to the first CPU breaks, and the system hangs because interrupts do not get routed correctly. Fix this by passing the appropriate bcm6434_l1_cpu to the interrupt handler instead of the chip itself, so the handler always has the right block. Fixes: c7c42ec2 ("irqchips/bmips: Add bcm6345-l1 interrupt controller") Signed-off-by:
Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
- 21 Jun, 2023 2 commits
-
-
Marc Zyngier authored
* irq/misc-6.5: : . : Misc cleanups: : : - Add a number of missing prototypes : - Mark global symbol as static where needed : - Drop some now useless non-DT code paths : - Add a missing interrupt mapping to the STM32 irqchip : - Silence another STM32 warning when building with W=1 : - Fix the jcore-aic driver that actually never worked... : . Revert "irqchip/mxs: Include linux/irqchip/mxs.h" irqchip/jcore-aic: Fix missing allocation of IRQ descriptors irqchip/stm32-exti: Fix warning on initialized field overwritten irqchip/stm32-exti: Add STM32MP15xx IWDG2 EXTI to GIC map irqchip/gicv3: Add a iort_pmsi_get_dev_id() prototype irqchip/mxs: Include linux/irqchip/mxs.h irqchip/clps711x: Remove unused clps711x_intc_init() function irqchip/mmp: Remove non-DT codepath irqchip/ftintc010: Mark all function static irqdomain: Include internals.h for function prototypes Signed-off-by: -
Marc Zyngier authored
This reverts commit 5b7e5676. Although including linux/irqchip/mxs.h is technically correct, this clashes with the parallel removal of this include file with 32bit ARM modernizing the low level irq handling as part of 5bb578a0 ("ARM: 9298/1: Drop custom mdesc->handle_irq()"). As such, this patch is not only unnecessary, it also breaks compilation in -next. Revert it. Signed-off-by:
-
- 17 Jun, 2023 12 commits
-
-
John Paul Adrian Glaubitz authored
The initialization function for the J-Core AIC aic_irq_of_init() is currently missing the call to irq_alloc_descs() which allocates and initializes all the IRQ descriptors. Add missing function call and return the error code from irq_alloc_descs() in case the allocation fails. Fixes: 981b58f6 ("irqchip/jcore-aic: Add J-Core AIC driver") Signed-off-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Tested-by:
Rob Landley <rob@landley.net> Signed-off-by:
-
Antonio Borneo authored
While compiling with W=1, both gcc and clang complain about a tricky way to initialize an array by filling it with a non-zero value and then overrride some of the array elements. In this case the override is intentional, so just disable the specific warning for only this part of the code. Note: the flag "-Woverride-init" is recognized by both compilers, but the warning msg from clang reports "-Winitializer-overrides". The doc of clang clarifies that the two flags are synonyms, so use here only the flag name common on both compilers. Signed-off-by:
Antonio Borneo <antonio.borneo@foss.st.com> Fixes: c2974933 ("irqchip/stm32-exti: Simplify irq description table") Signed-off-by:
-
Marek Vasut authored
The EXTI interrupt 46 is mapped to GIC interrupt 151. Add the missing mapping, which is used for IWDG2 pretimeout interrupt and wake up source. Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Arnd Bergmann authored
iort_pmsi_get_dev_id() has a __weak definition in the driver, and an override in arm64 specific code, but the declaration is conditional and not always seen when the copy in the driver gets built: drivers/irqchip/irq-gic-v3-its-platform-msi.c:41:12: error: no previous prototype for 'iort_pmsi_get_dev_id' [-Werror=missing-prototypes] Move the existing declaration out of the #ifdef block to ensure it can be seen in all configurations. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
-
Arnd Bergmann authored
This header contains the definition for icoll_handle_irq(), which is used in arch/arm/mach-mxs/mach-mxs.c, without this we get a warning about a missing prototype when building with W=1. Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
This function has no caller or declaration any more: drivers/irqchip/irq-clps711x.c:215:13: error: no previous prototype for 'clps711x_intc_init' The #ifdef check around clps711x_intc_init_dt() is also not needed since the file is only built when that is enabled. Fixes: 4a56f46a ("ARM: clps711x: Remove boards support") Signed-off-by:
-
Arnd Bergmann authored
Building with "W=1" warns about missing declarations for two functions in the mmp irqchip driver: drivers/irqchip/irq-mmp.c:248:13: error: no previous prototype for 'icu_init_irq' drivers/irqchip/irq-mmp.c:271:13: error: no previous prototype for 'mmp2_init_icu' The declarations are present in an unused header, but since there is no caller, it's best to just remove the functions and the header completely, making the driver DT-only to match the state of the platform. Fixes: 77acc85c ("ARM: mmp: remove device definitions") Signed-off-by:
-
Arnd Bergmann authored
Two functions were always global but never had any callers outside of this file: drivers/irqchip/irq-ftintc010.c:128:39: error: no previous prototype for 'ft010_irqchip_handle_irq' drivers/irqchip/irq-ftintc010.c:165:12: error: no previous prototype for 'ft010_of_init_irq' Fixes: b4d3053c ("irqchip: Add a driver for Cortina Gemini") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
irq_domain_debugfs_init() is defined in irqdomain.c, but the declaration is in a header that is not included here: kernel/irq/irqdomain.c:1965:13: error: no previous prototype for 'irq_domain_debugfs_init' [-Werror=missing-prototypes] Signed-off-by:
-
Marc Zyngier authored
* irq/loongarch-fixes-6.5: : . : Yet another series of random fixes for the Loongson/Loongarch : string of interrupt controller, covering : : - affinity setting, : - trigger polarity, : - wake-up, : - DT support : . irqchip/loongson-eiointc: Add DT init support dt-bindings: interrupt-controller: Add Loongson EIOINTC irqchip/loongson-eiointc: Fix irq affinity setting during resume irqchip/loongson-liointc: Add IRQCHIP_SKIP_SET_WAKE flag irqchip/loongson-liointc: Fix IRQ trigger polarity irqchip/loongson-pch-pic: Fix potential incorrect hwirq assignment irqchip/loongson-pch-pic: Fix initialization of HT vector register Signed-off-by: -
Binbin Zhou authored
Add EIOINTC irqchip DT support, which is needed for Loongson chips based on DT and supporting EIOINTC, such as the Loongson-2K0500 SOC. Signed-off-by:
Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by:
-
Binbin Zhou authored
Add Loongson Extended I/O Interrupt controller binding with DT schema format using json-schema. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 16 Jun, 2023 10 commits
-
-
Jianmin Lv authored
The hierarchy of PCH PIC, PCH PCI MSI and EIONTC is as following: PCH PIC ------->| |---->EIOINTC PCH PCI MSI --->| so the irq_data list of irq_desc for IRQs on PCH PIC and PCH PCI MSI is like this: irq_desc->irq_data(domain: PCH PIC)->parent_data(domain: EIOINTC) irq_desc->irq_data(domain: PCH PCI MSI)->parent_data(domain: EIOINTC) In eiointc_resume(), the irq_data passed into eiointc_set_irq_affinity() should be matched to EIOINTC domain instead of PCH PIC or PCH PCI MSI domain, so fix it. Fixes: a90335c2 ("irqchip/loongson-eiointc: Add suspend/resume support") Reported-by:yangqiming <yangqiming@loongson.cn> Signed-off-by:
Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by:
-
Yinbo Zhu authored
LIOINTC doesn't require specific logic to work with wakeup IRQs, and no irq_set_wake callback is needed. To allow registered IRQs from LIOINTC to be used as a wakeup-source, and ensure irq_set_irq_wake() works well, the flag IRQCHIP_SKIP_SET_WAKE should be added. Reviewed-by:
Huacai Chen <chenhuacai@kernel.org> Signed-off-by:
Yinbo Zhu <zhuyinbo@loongson.cn> Signed-off-by:
-
Jianmin Lv authored
For the INT_POLARITY register of Loongson-2K series IRQ controller, '0' indicates high level or rising edge triggered, '1' indicates low level or falling edge triggered, and we can find out the information from the Loongson 2K1000LA User Manual v1.0, Table 9-2, Section 9.3 (中断寄存器描述 / Description of the Interrupt Registers). For Loongson-3 CPU series, setting INT_POLARITY register is not supported and writting it has no effect. So trigger polarity setting shouled be fixed for Loongson-2K CPU series. Fixes: 17343d0b ("irqchip/loongson-liointc: Support to set IRQ type for ACPI path") Cc: stable@vger.kernel.org Reviewed-by:
Chong Qiao <qiaochong@loongson.cn> Signed-off-by:
-
Liu Peibao authored
In DeviceTree path, when ht_vec_base is not zero, the hwirq of PCH PIC will be assigned incorrectly. Because when pch_pic_domain_translate() adds the ht_vec_base to hwirq, the hwirq does not have the ht_vec_base subtracted when calling irq_domain_set_info(). The ht_vec_base is designed for the parent irq chip/domain of the PCH PIC. It seems not proper to deal this in callbacks of the PCH PIC domain and let's put this back like the initial commit ef8c01eb ("irqchip: Add Loongson PCH PIC controller"). Fixes: bcdd75c5 ("irqchip/loongson-pch-pic: Add ACPI init support") Cc: stable@vger.kernel.org Reviewed-by:
Huacai Chen <chenhuacai@loongson.cn> Signed-off-by:
Liu Peibao <liupeibao@loongson.cn> Signed-off-by:
-
Jianmin Lv authored
In an ACPI-based dual-bridge system, IRQ of each bridge's PCH PIC sent to CPU is always a zero-based number, which means that the IRQ on PCH PIC of each bridge is mapped into vector range from 0 to 63 of upstream irqchip(e.g. EIOINTC). EIOINTC N: [0 ... 63 | 64 ... 255] -------- ---------- ^ ^ | | PCH PIC N | PCH MSI N For example, the IRQ vector number of sata controller on PCH PIC of each bridge is 16, which is sent to upstream irqchip of EIOINTC when an interrupt occurs, which will set bit 16 of EIOINTC. Since hwirq of 16 on EIOINTC has been mapped to a irq_desc for sata controller during hierarchy irq allocation, the related mapped IRQ will be found through irq_resolve_mapping() in the IRQ domain of EIOINTC. So, the IRQ number set in HT vector register should be fixed to be a zero-based number. Cc: stable@vger.kernel.org Reviewed-by:liuyun <liuyun@loongson.cn> Signed-off-by:
-
Marc Zyngier authored
* irq/lpi-resend: : . : Patch series from James Gowans, working around an issue with : GICv3 LPIs that can fire concurrently on multiple CPUs. : . irqchip/gic-v3-its: Enable RESEND_WHEN_IN_PROGRESS for LPIs genirq: Allow fasteoi handler to resend interrupts on concurrent handling genirq: Expand doc for PENDING and REPLAY flags genirq: Use BIT() for the IRQD_* state flags Signed-off-by: -
James Gowans authored
GICv3 LPIs are impacted by an architectural design issue: they do not have a global active state and as such a given LPI can be delivered to a new CPU after an affinity change while the previous instance of the same LPI handler has not yet completed on the original CPU. If LPIs had an active state, this second LPI would not be delivered until the first CPU deactivated the initial LPI, just like SPIs. To solve this issue, use the newly introduced IRQD_RESEND_WHEN_IN_PROGRESS flag, ensuring that we do not lose an LPI being delivered during that window by getting the GIC to resend it. This workaround gets enabled for all LPIs, including the VPE doorbells. Suggested-by:
James Gowans <jgowans@amazon.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: KarimAllah Raslan <karahmed@amazon.com> Cc: Yipeng Zou <zouyipeng@huawei.com> Cc: Zhang Jianhua <chris.zjh@huawei.com> [maz: massaged commit message] Signed-off-by:
-
James Gowans authored
There is a class of interrupt controllers out there that, once they have signalled a given interrupt number, will still signal incoming instances of the *same* interrupt despite the original interrupt not having been EOIed yet. As long as the new interrupt reaches the *same* CPU, nothing bad happens, as that CPU still has its interrupts globally disabled, and we will only take the new interrupt once the interrupt has been EOIed. However, things become more "interesting" if an affinity change comes in while the interrupt is being handled. More specifically, while the per-irq lock is being dropped. This results in the affinity change taking place immediately. At this point, there is nothing that prevents the interrupt from firing on the new target CPU. We end-up with the interrupt running concurrently on two CPUs, which isn't a good thing. And that's where things become worse: the new CPU notices that the interrupt handling is in progress (irq_may_run() return false), and *drops the interrupt on the floor*. The whole race looks like this: CPU 0 | CPU 1 -----------------------------|----------------------------- interrupt start | handle_fasteoi_irq | set_affinity(CPU 1) handler | ... | interrupt start ... | handle_fasteoi_irq -> early out handle_fasteoi_irq return | interrupt end interrupt end | If the interrupt was an edge, too bad. The interrupt is lost, and the system will eventually die one way or another. Not great. A way to avoid this situation is to detect this problem at the point we handle the interrupt on the new target. Instead of dropping the interrupt, use the resend mechanism to force it to be replayed. Also, in order to limit the impact of this workaround to the pathetic architectures that require it, gate it behind a new irq flag aptly named IRQD_RESEND_WHEN_IN_PROGRESS. Suggested-by: -
James Gowans authored
Adding a bit more info about what the flags are used for may help future code readers. Signed-off-by:
-
Marc Zyngier authored
As we're about to use the last bit available in the IRQD_* state flags, rewrite these flags with BIT(), which ensures that these constant do not represent a signed value. Signed-off-by:
-
- 30 May, 2023 1 commit
-
-
Marc Zyngier authored
* irq/gic-v3-asr8601: : Workaround for the ASR8601 SoC that couples a GIC500 with : CPUs that use affinities that cannot be handled by the GIC... irqchip/gic-v3: Work around affinity issues on ASR8601 irqchip/gic-v3: Improve affinity helper Signed-off-by:
-
- 29 May, 2023 2 commits
-
-
zhengyan authored
The ASR8601 SoC combines ARMv8.2 CPUs from ARM with a GIC-500, also from ARM. However, the two are incompatible as the former expose an affinity in the form of (cluster, core, thread), while the latter can only deal with (cluster, core). If nothing is done, the GIC simply cannot route interrupts to the CPUs. Implement a workaround that shifts the affinity down by a level, ensuring the delivery of interrupts despite the implementation mismatch. Signed-off-by:
zhengyan <zhengyan@asrmicro.com> [maz: rewrote commit message, reimplemented the workaround in a manageable way] Signed-off-by:
-
Marc Zyngier authored
The GICv3 driver uses multiple formats for the affinity, all derived from a reading of MPDR_EL1 on one CPU or another. Simplify the handling of these affinity by moving the access to the CPU affinity via cpu_logical_map() inside the helper, and rename it accordingly. This will be helpful to support some more broken hardware. Signed-off-by:
-
- 28 May, 2023 8 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 cpu fix from Thomas Gleixner: "A single fix for x86: - Prevent a bogus setting for the number of HT siblings, which is caused by the CPUID evaluation trainwreck of X86. That recomputes the value for each CPU, so the last CPU "wins". That can cause completely bogus sibling values" * tag 'x86-urgent-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/topology: Fix erroneous smp_num_siblings on Intel Hybrid platforms -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Thomas Gleixner: "A small set of perf fixes: - Make the MSR-readout based CHA discovery work around broken discovery tables in some SPR firmwares. - Prevent saving PEBS configuration which has software bits set that cause a crash when restored into the relevant MSR" * tag 'perf-urgent-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/uncore: Correct the number of CHAs on SPR perf/x86/intel: Save/restore cpuc->active_pebs_data_cfg when using guest PEBS -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull unwinder fixes from Thomas Gleixner: "A set of unwinder and tooling fixes: - Ensure that the stack pointer on x86 is aligned again so that the unwinder does not read past the end of the stack - Discard .note.gnu.property section which has a pointlessly different alignment than the other note sections. That confuses tooling of all sorts including readelf, libbpf and pahole" * tag 'objtool-urgent-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/show_trace_log_lvl: Ensure stack pointer is aligned, again vmlinux.lds.h: Discard .note.gnu.property section -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull debugobjects fixes from Thomas Gleixner: "Two fixes for debugobjects: - Prevent the allocation path from waking up kswapd. That's a long standing issue due to the GFP_ATOMIC allocation flag. As debug objects can be invoked from pretty much any context waking kswapd can end up in arbitrary lock chains versus the waitqueue lock - Correct the explicit lockdep wait-type violation in debug_object_fill_pool()" * tag 'core-debugobjects-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: debugobjects: Don't wake up kswapd from fill_pool() debugobjects,locking: Annotate debug_object_fill_pool() wait type violation -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "A set of fixes for interrupt chip drivers: - Prevent loss of state in the MIPS GIC interrupt controller - Disable pseudo NMIs on Mediatek based Chromebooks as they have firmware issues which cause instantenous chrashes and freezes wen pseudo NMIs are used - Fix the error handling path in the MBIGEN driver and a defined but not used warning in the meson-gpio interrupt chip driver" * tag 'irq-urgent-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/mbigen: Unify the error handling in mbigen_of_create_domain() irqchip/meson-gpio: Mark OF related data as maybe unused irqchip/mips-gic: Use raw spinlock for gic_lock irqchip/mips-gic: Don't touch vl_map if a local interrupt is not routable irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/ broken FW -
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds authored
Pull MIPS fixes from Thomas Bogendoerfer: - fixes to get alchemy platform back in shape - fix for initrd detection * tag 'mips-fixes_6.4_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: mips: Move initrd_start check after initrd address sanitisation. MIPS: Alchemy: fix dbdma2 MIPS: Restore Au1300 support MIPS: unhide PATA_PLATFORM
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fix from Michael Ellerman: - Reinstate ARCH_FORCE_MAX_ORDER ranges to fix various breakage * tag 'powerpc-6.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/mm: Reinstate ARCH_FORCE_MAX_ORDER ranges
-
- 27 May, 2023 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds authored
Pull xen fixes from Juergen Gross: - a double free fix in the Xen pvcalls backend driver - a fix for a regression causing the MSI related sysfs entries to not being created in Xen PV guests - a fix in the Xen blkfront driver for handling insane input data better * tag 'for-linus-6.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/pci/xen: populate MSI sysfs entries xen/pvcalls-back: fix double frees with pvcalls_new_active_socket() xen/blkfront: Only check REQ_FUA for writes
-
