binfmt_elf.c: use get_random_int() to fix entropy depleting

Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57
deadline: Allow 0ms deadline latency, increase the read speed

Change a timer compare from after to after-equals, thus allowing
0 timeout and making deadline schedule FIFO.

Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: flar2 <asegaert@gmail.com>

Change-Id: Ifed1cef6d6a31c3ed23dad03b567b3b9eddf3a57
net/l2tp: don't fall back on UDP [get|set]sockopt

The l2tp [get|set]sockopt() code has fallen back to the UDP functions
for socket option levels != SOL_PPPOL2TP since day one, but that has
never actually worked, since the l2tp socket isn't an inet socket.

As David Miller points out:

  "If we wanted this to work, it'd have to look up the tunnel and then
   use tunnel->sk, but I wonder how useful that would be"

Since this can never have worked so nobody could possibly have depended
on that functionality, just remove the broken code and return -EINVAL.

Change-Id: Ia6c09487e92d1ee4e8d1d22a6273034b22272a2f
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: James Chapman <jchapman@katalix.com>
Acked-by: David Miller <davem@davemloft.net>
Cc: Phil Turnbull <phil.turnbull@oracle.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ARM: introduce Kernel Mode NEON

ARM: move VFP init to an earlier boot stage

In order to use the NEON unit in the kernel, we should
initialize it a bit earlier in the boot process so NEON users
that like to do a quick benchmark at load time (like the
xor_blocks or RAID-6 code) find the NEON/VFP unit already
enabled.

Replaced late_initcall() with core_initcall().

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>

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

Conflicts:
	arch/arm/vfp/vfpmodule.c

ARM: be strict about FP exceptions in kernel mode

The support code in vfp_support_entry does not care whether the
exception that caused it to be invoked occurred in kernel mode or
in user mode. However, neither condition that could trigger this
exception (lazy restore and VFP bounce to support code) is
currently allowable in kernel mode.

In either case, print a message describing the condition before
letting the undefined instruction handler run its course and trigger
an oops.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
	arch/arm/vfp/vfpmodule.c

ARM: add support for kernel mode NEON

In order to safely support the use of NEON instructions in
kernel mode, some precautions need to be taken:
- the userland context that may be present in the registers (even
  if the NEON/VFP is currently disabled) must be stored under the
  correct task (which may not be 'current' in the UP case),
- to avoid having to keep track of additional vfpstates for the
  kernel side, disallow the use of NEON in interrupt context
  and run with preemption disabled,
- after use, re-enable preemption and re-enable the lazy restore
  machinery by disabling the NEON/VFP unit.

This patch adds the functions kernel_neon_begin() and
kernel_neon_end() which take care of the above. It also adds
the Kconfig symbol KERNEL_MODE_NEON to enable it.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
	arch/arm/vfp/vfpmodule.c

ARM: crypto: add NEON accelerated XOR implementation

Add a source file xor-neon.c (which is really just the reference
C implementation passed through the GCC vectorizer) and hook it
up to the XOR framework.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>

ARM: 7835/2: fix modular build of xor_blocks() with NEON enabled

Commit 0195659 introduced a NEON accelerated version of the xor_blocks()
function, but it needs the changes in this patch to allow it to be built
as a module rather than statically into the kernel.

This patch creates a separate module xor-neon.ko which exports the NEON
inner xor_blocks() functions depended upon by the regular xor.ko if it
is built with CONFIG_KERNEL_MODE_NEON=y

Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: only allow kernel mode neon with AEABI

This prevents the linker erroring with:

arm-linux-ld: error: arch/arm/lib/xor-neon.o uses VFP instructions, whereas arch/arm/lib/built-in.o does not
arm-linux-ld: failed to merge target specific data of file arch/arm/lib/xor-neon.o

This is due to the non-neon files being marked as containing FPA data/
instructions (even though they do not) being mixed with files which
contain VFP, which is an incompatible floating point format.

Change-Id: Ib86af25a348a07fac3ca3b688e02e885d4ce7ea0
defconfig: bacon: Enabled KERNEL_MODE_NEON

Change-Id: I247d418cbbff3157e7802367f0e19a31cb2c1148
exFAT support

Change-Id: I5a934b530fe688470b2f679d537e18672b7ee95f
Signed-off-by: flar2 <asegaert@gmail.com>
defconfig: bacon: Enabled exFat

Change-Id: I1aba05d35fb7f0e9c8460804787ed9d9f4ad3080
defconfig: bacon: Enabled NTFS support

Change-Id: I0f4c0fa5a5db83fab6c865c84861e1f479cf793e
cpufreq: intelliactive: initial coding and introduction!

intelliactive is based on Latest Google Interactive cpufreq governor from
Google.  The original Interactive provides smooth UI operations but suffers
slight battery drain due to its aggressive policies.  Intelliactive is an
improvement built on top of it.

It has the following enhancements added:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to
   max freq
3. Checks for offline cpus and short circuits some unnecessary checks to
   improve code execution paths
4. removed trace calls

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

Change-Id: I221b8c3d8d8509a992db914f28187ca759fa2213
intelliactive: fix race condition when unregistering input handlers

Change-Id: I7e6d60929e16b6cfb70c814ca8bc8368760eea1c
intelliactive: make touch boost interface generic

Change-Id: I1e6802154c5f343d1854e8edb967b40c6952085a
Add SmartMAX from maxwen's Oppo 8974 kernel

Change-Id: I78d7b0fa02a75989b47ba726572b02f629ea1187
sched: move task load based functions

The task load based functions will need to make use of LOAD_AVG_MAX
in a subsequent patch, so move them below the definition of that
macro.

Change-Id: I02f18ba069b81033e611f8f8bba6dccd7cd81252
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: Add min_max_freq and rq->max_possible_freq

rq->max_possible_freq represents the maximum frequency a cpu is
capable of attaining, while rq->max_freq represents the maximum
frequency a cpu can attain at a given instant. rq->max_freq includes
constraints imposed by user or thermal driver.
rq->max_freq <= rq->max_possible_freq.

max_possible_freq is derived as max(rq->max_possible_freq) and
represents the "best" cpu that can attain best possible frequency.

min_max_freq is derived as min(rq->max_possible_freq). For homogeneous
systems, max_possible_freq and min_max_freq will be same, while they
could be different on heterogeneous systems.

Change-Id: Iec485fde35cfd33f55ebf2c2dce4864faa2083c5
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sched: window-based load stats improvements

Following cleanups and improvements are made to window-based load
stats feature:

* Add sysctl to pick max, avg or most recent samples as task's
  demand.

* Fix overflow possibility in calculation of sum for average policy.

* Use unscaled statistics when a task is running on a CPU which is
thermally throttled.

Change-Id: I8293565ca0c2a785dadf8adb6c67f579a445ed29
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: vidc: flush queued work during device suspend

This change flushes any queued work related to power collapse,
once the device is power suspended.
There are applications which do not destroy video instance
on suspending the device. For such applications, if the device
is power suspended, video driver does not prepare venus for
power collapse.
Considerable power saving is observed by power collapsing
venus before the device goes in suspend state.

Change-Id: I11252e45b10d0d3d3eefb38994acd083c847bbb8
msm: vidc: reduce clk frquency before disable

The change ensures that the clock frequency is reduced to min
before we disable it.
With just clk_disable, rpm still votes for high voltage on CX
as venus vote is not removed.
To unvote, the frequency is set to min.

CRs-Fixed: 574365
Change-Id: I8e0515b9816f8c451d545443573afaba611aafe7
Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: vidc: handle dynamic buffers in pendingq during flush

In dynamic buffer mode, if flush was received before
stream-on, driver would have incremented the ref count
for output buffers, but not yet sent to firmware. So,
after flush done, there would be no fbd from firmware
and the reference to these buffers would not be removed.
So when the buffers are dequeued, driver fails to
unmap and free the output buffers.
Subsequently, after flush done, when client queues
the same output buffers again to driver, the ref
count is increased and becomes 2. This results in
the driver holding the buffers with itself, thereby
entering in to a deadlock situation and starving the
firmware of output buffers. This results in a video
freeze.

Change-Id: I0c3d13124bd48b900e56e14666eaed2f0e7ee9d6
input: touch: synaptics: Reset the device when blanking display

This should be backed out as soon as fixed firmware becomes available!

Something is iffy with the controller that gets triggered under
certain environmental conditions and makes it hang or register ghost
touches for a few minutes. Instead of waiting for it to fix itself,
have the controller forcefully reset whenever the panel is cycled so
a manual recovery is possible.

This is not a fix or a workaround, just a recovery mechanism :(

Change-Id: I39a3ab99b9c5701eed047d125ffa12ea459ebae9
Linaro 4.8 fixes

Change-Id: I3171443c7cf3e8364392c8a5223802f10a3659a3