Fix section mismatch

Signed-off-by: Xmister <xmisterhu@gmail.com>
Fix warnings #1

Signed-off-by: Xmister <xmisterhu@gmail.com>
arm: make return_address available for ARM_UNWIND

Signed-off-by: Xmister <xmisterhu@gmail.com>
Fix warnings #2

Signed-off-by: Xmister <xmisterhu@gmail.com>
Fix sc8800 section mismatch

Signed-off-by: Xmister <xmisterhu@gmail.com>
netfilter: qtaguid: rate limit some of the printks

Some of the printks are in the packet handling path.
We now ratelimit the very unlikely errors to avoid
kmsg spamming.

Change-Id: I0cde56bcb7602bdafe1921cc6effbf234c9584f9
Signed-off-by: JP Abgrall <jpa@google.com>
Update kernel source to enru-3.1.10-g73bacb2

Change-Id: I5539243125fd5687952217f679b088747f322677

Conflicts:
	arch/arm/configs/ap33_android_defconfig
	arch/arm/mach-tegra/cpu-tegra.c
	arch/arm/mach-tegra/htc_battery_tps80032.c
	arch/arm/mach-tegra/tegra3_dvfs.c
	arch/arm/mach-tegra/usb_phy.c
	drivers/cpufreq/cpufreq_ondemand.c
	drivers/usb/gadget/composite.c
	drivers/usb/gadget/f_mtp.c
	drivers/usb/host/ehci-tegra.c
	fs/ext4/super.c
	kernel/sched.c
Where have you been?

Signed-off-by: Xmister <xmisterhu@gmail.com>
Update USB driver

Signed-off-by: Xmister <xmisterhu@gmail.com>
nf: xt_qtaguid: fix handling for cases where tunnels are used.

* fix skb->dev vs par->in/out
When there is some forwarding going on, it introduces extra state
around devs associated with xt_action_param->in/out and sk_buff->dev.
E.g.
   par->in and par->out are both set, or
   skb->dev and par->out are both set (and different)
This would lead qtaguid to make the wrong assumption about the
direction and update the wrong device stats.
Now we rely more on par->in/out.

* Fix handling when qtaguid is used as "owner"
When qtaguid is used as an owner module, and sk_socket->file is
not there (happens when tunnels are involved), it would
incorrectly do a tag stats update.

* Correct debug messages.

Bug: 11687690
Change-Id: I2b1ff8bd7131969ce9e25f8291d83a6280b3ba7f
Signed-off-by: JP Abgrall <jpa@google.com>
For config sync

Signed-off-by: Xmister <xmisterhu@gmail.com>
arm: endeavoru defconfig: Enable Android base and recommented configs

See http://source.android.com/devices/tech/kernel.html

Change-Id: If48d5b474de54f3b37317404af284a3857d8cb5a

Conflicts:
	arch/arm/configs/cyanogenmod_endeavoru_defconfig
Config sync done

Signed-off-by: Xmister <xmisterhu@gmail.com>
Cherry picked commits from the grouper kernel

Squashed commit of the following:

commit 764ff2b24c6237adca332084a9a504708c207863
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 18 09:14:12 2012 +0000

    tcp: fix FIONREAD/SIOCINQ

    [ Upstream commit a3374c42aa5f7237e87ff3b0622018636b0c847e ]

    tcp_ioctl() tries to take into account if tcp socket received a FIN
    to report correct number bytes in receive queue.

    But its flaky because if the application ate the last skb,
    we return 1 instead of 0.

    Correct way to detect that FIN was received is to test SOCK_DONE.

    Reported-by: Elliot Hughes <enh@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Tom Herbert <therbert@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ed Tam <etam@google.com>

commit 975ebe423567a462368ba20e1676ca977d023230
Author: Haley Teng <hteng@nvidia.com>
Date:   Sat May 4 02:00:37 2013 +0800

    asoc: tegra: need to enable ahub clocks before accessing DAM registers

    To avoid hard hang when you execute the below command lines

    - cat /sys/kernel/debug/asoc/tegra30-dam.0
    - cat /sys/kernel/debug/asoc/tegra30-dam.1
    - cat /sys/kernel/debug/asoc/tegra30-dam.2

    Bug 1283024

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

commit 2476bdfc50a45ae9785b5a6f0adc5cd0b25cf295
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 c340135e2c886be0db3007cb861556771900e764
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>

commit d0d0b81076bf70ae91a1184213658814dd0635a2
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>

    Conflicts:
    	kernel/ptrace.c

commit f01f1cd2ad51437a448a2941b288f14ca5c286a0
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.

    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>

    Conflicts:
    	kernel/ptrace.c

commit a9cb445f1cbaacf7022ac85678440c602a2d3da8
Author: Lorenzo Colitti <lorenzo@google.com>
Date:   Wed Mar 6 13:14:38 2013 -0800

    net: ipv6: Don't purge default router if accept_ra=2

    Setting net.ipv6.conf.<interface>.accept_ra=2 causes the kernel
    to accept RAs even when forwarding is enabled. However, enabling
    forwarding purges all default routes on the system, breaking
    connectivity until the next RA is received. Fix this by not
    purging default routes on interfaces that have accept_ra=2.

    Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
    Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Iliyan Malchev <malchev@google.com>

Change-Id: I31751c153d6aef98707f7c57aad43dbac1b5a794

Conflicts:
	kernel/ptrace.c
USB: OTG: Take wakelock when VBUS present

Enabled by default, can disable with:
   echo N > /sys/module/otg_wakelock/parameters/enabled

Change-Id: I34974624c52ae23490852b44c270d2f326cf6116
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Config update

Signed-off-by: Xmister <xmisterhu@gmail.com>
Ondemand fix

Signed-off-by: Xmister <xmisterhu@gmail.com>
rcu: add jrcu for small smp systems - https://github.com/TripNRaVeR/tripndroid-endeavoru-3.1.10-htc/commit/4e870c6c215e53655bba6213057d2afa3ce44394
sched: Folding nohz load accounting more accurate

After patch 453494c3d4 (sched: Fix nohz load accounting -- again!), we can fold
the idle into calc_load_tasks_idle between the last cpu load calculating and
calc_global_load calling. However problem still exits between the first cpu
load calculating and the last cpu load calculating. Every time when we do load
calculating, calc_load_tasks_idle will be added into calc_load_tasks, even if
the idle load is caused by calculated cpus. This problem is also described in
the following link:

https://lkml.org/lkml/2012/5/24/419

This bug can be found in our work load. The average running processes number
is about 15, but the load only shows about 4.

The patch provides a solution, by taking calculated load cpus' idle away from
 real effective idle. First adds a cpumask to record those cpus that alread
calculated their load, and then adds a calc_unmask_cpu_load_idle to record
thoses not marked cpus' go-idle load. Calc_unmask_cpu_load_idle takes place
of calc_load_tasks_idle to be added into calc_load_tasks every 5HZ when cpu
calculate its load. Go-idle load on those cpus which load alread has been calculated
will only be added into calc_load_tasks_idle, no in calc_unmask_cpu_load_idle.

Reported-by: Sha Zhengju <handai.szj@xxxxxxxxx>
Signed-off-by: Charles Wang <muming.wq@xxxxxxxxxx>
modified for HTC One X kernel from Linux 3.4+ by faux123
f_mtp: Remove cpu locks

Signed-off-by: Xmister <xmisterhu@gmail.com>