kernel/linux.git/drivers/irqchip, branch v5.9.12

irqchip/exiu: Fix the index of fwspec for IRQ type

2020-12-02T07:52:02+00:00

commit d001e41e1b15716e9b759df5ef00510699f85282 upstream. Since fwspec->param_count of ACPI node is two, the index of IRQ type in fwspec->param[] should be 1 rather than 2. Fixes: 3d090a36c8c8 ("irqchip/exiu: Implement ACPI support") Signed-off-by: Chen Baozi Signed-off-by: Marc Zyngier Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20201117032015.11805-1-cbz@baozis.org Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

irqchip/sifive-plic: Fix chip_data access within a hierarchy

2020-11-18T18:22:02+00:00

[ Upstream commit f9ac7bbd6e4540dcc6df621b9c9b6eb2e26ded1d ] The plic driver crashes in plic_irq_unmask() when the interrupt is within a hierarchy, as it picks the top-level chip_data instead of its local one. Using irq_data_get_irq_chip_data() instead of irq_get_chip_data() solves the issue for good. Fixes: f1ad1133b18f ("irqchip/sifive-plic: Add support for multiple PLICs") Signed-off-by: Greentime Hu [maz: rewrote commit message] Signed-off-by: Marc Zyngier Reviewed-by: Anup Patel Reviewed-by: Atish Patra Link: https://lore.kernel.org/r/20201029023738.127472-1-greentime.hu@sifive.com Signed-off-by: Sasha Levin

irqchip/sifive-plic: Fix broken irq_set_affinity() callback

2020-11-18T18:22:00+00:00

[ Upstream commit a7480c5d725c4ecfc627e70960f249c34f5d13e8 ] An interrupt submitted to an affinity change will always be left enabled after plic_set_affinity() has been called, while the expectation is that it should stay in whatever state it was before the call. Preserving the configuration fixes a PWM hang issue on the Unleashed board. [ 919.015783] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 919.020922] rcu: 0-...0: (0 ticks this GP) idle=7d2/1/0x4000000000000002 softirq=1424/1424 fqs=105807 [ 919.030295] (detected by 1, t=225825 jiffies, g=1561, q=3496) [ 919.036109] Task dump for CPU 0: [ 919.039321] kworker/0:1 R running task 0 30 2 0x00000008 [ 919.046359] Workqueue: events set_brightness_delayed [ 919.051302] Call Trace: [ 919.053738] [] __schedule+0x194/0x4de [ 982.035783] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 982.040923] rcu: 0-...0: (0 ticks this GP) idle=7d2/1/0x4000000000000002 softirq=1424/1424 fqs=113325 [ 982.050294] (detected by 1, t=241580 jiffies, g=1561, q=3509) [ 982.056108] Task dump for CPU 0: [ 982.059321] kworker/0:1 R running task 0 30 2 0x00000008 [ 982.066359] Workqueue: events set_brightness_delayed [ 982.071302] Call Trace: [ 982.073739] [] __schedule+0x194/0x4de [..] Fixes: bb0fed1c60cc ("irqchip/sifive-plic: Switch to fasteoi flow") Signed-off-by: Greentime Hu [maz: tidy-up commit message] Signed-off-by: Marc Zyngier Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20201020081532.2377-1-greentime.hu@sifive.com Signed-off-by: Sasha Levin

irqchip/loongson-htvec: Fix initial interrupt clearing

2020-11-05T10:51:31+00:00

commit 1d1e5630de78f7253ac24b92cee6427c3ff04d56 upstream. In htvec_reset() only the first group of initial interrupts is cleared. This sometimes causes spurious interrupts, so let's clear all groups. While at it, fix the nearby comment that to match the reality of what the driver does. Fixes: 818e915fbac518e8c78e1877 ("irqchip: Add Loongson HyperTransport Vector support") Signed-off-by: Huacai Chen Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1599819978-13999-2-git-send-email-chenhc@lemote.com Signed-off-by: Greg Kroah-Hartman

irqchip/ti-sci-intr: Fix unsigned comparison to zero

2020-10-29T09:11:01+00:00

[ Upstream commit 8ddf1905a904ca86d71ca1c435e4b0b2a0b70df8 ] ti_sci_intr_xlate_irq() return -ENOENT on fail, p_hwirq should be int type. Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR") Signed-off-by: YueHaibing Signed-off-by: Marc Zyngier Acked-by: Lokesh Vutla Link: https://lore.kernel.org/r/20200826035321.18620-1-yuehaibing@huawei.com Signed-off-by: Sasha Levin

irqchip/ti-sci-inta: Fix unsigned comparison to zero

2020-10-29T09:11:01+00:00

[ Upstream commit 4c9b1bfaa5039fee650f4de514a8e70ae976fc2f ] ti_sci_inta_xlate_irq() return -ENOENT on fail, p_hwirq should be int type. Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC") Signed-off-by: YueHaibing Signed-off-by: Marc Zyngier Acked-by: Lokesh Vutla Link: https://lore.kernel.org/r/20200826035430.21060-1-yuehaibing@huawei.com Signed-off-by: Sasha Levin

Merge tag 'irq-urgent-2020-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-08-30T18:56:54+00:00

Pull irq fixes from Thomas Gleixner: "A set of fixes for interrupt chip drivers: - Revert the platform driver conversion of interrupt chip drivers as it turned out to create more problems than it solves. - Fix a trivial typo in the new module helpers which made probing reliably fail. - Small fixes in the STM32 and MIPS Ingenic drivers - The TI firmware rework which had badly managed dependencies and had to wait post rc1" * tag 'irq-urgent-2020-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/ingenic: Leave parent IRQ unmasked on suspend irqchip/stm32-exti: Avoid losing interrupts due to clearing pending bits by mistake irqchip: Revert modular support for drivers using IRQCHIP_PLATFORM_DRIVER helperse irqchip: Fix probing deferal when using IRQCHIP_PLATFORM_DRIVER helpers arm64: dts: k3-am65: Update the RM resource types arm64: dts: k3-am65: ti-sci-inta/intr: Update to latest bindings arm64: dts: k3-j721e: ti-sci-inta/intr: Update to latest bindings irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC irqchip/ti-sci-inta: Do not store TISCI device id in platform device id field dt-bindings: irqchip: Convert ti, sci-inta bindings to yaml dt-bindings: irqchip: ti, sci-inta: Update docs to support different parent. irqchip/ti-sci-intr: Add support for INTR being a parent to INTR dt-bindings: irqchip: Convert ti, sci-intr bindings to yaml dt-bindings: irqchip: ti, sci-intr: Update bindings to drop the usage of gic as parent firmware: ti_sci: Add support for getting resource with subtype firmware: ti_sci: Drop unused structure ti_sci_rm_type_map firmware: ti_sci: Drop the device id to resource type translation

irqchip/ingenic: Leave parent IRQ unmasked on suspend

2020-08-25T09:59:29+00:00

All the wakeup sources we possibly want will go through the interrupt controller, so the parent IRQ must not be masked during suspend, or there won't be any way to wake up the system. Signed-off-by: Paul Cercueil Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20200819180602.136969-1-paul@crapouillou.net

irqchip/stm32-exti: Avoid losing interrupts due to clearing pending bits by mistake

2020-08-25T09:57:05+00:00

In the current code, when the eoi callback of the exti clears the pending bit of the current interrupt, it will first read the values of fpr and rpr, then logically OR the corresponding bit of the interrupt number, and finally write back to fpr and rpr. We found through experiments that if two exti interrupts, we call them int1/int2, arrive almost at the same time. in our scenario, the time difference is 30 microseconds, assuming int1 is triggered first. there will be an extreme scenario: both int's pending bit are set to 1, the irq handle of int1 is executed first, and eoi handle is then executed, at this moment, all pending bits are cleared, but the int 2 has not finally been reported to the cpu yet, which eventually lost int2. According to stm32's TRM description about rpr and fpr: Writing a 1 to this bit will trigger a rising edge event on event x, Writing 0 has no effect. Therefore, when clearing the pending bit, we only need to clear the pending bit of the irq. Fixes: 927abfc4461e7 ("irqchip/stm32: Add stm32mp1 support with hierarchy domain") Signed-off-by: qiuguorui1 Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org # v4.18+ Link: https://lore.kernel.org/r/20200820031629.15582-1-qiuguorui1@huawei.com

irqchip: Revert modular support for drivers using IRQCHIP_PLATFORM_DRIVER helperse

2020-08-25T09:48:54+00:00

It has become obvious that switching a number of irqchip drivers to being platform drivers without considering the platform was a mistake. We have multiple reports of end-point drivers not probing because the irqchip driver isn't there yet, breaking the expectations of the users. This patch reverts: 920ecb8c35cb ("irqchip/mtk-cirq: Convert to a platform driver") f97dbf48ca43 ("irqchip/mtk-sysirq: Convert to a platform driver") 5be57099d445 ("irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros") 95bf9305d2e3 ("irqchip/qcom-pdc: Allow QCOM_PDC to be loadable as a permanent module") and leave QCOM PDC, MTK sysrq and cirq drivers as built-in, special purpose drivers for the time being until we have worked out a better solution. Reported-by: Enric Balletbo i Serra Reported-by: Frank Wunderlich Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/93debe6a0308b66d3f307af67ba7ec2c@kernel.org