linux-toradex.git/drivers/irqchip, branch v4.4.48

irqchip/bcm7038-l1: Implement irq_cpu_offline() callback

2017-01-12T10:22:49+00:00

commit 34c535793bcbf9263cf22f8a52101f796cdfab8e upstream.

We did not implement an irq_cpu_offline callback for our irqchip, yet we
support setting a given IRQ's affinity. This resulted in interrupts
whose affinity mask included CPUs being taken offline not to work
correctly once the CPU had been put offline.

Fixes: 5f7f0317ed28 ("IRQCHIP: Add new driver for BCM7038-style level 1 interrupt controllers")
Signed-off-by: Florian Fainelli 
Cc: linux-mips@linux-mips.org
Cc: jason@lakedaemon.net
Cc: marc.zyngier@arm.com
Cc: cernekee@gmail.com
Cc: jaedon.shin@gmail.com
Cc: ralf@linux-mips.org
Cc: justinpopo6@gmail.com
Link: http://lkml.kernel.org/r/1477948656-12966-2-git-send-email-f.fainelli@gmail.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

irqchip/gicv3: Handle loop timeout proper

2016-10-28T07:01:33+00:00

commit d102eb5c1ac5e6743b1c6d145c06a25d98ad1375 upstream.

The timeout loop terminates when the loop count is zero, but the decrement
of the count variable is post check. So count is -1 when we check for the
timeout and therefor the error message is supressed.

Change it to predecrement, so the error message is emitted.

[ tglx: Massaged changelog ]

Fixes: a2c225101234 ("irqchip: gic-v3: Refactor gic_enable_redist to support both enabling and disabling")
Signed-off-by: Dan Carpenter 
Acked-by: Sudeep Holla 
Cc: Marc Zyngier 
Cc: kernel-janitors@vger.kernel.org
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

irqchip/gicv3: Silence noisy DEBUG_PER_CPU_MAPS warning

2016-10-07T13:23:42+00:00

commit 727653d6ce7103b245eb8041f55dd5885f4c3289 upstream.

gic_raise_softirq() walks the list of cpus using for_each_cpu(), it calls
gic_compute_target_list() which advances the iterator by the number of
CPUs in the cluster.

If gic_compute_target_list() reaches the last CPU it leaves the iterator
pointing at the last CPU. This means the next time round the for_each_cpu()
loop cpumask_next() will be called with an invalid CPU.

This triggers a warning when built with CONFIG_DEBUG_PER_CPU_MAPS:
[    3.077738] GICv3: CPU1: found redistributor 1 region 0:0x000000002f120000
[    3.077943] CPU1: Booted secondary processor [410fd0f0]
[    3.078542] ------------[ cut here ]------------
[    3.078746] WARNING: CPU: 1 PID: 0 at ../include/linux/cpumask.h:121 gic_raise_softirq+0x12c/0x170
[    3.078812] Modules linked in:
[    3.078869]
[    3.078930] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-rc5+ #5188
[    3.078994] Hardware name: Foundation-v8A (DT)
[    3.079059] task: ffff80087a1a0080 task.stack: ffff80087a19c000
[    3.079145] PC is at gic_raise_softirq+0x12c/0x170
[    3.079226] LR is at gic_raise_softirq+0xa4/0x170
[    3.079296] pc : [] lr : [] pstate: 200001c9
[    3.081139] Call trace:
[    3.081202] Exception stack(0xffff80087a19fbe0 to 0xffff80087a19fd10)

[    3.082269] [] gic_raise_softirq+0x12c/0x170
[    3.082354] [] smp_send_reschedule+0x34/0x40
[    3.082433] [] resched_curr+0x50/0x88
[    3.082512] [] check_preempt_curr+0x60/0xd0
[    3.082593] [] ttwu_do_wakeup+0x20/0xe8
[    3.082672] [] ttwu_do_activate+0x90/0xc0
[    3.082753] [] try_to_wake_up+0x224/0x370
[    3.082836] [] default_wake_function+0x10/0x18
[    3.082920] [] __wake_up_common+0x5c/0xa0
[    3.083003] [] __wake_up_locked+0x14/0x20
[    3.083086] [] complete+0x40/0x60
[    3.083168] [] secondary_start_kernel+0x15c/0x1d0
[    3.083240] [<00000000808911a4>] 0x808911a4
[    3.113401] Detected PIPT I-cache on CPU2

Avoid updating the iterator if the next call to cpumask_next() would
cause the for_each_cpu() loop to exit.

There is no change to gic_raise_softirq()'s behaviour, (cpumask_next()s
eventual call to _find_next_bit() will return early as start >= nbits),
this patch just silences the warning.

Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3")
Signed-off-by: James Morse 
Acked-by: Marc Zyngier 
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jason Cooper 
Link: http://lkml.kernel.org/r/1474306155-3303-1-git-send-email-james.morse@arm.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

irqchip/atmel-aic: Fix potential deadlock in ->xlate()

2016-09-24T08:07:43+00:00

commit 5eb0d6eb3fac3daa60d9190eed9fa41cf809c756 upstream.

aic5_irq_domain_xlate() and aic_irq_domain_xlate() take the generic chip
lock without disabling interrupts, which can lead to a deadlock if an
interrupt occurs while the lock is held in one of these functions.

Replace irq_gc_{lock,unlock}() calls by
irq_gc_{lock_irqsave,unlock_irqrestore}() ones to prevent this bug from
happening.

Fixes: b1479ebb7720 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers")
Signed-off-by: Boris Brezillon 
Acked-by: Marc Zyngier 
Cc: Jason Cooper 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Link: http://lkml.kernel.org/r/1473775109-4192-2-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144

2016-09-15T06:27:47+00:00

[ Upstream commit fbf8f40e1658cb2f17452dbd3c708e329c5d27e0 ]

The erratum fixes the hang of ITS SYNC command by avoiding inter node
io and collections/cpu mapping on thunderx dual-socket platform.

This fix is only applicable for Cavium's ThunderX dual-socket platform.

Reviewed-by: Robert Richter 
Signed-off-by: Ganapatrao Kulkarni 
Signed-off-by: Robert Richter 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v3: Configure all interrupts as non-secure Group-1

2016-06-01T19:15:49+00:00

commit 7c9b973061b03af62734f613f6abec46c0dd4a88 upstream.

The GICv3 driver wrongly assumes that it runs on the non-secure
side of a secure-enabled system, while it could be on a system
with a single security state, or a GICv3 with GICD_CTLR.DS set.

Either way, it is important to configure this properly, or
interrupts will simply not be delivered on this HW.

Reported-by: Peter Maydell 
Tested-by: Peter Maydell 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

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

2016-06-01T19:15:49+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 
Signed-off-by: Greg Kroah-Hartman

irqchip/mxs: Fix error check of of_io_request_and_map()

2016-05-04T21:48:50+00:00

commit edf8fcdc6b254236be005851af35ea5e826e7e09 upstream.

The of_io_request_and_map() returns a valid pointer in iomem region or
ERR_PTR(), check for NULL always fails and may cause a NULL pointer
dereference on error path.

Fixes: 25e34b44313b ("irqchip/mxs: Prepare driver for hardware with different offsets")
Signed-off-by: Vladimir Zapolskiy 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Oleksij Rempel 
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1457486500-10237-1-git-send-email-vz@mleia.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

irqchip/sunxi-nmi: Fix error check of of_io_request_and_map()

2016-05-04T21:48:50+00:00

commit cfe199afefe6201e998ddc07102fc1fdb55f196c upstream.

The of_io_request_and_map() returns a valid pointer in iomem region or
ERR_PTR(), check for NULL always fails and may cause a NULL pointer
dereference on error path.

Fixes: 0e841b04c829 ("irqchip/sunxi-nmi: Switch to of_io_request_and_map() from of_iomap()")
Signed-off-by: Vladimir Zapolskiy 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Chen-Yu Tsai 
Cc: Maxime Ripard 
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1457486489-10189-1-git-send-email-vz@mleia.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v3-its: Fix double ICC_EOIR write for LPI in EOImode==1

2016-03-03T23:07:14+00:00

commit 004fa08d7aba2a13974446bf212a48c0b3b0d9fd upstream.

When the GIC is using EOImode==1, the EOI is done immediately,
leaving the deactivation to be performed when the EOI was
previously done.

Unfortunately, the ITS is not aware of the EOImode at all, and
blindly EOIs the interrupt again. On most systems, this is ignored
(despite being a programming error), but some others do raise a
SError exception as there is no priority drop to perform for this
interrupt.

The fix is to stop trying to be clever, and always call into the
underlying GIC to perform the right access, irrespective of the
more we're in.

[Marc: Reworked commit message]

Fixes: 0b996fd35957a ("irqchip/GICv3: Convert to EOImode == 1")
Acked-by: Marc Zyngier 
Signed-off-by: Ashok Kumar 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman