BMC/Intel-BMC/linux.git/drivers/irqchip, branch dev-5.15-intel

irqchip/gic, gic-v3: Prevent GSI to SGI translations

2022-04-13T18:59:28+00:00

commit 544808f7e21cb9ccdb8f3aa7de594c05b1419061 upstream. At the moment the GIC IRQ domain translation routine happily converts ACPI table GSI numbers below 16 to GIC SGIs (Software Generated Interrupts aka IPIs). On the Devicetree side we explicitly forbid this translation, actually the function will never return HWIRQs below 16 when using a DT based domain translation. We expect SGIs to be handled in the first part of the function, and any further occurrence should be treated as a firmware bug, so add a check and print to report this explicitly and avoid lengthy debug sessions. Fixes: 64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard interrupts") Signed-off-by: Andre Przywara Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220404110842.2882446-1-andre.przywara@arm.com Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v4: Wait for GICR_VPENDBASER.Dirty to clear before descheduling

2022-04-13T18:59:28+00:00

commit af27e41612ec7e5b4783f589b753a7c31a37aac8 upstream. The way KVM drives GICv4.{0,1} is as follows: - vcpu_load() makes the VPE resident, instructing the RD to start scanning for interrupts - just before entering the guest, we check that the RD has finished scanning and that we can start running the vcpu - on preemption, we deschedule the VPE by making it invalid on the RD However, we are preemptible between the first two steps. If it so happens *and* that the RD was still scanning, we nonetheless write to the GICR_VPENDBASER register while Dirty is set, and bad things happen (we're in UNPRED land). This affects both the 4.0 and 4.1 implementations. Make sure Dirty is cleared before performing the deschedule, meaning that its_clear_vpend_valid() becomes a sort of full VPE residency barrier. Reported-by: Jingyi Wang Tested-by: Nianyao Tang Signed-off-by: Marc Zyngier Fixes: 57e3cebd022f ("KVM: arm64: Delay the polling of the GICR_VPENDBASER.Dirty bit") Link: https://lore.kernel.org/r/4aae10ba-b39a-5f84-754b-69c2eb0a2c03@huawei.com Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v3: Fix GICR_CTLR.RWP polling

2022-04-13T18:59:24+00:00

commit 0df6664531a12cdd8fc873f0cac0dcb40243d3e9 upstream. It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing. Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Andre Przywara Reviewed-by: Lorenzo Pieralisi Link: https://lore.kernel.org/r/20220315165034.794482-2-maz@kernel.org Signed-off-by: Greg Kroah-Hartman

irqchip/nvic: Release nvic_base upon failure

2022-04-08T12:23:56+00:00

[ Upstream commit e414c25e3399b2b3d7337dc47abccab5c71b7c8f ] smatch warning was reported as below -> smatch warnings: drivers/irqchip/irq-nvic.c:131 nvic_of_init() warn: 'nvic_base' not released on lines: 97. Release nvic_base upon failure. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Souptick Joarder (HPE) Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220218163303.33344-1-jrdr.linux@gmail.com Signed-off-by: Sasha Levin

irqchip/qcom-pdc: Fix broken locking

2022-04-08T12:23:55+00:00

[ Upstream commit a6aca2f460e203781dc41391913cc5b54f4bc0ce ] pdc_enable_intr() serves as a primitive to qcom_pdc_gic_{en,dis}able, and has a raw spinlock for mutual exclusion, which is uses with interruptible primitives. This means that this critical section can itself be interrupted. Should the interrupt also be a PDC interrupt, and the endpoint driver perform an irq_disable() on that interrupt, we end-up in a deadlock. Fix this by using the irqsave/irqrestore variants of the locking primitives. Signed-off-by: Marc Zyngier Reviewed-by: Maulik Shah Link: https://lore.kernel.org/r/20220224101226.88373-5-maz@kernel.org Signed-off-by: Sasha Levin

irqchip/sifive-plic: Add missing thead,c900-plic match string

2022-02-23T11:03:17+00:00

[ Upstream commit 1d4df649cbb4b26d19bea38ecff4b65b10a1bbca ] The thead,c900-plic has been used in opensbi to distinguish PLIC [1]. Although PLICs have the same behaviors in Linux, they are different hardware with some custom initializing in firmware(opensbi). Qute opensbi patch commit-msg by Samuel: The T-HEAD PLIC implementation requires setting a delegation bit to allow access from S-mode. Now that the T-HEAD PLIC has its own compatible string, set this bit automatically from the PLIC driver, instead of reaching into the PLIC's MMIO space from another driver. [1]: https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd62653b9fb31623a42ced45f38ea6 Signed-off-by: Guo Ren Cc: Anup Patel Cc: Marc Zyngier Cc: Palmer Dabbelt Cc: Samuel Holland Cc: Thomas Gleixner Tested-by: Samuel Holland Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220130135634.1213301-3-guoren@kernel.org Signed-off-by: Sasha Levin

irqchip/realtek-rtl: Service all pending interrupts

2022-02-16T11:56:11+00:00

[ Upstream commit 960dd884ddf5621ae6284cd3a42724500a97ae4c ] Instead of only servicing the lowest pending interrupt line, make sure all pending SoC interrupts are serviced before exiting the chained handler. This adds a small overhead if only one interrupt is pending, but should prevent rapid re-triggering of the handler. Signed-off-by: Sander Vanheule Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/5082ad3cb8b4eedf55075561b93eff6570299fe1.1641739718.git.sander@svanheule.net Signed-off-by: Sasha Levin

irqchip/realtek-rtl: Fix off-by-one in routing

2022-02-01T16:27:15+00:00

commit 91351b5dd0fd494eb2d85e1bb6aca77b067447e0 upstream. There is an offset between routing values (1..6) and the connected MIPS CPU interrupts (2..7), but no distinction was made between these two values. This issue was previously hidden during testing, because an interrupt mapping was used where for each required interrupt another (unused) routing was configured, with an offset of +1. Offset the CPU IRQ numbers by -1 to retrieve the correct routing value. Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller") Signed-off-by: Sander Vanheule Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/177b920aa8d8610615692d0e657e509f363c85ca.1641739718.git.sander@svanheule.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

irqchip/realtek-rtl: Map control data to virq

2022-02-01T16:27:15+00:00

commit 291e79c7e2eb6fdc016453597b78482e06199d0f upstream. The driver assigned the irqchip and irq handler to the hardware irq, instead of the virq. This is incorrect, and only worked because these irq numbers happened to be the same on the devices used for testing the original driver. Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller") Signed-off-by: Sander Vanheule Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/4b4936606480265db47df152f00bc2ed46340599.1641739718.git.sander@svanheule.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

irqchip/gic-v4: Disable redistributors' view of the VPE table at boot time

2022-01-27T10:05:02+00:00

[ Upstream commit 79a7f77b9b154d572bd9d2f1eecf58c4d018d8e2 ] Jay Chen reported that using a kdump kernel on a GICv4.1 system results in a RAS error being delivered when the secondary kernel configures the ITS's view of the new VPE table. As it turns out, that's because each RD still has a pointer to the previous instance of the VPE table, and that particular implementation is very upset by seeing two bits of the HW that should point to the same table with different values. To solve this, let's invalidate any reference that any RD has to the VPE table when discovering the RDs. The ITS can then be programmed as expected. Reported-by: Jay Chen Signed-off-by: Marc Zyngier Cc: Lorenzo Pieralisi Link: https://lore.kernel.org/r/20211214064716.21407-1-jkchen@linux.alibaba.com Link: https://lore.kernel.org/r/20211216144804.1578566-1-maz@kernel.org Signed-off-by: Sasha Levin