- 24 Apr, 2021 2 commits
-
-
Thomas Gleixner authored
Merge tag 'irqchip-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip and irqdomain updates from Marc Zyngier: New HW support: - New driver for the Nuvoton WPCM450 interrupt controller - New driver for the IDT 79rc3243x interrupt controller - Add support for interrupt trigger configuration to the MStar irqchip - Add more external interrupt support to the STM32 irqchip - Add new compatible strings for QCOM SC7280 to the qcom-pdc binding Fixes and cleanups: - Drop irq_create_strict_mappings() and irq_create_identity_mapping() from the irqdomain API, with cleanups in a couple of drivers - Fix nested NMI issue with spurious interrupts on GICv3 - Don't allow GICv4.1 vSGIs when the CPU doesn't support them - Various cleanups and minor fixes Link: https://lore.kernel.org/r/20210424094640.1731920-1-maz@kernel.org
-
Robert Hancock authored
Previously the XILINX_INTC config option was hidden and only auto-selected on the MicroBlaze platform. However, this IP can also be used on the Zynq and ZynqMP platforms as a secondary cascaded controller. Allow this option to be user-enabled on those platforms. Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210423185853.2556087-1-robert.hancock@calian.com
-
- 23 Apr, 2021 1 commit
-
-
He Ying authored
We triggered the following error while running our 4.19 kernel with the pseudo-NMI patches backported to it: [ 14.816231] ------------[ cut here ]------------ [ 14.816231] kernel BUG at irq.c:99! [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____)) [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] Hardware name: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [ 14.816258] Modules linked in: start_dp(O) smeth(O) [ 15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt [ 15.103099] SMP: stopping secondary CPUs [ 15.103100] Kernel Offset: disabled [ 15.103100] CPU features: 0x36,a2400218 [ 15.103100] Memory Limit: none which is cause by a 'BUG_ON(in_nmi())' in nmi_enter(). From the call trace, we can find three interrupts (noted A, B, C above): interrupt (A) is preempted by (B), which is further interrupted by (C). Subsequent investigations show that (B) results in nmi_enter() being called, but that it actually is a spurious interrupt. Furthermore, interrupts are reenabled in the context of (B), and (C) fires with NMI priority. We end-up with a nested NMI situation, something we definitely do not want to (and cannot) handle. The bug here is that spurious interrupts should never result in any state change, and we should just return to the interrupted context. Moving the handling of spurious interrupts as early as possible in the GICv3 handler fixes this issue. Fixes: 3f1f3234 ("irqchip/gic-v3: Switch to PMR masking before calling IRQ handler") Acked-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
He Ying <heying24@huawei.com> [maz: rewrote commit message, corrected Fixes: tag] Signed-off-by:
-
- 22 Apr, 2021 8 commits
-
-
Thomas Bogendoerfer authored
Document DT bindings for IDT 79RC3243x Interrupt Controller. Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
-
Thomas Bogendoerfer authored
IDT 79rc3243x SoCs have rather simple interrupt controllers connected to the MIPS CPU interrupt lines. Each of them has room for up to 32 interrupts. Signed-off-by:
-
Marc Zyngier authored
It was never completely implemented, and was removed a long time ago. Adjust the documentation to reflect this. Signed-off-by:
-
Marc Zyngier authored
No user of this helper is left, remove it. Signed-off-by: -
Marc Zyngier authored
irq_create_strict_mappings() is a poor way to allow the use of a linear IRQ domain as a legacy one. Let's be upfront about it. Signed-off-by:
-
Marc Zyngier authored
irq_create_strict_mappings() is a poor way to allow the use of a linear IRQ domain as a legacy one. Let's be upfront about it and use a legacy domain when appropriate. Signed-off-by:
-
Lorenzo Pieralisi authored
GIC CPU interfaces versions predating GIC v4.1 were not built to accommodate vINTID within the vSGI range; as reported in the GIC specifications (8.2 "Changes to the CPU interface"), it is CONSTRAINED UNPREDICTABLE to deliver a vSGI to a PE with ID_AA64PFR0_EL1.GIC < b0011. Check the GIC CPUIF version by reading the SYS_ID_AA64_PFR0_EL1. Disable vSGIs if a CPUIF version < 4.1 is detected to prevent using vSGIs on systems where they may misbehave. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by:
-
Randy Dunlap authored
Use the 'fallthrough' macro to document that this switch case does indeed fall through to the next case. ../drivers/irqchip/irq-tb10x.c: In function 'tb10x_irq_set_type': ../drivers/irqchip/irq-tb10x.c:62:13: warning: this statement may fall through [-Wimplicit-fallthrough=] 62 | flow_type = IRQ_TYPE_LEVEL_LOW; ../drivers/irqchip/irq-tb10x.c:63:2: note: here 63 | case IRQ_TYPE_LEVEL_LOW: | ^~~~ Fixes: b06eb017 ("irqchip: Add TB10x interrupt controller driver") Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: Christian Ruppert <christian.ruppert@abilis.com> Signed-off-by:
-
- 10 Apr, 2021 2 commits
-
-
Nicholas Piggin authored
note_interrupt() increments desc->irq_count for each interrupt even for percpu interrupt handlers, even when they are handled successfully. This causes cacheline bouncing and limits scalability. Instead of incrementing irq_count every time, only start incrementing it after seeing an unhandled irq, which should avoid the cache line bouncing in the common path. This actually should give better consistency in handling misbehaving irqs too, because instead of the first unhandled irq arriving at an arbitrary point in the irq_count cycle, its arrival will begin the irq_count cycle. Cédric reports the result of his IPI throughput test: Millions of IPIs/s ----------- -------------------------------------- upstream upstream patched chips cpus default noirqdebug default (irqdebug) ----------- ----------------------------------------- 1 0-15 4.061 4.153 4.084 0-31 7.937 8.186 8.158 0-47 11.018 11.392 11.233 0-63 11.460 13.907 14.022 2 0-79 8.376 18.105 18.084 0-95 7.338 22.101 22.266 0-111 6.716 25.306 25.473 0-127 6.223 27.814 28.029 Signed-off-by:Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210402132037.574661-1-npiggin@gmail.com
-
Tetsuo Handa authored
KMSAN complains that new_value at cpumask_parse_user() from write_irq_affinity() from irq_affinity_proc_write() is uninitialized. [ 148.133411][ T5509] ===================================================== [ 148.135383][ T5509] BUG: KMSAN: uninit-value in find_next_bit+0x325/0x340 [ 148.137819][ T5509] [ 148.138448][ T5509] Local variable ----new_value.i@irq_affinity_proc_write created at: [ 148.140768][ T5509] irq_affinity_proc_write+0xc3/0x3d0 [ 148.142298][ T5509] irq_affinity_proc_write+0xc3/0x3d0 [ 148.143823][ T5509] ===================================================== Since bitmap_parse() from cpumask_parse_user() calls find_next_bit(), any alloc_cpumask_var() + cpumask_parse_user() sequence has possibility that find_next_bit() accesses uninitialized cpu mask variable. Fix this problem by replacing alloc_cpumask_var() with zalloc_cpumask_var(). Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20210401055823.3929-1-penguin-kernel@I-love.SAKURA.ne.jp
-
- 08 Apr, 2021 1 commit
-
-
Marc Zyngier authored
This driver is (for now) ARM specific, and currently doesn't build with a variety of architectures (ia64, RISC-V, x86_64 at the very least). Drop COMPILE_TEST from Kconfig until it gets sorted out. Reviewed-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 07 Apr, 2021 11 commits
-
-
Mark-PK Tsai authored
Support irq polarity configuration and save and restore the config when system suspend and resume. Signed-off-by:
Mark-PK Tsai <mark-pk.tsai@mediatek.com> [maz: fixed irq_set_type callback] Signed-off-by:
-
Jonathan Neuschäfer authored
The WPCM450 AIC ("Advanced Interrupt Controller") is the interrupt controller found in the Nuvoton WPCM450 SoC and other Winbond/Nuvoton SoCs. The list of registers if based on the AMI vendor kernel and the Nuvoton W90N745 datasheet. Although the hardware supports other interrupt modes, the driver only supports high-level interrupts at the moment, because other modes could not be tested so far. Signed-off-by: -
Jonathan Neuschäfer authored
The WPCM450 AIC ("Advanced Interrupt Controller") is the interrupt controller found in the Nuvoton WPCM450 SoC and other Winbond/Nuvoton SoCs. Signed-off-by:Rob Herring <robh@kernel.org> Signed-off-by:
-
Rajendra Nayak authored
Add the compatible string for sc7280 SoC from Qualcomm Signed-off-by:
Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Acked-by:
-
Erwan Le Ray authored
Add following usart instances exti direct event support (used for UART wake up). - exti 26 (USART1) is mapped to GIC 37 - exti 27 (USART2) is mapped to GIC 38 - exti 28 (USART3) is mapped to GIC 39 - exti 29 (USART6) is mapped to GIC 71 - exti 31 (UART5) is mapped to GIC 53 - exti 32 (UART7) is mapped to GIC 82 - exti 33 (UART8) is mapped to GIC 83 Signed-off-by:
Erwan Le Ray <erwan.leray@foss.st.com> Signed-off-by:
-
Arnd Bergmann authored
When building with extra warnings enabled, clang points out a mistake in the error handling: drivers/irqchip/irq-gic-v3-mbi.c:306:21: error: result of comparison of constant 18446744073709551615 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (mbi_phys_base == OF_BAD_ADDR) { Truncate the constant to the same type as the variable it gets compared to, to shut make the check work and void the warning. Fixes: 50528752 ("irqchip/gic-v3: Add support for Message Based Interrupts as an MSI controller") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Jisheng Zhang authored
All of these two are never modified after init, so they can be __ro_after_init. Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Signed-off-by:
-
Hao Fang authored
s/Hisilicon/HiSilicon/ It should use capital S, according to https://www.hisilicon.com/en/terms-of-use. Signed-off-by:
Hao Fang <fanghao11@huawei.com> Signed-off-by:
-
Marc Zyngier authored
Use the generic irq_domain_simple_ops structure instead of a home-grown one. Acked-by:
-
Marc Zyngier authored
The sole user of irq_create_identity_mapping() having been converted, get rid of the unused helper. Signed-off-by: -
Marc Zyngier authored
Instead of playing games with using irq_create_identity_mapping() and irq_domain_associate(), drop the use of the former and only use the latter, together with the allocation of the irq_desc as needed. It doesn't make the code less awful, but at least the intent is clearer. Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
- 30 Mar, 2021 1 commit
-
-
Bartosz Golaszewski authored
The custom devres structure manages only a single pointer which can can be achieved by using devm_add_action_or_reset() as well which makes the code simpler. [ tglx: Fixed return value handling - found by smatch ] Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
-
- 25 Mar, 2021 1 commit
-
-
Sebastian Andrzej Siewior authored
The i915 driver has its own tasklet interface which was overseen in the tasklet rework. __tasklet_disable_sync_once() is a wrapper around tasklet_unlock_wait(). tasklet_unlock_wait() might sleep, but the i915 wrappers invokes it from non-preemtible contexts with bottom halves disabled. Use tasklet_unlock_spin_wait() instead which can be invoked from non-preemptible contexts. Fixes: da044747 ("tasklets: Replace spin wait in tasklet_unlock_wait()") Reported-by:
kernel test robot <oliver.sang@intel.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
- 22 Mar, 2021 1 commit
-
-
Ingo Molnar authored
Fix ~36 single-word typos in the IRQ, irqchip and irqdomain code comments. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
- 19 Mar, 2021 1 commit
-
-
Vitaly Kuznetsov authored
When irq_matrix_free() is called for an unallocated vector the managed_allocated and total_allocated counters get out of sync with the real state of the matrix. Later, when the last interrupt is freed, these counters will underflow resulting in UINTMAX because the counters are unsigned. While this is certainly a problem of the calling code, this can be catched in the allocator by checking the allocation bit for the to be freed vector which simplifies debugging. An example of the problem described above: https://lore.kernel.org/lkml/20210318192819.636943062@linutronix.de/ Add the missing sanity check and emit a warning when it triggers. Suggested-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
- 17 Mar, 2021 11 commits
-
-
Juergen Gross authored
The if condition in irq_matrix_reserve() can be much simpler. While at it fix a typo in the comment. Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
Thomas Gleixner authored
Soft interrupt disabled sections can legitimately be preempted or schedule out when blocking on a lock on RT enabled kernels so the RCU preempt check warning has to be disabled for RT kernels. Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Reviewed-by:
Frederic Weisbecker <frederic@kernel.org> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20210309085727.626304079@linutronix.de
-
Thomas Gleixner authored
On RT a task which has soft interrupts disabled can block on a lock and schedule out to idle while soft interrupts are pending. This triggers the warning in the NOHZ idle code which complains about going idle with pending soft interrupts. But as the task is blocked soft interrupt processing is temporarily blocked as well which means that such a warning is a false positive. To prevent that check the per CPU state which indicates that a scheduled out task has soft interrupts disabled. Signed-off-by:
-
Thomas Gleixner authored
Provide a local lock based serialization for soft interrupts on RT which allows the local_bh_disabled() sections and servicing soft interrupts to be preemptible. Provide the necessary inline helpers which allow to reuse the bulk of the softirq processing code. Signed-off-by:
-
Thomas Gleixner authored
To allow reuse of the bulk of softirq processing code for RT and to avoid #ifdeffery all over the place, split protections for various code sections out into inline helpers so the RT variant can just replace them in one go. Signed-off-by:
-
Thomas Gleixner authored
vtime_account_irq and irqtime_account_irq() base checks on preempt_count() which fails on RT because preempt_count() does not contain the softirq accounting which is seperate on RT. These checks do not need the full preempt count as they only operate on the hard and softirq sections. Use irq_count() instead which provides the correct value on both RT and non RT kernels. The compiler is clever enough to fold the masking for !RT: 99b: 65 8b 05 00 00 00 00 mov %gs:0x0(%rip),%eax - 9a2: 25 ff ff ff 7f and $0x7fffffff,%eax + 9a2: 25 00 ff ff 00 and $0xffff00,%eax Reported-by: -
Thomas Gleixner authored
RT requires the softirq processing and local bottomhalf disabled regions to be preemptible. Using the normal preempt count based serialization is therefore not possible because this implicitely disables preemption. RT kernels use a per CPU local lock to serialize bottomhalfs. As local_bh_disable() can nest the lock can only be acquired on the outermost invocation of local_bh_disable() and released when the nest count becomes zero. Tasks which hold the local lock can be preempted so its required to keep track of the nest count per task. Add a RT only counter to task struct and adjust the relevant macros in preempt.h. Signed-off-by:
-
Thomas Gleixner authored
-- NOT FOR IMMEDIATE MERGING -- Now that all users of tasklet_disable() are invoked from sleepable context, convert it to use tasklet_unlock_wait() which might sleep. Signed-off-by:
-
Sebastian Andrzej Siewior authored
tasklet_disable() is invoked in several places. Some of them are in atomic context which prevents a conversion of tasklet_disable() to a sleepable function. The atomic callchains are: ar_context_tasklet() ohci_cancel_packet() tasklet_disable() ... ohci_flush_iso_completions() tasklet_disable() The invocation of tasklet_disable() from at_context_flush() is always in preemptible context. Use tasklet_disable_in_atomic() for the two invocations in ohci_cancel_packet() and ohci_flush_iso_completions(). Signed-off-by: -
Sebastian Andrzej Siewior authored
The hv_compose_msi_msg() callback in irq_chip::irq_compose_msi_msg is invoked via irq_chip_compose_msi_msg(), which itself is always invoked from atomic contexts from the guts of the interrupt core code. There is no way to change this w/o rewriting the whole driver, so use tasklet_disable_in_atomic() which allows to make tasklet_disable() sleepable once the remaining atomic users are addressed. Signed-off-by:
Wei Liu <wei.liu@kernel.org> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
-
Sebastian Andrzej Siewior authored
The atmdev_ops::send callback which calls tasklet_disable() is invoked with bottom halfs disabled from net_device_ops::ndo_start_xmit(). All other invocations of tasklet_disable() in this driver happen in preemptible context. Change the send() call to use tasklet_disable_in_atomic() which allows tasklet_disable() to be made sleepable once the remaining atomic context usage sites are cleaned up. Signed-off-by:
-
