usb: otg:  Retry putting the OTG PHY in low power mode.

The MSM OTG PHY does not go into low power mode when powered up with a
charger. Hence reset the PHY and add logic to retry the LPM Handshake.
This will avoid the msm_otg wakelock getting stuck forever when powered
up with a charger.

Change-Id: I00d90ce3bf3bb23e36aa42233a2e91a719264ec9
Signed-off-by: Ravikumar Vembu <a18394@motorola.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
kswapd: Introduce congestion_wait_kswapd

congestion_wait for kswapd is similar to congestion_wait, the vital
difference is that congestion_wait_kswapd uses schedule_timeout
instead of io_schedule_timeout (which can cause IO wait conditions,
due to nr_iowait usage).

Derived from: https://github.com/oppo-source/Find5-Kernel-Source-4.2/commit/c7b44a43a970b699ecd68655bd6f83a8fbb3d74d
Original author: huanggd @oppo-source

Change-Id: I08bbbdd49c8764a3180c0d7a9197d2b9c8112d81
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
drivers: usb: Use Android device as USB keyboard/mouse

Adapt to 3.4.y 8974/hammerhead
Base project: https://github.com/pelya/android-keyboard-gadget
Required app:
https://play.google.com/store/apps/details?id=remote.hid.keyboard.client

Steps:
* Start ADB Debugging
* Start app
* Connect device to system via USB cable

All credits to @pelya for this sweet hack.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	drivers/usb/gadget/android.c

Change-Id: I775ba52925bdc52d865d8915e238ee7e5fc1455e
Merge changes I08bbbdd4,I00d90ce3 into cm-11.0

* changes:
  kswapd: Introduce congestion_wait_kswapd
  usb: otg:  Retry putting the OTG PHY in low power mode.
Merge "drivers: usb: Use Android device as USB keyboard/mouse" into cm-11.0
Revert "msm: display: clear sec_active when the pipe is not for secure"

This reverts commit ee1390591f8283e642da6aae38a8d4ab32dbe401.
msm: mdp: Free secure memory based on pipe config

When there is no secure pipe configured, we can unmap secure
memory instead of relying on unset with secure flag set from
userspace.

Bug: 11857675

Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>

Conflicts:
	drivers/video/msm/mdp4_overlay.c

Change-Id: Ie59ed14b31771c0c9a4ab9623f6d2a20b1147435
android: configs: Grab the android/configs from kernel/common

This is a squash of all changes from kernel/common android-3.4 up to
  5e35d66 android: configs: add IPV6 ROUTE INFO

Change-Id: I848f1865ec7da1dfc3338a3e9d7f944a6f00f2a6
Signed-off-by: JP Abgrall <jpa@google.com>
fs/dcache.c: Fix the too small buffer for dname

temp[64] is used for internal temporary buffer in dynamic_dname().
This is for dname. But It's too small. dname's size may be > 64.
In that case, it returns as -ENAMETOOLONG. So Increase the buffer size
to 256 for avoiding this issue.

The following was caused by the small buffer.
WARNING: at /kernel/mm/page_alloc.c:2470 __alloc_pages_nodemask+0x24c/0x938()
CPU: 2 PID: 505 Comm: android.bg Not tainted 3.10.0-g2f73780-00003-g2ff41d9-dirty #13
[<c010ba3c>] (unwind_backtrace+0x0/0x11c) from [<c0109cac>] (show_stack+0x10/0x14)
[<c0109cac>] (show_stack+0x10/0x14) from [<c01939a0>] (warn_slowpath_common+0x48/0x68)
[<c01939a0>] (warn_slowpath_common+0x48/0x68) from [<c0193a7c>] (warn_slowpath_null+0x18/0x20)
[<c0193a7c>] (warn_slowpath_null+0x18/0x20) from [<c0222454>] (__alloc_pages_nodemask+0x24c/0x938)
[<c0222454>] (__alloc_pages_nodemask+0x24c/0x938) from [<c0222b50>] (__get_free_pages+0x10/0x24)
[<c0222b50>] (__get_free_pages+0x10/0x24) from [<c024faf8>] (kmalloc_order_trace+0x24/0xf0)
[<c024faf8>] (kmalloc_order_trace+0x24/0xf0) from [<c024fe20>] (__kmalloc+0x30/0x244)
[<c024fe20>] (__kmalloc+0x30/0x244) from [<c02723c8>] (seq_read+0x270/0x464)
[<c02723c8>] (seq_read+0x270/0x464) from [<c0256a18>] (vfs_read+0xa4/0x134)
[<c0256a18>] (vfs_read+0xa4/0x134) from [<c0256de8>] (SyS_read+0x38/0x68)
[<c0256de8>] (SyS_read+0x38/0x68) from [<c0106140>] (ret_fast_syscall+0x0/0x30)

Change-Id: I74f5217ba3c4be73e91f33f900f1f0c26810cc05
Signed-off-by: Devin Kim <dojip.kim@lge.com>
seq_file: always clear m->count when we free m->buf

Once we'd freed m->buf, m->count should become zero - we have no valid
contents reachable via m->buf.

cherry-picked from
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/seq_file.c?id=801a76050bcf8d4e500eb8d048ff6265f37a61c8

Change-Id: I4c1d3e69db4ecf5362e2a5d05bfd7db754dc6dc6
Reported-by: Charley (Hao Chuan) Chu <charley.chu@broadcom.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Devin Kim <dojip.kim@lge.com>

Conflicts:
	fs/seq_file.c
seq_file: always update file->f_pos in seq_lseek()

This issue was first pointed out by Jiaxing Wang several months ago, but no
further comments:
https://lkml.org/lkml/2013/6/29/41

As we know pread() does not change f_pos, so after pread(), file->f_pos
and m->read_pos become different. And seq_lseek() does not update file->f_pos
if offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to
m->read_pos), then a subsequent read may read from a wrong position, the
following program produces the problem:

    char str1[32] = { 0 };
    char str2[32] = { 0 };
    int poffset = 10;
    int count = 20;

    /*open any seq file*/
    int fd = open("/proc/modules", O_RDONLY);

    pread(fd, str1, count, poffset);
    printf("pread:%s\n", str1);

    /*seek to where m->read_pos is*/
    lseek(fd, poffset+count, SEEK_SET);

    /*supposed to read from poffset+count, but this read from position 0*/
    read(fd, str2, count);
    printf("read:%s\n", str2);

out put:
pread:
 ck_netbios_ns 12665
read:
 nf_conntrack_netbios

/proc/modules:
nf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000
nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000

So we always update file->f_pos to offset in seq_lseek() to fix this issue.

cherry-picked from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/seq_file.c?id=05e16745c0c471bba313961b605b6da3b21a853d

Signed-off-by: Jiaxing Wang <hello.wjx@gmail.com>
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Conflicts:
	fs/seq_file.c

Change-Id: If419b92498e2c3e08669a4342e9b9ebf99ad3768
Signed-off-by: Devin Kim <dojip.kim@lge.com>
Import Samsung audio changes from ND8 release

There were others, but these are the only ones that looked interesting

Change-Id: Ifa0eb6c1b6cc6f2be60c2f01c932fdcf89ef830b
bcmdhd: update to 1.141.44 from sprint ND8 source

Change-Id: Ie87df94d96f99d696ceb80328a993e9aac04ade8
msm8960: update wifi and storage boardfiles from sprint NB8

Change-Id: I30ccad5011252a5638d70d68c322e38a22eda6fa

Conflicts:
	arch/arm/mach-msm/board-8960-storage.c
selinux: Report permissive mode in avc: denied messages.

We cannot presently tell from an avc: denied message whether access was in
fact denied or was allowed due to global or per-domain permissive mode.
Add a permissive= field to the avc message to reflect this information.

Change-Id: I23adf43e417687f1da7354d392d37f5fabbd805e
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
fs: exfat: update to 1.2.7 from ND8 release

Change-Id: Ib01801bbbd62f88704545f8f33ee74bc2628411a
tick: Upstream fixes

 * Addresses the issue of timers being scheduled on offline CPUs.

tick: Don't invoke tick_nohz_stop_sched_tick() if the cpu is offline

commit 5b39939a4 (nohz: Move ts->idle_calls incrementation into strict
idle logic) moved code out of tick_nohz_stop_sched_tick() and missed
to bail out when the cpu is offline. That's causing subsequent
failures as an offline CPU is supposed to die and not to fiddle with
nohz magic.

Return false in can_stop_idle_tick() if the cpu is offline.

Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz>
Reported-and-tested-by: Prarit Bhargava <prarit@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305132138160.2863@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

timers: Consolidate base->next_timer update

Another bunch of mindlessly copied code. All callers of
internal_add_timer() except the recascading code updates
base->next_timer.

Move this into internal_add_timer() and let the cascading code call
__internal_add_timer().

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20120525214819.189946224@linutronix.de

timers: Create detach_if_pending() and use it

Most callers of detach_timer() have the same pattern around
them. Check whether the timer is pending and eventually updating
base->next_timer.

Create detach_if_pending() and replace the duplicated code.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20120525214819.131246037@linutronix.de

timers: Add accounting of non deferrable timers

The code in get_next_timer_interrupt() is suboptimal as it has to run
through the cascade to find the next expiring timer. On a completely
idle core we should only do that when there is an active timer
enqueued and base->next_timer does not give us a fast answer.

Add accounting of the active timers to the now consolidated
attach/detach code. I deliberately avoided sanity checks because the
code is fully symetric and any fiddling with timers w/o using the API
functions will lead to cute explosions anyway. ulong is big enough
even on 32bit and if we really run into the situation to have more
than 1<<32 timers enqueued there, then we are definitely not in a
state to go idle and run through that code.

This allows us to fix another shortcoming of get_next_timer_interrupt().

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20120525214819.236377028@linutronix.de

timers: Improve get_next_timer_interrupt()

Gilad reported at

 http://lkml.kernel.org/r/1336056962-10465-2-git-send-email-gilad@benyossef.com

"Current timer code fails to correctly return a value meaning that
 there is no future timer event, with the result that the timer keeps
 getting re-armed in HZ one shot mode even when we could turn it off,
 generating unneeded interrupts.

 What is happening is that when __next_timer_interrupt() wishes
 to return a value that signifies "there is no future timer
 event", it returns (base->timer_jiffies + NEXT_TIMER_MAX_DELTA).

 However, the code in tick_nohz_stop_sched_tick(), which called
 __next_timer_interrupt() via get_next_timer_interrupt(),
 compares the return value to (last_jiffies + NEXT_TIMER_MAX_DELTA)
 to see if the timer needs to be re-armed.

 base->timer_jiffies != last_jiffies and so tick_nohz_stop_sched_tick()
 interperts the return value as indication that there is a distant
 future event 12 days from now and programs the timer to fire next
 after KTIME_MAX nsecs instead of avoiding to arm it. This ends up
 causing a needless interrupt once every KTIME_MAX nsecs."

Fix this by using the new active timer accounting. This avoids scans
when no active timer is enqueued completely, so we don't have to rely
on base->timer_next and base->timer_jiffies anymore.

Change-Id: I874ee5e5f837a228cebf5e6a084baf520d33cd0f
Reported-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20120525214819.317535385@linutronix.de
pktgen: clean up ktime_t helpers

Some years ago, the ktime_t helper functions ktime_now() and ktime_lt()
have been introduced. Instead of defining them inside pktgen.c, they
should either use ktime_t library functions or, if not available, they
should be defined in ktime.h, so that also others can benefit from them.
ktime_compare() is introduced with a similar notion as in timespec_compare().

Change-Id: I3d092b737d46cf2368baf4101c852fe9a4db510f
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
iopoll: Make readl_poll_timeout() and friends preemption-safe

With the previous implementation, pre-emption was possible
between reading the register value and evaluating the break
condition for the timeout. If jiffies advanced sufficiently to
expire the timeout before the polling thread was rescheduled,
the macro would return -ETIMEDOUT incorrectly.

Fix this by re-reading the register value again after evaluating
the timeout condition as true.

Change-Id: I58a42798235db3606373a2f689f7d6c95475702e
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
iopoll: Use ktime_get() instead of jiffies for timeout calculations

Presently, small timeout values will round up to 1 jiffy which,
on CONFIG_HZ=100 systems, corresponds to a full 10 milliseconds.
This is undesirable for drivers specifying timeouts of only a
few 10's of microseconds (which is common), since they may end
up tight-loop spinning for hundreds or thousands of times longer
than expected before reporting a timeout.

Additionally, jiffies cannot be reliably used with time_after()
when the value of jiffies is small (like 1). In rare but real
scenarios, jiffies may actually increment by more than 1 at a
time. Specifically, this will occur if interrupts are disabled
on for more than 1 jiffy (10 milliseconds for CONFIG_HZ=100) on
the CPU responsible for incrementing jiffies.

If interrupts are re-enabled on that CPU between the time the
iopoll code (on another CPU) calculates the timeout value of
jiffies and when the time_after() comparison is made, then the
iopoll APIs may return -ETIMEDOUT prematurely, even though the
specified timeout has not actually expired.

Using ktime_get() avoid this problem (which arguably also needs
a generic fix to avoid similar problems for other code which use
jiffies to calculate timeouts).

CRs-Fixed: 587801
Change-Id: I19150f41965b918c59c3fb98e29a8bd2e2c9609f
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>