synaptics_s7301: add disabling keypad

Change-Id: I5af258d2245024918f08a1a7c93c6efcc4d177b3
smdk4412: cypress-touchkey - add keydisabler

Change-Id: I85efd4c5b2d6a7283c430f5eca2a730ef6b03d18
mc1n2: Allow swapping of microphone ADC channels

The SGH-I777 libaudio has the configuration for
ADC0[0] and ADC0[1] swapped.

When using GT-I9100 libaudio, this results in
the microphones being improperly swapped between
the main mic and the NR mic near the earpiece.

This patch allows the mic channels to be swapped
within the driver to deal with incompatible libaudio.

It is configurable via
CONFIG_SND_SOC_MC1N2_MIC_ADC_SWAP in the defconfig
in case the SGH-I777 libaudio becomes available.

Change-Id: Id5738369f3614c6ccf710ac02ae96ee65eb4398b
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
Merge "smdk4412: cypress-touchkey - add keydisabler" into cm-11.0
Merge "synaptics_s7301: add disabling keypad" into cm-11.0
Fix CVE-2014-3153

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 ]

Change-Id: Ibe6195215657c86bf2e39305656fdacf7230389d
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>
smdk4412: update mali driver

from GT-N7100_SEA_KK_Opensource

Change-Id: I1ddaa2c88660427348f359a6477aced196c4d7dc
d710: build stage2 initramfs into kernel

Change-Id: I2c3f9dee52cd1241eb576a73893f8d8cf55bbe76
Merge "smdk4412: update mali driver" into cm-11.0
smdk4412: fix build

Change-Id: I3b9e6cee7343c9dd3a7ae68694e60991047db50d
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
smdk4412: fix kona bootloop

Change-Id: I21c2828a547f8387dada2e6393d92fe115e2491f
mach-exynos: cpufreq: Show list of available frequencies

This patch enables 'scaling_available_frequencies' attribute
showing list of available frequencies.

Change-Id: I9b6ad786ffaaba8ad6fe5aa9045fd793c095b5ae
mali: add r3p1 for devices that need it

d710 needs to use old mali drivers due to new ones causing signal to be completely killed

Change-Id: I450c356b50e3f3521a63717a1c241e3b818b936f
d710: enable r3p1 mali drivers and autoregen defconfig

Change-Id: I08dc1617e3f77b63a4eee45f78abbb989a5276f4
cpuidle-exynos4: calm down some logspam

* noticed these CONSTANTLY flooding the log with screen off
  using wireless adb (so it was unplugged)

Change-Id: I4df4f0da9f62cfd86552b77c71d4a2de11dac5d4
Fix kernel build errors for GT-N7000

defconfig: cyanogenmod_n7000_defconfig

Fix two mali400 drivers compile together 
Use mali400 r3p2 driver,disabled mali r3p1 driver.

Change-Id: Ia6c4290414b3f97f57b38da41dae6107c4d9c657
s3cfb_ops: Attempt to fix LPM (off charging mode) graphics issue

Change-Id: I4af44a979e5ab3b9d29888ce178ea9c0f71432b3
samsung_battery: Attemp to fix LPM (off charging mode) with KitKat bootloader

Change-Id: Icbc7f7b0d6e52485eadc2d801224e01eaffe29e1
otg: when removing ED from readyQ also set flag

The driver keeps track of the "is this endpoint in the list" state with
the redundant flag ".is_in_transfer_ready_q". It should therefore always
be sync with the .next and .prev of the readyq_list list:

        struct ed *ed;
        otg_list_head *qlist = (typeof qlist) ed->readyq_list;

        (qlist->prev == LIST_POISON2 || qlist->next == LIST_POISON1)
          == !ed->ed_status.is_in_transfer_ready_q;

Should both properties be not in sync, bad things can happen. All code
paths in driver rely on the flag and then call list operations. If the
flag suggests the entry is in the list, otg_list_pop () will be called.
When the entry however is not in the list, the members .prev and .next
are poisoned and an attempt to do list operations on them results into a
NULL (or rather an invalid address which is the poison) pointer
dereference. Such a fault would then trigger a kernel panic and the
device rebooting.
In real life this happens when disconnecting USB devices frequently,
especially when in operation (transfering data while detaching).

While in most positions in the code, it was taken care to keep both
properties, the flag and the list entry state, consistent, one position
was left out, which is addressed with this patch.
Extensive testing shows that the device would crash easily and in a
reproducable manner without the patch but does not show any faults with
the patch applied.

Change-Id: I80f3a8e7d866c699ddcd1c61b04d956e39d2197c