sched: fix race between try_to_wake_up() and move_task()

Until a task's state has been seen as interruptible/uninterruptible
and it is no longer on_cpu, it is possible that the task may move
to another CPU (load balancing may cause this). Here is an example
where the race condition results in incorrect operation:

- cpu 0 calls put_prev_task on task A, task A's state is TASK_RUNNING
- cpu 0 runs task B, which attempts to wake up A
- cpu 0 begins try_to_wake_up(), recording src_cpu for task A as cpu 0
- cpu 1 then pulls task A (perhaps due to idle balance)
- cpu 1 runs task A, which then sleeps, becoming INTERRUPTIBLE
- cpu 0 continues in try_to_wake_up(), thinking task A's previous
  cpu is 0, where it is actually 1
- if select_task_rq returns cpu 0, task A will be woken up on cpu 0
  without properly updating its cpu to 0 in set_task_cpu()

Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: Always allow update of user policy

In the cases where the system boots up in a constraint with policy min and
max lower than cpuinfo min/max, and user tries to set a higher user
policy min, the value would be overridden during the verifying the
limits.

Once user initiates the sysfs write the previous user policy is
maintained in policy min and max thus changing the limits for verification
of the current policy. Once the verification is completed restore the
current user policy min/max with the updated values if any. This would take
care of cases uwhere user policy min/max input is higher/lesser than the
current min and max.

Signed-off-by: Taniya Das <tdas@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: ccid_bridge: Don't kill URB in release after device is disconnected

The URBs are killed in disconnect method. If the device is disconnected
before the /dev/ccid_bridge is closed, no need to kill the URBs again.
As the URB reference count is dropped in disconnect, accessing it in
release is causing the kernel panic.

Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: ccid_bridge: Provide bulk message write/read stats via debugfs

The bulk message timeouts are observed occasionally during mass storage
transfers. This debug facility helps in identifying such timeout issues.

The sample output of the stats debugfs file.

ccid_bridge: connected
ccid_bridge: opened
total writes: 444
total reads: 444
write/read timeout val: 1000
write_timeout: 0
read_timeout: 0
write_max_time (msec): 130
read_max_time: (msec): 857

Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
timekeeping: Add persistent_clock_exist flag

In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling the read_persistent_clock() and validating its
return value.

So one optimization is to do the check only once in timekeeping_init(),
and use a flag persistent_clock_exist to record it.

v2: Add a has_persistent_clock() helper function, as suggested by John.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
timekeeping: Correct run-time detection of persistent_clock.

Since commit 31ade30692dc9680bfc95700d794818fa3f754ac, timekeeping_init()
checks for presence of persistent clock by attempting to read a non-zero
time value. This is an issue on platforms where persistent_clock (instead
is implemented as a free-running counter (instead of an RTC) starting
from zero on each boot and running during suspend. Examples are some ARM
platforms (e.g. PandaBoard).

An attempt to read such a clock during timekeeping_init() may return zero
value and falsely declare persistent clock as missing. Additionally, in
the above case suspend times may be accounted twice (once from
timekeeping_resume() and once from rtc_resume()), resulting in a gradual
drift of system time.

This patch does a run-time correction of the issue by doing the same check
during timekeeping_suspend().

A better long-term solution would have to return error when trying to read
non-existing clock and zero when trying to read an uninitialized clock, but
that would require changing all persistent_clock implementations.

This patch addresses the immediate breakage, for now.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
[jstultz: Tweaked commit message and subject]
Signed-off-by: John Stultz <john.stultz@linaro.org>
[Backport by Dorimanx]
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
time: create __getnstimeofday for WARNless calls

Expose getnstimeofday logic that returns
an error instead of a WARN. This can be detected and the timestamp can
be zeroed out.

Reported-by: Doug Anderson <dianders@chromium.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
timekeeping: Add suspend and resume of clock event devices

Some clock event devices, for example such that belong to PM domains,
need to be handled in a spcial way during the timekeeping suspend
and resume (which takes place in the system core, or "syscore",
stages of system power transitions) in analogy with clock sources.

Introduce .suspend() and .resume() callbacks for clock event devices
that will be executed by timekeeping_suspend/_resume(), respectively,
next the the clock sources' .suspend() and .resume() callbacks.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	include/linux/clockchips.h