rtmutex: Fix deadlock detector for real

The current deadlock detection logic does not work reliably due to the
following early exit path:

	/*
	 * Drop out, when the task has no waiters. Note,
	 * top_waiter can be NULL, when we are in the deboosting
	 * mode!
	 */
	if (top_waiter && (!task_has_pi_waiters(task) ||
			   top_waiter != task_top_pi_waiter(task)))
		goto out_unlock_pi;

So this not only exits when the task has no waiters, it also exits
unconditionally when the current waiter is not the top priority waiter
of the task.

So in a nested locking scenario, it might abort the lock chain walk
and therefor miss a potential deadlock.

Simple fix: Continue the chain walk, when deadlock detection is
enabled.

We also avoid the whole enqueue, if we detect the deadlock right away
(A-A). It's an optimization, but also prevents that another waiter who
comes in after the detection and before the task has undone the damage
observes the situation and detects the deadlock and returns
-EDEADLOCK, which is wrong as the other task is not in a deadlock
situation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20140522031949.725272460@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
lib/memcopy: use glibc version

the kernel's memcpy and memmove is very inefficient. But the glibc version is
quite fast, in some cases it is 10 times faster than the kernel version. So I
introduce some memory copy macros and functions of the glibc to improve the
kernel version's performance.

The strategy of the memory functions is:
1. Copy bytes until the destination pointer is aligned.
2. Copy words in unrolled loops.  If the source and destination are not
   aligned in the same way, use word memory operations, but shift and merge
   two read words before writing.
3. Copy the few remaining bytes.

Signed-off-by: Miao Xie <miaox*******>
Signed-off-by: faux123 <reioux@gmail.com>
lib: Sparc's strncpy_from_user is generic enough, move under lib/

To use this, an architecture simply needs to:

1) Provide a user_addr_max() implementation via asm/uaccess.h

2) Add "select GENERIC_STRNCPY_FROM_USER" to their arch Kcnfig

3) Remove the existing strncpy_from_user() implementation and symbol
   exports their architecture had.

Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: David Howells <dhowells@redhat.com>
adapted for Mako from kernel.org reference

Signed-off-by: Paul Reioux <reioux@gmail.com>
kernel: Move REPEAT_BYTE definition into linux/kernel.h

And make sure that everything using it explicitly includes
that header file.

Signed-off-by: David S. Miller <davem@davemloft.net>
modified for Mako kernel from kernel.org

Signed-off-by: faux123 <reioux@gmail.com>
word-at-a-time: make the interfaces truly generic

This changes the interfaces in <asm/word-at-a-time.h> to be a bit more
complicated, but a lot more generic.

In particular, it allows us to really do the operations efficiently on
both little-endian and big-endian machines, pretty much regardless of
machine details.  For example, if you can rely on a fast population
count instruction on your architecture, this will allow you to make your
optimized <asm/word-at-a-time.h> file with that.

NOTE! The "generic" version in include/asm-generic/word-at-a-time.h is
not truly generic, it actually only works on big-endian.  Why? Because
on little-endian the generic algorithms are wasteful, since you can
inevitably do better. The x86 implementation is an example of that.

(The only truly non-generic part of the asm-generic implementation is
the "find_zero()" function, and you could make a little-endian version
of it.  And if the Kbuild infrastructure allowed us to pick a particular
header file, that would be lovely)

The <asm/word-at-a-time.h> functions are as follows:

 - WORD_AT_A_TIME_CONSTANTS: specific constants that the algorithm
   uses.

 - has_zero(): take a word, and determine if it has a zero byte in it.
   It gets the word, the pointer to the constant pool, and a pointer to
   an intermediate "data" field it can set.

   This is the "quick-and-dirty" zero tester: it's what is run inside
   the hot loops.

 - "prep_zero_mask()": take the word, the data that has_zero() produced,
   and the constant pool, and generate an *exact* mask of which byte had
   the first zero.  This is run directly *outside* the loop, and allows
   the "has_zero()" function to answer the "is there a zero byte"
   question without necessarily getting exactly *which* byte is the
   first one to contain a zero.

   If you do multiple byte lookups concurrently (eg "hash_name()", which
   looks for both NUL and '/' bytes), after you've done the prep_zero_mask()
   phase, the result of those can be or'ed together to get the "either
   or" case.

 - The result from "prep_zero_mask()" can then be fed into "find_zero()"
   (to find the byte offset of the first byte that was zero) or into
   "zero_bytemask()" (to find the bytemask of the bytes preceding the
   zero byte).

   The existence of zero_bytemask() is optional, and is not necessary
   for the normal string routines.  But dentry name hashing needs it, so
   if you enable DENTRY_WORD_AT_A_TIME you need to expose it.

This changes the generic strncpy_from_user() function and the dentry
hashing functions to use these modified word-at-a-time interfaces.  This
gets us back to the optimized state of the x86 strncpy that we lost in
the previous commit when moving over to the generic version.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:
	fs/namei.c

Conflicts:

	fs/namei.c
word-at-a-time: provide generic big-endian zero_bytemask implementation

Whilst architectures may be able to do better than this (which they can,
by simply defining their own macro), this is a generic stab at a
zero_bytemask implementation for the asm-generic, big-endian
word-at-a-time implementation.

On arm64, a clz instruction is used to implement the fls efficiently.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
word-at-a-time: avoid undefined behaviour in zero_bytemask macro

The asm-generic, big-endian version of zero_bytemask creates a mask of
bytes preceding the first zero-byte by left shifting ~0ul based on the
position of the first zero byte.

Unfortunately, if the first (top) byte is zero, the output of
prep_zero_mask has only the top bit set, resulting in undefined C
behaviour as we shift left by an amount equal to the width of the type.
As it happens, GCC doesn't manage to spot this through the call to fls(),
but the issue remains if architectures choose to implement their shift
instructions differently.

An example would be arch/arm/ (AArch32), where LSL Rd, Rn, #32 results
in Rd == 0x0, whilst on arch/arm64 (AArch64) LSL Xd, Xn, #64 results in
Xd == Xn.

Rather than check explicitly for the problematic shift, this patch adds
an extra shift by 1, replacing fls with __fls. Since zero_bytemask is
never called with a zero argument (has_zero() is used to check the data
first), we don't need to worry about calling __fls(0), which is
undefined.

Cc: <stable@vger.kernel.org>
Cc: Victor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
word-at-a-time: simplify big-endian zero_bytemask macro

This is simpler and cleaner.  Depending on architecture, a smart
compiler may or may not generate the same code.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
lockdep: fix oops in processing workqueue

Under memory load, on x86_64, with lockdep enabled, the workqueue's
process_one_work() has been seen to oops in __lock_acquire(), barfing
on a 0xffffffff00000000 pointer in the lockdep_map's class_cache[].

Because it's permissible to free a work_struct from its callout function,
the map used is an onstack copy of the map given in the work_struct: and
that copy is made without any locking.

Surprisingly, gcc (4.5.1 in Hugh's case) uses "rep movsl" rather than
"rep movsq" for that structure copy: which might race with a workqueue
user's wait_on_work() doing lock_map_acquire() on the source of the
copy, putting a pointer into the class_cache[], but only in time for
the top half of that pointer to be copied to the destination map.

Boom when process_one_work() subsequently does lock_map_acquire()
on its onstack copy of the lockdep_map.

Fix this, and a similar instance in call_timer_fn(), with a
lockdep_copy_map() function which additionally NULLs the class_cache[].

Note: this oops was actually seen on 3.4-next, where flush_work() newly
does the racing lock_map_acquire(); but Tejun points out that 3.4 and
earlier are already vulnerable to the same through wait_on_work().

* Patch orginally from Peter.  Hugh modified it a bit and wrote the
  description.

Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Reported-by: Hugh Dickins <hughd@google.com>
LKML-Reference: <alpine.LSU.2.00.1205070951170.1544@eggly.anvils>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ARM: mm: implement LoUIS API for cache maintenance ops

ARM v7 architecture introduced the concept of cache levels and related
control registers. New processors like A7 and A15 embed an L2 unified cache
controller that becomes part of the cache level hierarchy. Some operations in
the kernel like cpu_suspend and __cpu_disable do not require a flush of the
entire cache hierarchy to DRAM but just the cache levels belonging to the
Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems
correspond to L1.

The current cache flushing API used in cpu_suspend and __cpu_disable,
flush_cache_all(), ends up flushing the whole cache hierarchy since for
v7 it cleans and invalidates all cache levels up to Level of Coherency
(LoC) which cripples system performance when used in hot paths like hotplug
and cpuidle.

Therefore a new kernel cache maintenance API must be added to cope with
latest ARM system requirements.

This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.

This function cleans and invalidates all data cache levels up to the
Level of Unification Inner Shareable (LoUIS) and invalidates the instruction
cache for processors that support it (> v7).

This patch also creates an alias of the cache LoUIS function to flush_kern_all
for all processor versions prior to v7, so that the current cache flushing
behaviour is unchanged for those processors.

v7 cache maintenance code implements a cache LoUIS function that cleans and
invalidates the D-cache up to LoUIS and invalidates the I-cache, according
to the new API.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>

Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: kernel: update cpu_suspend code to use cache LoUIS operations

In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.

When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.

The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.

outer_cache management remains unchanged.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: kernel: update __cpu_disable to use cache LoUIS maintenance API

When a CPU is hotplugged out caches that reside in its power domain
lose their contents and so must be cleaned to the next memory level.

Currently, __cpu_disable calls flush_cache_all() that for new generation
processor like A15/A7 ends up cleaning and invalidating all cache levels
up to Level of Coherency, which includes the unified L2.

This ends up being a waste of cycles since the L2 cache contents are not
lost on power down.

This patch updates __cpu_disable to use the new LoUIS API cache operations.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: smp: Fix Unknown IPI message 0x1

Commit 'ad3b6993' converted ARM smp_cross_call() to take IPI number
as a parameter to handle more event than SGI and do_IPI was suppose
to recover SGI number. But the do_IPI doesn't consider it and it's
getting detected as 'Unknown IPI message 0x1' with ipi numbers are
moved to starts from 'IPI_TIMER=2"

There can be 16 different SGI but only SGI1 is used as IPI so
only that one is handled in do_IPI as IPI_CPU_START.

Added IPI_CPU_START because it wasn't used and thought it's
appropriate. Not sure whether its the right one.

Change-Id: I4dbe7c489d9611fbbb4036c15ac247659fde4119
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
[johlstei@codeaurora.org: fixed bounds check error]
Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>
(cherry picked from commit 7f685e51169149a877cb3100670567fb03c969f5)
ARM: SMP: send IPI in backtrace only for SMP

Bug in backtrace leads to NULL Pointer dereference with CONFIG_SMP_ON_UP
while sending IPI, fix it.
-----------------------------------------------------------------
[  301.992943] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  302.023626] pgd = c0004000
[  302.033985] [00000000] *pgd=00000000
[  302.048057] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
[  302.070273] Modules linked in:
[  302.082206] CPU: 0    Not tainted  (3.4.0+ #12)
[  302.099386] PC is at 0x0
[  302.109251] LR is at smp_send_all_cpu_backtrace+0x88/0xe4
[  302.129993] pc : [<00000000>]    lr : [<c00144f0>]    psr: 20000193
[  302.130522] sp : c02edd80  ip : 00000000  fp : 7fffffff
[  302.173742] r10: 00000000  r9 : c02ee0c0  r8 : 19484bea
[  302.193789] r7 : 00002710  r6 : 00000000  r5 : 00000000  r4 : c031d034
[  302.218816] r3 : c030ad58  r2 : 00010001  r1 : 00000007  r0 : c031d044
[  302.243885] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  302.272171] Control: 10c5387d  Table: 2f404059  DAC: 00000015
[  302.293986]
[  302.294243] LR: 0xc0014470:
[  302.310233] 4470  e3c20d7f e30d4034 e3c0303f e34c4031 e3a00000 e284101c e5935014 eb05c24f
[  302.341559] 4490  e2503000 18bd80f8 e30567a4 e34c6021 e1a01004 e1a00005 e5962000 e1a06003
[  302.372890] 44b0  e3027710 e592e000 e5a1e010 eb05b841 e1a01005 e30a05bc e34c0027 eb07ed21
[  302.404222] 44d0  eb07ec87 e30a05e0 e34c0027 eb07ed1d e1a00004 e490c010 e3a01007 e12fff3c
[  302.435554] 44f0  ea000008 eb05bcab e594c010 e30605b0 e3400666 e31c000f 0a000009 eb05bca5
[  302.466888] 4510  e1560007 0a000006 e5941010 e2863001 e30605b0 e2836001 e311000f e3400666
[  302.498220] 4530  1affffef e3a00000 e59f1008 eb05b821 f57ff05f e8bd80f8 c031d050 e30537a8
[  302.529555] 4550  e34c3021 e92d4ff0 e5938000 e3067750 e30495c8 e30f6d00 e24dd00c e241b001
[  302.560973]
[  302.561235] SP: 0xc02edd00:
[  302.577222] dd00  392e3130 36353137 00205d36 00000000 c02edd7c c020f974 c02ca964 c02edd2c
[  302.608555] dd20  00000000 00000000 20000193 ffffffff c02edd6c c000eef8 c031d044 00000007
[  302.639897] dd40  00010001 c030ad58 c031d034 00000000 00000000 00002710 19484bea c02ee0c0
[  302.671221] dd60  00000000 7fffffff 00000000 c02edd80 c00144f0 00000000 20000193 ffffffff
[  302.702565] dd80  c030ad58 c05aca98 c0306764 c030dd00 c030dd00 c007c664 295f6000 00001dc6
[  302.733898] dda0  00000017 c0306970 00000000 c0306970 c02e9a98 19484bea 00000046 00000000
[  302.765220] ddc0  7fffffff c007cc58 c02ec000 c0307c80 00000000 00000000 19484bea c0033100
[  302.796555] dde0  c05ac888 c05ac888 c0341c40 c0305f40 19484bea c0060f78 c05ac888 c05ac738
[  302.827969]
[  302.828233] R0: 0xc031cfc4:
[  302.844218] cfc4  006c3776 00000000 c027eb38 00000000 410fc051 00000000 00000000 00000000
[  302.875563] cfe4  00000000 00000000 00000000 00000000 00000000 00000000 00000000 c030cac0
[  302.906895] d004  c0308d90 00000000 003.299225] ad98  00000004 ffffffff 00000000 00000001 00000000 00000000
ffffffff 00000001
[  303.330564] adb8  00000000 00000000 c030adc0 c030adc0 00000000 00000001 c0280068 c028006c
[  303.361958]
[  303.362221] R4: 0xc031cfb4:
[  303.378221] cfb4  00000000 00000000 00000000 c001e658 006c3776 0000ee000)
[  303.936303] dd80: c030ad58 c05aca98 c0306764 c030dd00 c030dd00 c007c664 295f6000 00001dc6
[  303.967588] dda0: 00000017 c0306970 00000000 c0306970 c02e9a98 19484bea 00000046 00000000
[  303.998940] ddc0: 7fffffff c007cc58 c02ec000 c0307c80 00000000 00000000 19484bea c0033100
[  304.030275] 04.500235] dfc0: c02e55ec c02ca964 00000000 00000000 c02ca448 00000000 00000000 c02e55ec
[  304.531597] dfe0: 10c5387d c0305ea0 c02e55bc c0308d04 20204059 20208040 00000000 00000000
[  304.563391] [<c00144f0>] (smp_send_all_cpu_backtrace+0x88/0xe4) from [<c007c664>] (__rcu_pending+0x17c/0x5ac)
[  30406] [<c0010108>] (handle_IRQ+0x5c/0xc0) from [<c0008530>] (gic_handle_irq+0x48/0xe8)
[  305.033405] [<c0008530>] (gic_handle_irq+0x48/0xe8) from [<c000ee00>] (__irq_svc+0x40/0x70)
[  305.064749] Exception stack(0xc02edf48 to 0xc02edf90)
[  305.084483] df40:                   00000000 00000000 a00000c02ee0c0  r8 : 80000007
[  305.544476] r7 : c0307c80  r6 : c02edb7c  r5 : c0305ef8  r4 : 000f4240
[  305.569465] r3 : 00000000  r2 : c031d034  r1 : 00000006  r0 : c02edb7c
[  305.594485] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  305.622824] Control: 10c5387d  Table: 2f408 00010000 c02ec000 c02ec2f0 0000000b c027bb60 c02edd38 00000000
[  306.414224] dbdc  00000000 80000007 00000000 00000000 c001addc 80000007 00000000 c02edd38
[  306.445623]
[  306.445886] R2: 0xc031cfb4:
[  306.461894] cfb4  00000000 00000000 00000000 c001e658 006c3776 00000000 c027eb38 00000000
[ bc  c02ec008 00010000 c02ec000 c02ec2f0 0000000b c027bb60 c02edd38 00000000
[  307.215227] dbdc  00000000 80000007 00000000 00000000 c001addc 80000007 00000000 c02edd38
[  307.246620]
[  307.246883] R7: 0xc0307c00:
[  307.262891] 7c00  c01b95ac c0213788 c01b95b8 c0213794 c01b9664 c02137a0 c01b966c b80: c031f380 c02edd38
00000000 c020f7ac c02ee0c0 c02edbbc 7fffffff c02ec2f0
[  308.150942] dba0: c02edd38 00000000 c0307c80 80000007 c031d018 c0013394 c027a19c c02ec008
[  308.182258] dbc0: 00010000 c02ec000 c02ec2f0 0000000b c027bb60 c02edd38 00000000 00000000
[  308.213580] dbe0: 80000007 000000004aa54 00000046 c02eff00
[  308.934261] dec0: c02eff54 cfa00540 00000000 d0804010 410fc051 00000027 00000000 c0074a9c
[  308.965605] dee0: c02eff00 c02eff54 00000027 c0077680 c0306970 c02e9f44 00000027 c00743ec
[  308.996956] df00: 00000178 c0010108 c0305ec8 d080400c c02edf48 c0305ec8 d0804010 c00085364>]
(__rcu_pending+0x17c/0x5ac) from [<c007cc58>] (rcu_check_callbacks+0x1c4/0x1e0)
[  309.664887] [<c007cc58>] (rcu_check_callbacks+0x1c4/0x1e0) from [<c0033100>] (update_process_times+0x38/0x68)
[  309.702911] [<c0033100>] (update_process_times+0x38/0x68) from [<c0060f78>]
(tick_sched_timer+0x9c/0xk(0xc02edf48 to 0xc02edf90)

Change-Id: Icfd3585361c88ada6550f22b316af19e1a2b7721
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
smp: change printks that occur every hotplug to pr_debugs

Hotplug occurs frequently enough on our targets that its messages are
clogging up the logs. There is no need for any messages to be printed
when hotplug is successful.

Change-Id: Icf213ab409ba428f39439f886cdf4c070a48bfbf
Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>
(cherry picked from commit 4d0bd4217b4e451843dc21208036d25f9d2871f8)

Conflicts:

	arch/arm/kernel/smp.c
Revert "ARM: smp: Wait just 1 second for other CPU to halt"
ARM: smp: Fix cpu_up() racing with sys_reboot

Nothing stops a process from hotplugging in a CPU concurrently
with a sys_reboot() call. In such a situation we could have
ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the
fact that the CPU is not really offline and call the
CPU_UP_PREPARE notifier. When this happens stop_machine code will
complain that the cpu thread already exists and BUG_ON().

CPU0                      CPU1

sys_reboot()
 kernel_restart()
  machine_restart()
   machine_shutdown()
    smp_send_stop()
    ...                   ipi_cpu_stop()
                           set_cpu_online(1, false)
                            local_irq_disable()
                             while(1)
    <PREEMPT>
cpu_up()
 _cpu_up()
   if (!cpu_online(1))
    __cpu_notify(CPU_UP_PREPARE...)

cpu_stop_cpu_callback()
  BUG_ON(stopper->thread)

This is easily reproducible by hotplugging in and out in a tight
loop while also rebooting.

Since the CPU is not really offline and hasn't gone through the
proper steps to be marked as such, let's mark the CPU as inactive.
This is just as easily testable as online and avoids any possibility
of _cpu_up() trying to bring the CPU back online when it never was
offline to begin with.

Change-Id: Ia1daea407220578d4212ef6c65c4be837ca370fd
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: 7536/1: smp: Formalize an IPI for wakeup

Remove the offset from ipi_msg_type and assume that SGI0 is the
wakeup interrupt now that all WFI hotplug users call
gic_raise_softirq() with 0 instead of 1. This allows us to
track how many wakeup interrupts are sent and also removes the
unknown IPI printk message for WFI hotplug based systems.

Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
arm: Use generic timer broadcast receiver

Currently, the ARM backend must maintain a redundant list of timers for
the purpose of centralising timer broadcast functionality. This prevents
sharing timer drivers across architectures.

This patch moves the pain of dealing with timer broadcasts to the core
clockevents tick broadcast code, which already maintains its own list
of timers.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ARM: use generic strnlen_user and strncpy_from_user functions

This patch implements the word-at-a-time interface for ARM using the
same algorithm as x86. We use the fls macro from ARMv5 onwards, where
we have a clz instruction available which saves us a mov instruction
when targetting Thumb-2. For older CPUs, we use the magic 0x0ff0001
constant. Big-endian configurations make use of the implementation from
asm-generic.

With this implemented, we can replace our byte-at-a-time strnlen_user
and strncpy_from_user functions with the optimised generic versions.

Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
modified for Mako from LKML reference

Signed-off-by: Paul Reioux <reioux@gmail.com>