video: sii9234: dynamically register and unregister input device

The RCP input device should only be registered as long as MHL is
connected

Original author for tuna: Greg Hackmann <ghackmann@google.com>

Change-Id: I044b04e7d6ffe48c5b837981a8656ca2bb13fa01
Signed-off-by: Andreas B <skate4life@gmx.de>
cpufreq: Bring smdk4x12's pegasusq governor to espresso10

Change-Id: I7c70e43d1ca68664006d0fa8e5c10584567baf31
Boeffla-Sound: Engine 1.6.0

Change-Id: I72f11a3bee4cbce4cfd4dca9bdd8dc40f540d63a
Boeffla Sound: FM radio not available with LTE models

set #ifdef conditional to disable unused logic

Credits to faux123 for the proper exclusions using #ifdefs instead of just removing the FM radio related code

Change-Id: I1051dc8ad7aa4c2a70ac56b2857867a23990b79f
Boeffla-Sound: Engine 1.6.3

- delayed apply of changed register settings (credits to Yank) to
  fix issues on CM
- delay time configurable via sysfs (credits to Yank)
- different headphone detection for s3 and note devices
- different call detection

Change-Id: I22b5e2aadefb14af6596781608d0e46b77b54122
Boeffla-Sound: Engine 1.6.4

- show settings in sysfs even if boeffla sound is switched off
- remove legacy interfaces for alternative eq settings + mic mode
- some code cleanup

Change-Id: I57c64c3ef5381aec6c77621ff5e33221dc6b1b81
Boeffla-Sound: Engine 1.6.5

- allow speaker minimum level of 20

Change-Id: I19511a5704c8a67e6591d488281cfe9c09822ed9
Boeffla-Sound: Engine 1.6.6

- allow minimum volume of 0 for both speaker and headphones

Change-Id: Ifaa3c5bf90485c9a40726a67201799fa45da60f2
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() in line with futex_wait_requeue_pi()
which performs the same check as per commit 6f7b0a2a5c0f ("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: I88a914469f436a8f299bf53ab58a79bc716f3a99
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>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.

Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Dave Jones <davej@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Darren Hart <darren@...art.com>
Cc: Davidlohr Bueso <davidlohr@...com>
Cc: Steven Rostedt <rostedt@...dmis.org>
Cc: Clark Williams <williams@...hat.com>
Cc: Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@...fujitsu.com>
Cc: Roland McGrath <roland@...k.frob.com>
Cc: Carlos ODonell <carlos@...hat.com>
Cc: Jakub Jelinek <jakub@...hat.com>
Cc: Michael Kerrisk <mtk.manpages@...il.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Link: http://lkml.kernel.org/r/20140512201701.194824402@...utronix.de
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

Change-Id: I7444c58d00cbded35b078331a8740e8431cb13a5
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@...hat.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.

Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Dave Jones <davej@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Darren Hart <darren@...art.com>
Cc: Davidlohr Bueso <davidlohr@...com>
Cc: Steven Rostedt <rostedt@...dmis.org>
Cc: Clark Williams <williams@...hat.com>
Cc: Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@...fujitsu.com>
Cc: Roland McGrath <roland@...k.frob.com>
Cc: Carlos ODonell <carlos@...hat.com>
Cc: Jakub Jelinek <jakub@...hat.com>
Cc: Michael Kerrisk <mtk.manpages@...il.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Link: http://lkml.kernel.org/r/20140512201701.097349971@...utronix.de
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

Change-Id: I245f77622443435cf36bbd157b98798c235acdb0