linux-stable.git/drivers/mmc/card, branch linux-4.2.y

mmc: core: Fix init_card in 52Mhz

2015-11-09T22:37:30+00:00

commit 08b137d90eec51b0e90c42e123ca8ceb118d233f upstream.

Suppose that we got a data crc error, and it triggers the mmc_reset.
mmc_reset will call mmc_send_status to see if HW reset was supported.
before issue CMD13, it will do retune, and if EMMC was in HS400 mode,
it will reduce frequency to 52Mhz firstly, then results in card init
was doing at 52Mhz.
The mmc_send_status was originally only done for mmc_test, should drop
it. And, rename the "eMMC hardware reset" to "Reset test", as we would
also be able to use the test for SD-cards.

Signed-off-by: Chaotian Jing 
Suggested-by: Adrian Hunter 
Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: block: Add missing mmc_blk_put() in power_ro_lock_show()

2015-07-24T08:18:34+00:00

Enclosing mmc_blk_put() is missing in power_ro_lock_show() sysfs handler,
let's add it.

Fixes: add710eaa886 ("mmc: boot partition ro lock support")
Signed-off-by: Tomas Winkler 
Signed-off-by: Ulf Hansson

mmc: queue: prevent soft lockups on PREEMPT=n

2015-06-18T07:21:04+00:00

On systems with CONFIG_PREEMPT=n, under certain circumstances, mmcqd
can continuously process requests for several seconds without blocking,
triggering the soft lockup watchdog.  For example, this can happen if
mmcqd runs on the CPU which services the controller's interrupt, and
a process on a different CPU continuously writes to the MMC block
device.

 NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [mmcqd/0:664]
 CPU: 0 PID: 664 Comm: mmcqd/0 Not tainted 4.1.0-rc7+ #4
 PC is at _raw_spin_unlock_irqrestore+0x24/0x28
 LR is at mmc_start_request+0x104/0x134
 ...
 [<805112a8>] (_raw_spin_unlock_irqrestore) from [<803db664>] (mmc_start_request+0x104/0x134)
 [<803db664>] (mmc_start_request) from [<803dc008>] (mmc_start_req+0x274/0x394)
 [<803dc008>] (mmc_start_req) from [<803eb2c4>] (mmc_blk_issue_rw_rq+0xd0/0xb98)
 [<803eb2c4>] (mmc_blk_issue_rw_rq) from [<803ebe8c>] (mmc_blk_issue_rq+0x100/0x470)
 [<803ebe8c>] (mmc_blk_issue_rq) from [<803ecab8>] (mmc_queue_thread+0xd0/0x170)
 [<803ecab8>] (mmc_queue_thread) from [<8003fd14>] (kthread+0xe0/0xfc)
 [<8003fd14>] (kthread) from [<8000f768>] (ret_from_fork+0x14/0x2c)

Fix it by adding a cond_resched() in the request handling loop so that
other processes get a chance to run.

Signed-off-by: Rabin Vincent 
Signed-off-by: Ulf Hansson

mmc: card: Fixup request missing in mmc_blk_issue_rw_rq

2015-06-16T06:58:36+00:00

The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
may cause new coming request permanent missing when the ongoing
request (previoulsy started) complete end.

The problem scenario is as follows:
(1) Request A is ongoing;
(2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called;
(3) Request A encounters the MMC_BLK_CMD_ERR error;
(4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err()
    end request A completed and return zero. Continue the error handling,
    suppose mmc_blk_reset() reset device success;
(5) Continue the execution, while loop completed because variable ret
    is zero now;
(6) Finally, mmc_blk_issue_rw_rq() return without processing request B.

The process related to the missing request may wait that IO request
complete forever, possibly crashing the application or hanging the system.

Fix this issue by starting new request when reset success.

Signed-off-by: Ding Wang 
Fixes: 67716327eec7 ("mmc: block: add eMMC hardware reset support")
Signed-off-by: Ulf Hansson

mmc: queue: use swap() in mmc_queue_thread()

2015-06-15T08:26:29+00:00

Use kernel.h macro definition.

Thanks to Julia Lawall for Coccinelle scripting support.

Signed-off-by: Fabian Frederick 
Signed-off-by: Ulf Hansson

mmc: mmc-test: use swap() in mmc_test_nonblock_transfer()

2015-06-01T07:07:08+00:00

Use kernel.h macro definition.

Signed-off-by: Fabian Frederick 
Signed-off-by: Ulf Hansson

mmc: cast unsigned int to typeof(sector_t) to avoid unexpected error

2015-06-01T07:07:03+00:00

card->csd.capacity is defined as "unsigned int", and sector_t is defined as
"u64" or "unsigned long" (depends on CONFIG_LBDAF). Thus, sector_t data
might have strange data (see below). This patch cast it to typeof(sector_t)
Special thanks to coverity 

ex) if sector_t was u64

        unsigned int data;
        sector_t sector;

        data = 0x800000;
        sector = (data << 8); // 0xffffffff80000000
        sector = (((typeof(sector_t))data) << 8); // 0x80000000

or

        data = 0x80000000;
        sector = (data << 8); // 0x0
        sector = (((typeof(sector_t))data) << 8); // 0x8000000000

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Ulf Hansson

mmc: card: mmc_test: Simplify a trivial if-return sequence

2015-06-01T07:07:01+00:00

Simplify a trivial if-return sequence. Possibly combine with a
preceding function call.

The semantic patch that makes this change is available
in scripts/coccinelle/misc/simple_return.cocci.

More information about semantic patching is available at
http://coccinelle.lip6.fr/

Signed-off-by: Fabio Estevam 
Signed-off-by: Ulf Hansson

mmc: block: Retry errored data requests when re-tuning is needed

2015-06-01T07:06:59+00:00

Retry errored data requests when re-tuning is needed and
add a flag to struct mmc_blk_request so that the retry
is only done once.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: block: Check re-tuning in the recovery path

2015-06-01T07:06:58+00:00

If re-tuning is needed, do it in the recovery path to
give recovery commands a better chance of success.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson