linux-stable.git/drivers/irqchip, branch linux-4.5.y

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

2016-06-01T19:16:58+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:16:58+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:49:10+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:49:10+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/gicv3-its: Avoid cache flush beyond ITS_BASERn memory size

2016-02-17T17:39:05+00:00

Function its_alloc_tables() maintains two local variables, "order" and
and "alloc_size", to hold memory size that has been allocated to
ITS_BASEn. We don't always refresh the variable alloc_size whenever
value of the variable order changes, causing the following two
problems.

  - Cache flush operation with size more than required.
  - Information reported by pr_info is not correct.

Use a helper macro that converts page order to size in bytes instead of
variable "alloc_size" to fix both the problems.

Signed-off-by: Shanker Donthineni 
Signed-off-by: Marc Zyngier

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

2016-02-11T16:01:28+00:00

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")
Cc: stable@vger.kernel.org
Acked-by: Marc Zyngier 
Signed-off-by: Ashok Kumar 
Signed-off-by: Marc Zyngier

irqchip/gic: Only set the EOImodeNS bit for the root controller

2016-02-11T10:20:02+00:00

EOImode1 is only used for the root controller and hence only the root
controller uses the eoimode1 functions for handling interrupts. However,
if the root controller supports EOImode1, then the EOImodeNS bit will be
set for all GICs, enabling EOImode1. This is not what we want and this
causes interrupts on non-root GICs to only be dropped in priority but
never deactivated. Therefore, only set the EOImodeNS bit for the root
controller.

Acked-by: Marc Zyngier 
Signed-off-by: Jon Hunter 
Signed-off-by: Marc Zyngier

irqchip/gic: Only populate set_affinity for the root controller

2016-02-11T10:20:02+00:00

Setting the affinity of an IRQ, it only applicable for the root
interrupt controller and so only populate this operator for the root
controller.

Acked-by: Marc Zyngier 
Signed-off-by: Jon Hunter 
Signed-off-by: Marc Zyngier

irqchip/gicv3-its: Fix memory leak in its_free_tables()

2016-02-04T14:14:50+00:00

The current ITS driver has a memory leak in its_free_tables(). It
happens on tear down path of the driver when its_probe() call fails.
its_free_tables() should free the exact number of pages that have
been allocated, not just a single page as current code does.

This patch records the memory size for each ITS_BASERn at the time of
page allocation and uses the same size information when freeing pages
to fix the issue.

Signed-off-by: Shanker Donthineni 
Acked-by: Marc Zyngier 
Cc: Jason Cooper 
Cc: Vikram Sethi 
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1454379584-21772-1-git-send-email-shankerd@codeaurora.org
Signed-off-by: Thomas Gleixner

irqchip/sun4i: Fix compilation outside of arch/arm

2016-02-02T14:46:40+00:00

The Allwinner sunxi specific interrupt controller cannot be compiled
for any architecture except arm:

drivers/irqchip/irq-sun4i.c:25:26: fatal error: asm/mach/irq.h: No such file or directory
compilation terminated.

It turns out that this header is actually not needed for the driver, so remove
it and allow compilation for other architectures like arm64.

Signed-off-by: Andre Przywara 
Acked-by: Arnd Bergmann 
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: linux-sunxi@googlegroups.com
Link: http://lkml.kernel.org/r/1454348370-3816-2-git-send-email-andre.przywara@arm.com
Signed-off-by: Thomas Gleixner