kernel/linux.git/include/linux/irq.h, branch linux-5.8.y

genirq/affinity: Make affinity setting if activated opt-in

2020-08-21T11:14:46+00:00

commit f0c7baca180046824e07fc5f1326e83a8fd150c7 upstream. John reported that on a RK3288 system the perf per CPU interrupts are all affine to CPU0 and provided the analysis: "It looks like what happens is that because the interrupts are not per-CPU in the hardware, armpmu_request_irq() calls irq_force_affinity() while the interrupt is deactivated and then request_irq() with IRQF_PERCPU | IRQF_NOBALANCING. Now when irq_startup() runs with IRQ_STARTUP_NORMAL, it calls irq_setup_affinity() which returns early because IRQF_PERCPU and IRQF_NOBALANCING are set, leaving the interrupt on its original CPU." This was broken by the recent commit which blocked interrupt affinity setting in hardware before activation of the interrupt. While this works in general, it does not work for this particular case. As contrary to the initial analysis not all interrupt chip drivers implement an activate callback, the safe cure is to make the deferred interrupt affinity setting at activation time opt-in. Implement the necessary core logic and make the two irqchip implementations for which this is required opt-in. In hindsight this would have been the right thing to do, but ... Fixes: baedb87d1b53 ("genirq/affinity: Handle affinity setting on inactive interrupts correctly") Reported-by: John Keeping Signed-off-by: Thomas Gleixner Tested-by: Marc Zyngier Acked-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87blk4tzgm.fsf@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman

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

2020-04-19T18:23:33+00:00

Pull irq fixes from Thomas Gleixner: "A set of fixes/updates for the interrupt subsystem: - Remove setup_irq() and remove_irq(). All users have been converted so remove them before new users surface. - A set of bugfixes for various interrupt chip drivers - Add a few missing static attributes to address sparse warnings" * tag 'irq-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() static irqchip/irq-mvebu-icu: Make legacy_bindings static irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock order irqchip/sifive-plic: Fix maximum priority threshold value irqchip/ti-sci-inta: Fix processing of masked irqs irqchip/mbigen: Free msi_desc on device teardown irqchip/gic-v4.1: Update effective affinity of virtual SGIs irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling genirq: Remove setup_irq() and remove_irq()

irq.h: Replace zero-length array with flexible-array member

2020-04-18T20:44:55+00:00

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva

genirq: Remove setup_irq() and remove_irq()

2020-04-14T08:08:50+00:00

Now that all the users of setup_irq() & remove_irq() have been replaced by request_irq() & free_irq() respectively, delete them. Signed-off-by: afzal mohammed Signed-off-by: Thomas Gleixner Reviewed-by: Linus Walleij Link: https://lkml.kernel.org/r/0aa8771ada1ac8e1312f6882980c9c08bd023148.1585320721.git.afzal.mohd.ma@gmail.com

genirq: Add protection against unsafe usage of generic_handle_irq()

2020-03-08T10:06:40+00:00

In general calling generic_handle_irq() with interrupts disabled from non interrupt context is harmless. For some interrupt controllers like the x86 trainwrecks this is outright dangerous as it might corrupt state if an interrupt affinity change is pending. Add infrastructure which allows to mark interrupts as unsafe and catch such usage in generic_handle_irq(). Reported-by: sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Thomas Gleixner Acked-by: Marc Zyngier Link: https://lkml.kernel.org/r/20200306130623.590923677@linutronix.de

x86/apic/msi: Plug non-maskable MSI affinity race

2020-02-01T08:31:47+00:00

Evan tracked down a subtle race between the update of the MSI message and the device raising an interrupt internally on PCI devices which do not support MSI masking. The update of the MSI message is non-atomic and consists of either 2 or 3 sequential 32bit wide writes to the PCI config space. - Write address low 32bits - Write address high 32bits (If supported by device) - Write data When an interrupt is migrated then both address and data might change, so the kernel attempts to mask the MSI interrupt first. But for MSI masking is optional, so there exist devices which do not provide it. That means that if the device raises an interrupt internally between the writes then a MSI message is sent built from half updated state. On x86 this can lead to spurious interrupts on the wrong interrupt vector when the affinity setting changes both address and data. As a consequence the device interrupt can be lost causing the device to become stuck or malfunctioning. Evan tried to handle that by disabling MSI accross an MSI message update. That's not feasible because disabling MSI has issues on its own: If MSI is disabled the PCI device is routing an interrupt to the legacy INTx mechanism. The INTx delivery can be disabled, but the disablement is not working on all devices. Some devices lose interrupts when both MSI and INTx delivery are disabled. Another way to solve this would be to enforce the allocation of the same vector on all CPUs in the system for this kind of screwed devices. That could be done, but it would bring back the vector space exhaustion problems which got solved a few years ago. Fortunately the high address (if supported by the device) is only relevant when X2APIC is enabled which implies interrupt remapping. In the interrupt remapping case the affinity setting is happening at the interrupt remapping unit and the PCI MSI message is programmed only once when the PCI device is initialized. That makes it possible to solve it with a two step update: 1) Target the MSI msg to the new vector on the current target CPU 2) Target the MSI msg to the new vector on the new target CPU In both cases writing the MSI message is only changing a single 32bit word which prevents the issue of inconsistency. After writing the final destination it is necessary to check whether the device issued an interrupt while the intermediate state #1 (new vector, current CPU) was in effect. This is possible because the affinity change is always happening on the current target CPU. The code runs with interrupts disabled, so the interrupt can be detected by checking the IRR of the local APIC. If the vector is pending in the IRR then the interrupt is retriggered on the new target CPU by sending an IPI for the associated vector on the target CPU. This can cause spurious interrupts on both the local and the new target CPU. 1) If the new vector is not in use on the local CPU and the device affected by the affinity change raised an interrupt during the transitional state (step #1 above) then interrupt entry code will ignore that spurious interrupt. The vector is marked so that the 'No irq handler for vector' warning is supressed once. 2) If the new vector is in use already on the local CPU then the IRR check might see an pending interrupt from the device which is using this vector. The IPI to the new target CPU will then invoke the handler of the device, which got the affinity change, even if that device did not issue an interrupt 3) If the new vector is in use already on the local CPU and the device affected by the affinity change raised an interrupt during the transitional state (step #1 above) then the handler of the device which uses that vector on the local CPU will be invoked. expose issues in device driver interrupt handlers which are not prepared to handle a spurious interrupt correctly. This not a regression, it's just exposing something which was already broken as spurious interrupts can happen for a lot of reasons and all driver handlers need to be able to deal with them. Reported-by: Evan Green Debugged-by: Evan Green Signed-off-by: Thomas Gleixner Tested-by: Evan Green Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87imkr4s7n.fsf@nanos.tec.linutronix.de

genirq: Introduce irq_chip_get/set_parent_state calls

2019-11-16T10:20:02+00:00

On certain QTI chipsets some GPIOs are direct-connect interrupts to the GIC to be used as regular interrupt lines. When the GPIOs are not used for interrupt generation the interrupt line is disabled. But disabling the interrupt at GIC does not prevent the interrupt to be reported as pending at GIC_ISPEND. Later, when drivers call enable_irq() on the interrupt, an unwanted interrupt occurs. Introduce get and set methods for irqchip's parent to clear it's pending irq state. This then can be invoked by the GPIO interrupt controller on the parents in it hierarchy to clear the interrupt before enabling the interrupt. Signed-off-by: Maulik Shah Signed-off-by: Lina Iyer Signed-off-by: Marc Zyngier Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1573855915-9841-7-git-send-email-ilina@codeaurora.org [updated commit text and minor code fixes]

genirq: Introduce irq_chip_{request,release}_resource_parent() apis

2019-05-01T09:41:38+00:00

Introduce irq_chip_{request,release}_resource_parent() apis so that these can be used in hierarchical irqchips. Signed-off-by: Lokesh Vutla Signed-off-by: Marc Zyngier

genirq: Fix typo in comment of IRQD_MOVE_PCNTXT

2019-03-21T10:52:37+00:00

Signed-off-by: Peter Xu Signed-off-by: Thomas Gleixner Cc: Marc Zyngier Cc: Dou Liyang Cc: Julien Thierry Link: https://lkml.kernel.org/r/20190318065123.11862-1-peterx@redhat.com

Merge tag 'gpio-v5.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2019-03-08T18:09:53+00:00

Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v5.1 cycle: Core changes: - The big change this time around is the irqchip handling in the qualcomm pin controllers, closely coupled with the gpiochip. This rework, in a classic fall-between-the-chairs fashion has been sidestepped for too long. The Qualcomm IRQchips using the SPMI and SSBI transport mechanisms have been rewritten to use hierarchical irqchip. This creates the base from which I intend to gradually pull support for hierarchical irqchips into the gpiolib irqchip helpers to cut down on duplicate code. We have too many hacks in the kernel because people have been working around the missing hierarchical irqchip for years, and once it was there, noone understood it for a while. We are now slowly adapting to using it. This is why this pull requests include changes to MFD, SPMI, IRQchip core and some ARM Device Trees pertaining to the Qualcomm chip family. Since Qualcomm have so many chips and such large deployments it is paramount that this platform gets this right, and now it (hopefully) does. - Core support for pull-up and pull-down configuration, also from the device tree. When a simple GPIO chip supports an "off or on" pull-up or pull-down resistor, we provide a way to set this up using machine descriptors or device tree. If more elaborate control of pull up/down (such as resistance shunt setting) is required, drivers should be phased over to use pin control. We do not yet provide a userspace ABI for this pull up-down setting but I suspect the makers are going to ask for it soon enough. PCA953x is the first user of this new API. - The GPIO mockup driver has been revamped after some discussion improving the IRQ simulator in the process. The idea is to make it possible to use the mockup for both testing and virtual prototyping, e.g. when you do not yet have a GPIO expander to play with but really want to get something to develop code around before hardware is available. It's neat. The blackbox testing usecase is currently making its way into kernelci. - ACPI GPIO core preserves non direction flags when updating flags. - A new device core helper for devm_platform_ioremap_resource() is funneled through the GPIO tree with Greg's ACK. New drivers: - TQ-Systems QTMX86 GPIO controllers (using port-mapped I/O) - Gateworks PLD GPIO driver (vaccumed up from OpenWrt) - AMD G-Series PCH (Platform Controller Hub) GPIO driver. - Fintek F81804 & F81966 subvariants. - PCA953x now supports NXP PCAL6416. Driver improvements: - IRQ support on the Nintendo Wii (Hollywood) GPIO. - get_direction() support for the MVEBU driver. - Set the right output level on SAMA5D2. - Drop the unused irq trigger setting on the Spreadtrum driver. - Wakeup support for PCA953x. - A slew of cleanups in the various Intel drivers" * tag 'gpio-v5.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (110 commits) gpio: gpio-omap: fix level interrupt idling gpio: amd-fch: Set proper output level for direction_output x86: apuv2: remove unused variable gpio: pca953x: Use PCA_LATCH_INT platform/x86: fix PCENGINES_APU2 Kconfig warning gpio: pca953x: Fix dereference of irq data in shutdown gpio: amd-fch: Fix type error found by sparse gpio: amd-fch: Drop const from resource gpio: mxc: add check to return defer probe if clock tree NOT ready gpio: ftgpio: Register per-instance irqchip gpio: ixp4xx: Add DT bindings x86: pcengines apuv2 gpio/leds/keys platform driver gpio: AMD G-Series PCH gpio driver drivers: depend on HAS_IOMEM for devm_platform_ioremap_resource() gpio: tqmx86: Set proper output level for direction_output gpio: sprd: Change to use SoC compatible string gpio: sprd: Use SoC compatible string instead of wildcard string gpio: of: Handle both enable-gpio{,s} gpio: of: Restrict enable-gpio quirk to regulator-gpio gpio: davinci: use devm_platform_ioremap_resource() ...