linux-stable.git/arch/arm/kernel, branch v3.18.76

ARM: 8452/3: PJ4: make coprocessor access sequences buildable in Thumb2 mode

2017-05-15T07:19:09+00:00

commit 5008efc83bf85b647aa1cbc44718b1675bbb7444 upstream.

The PJ4 inline asm sequence to write to cp15 cannot be built in Thumb-2
mode, due to the way it performs arithmetic on the program counter, so it
is built in ARM mode instead. However, building C files in ARM mode under
CONFIG_THUMB2_KERNEL is problematic, since the instrumentation performed
by subsystems like ftrace does not expect having to deal with interworking
branches.

Since the sequence in question is simply a poor man's ISB instruction,
let's use a straight 'isb' instead when building in Thumb2 mode. Thumb2
implies V7, so 'isb' should always be supported in that case.

Acked-by: Arnd Bergmann 
Acked-by: Nicolas Pitre 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8383/1: nommu: avoid deprecated source register on mov

2017-04-30T03:49:17+00:00

commit 970d96f9a81b0dd83ddd8bce0e5e1ba31881c5f5 upstream.

In Thumb2 mode, the stack register r13 is deprecated if the
destination register is the program counter (r15). Similar to
head.S, head-nommu.S uses r13 to store the return address used
after configuring the CPU's CP15 register. However, since we do
not enable a MMU, there will be no address switch and it is
possible to use branch with link instruction to call
__after_proc_init.

Avoid using r13 completely by using bl to call __after_proc_init
and get rid of __secondary_switched.

Beside removing unnecessary complexity, this also fixes a
compiler warning when compiling a !MMU kernel:
Warning: Use of r13 as a source register is deprecated when r15
is the destination register.

Tested-by: Maxime Coquelin 
Signed-off-by: Stefan Agner 
Signed-off-by: Russell King 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

[PATCH] arm: fix handling of F_OFD_... in oabi_fcntl64()

2016-09-11T13:57:24+00:00

[ Upstream commit 76cc404bfdc0d419c720de4daaf2584542734f42 ]

Cc: stable@vger.kernel.org # 3.15+
Reviewed-by: Jeff Layton 
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

ARM: fix PTRACE_SETVFPREGS on SMP systems

2016-06-20T03:47:42+00:00

[ Upstream commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf ]

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.

Cc: 
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: Sasha Levin

ARM: fix Thumb2 signal handling when ARMv6 is enabled

2015-10-28T02:13:00+00:00

[ Upstream commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab ]

When a kernel is built covering ARMv6 to ARMv7, we omit to clear the
IT state when entering a signal handler.  This can cause the first
few instructions to be conditionally executed depending on the parent
context.

In any case, the original test for >= ARMv7 is broken - ARMv6 can have
Thumb-2 support as well, and an ARMv6T2 specific build would omit this
code too.

Relax the test back to ARMv6 or greater.  This results in us always
clearing the IT state bits in the PSR, even on CPUs where these bits
are reserved.  However, they're reserved for the IT state, so this
should cause no harm.

Cc: 
Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler")
Acked-by: Tony Lindgren 
Tested-by: H. Nikolaus Schaller 
Tested-by: Grazvydas Ignotas 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: 8221/1: PJ4: allow building in Thumb-2 mode

2015-06-15T17:59:52+00:00

Two files that get included when building the multi_v7_defconfig target
fail to build when selecting THUMB2_KERNEL for this configuration.

In both cases, we can just build the file as ARM code, as none of its
symbols are exported to modules, so there are no interworking concerns.
In the iwmmxt.S case, add ENDPROC() declarations so the symbols are
annotated as functions, resulting in the linker to emit the appropriate
mode switches.

Acked-by: Nicolas Pitre 
Tested-by: Olof Johansson 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
(cherry picked from commit 13d1b9575ac2c2da143cd2236b6cf0fc314570f8)
Cc:  # v3.18+
Signed-off-by: Kevin Hilman 
Signed-off-by: Sasha Levin

ARM: fix missing syscall trace exit

2015-06-10T17:42:33+00:00

[ Upstream commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a ]

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: Sasha Levin

ARM: 8307/1: psci: move psci firmware calls out of line

2015-06-09T17:43:39+00:00

[ Upstream commit c097877319ab61dd045b6497953b4e3df8f2bb44 ]

arm64 builds with GCC 5 have caused the __asmeq assertions in the PSCI
calling code to fire, so move the ARM PSCI calls out of line into their
own assembly file for consistency and to safeguard against the same
issue occuring with the 32-bit toolchain.

[will: brought into line with arm64 implementation]

Reported-by: Andy Whitcroft 
Signed-off-by: Mark Rutland 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: fix broken hibernation

2015-05-17T23:11:57+00:00

[ Upstream commit 767bf7e7a1e82a81c59778348d156993d0a6175d ]

Normally, when a CPU wants to clear a cache line to zero in the external
L2 cache, it would generate bus cycles to write each word as it would do
with any other data access.

However, a Cortex A9 connected to a L2C-310 has a specific feature where
the CPU can detect this operation, and signal that it wants to zero an
entire cache line.  This feature, known as Full Line of Zeros (FLZ),
involves a non-standard AXI signalling mechanism which only the L2C-310
can properly interpret.

There are separate enable bits in both the L2C-310 and the Cortex A9 -
the L2C-310 needs to be enabled and have the FLZ enable bit set in the
auxiliary control register before the Cortex A9 has this feature
enabled.

Unfortunately, the suspend code was not respecting this - it's not
obvious from the code:

swsusp_arch_suspend()
 cpu_suspend() /* saves the Cortex A9 auxiliary control register */
  arch_save_image()
  soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
   cpu_resume() /* restores the Cortex A9 registers, inc auxcr */

At this point, we end up with the L2C disabled, but the Cortex A9 with
FLZ enabled - which means any memset() or zeroing of a full cache line
will fail to take effect.

A similar issue exists in the resume path, but it's slightly more
complex:

swsusp_arch_suspend()
 cpu_suspend() /* saves the Cortex A9 auxiliary control register */
  arch_save_image() /* image with A9 auxcr saved */
...
swsusp_arch_resume()
 call_with_stack()
  arch_restore_image() /* restores image with A9 auxcr saved above */
  soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
   cpu_resume() /* restores the Cortex A9 registers, inc auxcr */

Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled.

There's no need to turn off the L2C in either of these two paths; there
are benefits from not doing so - for example, the page copies will be
faster with the L2C enabled.

Hence, fix this by providing a variant of soft_restart() which can be
used without turning the L2 cache controller off, and use it in both
of these paths to keep the L2C enabled across the respective resume
transitions.

Fixes: 8ef418c7178f ("ARM: l2c: trial at enabling some Cortex-A9 optimisations")
Reported-by: Sean Cross 
Tested-by: Sean Cross 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

Revert "ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo"

2015-01-16T14:59:55+00:00

commit 4bf9636c39ac70da091d5a2e28d3448eaa7f115c upstream.

Commit 9fc2105aeaaf ("ARM: 7830/1: delay: don't bother reporting
bogomips in /proc/cpuinfo") breaks audio in python, and probably
elsewhere, with message

  FATAL: cannot locate cpu MHz in /proc/cpuinfo

I'm not the first one to hit it, see for example

  https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/
  https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1

Reading original changelog, I have to say "Stop breaking working setups.
You know who you are!".

Signed-off-by: Pavel Machek 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman