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>
ARM: Improve vmalloc address checking in show_data()

There is an unhandled corner case with the current check
which has recently been hit. The nbytes argument may be
large enough for the range being dumped to cross a
boundary between page-table mappings, and dump addresses
which are vmalloc'd in the neighboring mapping.

Check every address being dumped to see if its vmalloc'd,
not just the address passed to show_data().

CRs-Fixed: 625442
Change-Id: I255b093808177321f5202dcacea337ee333bfc63
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
ARM: Don't dump vmalloc addresses with show_data()

Memory-mapped IO address spaces cannot be safely dumped at will.
Some addresses may not be available (clocked, powered) at all times,
and may result in hangs or bus decode errors if accessed. Other
registers that are accessible may have read side-effects, and dumping
them may have adverse affects on stability or the functionality of
the affected peripheral.

Be safe, and skip dumping such addresses altogether.

CRs-Fixed: 625442
Change-Id: I4cfa75f027ededf841a0240715af0db385857cbe
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: Vignesh Radhakrishnan <vigneshr@codeaurora.org>
genirq: Introduce irq_do_set_affinity() to reduce duplicated code

All invocations of chip->irq_set_affinity() are doing the same return
value checks. Let them all use a common function.

[ tglx: removed the silly likely while at it ]

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Keping Chen <chenkeping@huawei.com>
Link: http://lkml.kernel.org/r/1333120296-13563-3-git-send-email-jiang.liu@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
fs/super.c: sync ro remount after blocking writers

Move sync_filesystem() after sb_prepare_remount_readonly().  If writers
sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
it can cause inodes to be dirtied and writeback to occur well after
sys_mount() has completely successfully.

This was spotted by corrupted ubifs filesystems on reboot, but appears
that it can cause issues with any filesystem using writeback.

CRs-Fixed: 627559
Change-Id: Ib417b59d39210aab2de4e5ae48b18129e8bc3e26
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
CC: Richard Weinberger <richard@nod.at>
Co-authored-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Git-commit: 807612db2f9940b9fa6deaef054eb16d51bd3e00
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
regulatory: use correct regulatory initiator on wiphy register

The current regdomain was not always set by the core. This causes
cards with a custom regulatory domain to ignore user initiated changes
if done before the card was registered.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
Acked-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-commit: 23df0b731954502a9391e739b92927cee4360343
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
CRs-Fixed: 569424
Change-Id: Ia5462145a27f5ecdd7a1eb9f4235992f7a801097
[smihir@codeaurora.org: changes to merge cleanly in older kernel]
Signed-off-by: Mihir Shete <smihir@codeaurora.org>
msm: acpuclock-krait: Enable HFPLL for init only if switching to it

The existing code left the HFPLL enabled in hfpll_init(), even if
the CPU was detected to be at a non-HFPLL rate. Correct this for
power savings between when hfpll_init() and the first runtime CPU
frequency switch happen. This also ensure votes for HFPLL
regulators are not left unnecessarily asserted.

Change-Id: Iaca5dc7e4769bdbd494d669726ba9b500256f793
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Remove extra defconfigs

Conflicts:
	arch/arm/configs/at91sam9g45_defconfig
	arch/arm/configs/fsm9xxx-perf_defconfig
	arch/arm/configs/mxs_defconfig

Change-Id: Icc58de766d712fc9607a682f1fb0681c563a8c0d
usb: Avoid incorrect memory leaks reported by kmemleak tool.

Certain memory allocations are not properly tracked by the kmemleak
tool, which causes it to incorrectly detect memory leaks. Notify the
tool by using kmemleak_not_leak() to ignore the memory allocation
so that incorrect leak reports are avoided.

CRs-Fixed: 612944
Change-Id: Ia15d94bb140f415a25d5b7e6996d3b985f33b28b
Signed-off-by: Saket Saurabh <ssaurabh@codeaurora.org>
d2: set to default interactive

We're setting this in userspace anyway

Change-Id: I80fafdd0c24219312d0961abc83c7b09a5322e3e