arch: arm: TLB invalidate if power collapse gets aborted

Invalidate entire local TLB in non sharable mode when
power collapse is aborted due to pending interrupt.

Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
kernel/smp.c: quit unconditionally enabling irqs in on_each_cpu_mask().

As in commit f21afc25f9ed ("smp.h: Use local_irq_{save,restore}() in
!SMP version of on_each_cpu()"), we don't want to enable irqs if they
are not already enabled.

I don't know of any bugs currently caused by this unconditional
local_irq_enable(), but I want to use this function in MIPS/OCTEON early
boot (when we have early_boot_irqs_disabled).  This also makes this
function have similar semantics to on_each_cpu() which is good in
itself.

Signed-off-by: David Daney <david.daney@cavium.com>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
genirq: Allow forcing cpu affinity of interrupts

The current implementation of irq_set_affinity() refuses rightfully to
route an interrupt to an offline cpu.

But there is a special case, where this is actually desired. Some of
the ARM SoCs have per cpu timers which require setting the affinity
during cpu startup where the cpu is not yet in the online mask.

If we can't do that, then the local timer interrupt for the about to
become online cpu is routed to some random online cpu.

The developers of the affected machines tried to work around that
issue, but that results in a massive mess in that timer code.

We have a yet unused argument in the set_affinity callbacks of the irq
chips, which I added back then for a similar reason. It was never
required so it got not used. But I'm happy that I never removed it.

That allows us to implement a sane handling of the above scenario. So
the affected SoC drivers can add the required force handling to their
interrupt chip, switch the timer code to irq_force_affinity() and
things just work.

This does not affect any existing user of irq_set_affinity().

Tagged for stable to allow a simple fix of the affected SoC clock
event drivers.

Reported-and-tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>,
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org,
Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs

Since commit 1dbfa187dad ("ARM: irq migration: force migration off CPU
going down") the ARM interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. At the point
of this change the argument had no effect because it was not used by
any interrupt chip driver and there was no semantics defined.

This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu
affinity of interrupts") which made the force argument useful to route
interrupts to not yet online cpus without checking the target cpu
against the cpu online mask. The following commit ffde1de64012
("irqchip: gic: Support forced affinity setting") implemented this for
the GIC interrupt controller.

As a consequence the ARM cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validataion against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.

Solve the issue by calling irq_set_affinity() with force=false from
the CPU offline irq migration code so the GIC driver validates the
affinity mask against CPU online mask and therefore removes CPU0 from
the possible target candidates.

Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
locks up as the IRQs are not migrated away from CPU0.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # 3.10.x
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: sdhci: Use DBG() instead of pr_warning() on large timeout

3bdc9ba892d6 ("mmc: use really long write timeout to deal with crappy
cards") in 3.4 increased the write timeout that the core sends to host
drivers to 3 seconds.  This makes sdhci's "requested timeout too large"
warning trigger on every write; so, change this pr_warning() to a DBG().

Change-Id: I3aada6581effdd619408badfae96ee580485ec84
Reported-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>

Conflicts:
	drivers/mmc/host/sdhci.c
mmc: core: Add MMC BKOPS statistics and debugfs ability to print them

The BKOPS statistics are used for BKOPS unit tests and APT tests
to determine test success or failure.
the BKOPS statstics provide the following information:
The number of times BKOPS were issued according to it's severity level
The number of times BKOPS were interrupted by HPI.
The number of times the host went into suspend

Change-Id: Ib84319aedfb49dc022bc27efbda842a5db38c7e9
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>

Conflicts:
	drivers/mmc/core/core.c
	include/linux/mmc/card.h
mmc: core: Fix updating clock scaling statistics

Due to stop transmission mechanism to handle high priority requests,
the update of clock scaling statistics is broken as the stop command
will re-enter host through mmc_start_request() and modifies ->start.busy
timestamp. If statistics are updated after sending stop command then
the duration of the interrupted command will be left unaccounted.

CRs-Fixed: 473385
Change-Id: Id671388efbfdd16981a262c0b1e5b95d119f51ae
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>

Conflicts:
	drivers/mmc/core/core.c
mmc: core: Expose access to RPMB partition

Following JEDEC standard, if the mmc support RPMB partition,
a new interface is created and exposed via /dev/block.
Users will be able to access RPMB partition using standard
mmc IOCTL command.

Change-Id: Ib8da61285f7a52499af1f9ac1071b19e2a47f6b3
Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Patch-mainline: v3.8
Git-commit: 090d25fe224c0933d2b261aad91532e725c1d889
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

Conflicts:
	include/linux/mmc/mmc.h
mmc: core: Bypass clock scaling while accessing RPMB partition

According to eMMC specification, only commands of classes 0, 2, 4
are admitted while accessing RPMB partition. Still usage of any
other command other than CMD0, CMD6, CMD8, CMD12, CMD13, CMD15,
CMD18, CMD23, CMD25 is illegal.

If the MMC clock scaling algorithm decides to switch the clocks
while accessing RPMB partition it might need to send tuning
command (CMD21) which is illegal.

Since RPMB accesses are short and doesn't depend on throughput
bypass clock scaling while the current partion mode is RPMB.
The clock scaling statistics still take into account the duration
of access and hence able to respond quickly on the transfers made
after partition switch.

Change-Id: I422f2e6acb33ab97105944e3f7f90c3afb37ef47
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Fix clock frequency transitions during invalid states

eMMC and SD card specifications restrict the usage of a class of
commands while commands in other class are in progress. For example,
during erase operations the SD/eMMC spec. allows only CMD35, CMD36,
CMD38. If clock scaling is enabled and decide to scale up the clocks
it may be possible that CMD19/21 tuning commands are sent in between
erase commands, which is illegal as per specification.

Fix such illegal transactions to the card and also make clock scaling
statistics accountable only for read/write commands instead of time
consuming commands, like CMD38 erase, where transactions are independent
of bus frequency.

Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: core: increase timeout for disable cache operation

According to eMMC specification, there is no upper bound defined on
a flush request and the duration of flush operation is left to card
vendor's implementation. This means that it may take a very long
time to complete.

When eMMC cache is disabled, the card has to flush all the data in its
cache. So this means that for certain cards, the driver is not waiting
long enough for the flush to complete during cache disable operation,
leading to data on the card being corrupted.

This change increases the timeout for cache disable operation, thus
preventing data corruption.

CRs-Fixed: 562350
Change-Id: If68328ab56b50c7596800f07ef92c0ab16a55ec0
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: David Ng <dave@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
mmc: core: fix issue with HPI polling timeout

Out of CPU time for the MMC context included into measured timeout. System
under heavy load will easily exceed out_of_int_time (typically 20 ms),
because  the MMC context is not running and when it is back to running,
timeout already elapsed. In this case real card status checked again and
error reported for wrong card state only.

Change-Id: I0da3bd2e7d41e4933ad3b1333d7135705a1eafec
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: hpi in TRAN state error handling

There could be a race condition in the stop transmission request.
1. Urgent read request comes in.
2. Stop the ongoing write request by calling stop_request MMC host op.
3. Send the stop command (CMD12) to move the card from the receive state
   to programming state.
4. Send the status command (CMD13) to know if the card is in programming
   state or not. If yes, then go to step.5 or else go to step.6.
5. Send the HPI command to bring the card out of programming state.
6. Now send the urgent read request.

In above sequence in step.4, we check if the card is in programming or
not and if it is then we go ahead and send the HPI in step.5 but what if
after step.4 is completed and before the step.5, card moves out of the
programming state so in that case HPI command would timeout as we are
sending it in the wrong state. In that case no command response (by eMMC
protocol) causes mmc_send_hpi_cmd to fail (with -ETIMEOUT error).  In
case the card indeed in TRAN state, no error is reported.

Change-Id: Ia6f81f6cc4ec933f2e8423029f7236401aea04df
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
correction for  mmc: card: Add BKOPS unit tests

The BKOPS tests check the following scenarios:
- Starting BKOPS delayed work, level 1
- Starting BKOPS delayed work, level 1, with HPI
- Cancel starting BKOPS delayed work, when a request is received
- Starting BKOPS urgent, level 2,3
- Starting BKOPS urgent with 2 requests
correction(2) for mmc: card: Add BKOPS unit tests

    The BKOPS tests check the following scenarios:
    - Starting BKOPS delayed work, level 1
    - Starting BKOPS delayed work, level 1, with HPI
    - Cancel starting BKOPS delayed work, when a request is received
    - Starting BKOPS urgent, level 2,3
    - Starting BKOPS urgent with 2 requests
mmc: core: Refactor bus speed selection code

The bus speed selection code in mmc_card_init() is convoluted, refactor
the code to simplify this and make it simpler for adding new bus speed
capabilities.

Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
mmc: core: Disable HPI for certain Hynix eMMC cards

Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.

As some of the other features like BKOPs/Cache/Sanitize are dependent on
HPI feature, those features would also get disabled if HPI is disabled.

Change-Id: I6a638ce089cbd977122e47aecb721bc3f0adf7b0
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>

Conflicts:
	drivers/mmc/core/mmc.c
mmc: core: Fix disabling of cache for Hynix cards

Commit f53e18514e11617c7111e0c8549a44077ab51e6c (mmc: card: quirk: disable cache for Hynix card)
claims to disable cache because of data corruption issues when cache
it is enabled. In reality, the patch allows enabling of cache during
card initialization but disallow flushing of cache during suspend or
file system sync operations. This is more dangerous than without
the commit. Move the fixups for disabling cache to mmc_fixups so as
to enable the quirk during initialization itself. Also, remove obvious
warnings everytime card is initialized during runtime resume.

Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: card: quirk: disable HPI for Kingston card

Certain Kingston eMMC 4.41 cards might get broken when HPI feature.
This quirk will disable the HPI feature for such buggy cards.

There are features depending on HPI, the change will disable them:
- BKOPS support
- stop transmission flow
- CACHE_CTRL

Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>