linux-stable.git/drivers/irqchip, branch v3.16.78

irqchip/brcmstb-l2: Use _irqsave locking variants in non-interrupt code

2019-07-09T21:04:05+00:00

commit 33517881ede742107f416533b8c3e4abc56763da upstream.

Using the irq_gc_lock/irq_gc_unlock functions in the suspend and
resume functions creates the opportunity for a deadlock during
suspend, resume, and shutdown. Using the irq_gc_lock_irqsave/
irq_gc_unlock_irqrestore variants prevents this possible deadlock.

Fixes: 7f646e92766e2 ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 interrupt controller")
Signed-off-by: Doug Berger 
Signed-off-by: Florian Fainelli 
[maz: tidied up $SUBJECT]
Signed-off-by: Marc Zyngier 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

irqchip: brcmstb-l2: Define an irq_pm_shutdown function

2017-11-11T13:33:16+00:00

commit c017d21147848fe017772764a77a7f32c5b017f9 upstream.

The Broadcom STB platforms support S5 and we allow specific hardware
wake-up events to take us out of this state. Because we were not
defining an irq_pm_shutdown() function pointer, we would not be
correctly masking non-wakeup events, which would result in spurious
wake-ups from sources that were not explicitly configured for wake-up.

Fixes: 7f646e92766e ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 interrupt controller")
Acked-by: Gregory Fong 
Signed-off-by: Florian Fainelli 
Signed-off-by: Marc Zyngier 
Signed-off-by: Ben Hutchings

irqchip/gic: Ensure ordering between read of INTACK and shared data

2016-08-22T21:37:57+00:00

commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 upstream.

When an IPI is generated by a CPU, the pattern looks roughly like:

  
  smp_wmb();
  

On the receiving CPU we rely on the fact that, once we've taken the
interrupt, then the freshly written shared data must be visible to us.
Put another way, the CPU isn't going to speculate taking an interrupt.

Unfortunately, this assumption turns out to be broken.

Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
to read some shared_data. Before CPUx has done anything, a random
peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
CPUy then takes the IRQ and starts executing the entry code, heading
towards gic_handle_irq. Furthermore, let's assume that a bunch of the
previous interrupts handled by CPUy were SGIs, so the branch predictor
kicks in and speculates that irqnr will be <16 and we're likely to
head into handle_IPI. The prefetcher then grabs a speculative copy of
shared_data which contains a stale value.

Meanwhile, CPUx gets round to updating shared_data and asking the GIC
to send an SGI to CPUy. Internally, the GIC decides that the SGI is
more important than the peripheral interrupt (which hasn't yet been
ACKed) but doesn't need to do anything to CPUy, because the IRQ line
is already raised.

CPUy then reads the ACK register on the GIC, sees the SGI value which
confirms the branch prediction and we end up with a stale shared_data
value.

This patch fixes the problem by adding an smp_rmb() to the IPI entry
code in gic_handle_irq. As it turns out, the combination of a control
dependency and an ISB instruction from the EOI in the GICv3 driver is
enough to provide the ordering we need, so we add a comment there
justifying the absence of an explicit smp_rmb().

Signed-off-by: Will Deacon 
Signed-off-by: Marc Zyngier 
[bwh: Backported to 3.16: drop changes to irq-gic-v3]
Signed-off-by: Ben Hutchings

irqchip/versatile-fpga: Fix PCI IRQ mapping on Versatile PB

2016-01-11T10:50:17+00:00

commit d5d4fdd86f5759924fe54efa793e22eccf508db6 upstream.

This patch is specifically for PCI support on the Versatile PB board using
a DT. Currently, the dynamic IRQ mapping is broken when using DTs. For
example, on QEMU, the SCSI driver is unable to request the IRQ. To fix
this issue, this patch replaces the current dynamic mechanism with a
static value as is done in the non-DT case.

Signed-off-by: Guillaume Delbergue 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Luis Henriques

irqchip: sunxi-nmi: Fix off-by-one error in irq iterator

2015-06-30T16:15:21+00:00

commit febe06962ab191db50e633a0f79d9fb89a2d1078 upstream.

Fixes: 6058bb362818 'ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller'
Signed-off-by: Axel Lin 
Cc: Maxime Ripard 
Cc: Carlo Caione 
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/1433684009.9134.1.camel@ingics.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Luis Henriques

irqchip: armada-370-xp: Fix chained per-cpu interrupts

2015-03-23T15:16:41+00:00

commit 5724be8464dceac047c1eaddaa3651cea0ec16ca upstream.

On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt
controller. Yet, it still has to handle some per-cpu interrupt.

To do so, it is chained with the GIC using a per-cpu interrupt. However, the
current code only call irq_set_chained_handler, which is called and enable that
interrupt only on the boot CPU, which means that the parent per-CPU interrupt
is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to
actually work as expected.

This was not seen until now since the only MPIC PPI users were the Marvell
timers that were not working, but not used either since the system use the ARM
TWD by default, and the ethernet controllers, that are faking there interrupts
as SPI, and don't really expect to have interrupts on the secondary cores
anyway.

Add a CPU notifier that will enable the PPI on the secondary cores when they
are brought up.

Signed-off-by: Maxime Ripard 
Acked-by: Gregory CLEMENT 
Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.com
Signed-off-by: Jason Cooper 
Signed-off-by: Luis Henriques

irqchip: armada-370-xp: Fix MPIC interrupt handling

2014-11-14T15:19:55+00:00

commit 758e8366754d3fa57da978fef9d2c652f7b55c02 upstream.

In both Armada-375 and Armada-38x MPIC interrupts should be identified by
reading cause register multiplied by the interrupt mask.

A lack of above mentioned multiplication resulted in a bug, caused by the
fact that in Armada-375 and Armada-38x some of the interrupts
(e.g. network interrupts) can be handled either as a GIC or MPIC interrupts.
Therefore during MPIC interrupts handling, cause register shows hits from
interrupts even if they are masked for MPIC but unmasked for a GIC.

This resulted in 'bad IRQ' error, because masked MPIC interrupt without
registered interrupt handler, was trying to be handled during interrupt
handling procedure of some other unmasked MPIC interrupt (e.g. local timer
irq).

This commit fixes that by ensuring that during MPIC interrupt handling only
interrupts that are unmasked for MPIC are processed.

Signed-off-by: Grzegorz Jaszczyk 
Reviewed-by: Gregory CLEMENT 
Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC")
Acked-by: Ezequiel Garcia 
Link: https://lkml.kernel.org/r/1411643839-64925-3-git-send-email-jaz@semihalf.com
Signed-off-by: Jason Cooper 
Signed-off-by: Luis Henriques

irqchip: armada-370-xp: Fix MSI interrupt handling

2014-11-14T15:19:55+00:00

commit 298dcb2dd0267d51e4f7c94a628cd0765a50ad75 upstream.

The MSI interrupts use the 16 high doorbells, which are notified by using IRQ1
of the main interrupt controller.

The MSI interrupts were handled correctly for Armada-XP and Armada-370 but not
for Armada-375 and Armada-38x, which use chained handler for the MPIC.

This commit fixes that by checking proper interrupt number in chained handler
for the MPIC.

Signed-off-by: Grzegorz Jaszczyk 
Reviewed-by: Gregory CLEMENT 
Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC")
Acked-by: Ezequiel Garcia 
Link: https://lkml.kernel.org/r/1411643839-64925-2-git-send-email-jaz@semihalf.com
Signed-off-by: Jason Cooper 
Signed-off-by: Luis Henriques

irqchip: gic: Fix core ID calculation when topology is read from DT

2014-07-18T13:13:41+00:00

Certain GIC implementation, namely those found on earlier, single
cluster, Exynos SoCs, have registers mapped without per-CPU banking,
which means that the driver needs to use different offset for each CPU.

Currently the driver calculates the offset by multiplying value returned
by cpu_logical_map() by CPU offset parsed from DT. This is correct when
CPU topology is not specified in DT and aforementioned function returns
core ID alone. However when DT contains CPU topology, the function
changes to return cluster ID as well, which is non-zero on mentioned
SoCs and so breaks the calculation in GIC driver.

This patch fixes this by masking out cluster ID in CPU offset
calculation so that only core ID is considered. Multi-cluster Exynos
SoCs already have banked GIC implementations, so this simple fix should
be enough.

Reported-by: Lorenzo Pieralisi 
Reported-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Tomasz Figa 
Fixes: db0d4db22a78d ("ARM: gic: allow GIC to support non-banked setups")
Cc:  # v3.3+
Link: https://lkml.kernel.org/r/1405610624-18722-1-git-send-email-t.figa@samsung.com
Signed-off-by: Jason Cooper

irqchip: gic: Add binding probe for ARM GIC400

2014-07-17T12:46:07+00:00

Commit 3ab72f9156bb "dt-bindings: add GIC-400 binding" added the
"arm,gic-400" compatible string, but the corresponding IRQCHIP_DECLARE
was never added to the gic driver.

Therefore add the missing irqchip declaration for it.

Signed-off-by: Suravee Suthikulpanit 

Removed additional empty line and adapted commit message to mark it
as fixing an issue.
Signed-off-by: Heiko Stuebner 
Acked-by: Will Deacon 
Fixes: 3ab72f9156bb ("dt-bindings: add GIC-400 binding")
Cc:  # v3.14+
Link: https://lkml.kernel.org/r/2621565.f5eISveXXJ@diego
Signed-off-by: Jason Cooper