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

ARM: mvebu: fix HW I/O coherency related deadlocks

2016-07-27T15:42:23+00:00

commit c5379ba8fccd99d5f99632c789f0393d84a57805 upstream.

Until now, our understanding for HW I/O coherency to work on the
Cortex-A9 based Marvell SoC was that only the PCIe regions should be
mapped strongly-ordered. However, we were still encountering some
deadlocks, especially when testing the CESA crypto engine. After
checking with the HW designers, it was concluded that all the MMIO
registers should be mapped as strongly ordered for the HW I/O coherency
mechanism to work properly.

This fixes some easy to reproduce deadlocks with the CESA crypto engine
driver (dmcrypt on a sufficiently large disk partition).

Tested-by: Terry Stockert 
Tested-by: Romain Perier 
Cc: Terry Stockert 
Cc: Romain Perier 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: armada-38x: fix MBUS_ID for crypto SRAM on Armada 385 Linksys

2016-07-27T15:42:23+00:00

commit 929e604efa3dc0522214e0dc18984be23993e9f0 upstream.

When the support for the Marvell crypto engine was added in the Device
Tree of the various Armada 385 Device Tree files in commit
d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x
boards"), a typo was made in the MBus window attributes for the Armada
385 Linksys board: 0x09/0x05 are used instead of 0x19/0x15. This commit
fixes this typo, which makes the CESA engines operational on Armada 385
Linksys boards.

Reported-by: Terry Stockert 
Cc: Terry Stockert 
Cc: Imre Kaloz 
Cc: Boris Brezillon 
Fixes: d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards")
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: sunxi/dt: make the CHIP inherit from allwinner,sun5i-a13

2016-07-27T15:42:23+00:00

commit 5fc39d347267bd029fcc9099c70e2fe2d53130e9 upstream.

The sun4i-timer driver registers its sched_clock only if the machine is
compatible with "allwinner,sun5i-a13", "allwinner,sun5i-a10s" or
"allwinner,sun4i-a10".
Add the missing "allwinner,sun5i-a13" string to the machine compatible.

Signed-off-by: Boris Brezillon 
Fixes: 465a225fb2af ("ARM: sun5i: Add C.H.I.P DTS")
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

KVM: arm/arm64: Stop leaking vcpu pid references

2016-07-27T15:42:14+00:00

commit 591d215afcc2f94e8e2c69a63c924c044677eb31 upstream.

kvm provides kvm_vcpu_uninit(), which amongst other things, releases the
last reference to the struct pid of the task that was last running the vcpu.

On arm64 built with CONFIG_DEBUG_KMEMLEAK, starting a guest with kvmtool,
then killing it with SIGKILL results (after some considerable time) in:
> cat /sys/kernel/debug/kmemleak
> unreferenced object 0xffff80007d5ea080 (size 128):
>  comm "lkvm", pid 2025, jiffies 4294942645 (age 1107.776s)
>  hex dump (first 32 bytes):
>    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>  backtrace:
>    [] create_object+0xfc/0x278
>    [] kmemleak_alloc+0x34/0x70
>    [] kmem_cache_alloc+0x16c/0x1d8
>    [] alloc_pid+0x34/0x4d0
>    [] copy_process.isra.6+0x79c/0x1338
>    [] _do_fork+0x74/0x320
>    [] SyS_clone+0x18/0x20
>    [] el0_svc_naked+0x24/0x28
>    [] 0xffffffffffffffff

On x86 kvm_vcpu_uninit() is called on the path from kvm_arch_destroy_vm(),
on arm no equivalent call is made. Add the call to kvm_arch_vcpu_free().

Signed-off-by: James Morse 
Fixes: 749cf76c5a36 ("KVM: ARM: Initial skeleton to compile KVM support")
Acked-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: sun6i: primo81: Drop constraints on dc1sw regulator

2016-07-27T15:42:13+00:00

commit cb84f6c0a25eb76b1f838eb63e212705c0c06b5f upstream.

This is the same issue fixed in commit dcf5341f0150 ("ARM: dts:
sun8i-q8-common: Do not set constraints on dc1sw regulator").
Commit message copied:

dc1sw is an on/off only regulator and as such it cannot have constraints.

This is a limitation of the kernel regulator implementation which resolves
supplies on the first regulator_get(), which is done after applying
constraints, and applying the constrains will fail because it calls
_regulator_get_voltage() and _regulator_do_set_voltage() both of which
will fail on a switch regulator when there is no supply (yet).

This causes registering of all axp22x regulators to fail with the
following errors:

[    1.395249] vcc-lcd: failed to get the current voltage(-22)
[    1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw
[    1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22

This commit removes the constrains on dc1sw / vcc-lcd fixing this problem.
Note that dcdc1 itself is contrained to the exact same values, so this
does not change anything.

Cc: Hans de Goede 
Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: sun6i: yones-toptech-bs1078-v2: Drop constraints on dc1sw regulator

2016-07-27T15:42:13+00:00

commit b223d6242c372a81cca3bb81998f53d3b3e3fb70 upstream.

This is the same issue fixed in commit dcf5341f0150 ("ARM: dts:
sun8i-q8-common: Do not set constraints on dc1sw regulator").
Commit message copied:

dc1sw is an on/off only regulator and as such it cannot have constraints.

This is a limitation of the kernel regulator implementation which resolves
supplies on the first regulator_get(), which is done after applying
constraints, and applying the constrains will fail because it calls
_regulator_get_voltage() and _regulator_do_set_voltage() both of which
will fail on a switch regulator when there is no supply (yet).

This causes registering of all axp22x regulators to fail with the
following errors:

[    1.395249] vcc-lcd: failed to get the current voltage(-22)
[    1.405131] axp20x-regulator axp20x-regulator: Failed to register dc1sw
[    1.412436] axp20x-regulator: probe of axp20x-regulator failed with error -22

This commit removes the constrains on dc1sw / vcc-lcd fixing this problem.
Note that dcdc1 itself is contrained to the exact same values, so this
does not change anything.

Cc: Hans de Goede 
Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: 8579/1: mm: Fix definition of pmd_mknotpresent

2016-07-27T15:42:12+00:00

commit 56530f5d2ddc9b9fade7ef8db9cb886e9dc689b5 upstream.

Currently pmd_mknotpresent will use a zero entry to respresent an
invalidated pmd.

Unfortunately this definition clashes with pmd_none, thus it is
possible for a race condition to occur if zap_pmd_range sees pmd_none
whilst __split_huge_pmd_locked is running too with pmdp_invalidate
just called.

This patch fixes the race condition by modifying pmd_mknotpresent to
create non-zero faulting entries (as is done in other architectures),
removing the ambiguity with pmd_none.

[catalin.marinas@arm.com: using L_PMD_SECT_VALID instead of PMD_TYPE_SECT]

Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
Reported-by: Kirill A. Shutemov 
Acked-by: Will Deacon 
Cc: Russell King 
Signed-off-by: Steve Capper 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8578/1: mm: ensure pmd_present only checks the valid bit

2016-07-27T15:42:12+00:00

commit 624531886987f0f1b5d01fb598034d039198e090 upstream.

In a subsequent patch, pmd_mknotpresent will clear the valid bit of the
pmd entry, resulting in a not-present entry from the hardware's
perspective. Unfortunately, pmd_present simply checks for a non-zero pmd
value and will therefore continue to return true even after a
pmd_mknotpresent operation. Since pmd_mknotpresent is only used for
managing huge entries, this is only an issue for the 3-level case.

This patch fixes the 3-level pmd_present implementation to take into
account the valid bit. For bisectability, the change is made before the
fix to pmd_mknotpresent.

[catalin.marinas@arm.com: comment update regarding pmd_mknotpresent patch]

Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
Cc: Russell King 
Cc: Steve Capper 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: imx6ul: Fix Micrel PHY mask

2016-07-27T15:42:12+00:00

commit 20c15226d1c73150c4d9107301cac5dda0b7f995 upstream.

The value used for Micrel PHY mask is not correct. Use the
MICREL_PHY_ID_MASK definition instead.

Thanks to Jiri Luznicky for proposing the fix at
https://community.freescale.com/thread/387739

Fixes: 709bc0657fe6f9f55 ("ARM: imx6ul: add fec MAC refrence clock and phy fixup init")
Signed-off-by: Fabio Estevam 
Reviewed-by: Andrew Lunn 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

ARM: fix PTRACE_SETVFPREGS on SMP systems

2016-06-24T17:22:02+00:00

commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf upstream.

PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
reloaded, because it undoes one of the effects of vfp_flush_hwstate().

Specifically vfp_flush_hwstate() sets thread->vfpstate.hard.cpu to
an invalid CPU number, but vfp_set() overwrites this with the original
CPU number, thereby rendering the hardware state as apparently "valid",
even though the software state is more recent.

Fix this by reverting the previous change.

Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
Acked-by: Will Deacon 
Tested-by: Simon Marchi 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman