msm: don't build mpdecision
cpufreq: interactive: Optimize sync_freq implementation

Don't let frequency drop below sync_freq if either load or
frequency among other cpus is above a certain threshold,
not necessarily both.

Change-Id: Iada28e08e812498e16d5189b309a7314f88814dd
cpufreq: interactive: Fix race in sync freq feature

When we switch to the interactive governor, the kernel will panic
because the policy object is NULL on affected cpus. Add a check to
avoid this situation.

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: fix merge error
Revert "lzo: properly check for overruns"

This reverts commit ("lzo: properly check for overruns").

As analysed by Willem Pinckaers, this fix is still incomplete on
certain rare corner cases, and it is easier to restart from the
original code.

Reported-by: Willem Pinckaers <willem@lekkertech.net>
Cc: "Don A. Bailey" <donb@securitymouse.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
lzo: check for length overrun in variable length encoding.

This fix ensures that we never meet an integer overflow while adding
255 while parsing a variable length encoding. It works differently from
commit 206a81c ("lzo: properly check for overruns") because instead of
ensuring that we don't overrun the input, which is tricky to guarantee
due to many assumptions in the code, it simply checks that the cumulated
number of 255 read cannot overflow by bounding this number.

The MAX_255_COUNT is the maximum number of times we can add 255 to a base
count without overflowing an integer. The multiply will overflow when
multiplying 255 by more than MAXINT/255. The sum will overflow earlier
depending on the base count. Since the base count is taken from a u8
and a few bits, it is safe to assume that it will always be lower than
or equal to 2*255, thus we can always prevent any overflow by accepting
two less 255 steps.

This patch also reduces the CPU overhead and actually increases performance
by 1.1% compared to the initial code, while the previous fix costs 3.1%
(measured on x86_64).

The fix needs to be backported to all currently supported stable kernels.

Reported-by: Willem Pinckaers <willem@lekkertech.net>
Cc: "Don A. Bailey" <donb@securitymouse.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Documentation: lzo: document part of the encoding

Add a complete description of the LZO format as processed by the
decompressor. I have not found a public specification of this format
hence this analysis, which will be used to better understand the code.

Cc: Willem Pinckaers <willem@lekkertech.net>
Cc: "Don A. Bailey" <donb@securitymouse.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
arm/dts: togari: lower vibrator voltage to 2900 mV
This time the right one.
qpnp-vibrator: lower vibrator voltage
msm: pm: Fix cpu collapse timeout

Looks like caf mismerged. This may fix the following warning:

<4>[  124.983957] ------------[ cut here ]------------
<4>[  124.984381] WARNING: at arch/arm/mach-msm/msm-pm.c:837 msm_pm_wait_cpu_shu
tdown+0x9c/0xb0()
<4>[  124.984661] CPU2 didn't collapse in 2 ms
<4>[  124.984869] [<c010e10c>] (unwind_backtrace+0x0/0x144) from [<c0a1c68c>] (d
ump_stack+0x20/0x24)
<4>[  124.985170] [<c0a1c68c>] (dump_stack+0x20/0x24) from [<c019ab44>] (warn_sl
owpath_common+0x58/0x70)
<4>[  124.985464] [<c019ab44>] (warn_slowpath_common+0x58/0x70) from [<c019abd8>
] (warn_slowpath_fmt+0x40/0x48)
<4>[  124.985943] [<c019abd8>] (warn_slowpath_fmt+0x40/0x48) from [<c0179d30>] (
msm_pm_wait_cpu_shutdown+0x9c/0xb0)
<4>[  124.986287] [<c0179d30>] (msm_pm_wait_cpu_shutdown+0x9c/0xb0) from [<c0126
750>] (platform_cpu_kill+0x38/0x48)
<4>[  124.986591] [<c0126750>] (platform_cpu_kill+0x38/0x48) from [<c010c6fc>] (
__cpu_die+0x4c/0x98)
<4>[  124.986778] [<c010c6fc>] (__cpu_die+0x4c/0x98) from [<c09ee9cc>] (_cpu_dow
n+0xf8/0x2e0)
<4>[  124.987074] [<c09ee9cc>] (_cpu_down+0xf8/0x2e0) from [<c09eec58>] (cpu_dow
n+0x34/0x50)
<4>[  124.987383] [<c09eec58>] (cpu_down+0x34/0x50) from [<c0194250>] (cpu_down_
work+0xc4/0xd8)
<4>[  124.987564] [<c0194250>] (cpu_down_work+0xc4/0xd8) from [<c01b4e44>] (proc
ess_one_work+0x178/0x4f4)
<4>[  124.987861] [<c01b4e44>] (process_one_work+0x178/0x4f4) from [<c01b5540>]
(worker_thread+0x174/0x448)
<4>[  124.988152] [<c01b5540>] (worker_thread+0x174/0x448) from [<c01bb8ac>] (kt
hread+0xb4/0xc0)
<4>[  124.988450] [<c01bb8ac>] (kthread+0xb4/0xc0) from [<c0108060>] (kernel_thr
ead_exit+0x0/0x8)
<4>[  124.988725] ---[ end trace 77427e632785e345 ]---

Change-Id: I40ea4459f333d44b3f1f11ebcec85466a896d974
lib/int_sqrt.c: optimize square root algorithm

Optimize the current version of the shift-and-subtract (hardware)
algorithm, described by John von Newmann[1] and Guy L Steele.

Iterating 1,000,000 times, perf shows for the current version:

 Performance counter stats for './sqrt-curr' (10 runs):

         27.170996 task-clock                #    0.979 CPUs utilized            ( +-  3.19% )
                 3 context-switches          #    0.103 K/sec                    ( +-  4.76% )
                 0 cpu-migrations            #    0.004 K/sec                    ( +-100.00% )
               104 page-faults               #    0.004 M/sec                    ( +-  0.16% )
        64,921,199 cycles                    #    2.389 GHz                      ( +-  0.03% )
        28,967,789 stalled-cycles-frontend   #   44.62% frontend cycles idle     ( +-  0.18% )
   <not supported> stalled-cycles-backend
       104,502,623 instructions              #    1.61  insns per cycle
                                             #    0.28  stalled cycles per insn  ( +-  0.00% )
        34,088,368 branches                  # 1254.587 M/sec                    ( +-  0.00% )
             4,901 branch-misses             #    0.01% of all branches          ( +-  1.32% )

       0.027763015 seconds time elapsed                                          ( +-  3.22% )

And for the new version:

Performance counter stats for './sqrt-new' (10 runs):

          0.496869 task-clock                #    0.519 CPUs utilized            ( +-  2.38% )
                 0 context-switches          #    0.000 K/sec
                 0 cpu-migrations            #    0.403 K/sec                    ( +-100.00% )
               104 page-faults               #    0.209 M/sec                    ( +-  0.15% )
           590,760 cycles                    #    1.189 GHz                      ( +-  2.35% )
           395,053 stalled-cycles-frontend   #   66.87% frontend cycles idle     ( +-  3.67% )
   <not supported> stalled-cycles-backend
           398,963 instructions              #    0.68  insns per cycle
                                             #    0.99  stalled cycles per insn  ( +-  0.39% )
            70,228 branches                  #  141.341 M/sec                    ( +-  0.36% )
             3,364 branch-misses             #    4.79% of all branches          ( +-  5.45% )

       0.000957440 seconds time elapsed                                          ( +-  2.42% )

Furthermore, this saves space in instruction text:

   text    data     bss     dec     hex filename
    111       0       0     111      6f lib/int_sqrt-baseline.o
     89       0       0      89      59 lib/int_sqrt.o

[1] http://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC

Signed-off-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Reviewed-by: Jonathan Gonzalez <jgonzlez@linets.cl>
Tested-by: Jonathan Gonzalez <jgonzlez@linets.cl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[v4] binfmt_elf.c: use get_random_int() to fix entropy depleting
Entropy is quickly depleted under normal operations like ls(1), cat(1),
etc...  between 2.6.30 to current mainline, for instance:

$ cat /proc/sys/kernel/random/entropy_avail
3428
$ cat /proc/sys/kernel/random/entropy_avail
2911
$cat /proc/sys/kernel/random/entropy_avail
2620

We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by
f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").

/*
 * Generate 16 random bytes for userspace PRNG seeding.
 */
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));

The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.

With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878

Analyzed by John Sobecki.

Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <aedilger@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Arnd Bergmann <arnn@arndb.de>
Cc: John Sobecki <john.sobecki@oracle.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ulrich Drepper <drepper@redhat.com>
AIO: Don't plug the I/O queue in do_io_submit() Asynchronous I/O latency to a solid-state disk greatly increased between the 2.6.32 and 3.0 kernels. By removing the plug from do_io_submit(), we observed a 34% improvement in the I/O latency.

Unfortunately, at this level, we don't know if the request is to
a rotating disk or not.

Change-Id: I7101df956473ed9fd5dcff18e473dd93b688a5c1
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: linux-aio@kvack.org
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
mm: slub: Default slub_max_order to 0

To avoid locking and per-cpu overhead, SLUB optimisically uses
high-order allocations up to order-3 by default and falls back to
lower allocations if they fail. While care is taken that the caller
and kswapd take no unusual steps in response to this, there are
further consequences like shrinkers who have to free more objects to
release any memory. There is anecdotal evidence that significant time
is being spent looping in shrinkers with insufficient progress being
made (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.

SLUB is now the default allocator and some bug reports have been
pinned down to SLUB using high orders during operations like
copying large amounts of data. SLUBs use of high-orders benefits
applications that are sized to memory appropriately but this does not
necessarily apply to large file servers or desktops.  This patch
causes SLUB to use order-0 pages like SLAB does by default.
There is further evidence that this keeps kswapd's usage lower
(https://lkml.org/lkml/2011/5/10/383).

Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire. From http://ripke.com/loadavg/moire

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mdss: Add fb status helper
qpnp-pon: Add POnKey Emulator

I hope that my power-on key will last longer.

Also, preparing API for S2W stuff..

Signed-off-by: cocafe <cocafehj@gmail.com>
wcd9320: Wakeup on plugging headset

Signed-off-by: cocafe <cocafehj@gmail.com>
touchscreen: initial import of s2w/s2s from showp1984
s2w/s2s: adapt for togari