mmc: fix deadlock from mmc core when suspend the device

Hi Chris Ball & Greg KH,

This patch can fix the mmc deadlock when suspen the mmc devices.

when mmc_pm_notify to do the host->bus_ops->remove, there is deadlock,
because it was locked at mmc_claim_host, so it modify the mmc_claim_host
after the host->bus_ops->remove.
the problem can reproduce at lots of the emmc/sd devices when create
multi partitions,and I have tested this modify at lots of the platform.

Can this patch fixed?

Signed-off-by: LiuQi <liuqi@thundersoft.com>
Signed-off-by: Jack Qin <qinjian@thundersoft.com>
cpufreq: update lpj only if frequency has changed

During scaling up of cpu frequency, loops_per_jiffy
is updated upon invoking PRECHANGE notifier.
If setting to new frequency fails in cpufreq driver,
lpj is left at incorrect value.

Hence update lpj only if cpu frequency is changed,
i.e. upon invoking POSTCHANGE notifier.

Penalty would be that during time period between
changing cpu frequency & invocation of POSTCHANGE
notifier, udelay(x) may not gurantee minimal delay
of 'x' us for frequency scaling up operation.

Perhaps a better solution would be to define
CPUFREQ_ABORTCHANGE & handle accordingly, but then
it would be more intrusive (using ABORTCHANGE may
help drivers also; if any has registered notifier
and expect POST for a PRECHANGE, their needs can
be taken care using ABORT)

Signed-off-by: Afzal Mohammed <afzal@ti.com>
cpufreq:userspace: fix cpu_cur_freq updation

CPU frequency is guranteed to be changed on notifier callback with
CPUFREQ_POSTCHANGE. Notifier callback with CPUFREQ_PRECHANGE does
not gurantee a change in frequency; after it, if cpufreq driver is
unable to change CPU to new frequency. This results in wrong
information being fed to user (if setting CPU frequency fails)
upon doing like,

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

Hence in userspace governer update cpu_cur_freq only if notifier
has been called with POSTCHANGE.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
ARM: hwcaps: use shifts instead of hardcoded constants

The HWCAP numbers are defined as constants, each one being a power of 2.
This has become slightly unwieldy now that we have reached 32k.

This patch changes the HWCAP defines to use (1 << n) instead of coding
the constant directly. The values remain unchanged.

Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: hwcaps: add new HWCAP defines for ARMv7-A

Modern ARMv7-A cores can optionally implement these new hardware
features:

- VFPv4:
    The latest version of the ARMv7 vector floating-point extensions,
    including hardware support for fused multiple accumulate. D16 or D32
    variants may be implemented.

- Integer divide:
    The SDIV and UDIV instructions provide signed and unsigned integer
    division in hardware. When implemented, these instructions may be
    available in either both Thumb and ARM, or Thumb only.

This patch adds new HWCAP defines to describe these new features. The
integer divide capabilities are split into two bits for ARM and Thumb
respectively. Whilst HWCAP_IDIVA should never be set if HWCAP_IDIVT is
clear, separating the bits makes it easier to interpret from userspace.

Signed-off-by: Will Deacon <will.deacon@arm.com>
include/filter.h: add missing rcu_types.h for kernel usage
ARM: net: JIT compiler for packet filters

based of Matt Evans's PPC64 implementation.

The compiler generates ARM instructions but interworking is
supported for Thumb2 kernels.

Supports both little and big endian. Unaligned loads are emitted
for ARMv6+. Not all the BPF opcodes that deal with ancillary data
are supported. The scratch memory of the filter lives on the stack.
Hardware integer division is used if it is available.

Enabled in the same way as for x86-64 and PPC64:

	echo 1 > /proc/sys/net/core/bpf_jit_enable

A value greater than 1 enables opcode output.

Signed-off-by: Mircea Gherzan <mgherzan@xxxxxxxxx>
---

Changes in v7:
 * fix the intruction generation for LDX_MSH, OR_X, LSH_K,
   RSH_K and JMP_JA
 * fix the condition for saving the A register
 * use fls() instead of the compiler builtin
 * punt to the interpreter on absolute loads with K < 0
 * check for invalid data references
 * support the NEG opcode
 * clear X in the prologue based on a context flag
 * simplify the conditional jumps

Changes in v6:
 * fix the code generation for the ANC_CPU opcode

Changes in v5:
 * replace SEEN_LEN with SEEN_SKB
 * set ctx->seen when handling some ancillary data opcodes

Changes in v4:
 * first check if the JIT compiler is enabled
 * fix the code generation for the LDX_MSH opcode

Changes in v3:
 * no longer depend on EABI and !Thumb2
 * add BLX "emulation" for ARMv4 without Thumb
 * use the integer divide instruction on Cortex-A15
 * fix the handling of the DIV_K opcode
 * use a C wrapper for __aeabi_uidiv
 * fix the generation of the epilogue (non-FP case)

Changes in v2:
 * enable the compiler only for ARMv5+ because of the BLX instruction
 * use the same comparison for the ARM version checks
 * use misaligned accesses on ARMv6
 * fix the SEEN_MEM
 * fix the mem_words_used()

Conflicts:

	arch/arm/Kconfig
ARM: net: JIT compiler for packet filters enabled by default
mm: vmscan: check page order in isolating lru pages

Before attempting to take all pages in the order aligned region, check for
page order is added for minor optimization, since the pfn-based isolation
could be bypassed if the newly isolated page is no less than that region.

v1->v2 changes
1, the reason to add the check is described in change log,
2, the check is corrected,
3, comment for the check is corrected.

Thanks for all comments recieved.

Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Hillf Danton <dhillf@gmail.com>
mm: vmscan: recompute page status when putting back

If unlikely the given page is isolated from lru list again, its status is
recomputed before putting back to lru list, since the comment says page's
status can change while we move it among lru.

Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Hillf Danton <dhillf@gmail.com>
Revert "Init: Multithread initcalls to auto-resolve ordering issues."

This reverts commit fcfc1c4729b72ebfd8eb949e4c58529dc9868f43.
ARM: smp_twd: make sure timer is stopped before registration

On secondary CPUs, the Timer Control Register is not reset
to a sane value before the timer is registered, and the TRM
doesn't seem to indicate any reset value either. In some cases,
the kernel will take an interrupt too early, depending on what
junk was present in the registers at reset time.

The fix is to set the Timer Control Register to 0 before
registering the clock_event_device and enabling the interrupt.

Problem seen on VE (Cortex A5) and Tegra.

Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx>
PM / Hibernate: Correct additional page calculation

The struct bm_block is allocated by chain_alloc(),
so it'd better counting it in LINKED_PAGE_DATA_SIZE.

Signed-off-by: Namhyung Kim <namhyung.kim@lge.com>
hrtimers: teach usleep_range() to return how many usecs was slept

Teach usleep_range() to return how many usecs was actually spent in
sleep. The rationale beyond this is to convert jiffies-based time-bound
wait-for-hardware loops from using msleep() to usleep_range().

Signed-off-by: Dmitry Antipov <dmitry.antipov@linaro.org>
ARM: vmlinux.lds.S: do not hardcode cacheline size as 32 bytes

The linker script assumes a cacheline size of 32 bytes when aligning
the .data..cacheline_aligned and .data..percpu sections.

This patch updates the script to use L1_CACHE_BYTES, which should be set
to 64 on platforms that require it.

Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
ARM: vmlinux.lds.S: align the exception fixup table to a 4-byte boundary

The exception fixup table is currently aligned to a 32-byte boundary.
Whilst this won't cause any problems, the exception_table_entry
structures contain only a pair of unsigned longs, so 4-byte alignment
is all that is required.

Cc: Nicolas Pitre <nico@xxxxxxxxxxx>
Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
ARM: cache: assume 64-byte L1 cachelines for ARMv7 CPUs

To ensure correct alignment of cacheline-aligned data, the maximum
cacheline size needs to be known at compile time.

Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
that there will be future ARMv7 implementations with the same line size)
then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
size. For CPUs with smaller caches, this will result in some harmless
padding but will help with single zImage work and avoid hitting subtle
bugs with misaligned data structures.

Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
ARM: SMP: use a timing out completion for cpu hotplug

Rather than open-coding the jiffy-based wait, and polling for the
secondary CPU to come online, use a completion instead.  This
removes the need to poll, instead we will be notified when the
secondary CPU has initialized.

Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx>
block: Invalidate the cache for a parent block-device if blkdev_issue_flush()
was called for a partition

Executing a BLKFLSBUF-ioctl on a partition flushes the caches for that
partition but reading data through the parent device will still return
the old cached data.

The cache for the block-device is not synced if the block-device is kept
open (due to a mounted partition, for example). Only when all users for
the disk have exited, the cache for the disk is made consistent again.

Calling invalidate_bdev() on the parent block-device in case
blkdev_issue_flush() was called for a partition fixes this.

The problem can be worked around by forcing the caches to be flushed
with either
	# blockdev --flushbufs ${dev_disk}
or
	# echo 3 > /proc/sys/vm/drop_caches
CC: Bryn M. Reeves <bmr@redhat.com>
Signed-off-by: Niels de Vos <ndevos@redhat.com>
rtc: twl: Enable RTC irrespective of its prior state

From: Venu Byravarasu <vbyravarasu@nvidia.com>

As part of probe, before enabling RTC, RTC_CTRL register is read
to check if it is already running. If RTC is used by kernel alone,
then this read is not required. Even if RTC was enabled already by
boot loader, setting STOP_RTC bit again should not harm.
Hence removed unwanted read operation.

Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com>

Conflicts:

	drivers/rtc/rtc-twl.c