msm: sdcc: Move vdd to optional property

Some devices might not use the vdd. So move vdd to optional property and
avoid controling the vdd in that device if qcom,not-use-vdd exists.

Change-Id: Ic504e7c2f6311cf158fc77fdc28b2723679826af
Signed-off-by: Devin Kim <dojip.kim@lge.com>
msm: sdcc: Use wifi_control_func to identify the wlan slot

Change-Id: I2a694d17ee74d90d789892e5058190b6cf8f4934
Revert "rfkill: Don't run btlock"

This reverts commit 746ec22855cc842a751585d14c3a481f900721b9.
bcmdhd: Update bcm4335 driver to 1.88.60

Change-Id: I9432f96429c8d7f3d51252af68594416670e9478
msm: mdss: mdss: g2_dcm: remove stock rom dependecy process.

this is JPN/DCM carrier specific logo only.
it is no need Cyanogenmod base rom, because it does not have "/initlogo_dcm_xi.rle""
and it is shown invalid frame a few times at phone starting.

Change-Id: I3c0800518fc5cf83f1c47ce406056bf765088b84
Add L-01F(G2 JPN-DCM) defconfig

Change-Id: Ie4a879f10ac4ce85c39dedbc4cd441cf5ece51d7
Add LGL22 au isai (G2 JPN-KDDI) defconfig

Change-Id: Ibff317fb53488450966e12d1606ac06f8225869d
Merge "msm: mdss: mdss: g2_dcm: remove stock rom dependecy process." into cm-11.0
Merge branch 'cm-11.0' of https://github.com/CyanogenMod/android_kernel_lge_msm8974 into cm-11.0
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 branch 'cm-11.0' of https://github.com/CyanogenMod/android_kernel_lge_msm8974 into cm-11.0
Revert "Revert "rfkill: Don't run btlock""

This reverts commit 6e4088f7a12f160e87bfb6505c4408e48f2d7485.
Merge branch 'cm-11.0' of https://github.com/CyanogenMod/android_kernel_lge_msm8974 into cm-11.0
bcmdhd: Adjust default hostwake/reset GPIOs to match the galbis

Change-Id: I84c3d71dde9fdea45652b24a65523d9947cdd25d
bluesleep: Don't wait for uart tx queue to flush before entering standby

There's no need to delay sleep for this. msm_hs_serial will do it on
its own, and this reduces the time to enter lpm

Change-Id: Ia13d44148130aaf133ea888807b5ba114936ce78
Merge "Add L-01F(G2 JPN-DCM) defconfig" into cm-11.0
Merge "Add LGL22 au isai (G2 JPN-KDDI) defconfig" into cm-11.0
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.

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>

Change-Id: I155eafa98f365408450527e34998893dcdd64801
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. ]

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>

Change-Id: I155eafa98f365408450527e34998893dcdd64802
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.

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

Change-Id: I155eafa98f365408450527e34998893dcdd64803