linux-stable.git/arch/arm, branch v4.4.97

ARM: pxa: Don't rely on public mmc header to include leds.h

2017-11-08T09:06:29+00:00

[ Upstream commit 40d727a2defa176b78159d445bcf7afcc2ed9021 ]

Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi,
trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include
it instead of relying on the public mmc header host.h.

Cc: Daniel Mack 
Cc: Haojian Zhuang 
Cc: Robert Jarzmik 
Cc: 
Signed-off-by: Ulf Hansson 
Acked-by: Robert Jarzmik 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARM: 8715/1: add a private asm/unaligned.h

2017-11-08T09:06:28+00:00

commit 1cce91dfc8f7990ca3aea896bfb148f240b12860 upstream.

The asm-generic/unaligned.h header provides two different implementations
for accessing unaligned variables: the access_ok.h version used when
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers
are in fact aligned, while the le_struct.h version convinces gcc that the
alignment of a pointer is '1', to make it issue the correct load/store
instructions depending on the architecture flags.

On ARMv5 and older, we always use the second version, to let the compiler
use byte accesses. On ARMv6 and newer, we currently use the access_ok.h
version, so the compiler can use any instruction including stm/ldm and
ldrd/strd that will cause an alignment trap. This trap can significantly
impact performance when we have to do a lot of fixups and, worse, has
led to crashes in the LZ4 decompressor code that does not have a trap
handler.

This adds an ARM specific version of asm/unaligned.h that uses the
le_struct.h/be_struct.h implementation unconditionally. This should lead
to essentially the same code on ARMv6+ as before, with the exception of
using regular load/store instructions instead of the trapping instructions
multi-register variants.

The crash in the LZ4 decompressor code was probably introduced by the
patch replacing the LZ4 implementation, commit 4e1a33b105dd ("lib: update
LZ4 compressor module"), so linux-4.11 and higher would be affected most.
However, we probably want to have this backported to all older stable
kernels as well, to help with the performance issues.

There are two follow-ups that I think we should also work on, but not
backport to stable kernels, first to change the asm-generic version of
the header to remove the ARM special case, and second to review all
other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they
might be affected by the same problem on ARM.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: mvebu: pl310-cache disable double-linefill

2017-11-08T09:06:27+00:00

commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream.

Under heavy system stress mvebu SoC using Cortex A9 sporadically
encountered instability issues.

The "double linefill" feature of L2 cache was identified as causing
dependency between read and write which lead to the deadlock.

Especially, it was the cause of deadlock seen under heavy PCIe traffic,
as this dependency violates PCIE overtaking rule.

Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration")
Signed-off-by: Yan Markman 
Signed-off-by: Igal Liberman 
Signed-off-by: Nadav Haklai 
[gregory.clement@free-electrons.com: reformulate commit log, add Armada
375 and add Fixes tag]
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: remove duplicate 'const' annotations'

2017-10-08T08:14:20+00:00

commit 0527873b29b077fc8e656acd63e1866b429fef55 upstream.

gcc-7 warns about some declarations that are more 'const' than necessary:

arch/arm/mach-at91/pm.c:338:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct of_device_id const ramc_ids[] __initconst = {
arch/arm/mach-bcm/bcm_kona_smc.c:36:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct of_device_id const bcm_kona_smc_ids[] __initconst = {
arch/arm/mach-spear/time.c:207:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct of_device_id const timer_of_match[] __initconst = {
arch/arm/mach-omap2/prm_common.c:714:34: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct of_device_id const omap_prcm_dt_match_table[] __initconst = {
arch/arm/mach-omap2/vc.c:562:35: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]
 static const struct i2c_init_data const omap4_i2c_timing_data[] __initconst = {

The ones in arch/arm were apparently all introduced accidentally by one
commit that correctly marked a lot of variables as __initconst.

Fixes: 19c233b79d1a ("ARM: appropriate __init annotation for const data")
Acked-by: Alexandre Belloni 
Acked-by: Tony Lindgren 
Acked-by: Nicolas Pitre 
Acked-by: Florian Fainelli 
Acked-by: Viresh Kumar 
Acked-by: Krzysztof Hałasa 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM

2017-10-08T08:14:17+00:00

[ Upstream commit 8a792e9afbce84a0fdaf213fe42bb97382487094 ]

REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a
hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on
DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself
available to Kconfig, DRAM_BASE also is available as the Kconfig
gets sourced on !MMU.

Signed-off-by: Afzal Mohammed 
Reviewed-by: Vladimir Murzin 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes

2017-10-08T08:14:16+00:00

[ Upstream commit 654450baf2afba86cf328e1849ccac61ec4630af ]

Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7790 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

swiotlb-xen: implement xen_swiotlb_dma_mmap callback

2017-10-05T07:41:48+00:00

commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 upstream.

This function creates userspace mapping for the DMA-coherent memory.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Andrii Anisov 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

ARM: pxa: fix the number of DMA requestor lines

2017-10-05T07:41:48+00:00

commit 4c35430ad18f5a034302cb90e559ede5a27f93b9 upstream.

The number of requestor lines was clamped to 0 for all pxa architectures
in the requestor declaration. Fix this by using the value.

Fixes: 72b195cb7162 ("ARM: pxa: add the number of DMA requestor lines")
Signed-off-by: Robert Jarzmik 
Signed-off-by: Greg Kroah-Hartman

ARM: pxa: add the number of DMA requestor lines

2017-10-05T07:41:48+00:00

commit 72b195cb716284217e8b270af420bc7e5cf04b3c upstream.

Declare the number of DMA requestor lines per platform :
 - for pxa25x: 40 requestor lines
 - for pxa27x: 75 requestor lines
 - for pxa3xx: 100 requestor lines

This information will be used to activate the DMA flow control or not.

Signed-off-by: Robert Jarzmik 
Signed-off-by: Greg Kroah-Hartman

ARM: 8692/1: mm: abort uaccess retries upon fatal signal

2017-09-13T21:09:46+00:00

commit 746a272e44141af24a02f6c9b0f65f4c4598ed42 upstream.

When there's a fatal signal pending, arm's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.

However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.

To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.

Signed-off-by: Mark Rutland 
Reviewed-by: Steve Capper 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman