linux-toradex.git/arch, branch v3.17.6

x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is read-only

2014-12-06T23:57:34+00:00

commit c1118b3602c2329671ad5ec8bdf8e374323d6343 upstream.

On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
In that case, KVM will fail to patch VMCALL instructions to VMMCALL
as required on AMD processors.

The failure mode is currently a divide-by-zero exception, which obviously
is a KVM bug that has to be fixed.  However, picking the right instruction
between VMCALL and VMMCALL will be faster and will help if you cannot upgrade
the hypervisor.

Reported-by: Chris Webb 
Tested-by: Chris Webb 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x86@kernel.org
Acked-by: Borislav Petkov 
Signed-off-by: Paolo Bonzini 
Cc: Chris J Arges 
Signed-off-by: Greg Kroah-Hartman

powerpc/powernv: Honor the generic "no_64bit_msi" flag

2014-12-06T23:57:33+00:00

commit 360743814c4082515581aa23ab1d8e699e1fbe88 upstream.

Instead of the arch specific quirk which we are deprecating
and that drivers don't understand.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

ARM: 8226/1: cacheflush: get rid of restarting block

2014-12-06T23:57:29+00:00

commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1 upstream.

We cannot restart cacheflush safely if a process provides user-defined
signal handler and signal is pending. In this case -EINTR is returned
and it is expected that process re-invokes syscall. However, there are
a few problems with that:
 * looks like nobody bothers checking return value from cacheflush
 * but if it did, we don't provide the restart address for that, so the
   process has to use the same range again
 * ...and again, what might lead to looping forever

So, remove cacheflush restarting code and terminate cache flushing
as early as fatal signal is pending.

Reported-by: Chanho Min 
Signed-off-by: Vladimir Murzin 
Acked-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8222/1: mvebu: enable strex backoff delay

2014-12-06T23:57:29+00:00

commit 995ab5189d1d7264e79e665dfa032a19b3ac646e upstream.

Under extremely rare conditions, in an MPCore node consisting of at
least 3 CPUs, two CPUs trying to perform a STREX to data on the same
shared cache line can enter a livelock situation.

This patch enables the HW mechanism that overcomes the bug. This fixes
the incorrect setup of the STREX backoff delay bit due to a wrong
description in the specification.

Note that enabling the STREX backoff delay mechanism is done by
leaving the bit *cleared*, while the bit was currently being set by
the proc-v7.S code.

[Thomas: adapt to latest mainline, slightly reword the commit log, add
stable markers.]

Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")

Signed-off-by: Nadav Haklai 
Signed-off-by: Thomas Petazzoni 
Acked-by: Gregory CLEMENT 
Acked-by: Jason Cooper 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8216/1: xscale: correct auxiliary register in suspend/resume

2014-12-06T23:57:29+00:00

commit ef59a20ba375aeb97b3150a118318884743452a8 upstream.

According to the manuals I have, XScale auxiliary register should be
reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init
correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and
cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to
also use c1, c0, 1.

The issue was primarily noticed thanks to qemu reporing "unsupported
instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255
XScale Core manuals and in PXA270 and PXA320 Developers Guides.

Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board.

Tested-by: Robert Jarzmik 
Signed-off-by: Dmitry Eremin-Solenikov 
Acked-by: Robert Jarzmik 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: add missing of_node_put() call in coherency.c

2014-12-06T23:57:29+00:00

commit 2eb04ae010a8fb165ba7aa56e9aa8e7980887dee upstream.

There is a missing of_node_put() to decrement the device_node
reference counter after a of_find_matching_node() in coherency_init().

Fixes: 501f928e0097 ("ARM: mvebu: add a coherency_available() call")
Signed-off-by: Thomas Petazzoni 
Acked-by: Gregory CLEMENT 
Link: https://lkml.kernel.org/r/1414423955-5933-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

powerpc/powernv: Fix the hmi event version check.

2014-12-06T23:57:23+00:00

commit 6acbc5a1dab30aa8f7be7bf3852f343f89147ac5 upstream.

The current HMI event structure is an ABI and carries a version field to
accommodate future changes without affecting/rearranging current structure
members that are valid for previous versions.

The current version check "if (hmi_evt->version != OpalHMIEvt_V1)"
doesn't accomodate the fact that the version number may change in
future.

If firmware starts returning an HMI event with version > 1, this check
will fail and no HMI information will be printed on older kernels.

This patch fixes this issue.

Signed-off-by: Mahesh Salgaonkar 
[mpe: Reword changelog]
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: Fix endiannes issue in RTAS call from xmon

2014-12-06T23:57:23+00:00

commit 3b8a3c01096925a824ed3272601082289d9c23a5 upstream.

On pseries system (LPAR) xmon failed to enter when running in LE mode,
system is hunging. Inititating xmon will lead to such an output on the
console:

SysRq : Entering xmon
cpu 0x15: Vector: 0  at [c0000003f39ffb10]
    pc: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
    lr: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
    sp: c0000003f39ffc70
   msr: 8000000000009033
  current = 0xc0000003fafa7180
  paca    = 0xc000000007d75e80	 softe: 0	 irq_happened: 0x01
    pid   = 14617, comm = bash
Bad kernel stack pointer fafb4b0 at eca7cc4
cpu 0x15: Vector: 300 (Data Access) at [c000000007f07d40]
    pc: 000000000eca7cc4
    lr: 000000000eca7c44
    sp: fafb4b0
   msr: 8000000000001000
   dar: 10000000
 dsisr: 42000000
  current = 0xc0000003fafa7180
  paca    = 0xc000000007d75e80	 softe: 0	 irq_happened: 0x01
    pid   = 14617, comm = bash
cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop
xmon: WARNING: bad recursive fault on cpu 0x15

The root cause is that xmon is calling RTAS to turn off the surveillance
when entering xmon, and RTAS is requiring big endian parameters.

This patch is byte swapping the RTAS arguments when running in LE mode.

Signed-off-by: Laurent Dufour 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/powernv: Replace OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE

2014-12-06T23:57:22+00:00

commit 360d88a9e3fba596a12520b242fbab1c45b983e1 upstream.

The flag passed to ioda_eeh_phb_reset() should be EEH_RESET_DEACTIVATE,
which is translated to OPAL_DEASSERT_RESET or something else by the
EEH backend accordingly.

The patch replaces OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE for
ioda_eeh_phb_reset().

Signed-off-by: Gavin Shan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc: 32 bit getcpu VDSO function uses 64 bit instructions

2014-12-06T23:57:22+00:00

commit 152d44a853e42952f6c8a504fb1f8eefd21fd5fd upstream.

I used some 64 bit instructions when adding the 32 bit getcpu VDSO
function. Fix it.

Fixes: 18ad51dd342a ("powerpc: Add VDSO version of getcpu")
Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman