x3: Updates for latest KitKat support

Squashed commit of the following:

commit 6add3ee16507190b3650f0ee6a84f4f25349bac6
Author: Adam77Root <adam77root@gmail.com>
Date:   Fri Jun 27 15:37:10 2014 +0200

    defconfig: enable some recommended Android settings

commit 8017d5472cf562ce3f6abfa487e731a7d696e408
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Aug 7 23:39:41 2013 +0100

    ARM: 7809/1: perf: fix event validation for software group leaders

    It is possible to construct an event group with a software event as a
    group leader and then subsequently add a hardware event to the group.
    This results in the event group being validated by adding all members
    of the group to a fake PMU and attempting to allocate each event on
    their respective PMU.

    Unfortunately, for software events wthout a corresponding arm_pmu, this
    results in a kernel crash attempting to dereference the ->get_event_idx
    function pointer.

    This patch fixes the problem by checking explicitly for software events
    and ignoring those in event validation (since they can always be
    scheduled). We will probably want to revisit this for 3.12, since the
    validation checks don't appear to work correctly when dealing with
    multiple hardware PMUs anyway.

    Cc: <stable@vger.kernel.org>
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Tested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

    Conflicts:
    	arch/arm/kernel/perf_event.c

commit cc37e41e0de0c577f2e245f9d916c4238be14ed5
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Fri May 10 10:16:19 2013 -0400

    Enable setting security contexts on rootfs inodes.

    rootfs (ramfs) can support setting of security contexts
    by userspace due to the vfs fallback behavior of calling
    the security module to set the in-core inode state
    for security.* attributes when the filesystem does not
    provide an xattr handler.  No xattr handler required
    as the inodes are pinned in memory and have no backing
    store.

    This is useful in allowing early userspace to label individual
    files within a rootfs while still providing a policy-defined
    default via genfs.

    Change-Id: I95d287398508aacb706544bdbfa58c104a8fe5df
    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>

commit c3a23709818fe04db0585d05f3a8e030ecfca33b
Author: demetris <demetris@walla.com>
Date:   Sat Dec 7 17:57:41 2013 +0200

    Disabling tegra auto hotplug

commit 8f3f8c8e581d04a2917a083ad1f671b3c43fded3
Author: laufersteppenwolf <laufersteppenwolf@gmail.com>
Date:   Sat Dec 7 16:10:56 2013 +0100

    Fix cpuquiet

    Change-Id: Iab632949fe559d46b5aa749fd26f6261d06eec41

commit 6cdb7e12749f51cb5fecf9be406fa8e977bd9d0a
Author: demetris <demetris@walla.com>
Date:   Sat Dec 7 16:04:29 2013 +0200

    Corrected wifi firmware path

commit b5a170c0f007e8f5a2fd4644df19d4b9b86ec3af
Author: demetris <demetris@walla.com>
Date:   Sat Dec 7 10:17:54 2013 +0200

    Add cpuquiet configs

commit 3635e245f8f876d22fd07d89223257b8f3022e65
Author: Timothy Nelson <nelson.ecp@gmail.com>
Date:   Wed Jan 9 00:42:11 2013 -0800

    board/cpu-tegra3: Additional runnable threat edits necessary for compilation option

    Change-Id: I1fa2fab02582e987314ae7e23342c09c78d042af

commit 0170449140cbcb643d1c2a82f3ba9d70c3d8ea10
Author: faux123 <reioux@gmail.com>
Date:   Sun Sep 9 10:59:41 2012 -0700

    cpuquiet/governors/balanced: make runnable thread as a compilation option

commit 01a9e3864a4952c0865aa95878210c44cffed3f0
Author: faux123 <reioux@gmail.com>
Date:   Sun Sep 9 10:47:31 2012 -0700

    board/cpu-tegra3: make runnable thread as a compilation option

    Conflicts:
    	arch/arm/mach-tegra/cpu-tegra3.c

    Change-Id: I6901002cdc792877651137fa5588ca7e0dd86bed

commit 1766389bbfba5d246b2e2e28c867b860e60624b0
Author: faux123 <reioux@gmail.com>
Date:   Sun Sep 23 08:36:46 2012 -0700

    drivers/cpuquiet/governors: make balanced as default governor

commit a5b80ad45ac5a54d43d644523904dac4d497858c
Author: faux123 <reioux@gmail.com>
Date:   Wed Sep 12 20:34:44 2012 -0500

    drivers/cpuquiet/governors/runnable_threads: fix typo derp

commit 1c4d7323ee582f335c4e50ba34631d1de5638014
Author: Sai Charan Gurrappadi <sgurrappadi@nvidia.com>
Date:   Fri Aug 24 18:09:57 2012 -0700

    cpuquiet: Add notifiers for the runnables governor

    The governor stops sampling whenever the device is busy and starts its
    sampling loop when the device is free.

    Change-Id: I6b4dae94a60f8091d34400028a8d1f58faa51380
    Signed-off-by: Sai Charan Gurrappadi <sgurrappadi@nvidia.com>

commit a97aea817dc758cc347ff68011bd514a00cd6492
Author: Sai Charan Gurrappadi <sgurrappadi@nvidia.com>
Date:   Wed Jul 25 08:37:14 2012 -0700

    cpuquiet: Runnable threads governor

    [perf] The runnable threads governor only looks at the average number of
    runnables in the system to make a decision when bringing cores
    offline/online. First pass; tweaks thresholds and delays to reduce
    decision latency to about ~50-70ms per core (from ~100-150ms per core)

    Change-Id: Idd3b268a74a8f56ad3fc0e5c7f388174d1b6611f
    Signed-off-by: Sai Charan Gurrappadi <sgurrappadi@nvidia.com>

commit b17d66e8912ed746825c199b99d2aebd7f073466
Author: Sai Charan Gurrappadi <sgurrappadi@nvidia.com>
Date:   Wed Jul 25 11:16:08 2012 -0700

    ARM: tegra: cpuquiet: Fix cpuquiet notifiers

    The notifiers now properly fire on every cluster switch

    Change-Id: I381301cf62f25b49532326cc7759696c7f6797b7
    Signed-off-by: Sai Charan Gurrappadi <sgurrappadi@nvidia.com>

commit 5618e2426d12ede7e8bba0b14356ddbfeeab39a1
Author: Sai Charan Gurrappadi <sgurrappadi@nvidia.com>
Date:   Tue Jul 10 17:33:58 2012 -0700

    ARM: tegra: cpuquiet: Notify the cpuquiet governor when the driver is busy

    Added generic busy/free notifiers that the driver can invoke to let the
    governor know that it cannot process further core online/offline
    requests (invoked in our case whenever we switch to the LP cluster).

    Change-Id: I5e3f7f28f38806a7f87050e8d0c8d2f2cf7521aa
    Signed-off-by: Sai Charan Gurrappadi <sgurrappadi@nvidia.com>

    Conflicts:
    	arch/arm/mach-tegra/cpuquiet.c

commit 1ec4fbdb69f6871a4b23e15a30635116f105c631
Author: faux123 <reioux@gmail.com>
Date:   Tue Sep 4 07:49:52 2012 -0700

    kernel/sys: cpuquiet compatibility fixup

    Change-Id: I6af61aee8df5fe2de07c40b7711fd8cbf44ca6f7

    Conflicts:
    	kernel/sys.c

commit a32065f4ec0f39e4e3d94a4f447596311352dc2e
Author: Adam77Root <adam77root@gmail.com>
Date:   Sun Mar 30 18:55:14 2014 +0200

    kexec-HB support for X3

commit d7f10c5a8b04d63b3edee059cec229152f47fa54
Author: Vojtech Bocek <vbocek@gmail.com>
Date:   Wed Aug 21 00:24:35 2013 +0200

    Kexec-hardboot: speed-up atags copying in host kernel

    * _now_ I know atags are always at least 32b aligned

commit 9b535b1b8b4a845c35ce0dcd224a6185adba9b70
Author: Vojtech Bocek <vbocek@gmail.com>
Date:   Wed Aug 21 00:06:19 2013 +0200

    Backport arch/arm/kernel/atags.c from 3.10 (for kexec-hardboot)

    * There is a bug in older kernels, causing kexec-tools binary to
      only read first 1024 bytes from /proc/atags. I guess the bug is
      somewhere in /fs/proc/, since I don't think the callback in atags.c
      does something wrong. It might affect all procfs files using that
      old read callback instead of fops. Doesn't matter though, since it
      was accidentally fixed when 3.10 removed it.

    * This has no particular effect on grouper, because the atags are
      organized "just right" (most important tags are near beginning,
      the ones at the end are some useless nvidia-specific tags), but
      it might be very hard to track down on a device where it causes
      problems.

    Signed-off-by: Vojtech Bocek <vbocek@gmail.com>

commit 2a52d73eef7f7b6b1d4f095c82ccd711a9a2848a
Author: Vojtech Bocek <vbocek@gmail.com>
Date:   Tue Aug 20 20:57:16 2013 +0200

    Kexec-hardboot: Copy atags for guest kernel in the host before jumping

    * This removes the need to patch the guest kernel

commit 2c2fe207234eaee87f4673036024e0c3bfc575bc
Author: Vojtech Bocek <vbocek@gmail.com>
Date:   Tue Aug 20 20:56:34 2013 +0200

    Make config option to choose hardboot restart mode (normal or recovery)

    Conflicts:
    	arch/arm/mach-tegra/Kconfig

    Conflicts:
    	arch/arm/configs/tegra_p1852_android_defconfig

commit 192dc48bbe9e5d469e8371ee04c1ea6230553ef1
Author: Mike Kasick <mike@kasick.org>
Date:   Tue Aug 20 20:50:17 2013 +0200

    Add support for kexec-hardboot

    "Allows hard booting (i.e., with a full hardware reboot) to a kernel
    previously loaded in memory by kexec.  This works around the problem of
    soft-booted kernel hangs due to improper device shutdown and/or
    reinitialization."
    More info in /arch/arm/Kconfig.

    Original author: Mike Kasick <mike@kasick.org>
    These patches are ported from Asus TF201, to which it
    was ported by Jens Andersen <jens.andersen@gmail.com>.

    Conflicts:
    	arch/arm/boot/compressed/misc.c

    Conflicts:
    	arch/arm/configs/tegra_p1852_android_defconfig

commit 6a2bcbd02c48c8e255de58a75e2e5c8454f0e2be
Author: demetris <demetris@walla.com>
Date:   Sat Dec 7 09:54:38 2013 +0200

    X3:net: wireless: bcmdhd: enable 5ghz support

commit 859c5c24c3cda49e0cbe1132b61b8a41151d45d0
Author: Ricardo Cerqueira <cyanogenmod@cerqueira.org>
Date:   Fri Mar 7 15:22:45 2014 +0000

    lge_touch_core: Allow disabling the nav keys

    Change-Id: Id1119ca4bd89db46effe8c57d1a4ccb27199c80b

commit b2cc5c22a79d2208c67e21f00fb57dc237447a84
Author: demetris <demetris@walla.com>
Date:   Fri Dec 6 02:02:32 2013 +0200

    This fixes MHL output always being in vertical position

    Change-Id: I8a58097bd90b79b416d4facabe4747b0dfe5188e

commit ea29ee0301c60fa1b27da3aa0002fe4a888056bf
Author: demetris <ierokipides.dem@gmail.com>
Date:   Fri Feb 7 14:13:02 2014 +0200

    Add support for OUYA Wireless Bluetooth Controller

    Change-Id: I0b3a941288df1f0e3aa1ad40ba1897bf570d2cf5

commit b6a0cfa55b538b2ecd7ad7333edfc7c724fce5de
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Mon Mar 12 02:59:41 2012 +0000

    tun: don't hold network namespace by tun sockets

    v3: added previously removed sock_put() to the tun_release() callback, because
    sk_release_kernel() doesn't drop the socket reference.

    v2: sk_release_kernel() used for socket release. Dummy tun_release() is
    required for sk_release_kernel() ---> sock_release() ---> sock->ops->release()
    call.

    TUN was designed to destroy it's socket on network namesapce shutdown. But this
    will never happen for persistent device, because it's socket holds network
    namespace.
    This patch removes of holding network namespace by TUN socket and replaces it
    by creating socket in init_net and then changing it's net it to desired one. On
    shutdown socket is moved back to init_net prior to final put.

    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 751eeb43a4df1ab2391614f6d8a1b138c593f299
Author: iodak <o93.ivan@gmail.com>
Date:   Tue Jan 7 09:07:57 2014 +0100

    sound: soc: tegra: raise audio gain by 50%

    Change-Id: I373f04c1bdbba02bace322d488a95ac7ea693b08

commit 6795a8f6c2724777ebdbde31e94973f9d0cf38c2
Author: iodak <o93.ivan@gmail.com>
Date:   Fri Jan 10 21:30:05 2014 +0100

    arm: tegra: xmm: fix for kernel panic on xmm on/off

    when baseband_xmm_power_switch is called or enumeration did not complete properly,
    there is kernel panic because of extra unregister-ehci device
    so set to null in uregister

    Change-Id: I8dec553a7310c2b0bc2ceb6c4fca5e28f5b39e7a

commit 9e169bc9e6c2b1593870a4272193f5381d2008b4
Author: iodak <o93.ivan@gmail.com>
Date:   Mon Dec 30 13:30:59 2013 +0100

    x3: updated to work with new baseband driver

    Change-Id: I6d1d81b4b3fc5c070d0ef735775607782542764f

commit da8e6fa63792f2a1bebebec0e727bc4782309bc5
Author: iodak <o93.ivan@gmail.com>
Date:   Mon Dec 30 12:53:47 2013 +0100

    tegra: baseband: update to latest from 3.4 tegra kernel

    small changes to make it work on x3
    removed unused tegra_baseband_rail_on/off
    added xmm_onoff function from LG

    Change-Id: I311ee7b7daff2eb4124b9d4a831c4790fedaea17

commit 4704c68987f8e2965cf9070868f68876296a4271
Author: iodak <o93.ivan@gmail.com>
Date:   Fri Dec 13 21:36:19 2013 +0100

    arm: x3: board-x3-baseband clean up

    This commit is the first of a series trying to combat
    out battery depletion by baseband wakelock.
    Change-Id: I4e21e8bcde3b8b7c6468114933387104ed32a640

commit 4ca5b1e726f82f139564452687887324c144c079
Author: ks.kwon <ks.kwon@lge.com>
Date:   Tue Aug 7 13:50:18 2012 +0900

    X3:touch:reset_pin control during touch power control.

    Commit taken from mako kernel source by iodak

    This commit is to assert/de-assert reset signal during suspend/resume.
    Without this commit, there is a 2~3mA of leakage current from reset pin
    to touch contorller IC.

    Change-Id: I32717412b1dec13996aa986c7939c76dd6453ebb

commit 21b40c428070894fa15b9b4ce94a8b14c02aaa86
Author: Pontus Fuchs <pontus.fuchs@gmail.com>
Date:   Mon Nov 19 11:44:51 2012 -0800

    netfilter: qtaguid: Don't BUG_ON if create_if_tag_stat fails

    If create_if_tag_stat fails to allocate memory (GFP_ATOMIC) the
    following will happen:

    qtaguid: iface_stat: tag stat alloc failed
    ...
    kernel BUG at xt_qtaguid.c:1482!

    Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
    Change-Id: Ia156bc63b99089cbccab18c9ad69f40d423b623a

commit 9c692b3f38dd2dec9de2b8a0936105f71a789f76
Author: JP Abgrall <jpa@google.com>
Date:   Tue Oct 9 20:38:21 2012 -0700

    netfilter: xt_qtaguid: fix error exit that would keep a spinlock.

    qtudev_open() could return with a uid_tag_data_tree_lock held
    when an kzalloc(..., GFP_ATOMIC) would fail.
    Very unlikely to get triggered AND survive the mayhem of running out of mem.

    Signed-off-by: JP Abgrall <jpa@google.com>
    Change-Id: Id39ae3452a203346a68906bf9c40869d7331fd95

commit 372edbb3412aa4869dad702adca0c150227f6e48
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Thu Nov 15 14:01:44 2012 -0500

    Fix security_binder_transfer_binder hook.

    Drop the owning task argument to security_binder_transfer_binder
    since ref->node->proc can be NULL (dead owner?).
    Revise the SELinux checking to apply a single transfer check between
    the source and destination tasks.  Owning task is no longer relevant.
    Drop the receive permission definition as it is no longer used.

    This makes the transfer permission similar to the call permission; it is only
    useful if you want to allow a binder IPC between two tasks (call permission)
    but deny passing of binder references between them (transfer permission).

    Signed-off-by: Ed Tam <etam@google.com>
    Change-Id: Ic3800dd3aed3629ff54ff95ed0dc97b7b38a613b

commit 2590fc52640901081fe85cfa6afdef7759d4d11c
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Mon Dec 19 16:44:10 2011 -0500

    Add permission checking for binder IPC.

    Signed-off-by: Ed Tam <etam@google.com>
    Change-Id: Ibb29fb641b8119db61e84c1d8ad7e0f61b357c6b

commit d4ba267cb856e313cdf36b693c77435a42b9a8d9
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Feb 19 14:56:53 2013 +0100

    wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task

    wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
    Change it to use TASK_NORMAL and add the WARN_ON().

    TASK_ALL has no other users, probably can be killed.

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ed Tam <etam@google.com>
    Change-Id: I58ab37ae11a983673e26deaff5193f381974f336

commit 949d180ca0c8853491fc3097b04a34047e60ae45
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Feb 19 14:56:52 2013 +0100

    ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL

    putreg() assumes that the tracee is not running and pt_regs_access() can
    safely play with its stack.  However a killed tracee can return from
    ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
    that debugger can actually read/modify the kernel stack until the tracee
    does SAVE_REST again.

    set_task_blockstep() can race with SIGKILL too and in some sense this
    race is even worse, the very fact the tracee can be woken up breaks the
    logic.

    As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
    call, this ensures that nobody can ever wakeup the tracee while the
    debugger looks at it.  Not only this fixes the mentioned problems, we
    can do some cleanups/simplifications in arch_ptrace() paths.

    Probably ptrace_unfreeze_traced() needs more callers, for example it
    makes sense to make the tracee killable for oom-killer before
    access_process_vm().

    While at it, add the comment into may_ptrace_stop() to explain why
    ptrace_stop() still can't rely on SIGKILL and signal_pending_state().

    Reported-by: Salman Qazi <sqazi@google.com>
    Reported-by: Suleiman Souhlal <suleiman@google.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ed Tam <etam@google.com>
    Change-Id: Ice05797d8f4a98d1e7bac26304e106050962fdee

commit 5c315a7cf727edf89b711412066ed12af033437e
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Feb 19 14:56:51 2013 +0100

    ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()

    Cleanup and preparation for the next change.

    signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
    actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
    necessary mask.

    Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
    signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
    which adds __TASK_TRACED.

    This way ptrace_signal_wake_up() can work "inside" ptrace_request()
    even if the tracee doesn't have the TASK_WAKEKILL bit set.

    Change-Id: I4d9d918696d42332db34228478d59b7cd8a3c5dc

commit 5395348ad51a363db4dcb7f65007fc36506c0cf3
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Sep 7 18:22:28 2012 +0100

    ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS

    The {get,put}_user macros don't perform range checking on the provided
    __user address when !CPU_HAS_DOMAINS.

    This patch reworks the out-of-line assembly accessors to check the user
    address against a specified limit, returning -EFAULT if is is out of
    range.

    [will: changed get_user register allocation to match put_user]
    [rmk: fixed building on older ARM architectures]

    Change-Id: I11f883c7d0c6f2464395104f99b66200ca62dbe2

commit a4899b146f7bfc3ec558c332a76ccfc89f132537
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Wed Jan 25 11:38:13 2012 +0100

    ARM: 7301/1: Rename the T() macro to TUSER() to avoid namespace conflicts

    This macro is used to generate unprivileged accesses (LDRT/STRT) to user
    space.

    Change-Id: I437b29aa989fce232e428859af7d28222d943353

commit e7e06a04645788c4b49bdda10bcb3b5fb428f90d
Author: Lorenzo Colitti <lorenzo@google.com>
Date:   Thu Jul 4 00:12:40 2013 +0900

    net: ipv6: fix wrong ping_v6_sendmsg return value

    [net-next commit fbfe80c890a1dc521d0b629b870e32fcffff0da5]

    ping_v6_sendmsg currently returns 0 on success. It should return
    the number of bytes written instead.

    Bug: 9469865
    Change-Id: I86eb936e06bf8582975d59597e48e2bcc53b958d

commit 59ea0c9faeaf47a77c911cccbe085a75993cc2b8
Author: Lorenzo Colitti <lorenzo@google.com>
Date:   Thu Jul 4 00:52:49 2013 +0900

    net: ipv6: add missing lock in ping_v6_sendmsg

    [net-next commit a1bdc45580fc19e968b32ad27cd7e476a4aa58f6]

    Bug: 9469865
    Change-Id: I7ae28d29c645c535e570eb8d12f45e8eafd9c70b

commit ba90191f106463fbd54191cb9a769d1f251d8190
Author: Jon Mayo <jmayo@nvidia.com>
Date:   Sat May 4 01:54:35 2013 +0800

    video: tegra: avoid null deref on nvdps read

    When reading nvdps sysfs file, check mode to avoid a null dereference.

    Bug 1032235
    Bug 1283024

    Change-Id: I19b3b5b3de6743cdcc9e3a846a4ba102de681ad3
    Signed-off-by: Haley Teng <hteng@nvidia.com>

commit 1af852915f80fde43791349df9ebfbc1fa602b26
Author: demetris <ierokipides.dem@gmail.com>
Date:   Sun Feb 2 20:48:36 2014 +0200

    Clean up X3 panel mess

    Change-Id: If9d3ef4e35129333123b2576e904dcf21010db32

commit 1edb386e3783dc31b009b7b539bc121c779ac9a1
Author: Ricardo Cerqueira <cyanogenmod@cerqueira.org>
Date:   Sun Feb 2 22:37:22 2014 +0000

    x3-reboot: Always use the MAX77663_SCRATCH_REG_BL_UNLOCK register for fastboot

    The MAX77663_SCRATCH_REG_BOOTLOADER register replies to fastboot, but
    doesn't accept write commands

    Change-Id: I7a78ab1f047e17796c3b67783f323ca5886775f3

commit 815256a7dfbd8547edb4131f7c2aa5dd0c8aa9c0
Author: demetris <ierokipides.dem@gmail.com>
Date:   Sun Feb 2 20:32:54 2014 +0200

    apds990x: setting near value to be 0 and fix 10 value.
    This should fix all proximity problems we have

    Change-Id: Icf007dc2548baa6ebf959a32e47fecfa1443919d

commit 6ae80fb10f255e2c3c12d43c413fbdcb752b242d
Author: Ricardo Cerqueira <cyanogenmod@cerqueira.org>
Date:   Fri Jan 31 23:34:11 2014 +0000

    gpio_keys: Remove triplicate reporting of wakeups...

    Wake keys were being triggered 3 times on wake, causing a
    ON/OFF/ON sequence: The key itself, once when disabling irqwake,
    and then once more as a gpio event. If one of the events
    was lost for some reason (like debouncing pauses), we'd
    end up with "ON/OFF", and the device wouldn't actually turn
    on.
    Get rid of the 2 superfluous reports.

    Change-Id: Ic49fbe8d0cdaa8138ace069b784a68b5ad6f7afc

commit 138f7fc2a300255e214393bfbb932104e9888828
Author: Ricardo Cerqueira <cyanogenmod@cerqueira.org>
Date:   Fri Jan 3 03:39:20 2014 +0000

    nvcd: Enable didim

    Change-Id: Ifdb5b40ca055345dbf853186146adc038e168a0d

commit ffcaddb692c08624ebaa832093e57f268acdc3c3
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 3 12:27:08 2014 +0000

    futex: Make lookup_pi_state more robust

    The current implementation of lookup_pi_state has ambigous handling of
    the TID value 0 in the user space futex. We can get into the kernel
    even if the TID value is 0, because either there is a stale waiters
    bit or the owner died bit is set or we are called from the requeue_pi
    path or from user space just for fun.

    The current code avoids an explicit sanity check for pid = 0 in case
    that kernel internal state (waiters) are found for the user space
    address. This can lead to state leakage and worse under some
    circumstances.

    Handle the cases explicit:

         Waiter | pi_state | pi->owner | uTID      | uODIED | ?

    [1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
    [2]  NULL   | ---      | ---       | >0        | 0/1    | Valid

    [3]  Found  | NULL     | --        | Any       | 0/1    | Invalid

    [4]  Found  | Found    | NULL      | 0         | 1      | Valid
    [5]  Found  | Found    | NULL      | >0        | 1      | Invalid

    [6]  Found  | Found    | task      | 0         | 1      | Valid

    [7]  Found  | Found    | NULL      | Any       | 0      | Invalid

    [8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
    [9]  Found  | Found    | task      | 0         | 0      | Invalid
    [10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid

    [1]  Indicates that the kernel can acquire the futex atomically. We
         came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.

    [2]  Valid, if TID does not belong to a kernel thread. If no matching
         thread is found then it indicates that the owner TID has died.

    [3]  Invalid. The waiter is queued on a non PI futex

    [4]  Valid state after exit_robust_list(), which sets the user space
         value to FUTEX_WAITERS | FUTEX_OWNER_DIED.

    [5]  The user space value got manipulated between exit_robust_list()
         and exit_pi_state_list()

    [6]  Valid state after exit_pi_state_list() which sets the new owner in
         the pi_state but cannot access the user space value.

    [7]  pi_state->owner can only be NULL when the OWNER_DIED bit is set.

    [8]  Owner and user space value match

    [9]  There is no transient state which sets the user space TID to 0
         except exit_robust_list(), but this is indicated by the
         FUTEX_OWNER_DIED bit. See [4]

    [10] There is no transient state which leaves owner and user space
         TID out of sync.

    Backport to 3.13
      conflicts: kernel/futex.c

    Change-Id: Ibec82fe154f4ed702332d2d259ec88317b6fede1
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Will Drewry <wad@chromium.org>
    Cc: Darren Hart <dvhart@linux.intel.com>
    Cc: stable@vger.kernel.org

commit c699165eeb575706c9ad757e8e138f84ef8bd221
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 3 12:27:07 2014 +0000

    futex: Always cleanup owner tid in unlock_pi

    If the owner died bit is set at futex_unlock_pi, we currently do not
    cleanup the user space futex. So the owner TID of the current owner
    (the unlocker) persists. That's observable inconsistant state,
    especially when the ownership of the pi state got transferred.

    Clean it up unconditionally.

    Change-Id: I8708a8c38c82ac4565634421fce8f916a6da873b
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Will Drewry <wad@chromium.org>
    Cc: Darren Hart <dvhart@linux.intel.com>
    Cc: stable@vger.kernel.org

commit de61a8cfd94785956987ad2ec810d887c0ec03ff
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 3 12:27:06 2014 +0000

    futex: Validate atomic acquisition in futex_lock_pi_atomic()

    We need to protect the atomic acquisition in the kernel against rogue
    user space which sets the user space futex to 0, so the kernel side
    acquisition succeeds while there is existing state in the kernel
    associated to the real owner.

    Verify whether the futex has waiters associated with kernel state. If
    it has, return -EINVAL. The state is corrupted already, so no point in
    cleaning it up. Subsequent calls will fail as well. Not our problem.

    [ tglx: Use futex_top_waiter() and explain why we do not need to try
      	restoring the already corrupted user space state. ]

    Change-Id: Ifca31cf91f32a408171a01b8db1e49c14411a776
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Will Drewry <wad@chromium.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit 3a4a3df86f4f38ce70a3d584dba0e1cd1bf00fed
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jun 3 12:27:06 2014 +0000

    futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

    If uaddr == uaddr2, then we have broken the rule of only requeueing
    from a non-pi futex to a pi futex with this call. If we attempt this,
    then dangling pointers may be left for rt_waiter resulting in an
    exploitable condition.

    This change brings futex_requeue() into line with
    futex_wait_requeue_pi() which performs the same check as per commit
    6f7b0a2a5 (futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi())

    [ tglx: Compare the resulting keys as well, as uaddrs might be
      	different depending on the mapping ]

    Fixes CVE-2014-3153.

    Change-Id: I6bfa0943ee54d6331e6faa7779d621f9cf19fe52
    Reported-by: Pinkie Pie
    Signed-off-by: Will Drewry <wad@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit 8f36d5845bfe42d290723c152a36a0c96527bcef
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon May 12 20:45:34 2014 +0000

    futex: Add another early deadlock detection check

    Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
    detection code of rtmutex:
      http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com

    That underlying issue has been fixed with a patch to the rtmutex code,
    but the futex code must not call into rtmutex in that case because
        - it can detect that issue early
        - it avoids a different and more complex fixup for backing out

    If the user space variable got manipulated to 0x80000000 which means
    no lock holder, but the waiters bit set and an active pi_state in the
    kernel is found we can figure out the recursive locking issue by
    looking at the pi_state owner. If that is the current task, then we
    can safely return -EDEADLK.

    The check should have been added in commit 59fa62451 (futex: Handle
    futex_pi OWNER_DIED take over correctly) already, but I did not see
    the above issue caused by user space manipulation back then.

    Change-Id: I038ce8d61ee0d427574939b048035877149a2981
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Darren Hart <darren@dvhart.com>
    Cc: Davidlohr Bueso <davidlohr@hp.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Clark Williams <williams@redhat.com>
    Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
    Cc: Roland McGrath <roland@hack.frob.com>
    Cc: Carlos ODonell <carlos@redhat.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org

commit a176e67ed322ae617dcbd7e83bf58aba5cb48214
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon May 12 20:45:35 2014 +0000

    futex: Prevent attaching to kernel threads

    We happily allow userspace to declare a random kernel thread to be the
    owner of a user space PI futex.

    Found while analysing the fallout of Dave Jones syscall fuzzer.

    We also should validate the thread group for private futexes and find
    some fast way to validate whether the "alleged" owner has RW access on
    the file which backs the SHM, but that's a separate issue.

    Change-Id: Id43144232efa7c3ae7c630cffa69f55ff83d8fd9
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Darren Hart <darren@dvhart.com>
    Cc: Davidlohr Bueso <davidlohr@hp.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Clark Williams <williams@redhat.com>
    Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
    Cc: Roland McGrath <roland@hack.frob.com>
    Cc: Carlos ODonell <carlos@redhat.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org

commit 051e4986ba0a524a4389e7fa79125cf4f9cf0138
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Sat May 3 14:04:59 2014 +0200

    n_tty: Fix n_tty_write crash when echoing in raw mode

    The tty atomic_write_lock does not provide an exclusion guarantee for
    the tty driver if the termios settings are LECHO & !OPOST.  And since
    it is unexpected and not allowed to call TTY buffer helpers like
    tty_insert_flip_string concurrently, this may lead to crashes when
    concurrect writers call pty_write. In that case the following two
    writers:
    * the ECHOing from a workqueue and
    * pty_write from the process
    race and can overflow the corresponding TTY buffer like follows.

    If we look into tty_insert_flip_string_fixed_flag, there is:
      int space = __tty_buffer_request_room(port, goal, flags);
      struct tty_buffer *tb = port->buf.tail;
      ...
      memcpy(char_buf_ptr(tb, tb->used), chars, space);
      ...
      tb->used += space;

    so the race of the two can result in something like this:
                  A                                B
    __tty_buffer_request_room
                                      __tty_buffer_request_room
    memcpy(buf(tb->used), ...)
    tb->used += space;
                                      memcpy(buf(tb->used), ...) ->BOOM

    B's memcpy is past the tty_buffer due to the previous A's tb->used
    increment.

    Since the N_TTY line discipline input processing can output
    concurrently with a tty write, obtain the N_TTY ldisc output_lock to
    serialize echo output with normal tty writes.  This ensures the tty
    buffer helper tty_insert_flip_string is not called concurrently and
    everything is fine.

    Note that this is nicely reproducible by an ordinary user using
    forkpty and some setup around that (raw termios + ECHO). And it is
    present in kernels at least after commit
    d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to
    use the normal buffering logic) in 2.6.31-rc3.

    js: add more info to the commit log
    js: switch to bool
    js: lock unconditionally
    js: lock only the tty->ops->write call

    References: CVE-2014-0196
    Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.4: output_lock is a member of struct tty_struct]

    Change-Id: I11d1685056e18f107c970fbe2cab5176ca3a91c4

Change-Id: I9ef445aec93fb79d0ed412b04c530578e5d0448f