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

ARM: mvebu: fix suspend to RAM on big-endian configurations

2015-07-10T16:45:41+00:00

commit 2f5bc307be2480ba89e4c5d118f406f04a4a7299 upstream.

The current Armada XP suspend to RAM implementation, as added in
commit 27432825ae19f ("ARM: mvebu: Armada XP GP specific
suspend/resume code") does not handle big-endian configurations
properly: the small bit of assembly code putting the DRAM in
self-refresh and toggling the GPIOs to turn off power forgets to
convert the values to little-endian.

This commit fixes that by making sure the two values we will write to
the DRAM controller register and GPIO register are already in
little-endian before entering the critical assembly code.

Signed-off-by: Thomas Petazzoni 
Fixes: 27432825ae19f ("ARM: mvebu: Armada XP GP specific suspend/resume code")
Signed-off-by: Greg Kroah-Hartman

ARM: tegra20: Store CPU "resettable" status in IRAM

2015-07-10T16:45:40+00:00

commit 4d48edb3c3e1234d6b3fcdfb9ac24d7c6de449cb upstream.

Commit 7232398abc6a ("ARM: tegra: Convert PMC to a driver") changed tegra_resume()
location storing from late to early and, as a result, broke suspend on Tegra20.
PMC scratch register 41 is used by tegra LP1 resume code for retrieving stored
physical memory address of common resume function and in the same time used by
tegra20_cpu_shutdown() (shared by Tegra20 cpuidle driver and platform SMP code),
which is storing CPU1 "resettable" status. It implies strict order of scratch
register usage, otherwise resume function address is lost on Tegra20 after
disabling non-boot CPU's on suspend. Fix it by storing "resettable" status in
IRAM instead of PMC scratch register.

Signed-off-by: Dmitry Osipenko 
Fixes: 7232398abc6a (ARM: tegra: Convert PMC to a driver)
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman

ARM: kvm: psci: fix handling of unimplemented functions

2015-07-10T16:45:40+00:00

commit e2d997366dc5b6c9d14035867f73957f93e7578c upstream.

According to the PSCI specification and the SMC/HVC calling
convention, PSCI function_ids that are not implemented must
return NOT_SUPPORTED as return value.

Current KVM implementation takes an unhandled PSCI function_id
as an error and injects an undefined instruction into the guest
if PSCI implementation is called with a function_id that is not
handled by the resident PSCI version (ie it is not implemented),
which is not the behaviour expected by a guest when calling a
PSCI function_id that is not implemented.

This patch fixes this issue by returning NOT_SUPPORTED whenever
the kvm PSCI call is executed for a function_id that is not
implemented by the PSCI kvm layer.

Cc: Christoffer Dall 
Acked-by: Sudeep Holla 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

arm: KVM: force execution of HCPTR access on VM exit

2015-07-10T16:45:40+00:00

commit 85e84ba31039595995dae80b277378213602891b upstream.

On VM entry, we disable access to the VFP registers in order to
perform a lazy save/restore of these registers.

On VM exit, we restore access, test if we did enable them before,
and save/restore the guest/host registers if necessary. In this
sequence, the FPEXC register is always accessed, irrespective
of the trapping configuration.

If the guest didn't touch the VFP registers, then the HCPTR access
has now enabled such access, but we're missing a barrier to ensure
architectural execution of the new HCPTR configuration. If the HCPTR
access has been delayed/reordered, the subsequent access to FPEXC
will cause a trap, which we aren't prepared to handle at all.

The same condition exists when trapping to enable VFP for the guest.

The fix is to introduce a barrier after enabling VFP access. In the
vmexit case, it can be relaxed to only takes place if the guest hasn't
accessed its view of the VFP registers, making the access to FPEXC safe.

The set_hcptr macro is modified to deal with both vmenter/vmexit and
vmtrap operations, and now takes an optional label that is branched to
when the guest hasn't touched the VFP registers.

Reported-by: Vikram Sethi 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: update Ethernet compatible string for Armada XP

2015-07-10T16:45:38+00:00

[ Upstream commit ea3b55fe83b5fcede82d183164b9d6831b26e33b ]

This patch updates the Ethernet DT nodes for Armada XP SoCs with the
compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot 
Fixes: 77916519cba3 ("arm: mvebu: Armada XP MV78230 has only three Ethernet interfaces")
Cc:  # v3.8+
Acked-by: Gregory CLEMENT 
Reviewed-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ARM: clk-imx6q: refine sata's parent

2015-07-10T16:45:32+00:00

commit da946aeaeadcd24ff0cda9984c6fb8ed2bfd462a upstream.

According to IMX6D/Q RM, table 18-3, sata clock's parent is ahb, not ipg.

Signed-off-by: Sebastien Szymanski 
Reviewed-by: Fabio Estevam 
Signed-off-by: Shawn Guo 
[dirk.behme: Adjust moved file]
Signed-off-by: Dirk Behme 
Signed-off-by: Greg Kroah-Hartman

ARM: EXYNOS: Fix failed second suspend on Exynos4

2015-06-29T19:29:08+00:00

commit 6f024978e74bda616b27183adee029b65eb27032 upstream.

On Exynos4412 boards (Trats2, Odroid U3) after enabling L2 cache in
56b60b8bce4a ("ARM: 8265/1: dts: exynos4: Add nodes for L2 cache
controller") the second suspend to RAM failed. First suspend worked fine
but the next one hang just after powering down of secondary CPUs (system
consumed energy as it would be running but was not responsive).

The issue was caused by enabling delayed reset assertion for CPU0 just
after issuing power down of cores. This was introduced for Exynos4 in
13cfa6c4f7fa ("ARM: EXYNOS: Fix CPU idle clock down after CPU off").

The whole behavior is not well documented but after checking with vendor
code this should be done like this (on Exynos4):
1. Enable delayed reset assertion when system is running (for all CPUs).
2. Disable delayed reset assertion before suspending the system.
   This can be done after powering off secondary CPUs.
3. Re-enable the delayed reset assertion when system is resumed.

Fixes: 13cfa6c4f7fa ("ARM: EXYNOS: Fix CPU idle clock down after CPU off")
Signed-off-by: Krzysztof Kozlowski 
Tested-by: Bartlomiej Zolnierkiewicz 
Tested-by: Chanwoo Choi 
Signed-off-by: Kukjin Kim 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage

2015-06-23T00:03:31+00:00

commit 7a6cb0abe1aa63334f3ded6d2b6c8eca80e72302 upstream.

Avoid entering "RTC-only mode" at poweroff. It is unsupported by most
versions of BeagleBone, and risks hardware damage.

The damaging configuration is having system-power-controller
without ti,pmic-shutdown-controller.

Reported-by: Matthijs van Duin 
Tested-by: Matthijs van Duin 
Signed-off-by: Robert Nelson 
Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: Johan Hovold 
[Matthijs van Duin: added explanatory comments]
Signed-off-by: Matthijs van Duin 
Fixes: http://bugs.elinux.org/issues/143
[tony@atomide.com: updated comments with the hardware breaking info]
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: fix missing syscall trace exit

2015-06-06T15:21:05+00:00

commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.

Josh Stone reports:

  I've discovered a case where both arm and arm64 will miss a ptrace
  syscall-exit that they should report.  If the syscall is entered
  without TIF_SYSCALL_TRACE set, then it goes on the fast path.  It's
  then possible to have TIF_SYSCALL_TRACE added in the middle of the
  syscall, but ret_fast_syscall doesn't check this flag again.

Fix this by always checking for a syscall trace in the fast exit path.

Reported-by: Josh Stone 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: set display clock correctly for exynos4412-trats2

2015-06-06T15:21:05+00:00

commit 242ddf04297f2c4768bd8eb7593ab911910c5f76 upstream.

This patch sets display clock correctly. If Display clock isn't set
correctly then you would find below messages and Display controller
doesn't work correctly.

 exynos-drm: No connectors reported connected with modes
 [drm] Cannot find any crtc or sizes - going 1024x768

Fixes: abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
Signed-off-by: Inki Dae 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
Signed-off-by: Greg Kroah-Hartman