commit a6d2ebcda7cb7467b3f5ca597710be25cc8ad76f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 13 13:00:25 2014 -0800

    Linux 3.4.80

commit cd34de10471a5ddad397739fae33555d47e53769
Author: Colin Cross <ccross@android.com>
Date:   Mon Feb 10 13:16:29 2014 -0800

    3.4.y: timekeeping: fix 32-bit overflow in get_monotonic_boottime

    fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c

    get_monotonic_boottime adds three nanonsecond values stored
    in longs, followed by an s64.  If the long values are all
    close to 1e9 the first three additions can overflow and
    become negative when added to the s64.  Cast the first
    value to s64 so that all additions are 64 bit.

    Signed-off-by: Colin Cross <ccross@android.com>
    [jstultz: Fished this out of the AOSP commong.git tree. This was
    fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf85cc93b24891b7e57b1d9939742b5774570b19
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Dec 10 17:18:18 2013 -0800

    timekeeping: Avoid possible deadlock from clock_was_set_delayed

    commit 6fdda9a9c5db367130cf32df5d6618d08b89f46a upstream.

    As part of normal operaions, the hrtimer subsystem frequently calls
    into the timekeeping code, creating a locking order of
      hrtimer locks -> timekeeping locks

    clock_was_set_delayed() was suppoed to allow us to avoid deadlocks
    between the timekeeping the hrtimer subsystem, so that we could
    notify the hrtimer subsytem the time had changed while holding
    the timekeeping locks. This was done by scheduling delayed work
    that would run later once we were out of the timekeeing code.

    But unfortunately the lock chains are complex enoguh that in
    scheduling delayed work, we end up eventually trying to grab
    an hrtimer lock.

    Sasha Levin noticed this in testing when the new seqlock lockdep
    enablement triggered the following (somewhat abrieviated) message:

    [  251.100221] ======================================================
    [  251.100221] [ INFO: possible circular locking dependency detected ]
    [  251.100221] 3.13.0-rc2-next-20131206-sasha-00005-g8be2375-dirty #4053 Not tainted
    [  251.101967] -------------------------------------------------------
    [  251.101967] kworker/10:1/4506 is trying to acquire lock:
    [  251.101967]  (timekeeper_seq){----..}, at: [<ffffffff81160e96>] retrigger_next_event+0x56/0x70
    [  251.101967]
    [  251.101967] but task is already holding lock:
    [  251.101967]  (hrtimer_bases.lock#11){-.-...}, at: [<ffffffff81160e7c>] retrigger_next_event+0x3c/0x70
    [  251.101967]
    [  251.101967] which lock already depends on the new lock.
    [  251.101967]
    [  251.101967]
    [  251.101967] the existing dependency chain (in reverse order) is:
    [  251.101967]
    -> #5 (hrtimer_bases.lock#11){-.-...}:
    [snipped]
    -> #4 (&rt_b->rt_runtime_lock){-.-...}:
    [snipped]
    -> #3 (&rq->lock){-.-.-.}:
    [snipped]
    -> #2 (&p->pi_lock){-.-.-.}:
    [snipped]
    -> #1 (&(&pool->lock)->rlock){-.-...}:
    [  251.101967]        [<ffffffff81194803>] validate_chain+0x6c3/0x7b0
    [  251.101967]        [<ffffffff81194d9d>] __lock_acquire+0x4ad/0x580
    [  251.101967]        [<ffffffff81194ff2>] lock_acquire+0x182/0x1d0
    [  251.101967]        [<ffffffff84398500>] _raw_spin_lock+0x40/0x80
    [  251.101967]        [<ffffffff81153e69>] __queue_work+0x1a9/0x3f0
    [  251.101967]        [<ffffffff81154168>] queue_work_on+0x98/0x120
    [  251.101967]        [<ffffffff81161351>] clock_was_set_delayed+0x21/0x30
    [  251.101967]        [<ffffffff811c4bd1>] do_adjtimex+0x111/0x160
    [  251.101967]        [<ffffffff811e2711>] compat_sys_adjtimex+0x41/0x70
    [  251.101967]        [<ffffffff843a4b49>] ia32_sysret+0x0/0x5
    [  251.101967]
    -> #0 (timekeeper_seq){----..}:
    [snipped]
    [  251.101967] other info that might help us debug this:
    [  251.101967]
    [  251.101967] Chain exists of:
      timekeeper_seq --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock#11

    [  251.101967]  Possible unsafe locking scenario:
    [  251.101967]
    [  251.101967]        CPU0                    CPU1
    [  251.101967]        ----                    ----
    [  251.101967]   lock(hrtimer_bases.lock#11);
    [  251.101967]                                lock(&rt_b->rt_runtime_lock);
    [  251.101967]                                lock(hrtimer_bases.lock#11);
    [  251.101967]   lock(timekeeper_seq);
    [  251.101967]
    [  251.101967]  *** DEADLOCK ***
    [  251.101967]
    [  251.101967] 3 locks held by kworker/10:1/4506:
    [  251.101967]  #0:  (events){.+.+.+}, at: [<ffffffff81154960>] process_one_work+0x200/0x530
    [  251.101967]  #1:  (hrtimer_work){+.+...}, at: [<ffffffff81154960>] process_one_work+0x200/0x530
    [  251.101967]  #2:  (hrtimer_bases.lock#11){-.-...}, at: [<ffffffff81160e7c>] retrigger_next_event+0x3c/0x70
    [  251.101967]
    [  251.101967] stack backtrace:
    [  251.101967] CPU: 10 PID: 4506 Comm: kworker/10:1 Not tainted 3.13.0-rc2-next-20131206-sasha-00005-g8be2375-dirty #4053
    [  251.101967] Workqueue: events clock_was_set_work

    So the best solution is to avoid calling clock_was_set_delayed() while
    holding the timekeeping lock, and instead using a flag variable to
    decide if we should call clock_was_set() once we've released the locks.

    This works for the case here, where the do_adjtimex() was the deadlock
    trigger point. Unfortuantely, in update_wall_time() we still hold
    the jiffies lock, which would deadlock with the ipi triggered by
    clock_was_set(), preventing us from calling it even after we drop the
    timekeeping lock. So instead call clock_was_set_delayed() at that point.

    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Tested-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab99a94d45f5db1ed178ed986f93b938bc018a87
Author: Borislav Petkov <bp@alien8.de>
Date:   Sat Jul 20 19:00:23 2013 +0200

    rtc-cmos: Add an alarm disable quirk

    commit d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d upstream.

    41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the
    functionality to disable the RTC wake alarm when shutting down the box.

    However, there are at least two b0rked BIOSes we know about:

    https://bugzilla.novell.com/show_bug.cgi?id=812592
    https://bugzilla.novell.com/show_bug.cgi?id=805740

    where, when wakeup alarm is enabled in the BIOS, the machine reboots
    automatically right after shutdown, regardless of what wakeup time is
    programmed.

    Bisecting the issue lead to this patch so disable its functionality with
    a DMI quirk only for those boxes.

    Cc: Brecht Machiels <brecht@mos6581.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Rabin Vincent <rabin.vincent@stericsson.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    [jstultz: Changed variable name for clarity, added extra dmi entry]
    Tested-by: Brecht Machiels <brecht@mos6581.org>
    Tested-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbf3239455b155c3e72deacda93ef3a041e190c9
Author: Ying Xue <ying.xue@windriver.com>
Date:   Tue Jul 17 15:03:43 2012 +0800

    sched/rt: Avoid updating RT entry timeout twice within one tick period

    commit 57d2aa00dcec67afa52478730f2b524521af14fb upstream.

    The issue below was found in 2.6.34-rt rather than mainline rt
    kernel, but the issue still exists upstream as well.

    So please let me describe how it was noticed on 2.6.34-rt:

    On this version, each softirq has its own thread, it means there
    is at least one RT FIFO task per cpu. The priority of these
    tasks is set to 49 by default. If user launches an RT FIFO task
    with priority lower than 49 of softirq RT tasks, it's possible
    there are two RT FIFO tasks enqueued one cpu runqueue at one
    moment. By current strategy of balancing RT tasks, when it comes
    to RT tasks, we really need to put them off to a CPU that they
    can run on as soon as possible. Even if it means a bit of cache
    line flushing, we want RT tasks to be run with the least latency.

    When the user RT FIFO task which just launched before is
    running, the sched timer tick of the current cpu happens. In this
    tick period, the timeout value of the user RT task will be
    updated once. Subsequently, we try to wake up one softirq RT
    task on its local cpu. As the priority of current user RT task
    is lower than the softirq RT task, the current task will be
    preempted by the higher priority softirq RT task. Before
    preemption, we check to see if current can readily move to a
    different cpu. If so, we will reschedule to allow the RT push logic
    to try to move current somewhere else. Whenever the woken
    softirq RT task runs, it first tries to migrate the user FIFO RT
    task over to a cpu that is running a task of lesser priority. If
    migration is done, it will send a reschedule request to the found
    cpu by IPI interrupt. Once the target cpu responds the IPI
    interrupt, it will pick the migrated user RT task to preempt its
    current task. When the user RT task is running on the new cpu,
    the sched timer tick of the cpu fires. So it will tick the user
    RT task again. This also means the RT task timeout value will be
    updated again. As the migration may be done in one tick period,
    it means the user RT task timeout value will be updated twice
    within one tick.

    If we set a limit on the amount of cpu time for the user RT task
    by setrlimit(RLIMIT_RTTIME), the SIGXCPU signal should be posted
    upon reaching the soft limit.

    But exactly when the SIGXCPU signal should be sent depends on the
    RT task timeout value. In fact the timeout mechanism of sending
    the SIGXCPU signal assumes the RT task timeout is increased once
    every tick.

    However, currently the timeout value may be added twice per
    tick. So it results in the SIGXCPU signal being sent earlier
    than expected.

    To solve this issue, we prevent the timeout value from increasing
    twice within one tick time by remembering the jiffies value of
    last updating the timeout. As long as the RT task's jiffies is
    different with the global jiffies value, we allow its timeout to
    be updated.

    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: Fan Du <fan.du@windriver.com>
    Reviewed-by: Yong Zhang <yong.zhang0@gmail.com>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1342508623-2887-1-git-send-email-ying.xue@windriver.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [ lizf: backported to 3.4: adjust context ]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f61eb9ceb26cee3fdbb8c7a4920f171f7661fb4f
Author: Peter Boonstoppel <pboonstoppel@nvidia.com>
Date:   Thu Aug 9 15:34:47 2012 -0700

    sched: Unthrottle rt runqueues in __disable_runtime()

    commit a4c96ae319b8047f62dedbe1eac79e321c185749 upstream.

    migrate_tasks() uses _pick_next_task_rt() to get tasks from the
    real-time runqueues to be migrated. When rt_rq is throttled
    _pick_next_task_rt() won't return anything, in which case
    migrate_tasks() can't move all threads over and gets stuck in an
    infinite loop.

    Instead unthrottle rt runqueues before migrating tasks.

    Additionally: move unthrottle_offline_cfs_rqs() to rq_offline_fair()

    Signed-off-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Paul Turner <pjt@google.com>
    Link: http://lkml.kernel.org/r/5FBF8E85CA34454794F0F7ECBA79798F379D3648B7@HQMAIL04.nvidia.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [ lizf: backported to 3.4: adjust context ]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e5c13ec422f665432bfc9f7c5fc1f9fd614afd3
Author: Mike Galbraith <efault@gmx.de>
Date:   Tue Aug 7 10:02:38 2012 +0200

    sched,rt: fix isolated CPUs leaving root_task_group indefinitely throttled

    commit e221d028bb08b47e624c5f0a31732c642db9d19a upstream.

    Root task group bandwidth replenishment must service all CPUs, regardless of
    where the timer was last started, and regardless of the isolation mechanism,
    lest 'Quoth the Raven, "Nevermore"' become rt scheduling policy.

    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1344326558.6968.25.camel@marge.simpson.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21b53baf40aecb134593ec74eb787f16c569cfc5
Author: Colin Cross <ccross@android.com>
Date:   Wed May 16 21:34:23 2012 -0700

    sched/rt: Fix SCHED_RR across cgroups

    commit 454c79999f7eaedcdf4c15c449e43902980cbdf5 upstream.

    task_tick_rt() has an optimization to only reschedule SCHED_RR tasks
    if they were the only element on their rq.  However, with cgroups
    a SCHED_RR task could be the only element on its per-cgroup rq but
    still be competing with other SCHED_RR tasks in its parent's
wcnss: Add support to configure the Wlan MAC addr

This change introduces a sysfs entry to allow userspace to
configure the wlan MAC addr and exports an API which allows
WLAN and other wireless technologies to query the wlan MAC
addr

Change-Id: I751b2cf2db1321926e8e16ef1baaa4fa3d8d06cf
CRs-Fixed: 583465
Signed-off-by:  <hkpatel@codeaurora.org>
wlan: Store avoid channel list

Store avoid channel list into recoverable location.
If Softap mode detects current channel is not safe to use,
WLAN kernel module will be restarted.
Then WLAN kernel module internal storage will lost
unsafe channel information.
To avoid start softap with unsafe channel, channel information
should be stored in static location.

Change-Id: I5a6d7ab7314936d7bbaaf7a005e58179a4dc0613
CRs-fixed: 576020
Signed-off-by: Leo Chang <leochang@codeaurora.org>
make GCC 4.8 happy