linux-stable.git/arch/arm, branch v3.16.6

ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants

2014-10-05T20:41:12+00:00

commit af438fec6cb99fc2e2faf8b16b865af26ce722e6 upstream.

Use the corresponding compatibles to identify the devices.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Lokesh Vutla 
Acked-by: Nishanth Menon 
Tested-by: Nishanth Menon 
Signed-off-by: Paul Walmsley 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

arm: armv7: perf: fix armv7 ref-cycles error

2014-10-05T20:41:09+00:00

ref-cycles event is specially to Intel core, but can still used in arm
architecture with the wrong return value with 3.10 stable. this patch fix the
bug and make it return NOT SUPPORTED distinctly.

In upstream this bug has been fixed by other way, which changes more than one
file and more than 1000 lines. the primary commit is
6b7658ec8a100b608e59e3cde353434db51f5be0.  besides we can not simply
cherry-pick.

Signed-off-by: Zhiqiang Zhang 
Cc: Mark Rutland 
Cc: Christopher Covington 
Signed-off-by: Greg Kroah-Hartman

ARM: 8178/1: fix set_tls for !CONFIG_KUSER_HELPERS

2014-10-05T20:41:02+00:00

commit 9cc6d9e5daaa147a9a3e31557efcb331989e77be upstream.

Joachim Eastwood reports that commit fbfb872f5f41 "ARM: 8148/1: flush
TLS and thumbee register state during exec" causes a boot-time crash
on a Cortex-M4 nommu system:

Freeing unused kernel memory: 68K (281e5000 - 281f6000)
Unhandled exception: IPSR = 00000005 LR = fffffff1
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
task: 29834000 ti: 29832000 task.ti: 29832000
PC is at flush_thread+0x2e/0x40
LR is at flush_thread+0x21/0x40
pc : [<2800954a>] lr : [<2800953d>] psr: 4100000b
sp : 29833d60 ip : 00000000 fp : 00000001
r10: 00003cf8 r9 : 29b1f000 r8 : 00000000
r7 : 29b0bc00 r6 : 29834000 r5 : 29832000 r4 : 29832000
r3 : ffff0ff0 r2 : 29832000 r1 : 00000000 r0 : 282121f0
xPSR: 4100000b
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
[<2800afa5>] (unwind_backtrace) from [<2800a327>] (show_stack+0xb/0xc)
[<2800a327>] (show_stack) from [<2800a963>] (__invalid_entry+0x4b/0x4c)

The problem is that set_tls is attempting to clear the TLS location in
the kernel-user helper page, which isn't set up on V7M.

Fix this by guarding the write to the kuser helper page with
a CONFIG_KUSER_HELPERS ifdef.

Fixes: fbfb872f5f41 ARM: 8148/1: flush TLS and thumbee register state during exec

Reported-by: Joachim Eastwood 
Tested-by: Joachim Eastwood 
Signed-off-by: Nathan Lynch 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8165/1: alignment: don't break misaligned NEON load/store

2014-10-05T20:41:02+00:00

commit 5ca918e5e3f9df4634077c06585c42bc6a8d699a upstream.

The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn
instructions (where the optional alignment hint is given but incorrect)
as LDR/STR, leading to register corruption. Detect these and correctly
treat them as unhandled, so that userspace gets the fault it expects.

Reported-by: Simon Hosie 
Signed-off-by: Robin Murphy 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: imx: fix .is_enabled() of shared gate clock

2014-10-05T20:41:02+00:00

commit 9e1ac462b982f496ed3b491f02c417dcc8e40347 upstream.

Commit 63288b721a80 ("ARM: imx: fix shared gate clock") attempted to fix
an issue with particular enable/disable sequence from two shared gate
clocks.  But unfortunately, while it partially fixed the issue, it also
did something wrong in .is_enabled() function hook.  In case of shared
gate, the function shouldn't really query the hardware state via
share_count, because the function is trying to query the enabling state
of the clock in question, not the hardware state which is shared by
multiple clocks.

Fix the issue by returning the enable_count of the clock itself which is
maintained by clock core, in case it's a clock sharing hardware gate
with others.  As the result, the initialization of share_count per
hardware state is not needed now.  So remove it.

Reported-by: Fabio Estevam 
Fixes: 63288b721a80 ("ARM: imx: fix shared gate clock")
Signed-off-by: Shawn Guo 
Tested-by: Fabio Estevam 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: DT: imx53: fix lvds channel 1 port

2014-10-05T20:41:02+00:00

commit 1b134c9c4b555342be667f144ee714af1c3f6a9f upstream.

using LVDS channel 1 on an i.MX53 leads to following error:

imx-ldb 53fa8008.ldb: unable to set di0 parent clock to ldb_di1

This comes from imx_ldb_set_clock with mux = 0. Mux parameter must be "1" for
reparenting di1 clock to ldb_di1. The value of the mux param comes from device
tree port settings.

On i.MX5, the internal two-input-multiplexer is used. Due to hardware limitations,
only one port (port@[0,1]) can be used for each channel (lvds-channel@[0,1],
respectively)

Documentation update suggested by Philipp Zabel 

Signed-off-by: Markus Niebel 
Fixes: e05c8c9a790a ("ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi")
Acked-by: Philipp Zabel 
Signed-off-by: Shawn Guo 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: dra7-evm: Fix NAND GPMC timings

2014-10-05T20:41:02+00:00

commit 5990047cef0c6a36eefcb166bd32d99a8f95c75b upstream.

The nand timings were scaled down by 2 to account for
the 2x rate returned by clk_get_rate(gpmc_fclk).

As the clock data got fixed by [1], revert back to actual
timings (i.e. scale them up by 2).

Without this NAND doesn't work on dra7-evm.

[1] - commit dd94324b983afe114ba9e7ee3649313b451f63ce
    ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates

Fixes: ff66a3c86e00 ("ARM: dts: dra7: add support for parallel NAND flash")
Signed-off-by: Roger Quadros 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: 8149/1: perf: Don't sleep while atomic when enabling per-cpu interrupts

2014-10-05T20:41:02+00:00

commit 505013bc9065391f09a51d51cd3bf0b06dfb570a upstream.

Rob Clark reports a sleeping while atomic bug when using perf.

BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:583
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
------------[ cut here ]------------
WARNING: CPU: 2 PID: 4828 at ../kernel/locking/mutex.c:479 mutex_lock_nested+0x3a0/0x3e8()
DEBUG_LOCKS_WARN_ON(in_interrupt())
Modules linked in:
CPU: 2 PID: 4828 Comm: Xorg.bin Tainted: G        W      3.17.0-rc3-00234-gd535c45-dirty #819
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x98/0xb8)
[] (dump_stack) from [] (warn_slowpath_common+0x70/0x8c)
[] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from [] (mutex_lock_nested+0x3a0/0x3e8)
[] (mutex_lock_nested) from [] (irq_find_host+0x20/0x9c)
[] (irq_find_host) from [] (of_irq_get+0x28/0x48)
[] (of_irq_get) from [] (platform_get_irq+0x1c/0x8c)
[] (platform_get_irq) from [] (cpu_pmu_enable_percpu_irq+0x14/0x38)
[] (cpu_pmu_enable_percpu_irq) from [] (flush_smp_call_function_queue+0x88/0x178)
[] (flush_smp_call_function_queue) from [] (handle_IPI+0x88/0x160)
[] (handle_IPI) from [] (gic_handle_irq+0x64/0x68)
[] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c)
Exception stack(0xe63ddea0 to 0xe63ddee8)
dea0: 00000001 00000001 00000000 c2f3b200 c16db380 c032d4a0 e63ddf40 60010013
dec0: 00000000 001fbfd4 00000100 00000000 00000001 e63ddee8 c0284770 c02a2e30
dee0: 20010013 ffffffff
[] (__irq_svc) from [] (ktime_get_ts64+0x1c8/0x200)
[] (ktime_get_ts64) from [] (poll_select_set_timeout+0x60/0xa8)
[] (poll_select_set_timeout) from [] (SyS_select+0xa8/0x118)
[] (SyS_select) from [] (ret_fast_syscall+0x0/0x48)
---[ end trace 0bb583b46342da6f ]---
INFO: lockdep is turned off.

We don't really need to get the platform irq again when we're
enabling or disabling the per-cpu irq. Furthermore, we don't
really need to set and clear bits in the active_irqs bitmask
because that's only used in the non-percpu irq case to figure out
when the last CPU PMU has been disabled. Just pass the irq
directly to the enable/disable functions to clean all this up.
This should be slightly more efficient and also fix the
scheduling while atomic bug.

Fixes: bbd64559376f "ARM: perf: support percpu irqs for the CPU PMU"

Reported-by: Rob Clark 
Acked-by: Will Deacon 
Signed-off-by: Stephen Boyd 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8148/1: flush TLS and thumbee register state during exec

2014-10-05T20:41:02+00:00

commit fbfb872f5f417cea48760c535e0ff027c88b507a upstream.

The TPIDRURO and TPIDRURW registers need to be flushed during exec;
otherwise TLS information is potentially leaked.  TPIDRURO in
particular needs careful treatment.  Since flush_thread basically
needs the same code used to set the TLS in arm_syscall, pull that into
a common set_tls helper in tls.h and use it in both places.

Similarly, TEEHBR needs to be cleared during exec as well.  Clearing
its save slot in thread_info isn't right as there is no guarantee
that a thread switch will occur before the new program runs.  Just
setting the register directly is sufficient.

Signed-off-by: Nathan Lynch 
Acked-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs

2014-10-05T20:41:01+00:00

commit a040803a9d6b8c1876d3487a5cb69602ebcbb82c upstream.

Since commit 1dbfa187dad ("ARM: irq migration: force migration off CPU
going down") the ARM interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. At the point
of this change the argument had no effect because it was not used by
any interrupt chip driver and there was no semantics defined.

This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu
affinity of interrupts") which made the force argument useful to route
interrupts to not yet online cpus without checking the target cpu
against the cpu online mask. The following commit ffde1de64012
("irqchip: gic: Support forced affinity setting") implemented this for
the GIC interrupt controller.

As a consequence the ARM cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validataion against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.

Solve the issue by calling irq_set_affinity() with force=false from
the CPU offline irq migration code so the GIC driver validates the
affinity mask against CPU online mask and therefore removes CPU0 from
the possible target candidates.

Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
locks up as the IRQs are not migrated away from CPU0.

Signed-off-by: Sudeep Holla 
Acked-by: Thomas Gleixner 
Acked-by: Mark Rutland 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman