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

irqchip/crossbar: Fix incorrect type of local variables

2017-10-21T15:07:25+00:00

[ Upstream commit b28ace12661fbcfd90959c1e84ff5a85113a82a1 ]

The max and entry variables are unsigned according to the dt-bindings.
Fix following 3 sparse issues (-Wtypesign):

  drivers/irqchip/irq-crossbar.c:222:52: warning: incorrect type in argument 3 (different signedness)
  drivers/irqchip/irq-crossbar.c:222:52:    expected unsigned int [usertype] *out_value
  drivers/irqchip/irq-crossbar.c:222:52:    got int *

  drivers/irqchip/irq-crossbar.c:245:56: warning: incorrect type in argument 4 (different signedness)
  drivers/irqchip/irq-crossbar.c:245:56:    expected unsigned int [usertype] *out_value
  drivers/irqchip/irq-crossbar.c:245:56:    got int *

  drivers/irqchip/irq-crossbar.c:263:56: warning: incorrect type in argument 4 (different signedness)
  drivers/irqchip/irq-crossbar.c:263:56:    expected unsigned int [usertype] *out_value
  drivers/irqchip/irq-crossbar.c:263:56:    got int *

Signed-off-by: Franck Demathieu 
Cc: marc.zyngier@arm.com
Cc: jason@lakedaemon.net
Link: http://lkml.kernel.org/r/20170223094855.6546-1-fdemathieu@gmail.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()

2017-08-25T00:00:10+00:00

commit 277867ade8262583f4280cadbe90e0031a3706a7 upstream.

of_find_compatible_node() is calling of_node_put() on its first argument
thus leading to an unbalanced of_node_get/put() issue if the node has not
been retained before that.

Instead of passing the root node, pass NULL, which does exactly the same:
iterate over all DT nodes, starting from the root node.

Signed-off-by: Boris Brezillon 
Reported-by: Alexandre Belloni 
Fixes: 3d61467f9bab ("irqchip: atmel-aic: Implement RTC irq fixup")
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()

2017-08-25T00:00:10+00:00

commit 469bcef53c546bb792aa66303933272991b7831d upstream.

aic_common_irq_fixup() is calling twice of_node_put() on the same node
thus leading to an unbalanced refcount on the root node.

Signed-off-by: Boris Brezillon 
Reported-by: Alexandre Belloni 
Fixes: b2f579b58e93 ("irqchip: atmel-aic: Add irq fixup infrastructure")
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity

2017-07-21T06:12:22+00:00

commit 866d7c1b0a3c70387646c4e455e727a58c5d465a upstream.

The GICv3 driver doesn't check if the target CPU for gic_set_affinity
is valid before going ahead and making the changes. This triggers the
following splat with KASAN:

[  141.189434] BUG: KASAN: global-out-of-bounds in gic_set_affinity+0x8c/0x140
[  141.189704] Read of size 8 at addr ffff200009741d20 by task swapper/1/0
[  141.189958]
[  141.190158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.12.0-rc7
[  141.190458] Hardware name: Foundation-v8A (DT)
[  141.190658] Call trace:
[  141.190908] [] dump_backtrace+0x0/0x328
[  141.191224] [] show_stack+0x14/0x20
[  141.191507] [] dump_stack+0xa4/0xc8
[  141.191858] [] print_address_description+0x13c/0x250
[  141.192219] [] kasan_report+0x210/0x300
[  141.192547] [] __asan_load8+0x84/0x98
[  141.192874] [] gic_set_affinity+0x8c/0x140
[  141.193158] [] irq_do_set_affinity+0x54/0xb8
[  141.193473] [] irq_set_affinity_locked+0x64/0xf0
[  141.193828] [] __irq_set_affinity+0x48/0x78
[  141.194158] [] arm_perf_starting_cpu+0x104/0x150
[  141.194513] [] cpuhp_invoke_callback+0x17c/0x1f8
[  141.194783] [] notify_cpu_starting+0x8c/0xb8
[  141.195130] [] secondary_start_kernel+0x15c/0x200
[  141.195390] [<0000000080db81b4>] 0x80db81b4
[  141.195603]
[  141.195685] The buggy address belongs to the variable:
[  141.196012]  __cpu_logical_map+0x200/0x220
[  141.196176]
[  141.196315] Memory state around the buggy address:
[  141.196586]  ffff200009741c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  141.196913]  ffff200009741c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  141.197158] >ffff200009741d00: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
[  141.197487]                                ^
[  141.197758]  ffff200009741d80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
[  141.198060]  ffff200009741e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  141.198358] ==================================================================
[  141.198609] Disabling lock debugging due to kernel taint
[  141.198961] CPU1: Booted secondary processor [410fd051]

This patch adds the check to make sure the cpu is valid.

Fixes: commit 021f653791ad17e03f98 ("irqchip: gic-v3: Initial support for GICv3")
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

irqchip/gicv3: Handle loop timeout proper

2016-11-24T02:28:50+00:00

[ Upstream commit d102eb5c1ac5e6743b1c6d145c06a25d98ad1375 ]

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 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

genirq: Generic chip: Change irq_reg_{readl,writel} arguments

2016-10-06T02:40:20+00:00

[ Upstream commit 332fd7c4fef5f3b166e93decb07fd69eb24f7998 ]

Pass in the irq_chip_generic struct so we can use different readl/writel
settings for each irqchip driver, when appropriate.  Compute
(gc->reg_base + reg_offset) in the helper function because this is pretty
much what all callers want to do anyway.

Compile-tested using the following configurations:

    at91_dt_defconfig (CONFIG_ATMEL_AIC_IRQ=y)
    sama5_defconfig (CONFIG_ATMEL_AIC5_IRQ=y)
    sunxi_defconfig (CONFIG_ARCH_SUNXI=y)

tb10x (ARC) is untested.

Signed-off-by: Kevin Cernekee 
Acked-by: Thomas Gleixner 
Acked-by: Acked-by: Arnd Bergmann 
Link: https://lkml.kernel.org/r/1415342669-30640-3-git-send-email-cernekee@gmail.com
Signed-off-by: Jason Cooper 
Signed-off-by: Sasha Levin

arm64: GICv3: introduce symbolic names for GICv3 ICC_SGI1R_EL1 fields

2016-06-20T03:47:43+00:00

[ Upstream commit 7e5802781c3e109558ddfd8b02155ad24d872ee7 ]

The gic_send_sgi() function used hardcoded bit shift values to
generate the ICC_SGI1R_EL1 register value.
Replace this with symbolic names to allow reusing them later.

Signed-off-by: Andre Przywara 
Reviewed-by: Christoffer Dall 
Signed-off-by: Christoffer Dall 
Signed-off-by: Sasha Levin

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

2016-06-06T23:11:02+00:00

[ Upstream commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 ]

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().

Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin

irqchip/omap-intc: Add support for spurious irq handling

2016-04-12T13:07:31+00:00

[ Upstream commit d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d ]

Under some conditions, irq sorting procedure used by INTC can go wrong
resulting in a spurious irq getting reported.

If this condition is not handled, it results in endless stream of:

    unexpected IRQ trap at vector 00

messages from ack_bad_irq()

Handle the spurious interrupt condition in omap-intc driver to prevent this.

Measurements using kernel function profiler on AM335x EVM running at 720MHz
show that after this patch omap_intc_handle_irq() takes about 37.4us against
34us before this patch.

Signed-off-by: Sekhar Nori 
Acked-by: Tony Lindgren 
Cc: John Ogness 
Cc: Felipe Balbi 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Link: http://lkml.kernel.org/r/9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

irqchip: omap-intc: Improve IRQ handler

2016-04-12T13:07:22+00:00

[ Upstream commit 6ed3464897cc825a75218653c710d673282dfcf8 ]

As it turns out the current IRQ number will *always* be available from
SIR register which renders the reads of PENDING registers as plain
unnecessary overhead.

In order to catch any situation where SIR reads as zero, we're adding
a WARN() to turn it into a very verbose error and users actually
report it.

With this patch average running time of omap_intc_handle_irq() reduced
from about 28.5us to 19.8us as measured by the kernel function
profiler.

Tested with BeagleBoneBlack Rev A5C.

Tested-by: Tony Lindgren 
Signed-off-by: Felipe Balbi 
Cc: Linux ARM Kernel Mailing List 
Link: http://lkml.kernel.org/r/20150720204910.GH5394@saruman.tx.rr.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin