linux-stable.git/drivers/mmc, branch v3.18.28

mmc: core: Enable tuning according to the actual timing

2016-02-10T03:57:04+00:00

[ Upstream commit e10c321977091f163eceedec0650e0ef4b3cf4bb ]

While in sdhci_execute_tuning() the choice whether or not to enable the
tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the
check is done on the capability of the card.

This difference is causing some issues with some SDIO cards in DDR50
mode where the CDM19 is wrongly issued.

With this patch we modify the check in both
mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision
only according to the actual timing specification.

Cc: stable@vger.kernel.org
Signed-off-by: Carlo Caione 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: core: enable CMD19 tuning for DDR50 mode

2016-02-10T03:57:02+00:00

[ Upstream commit 4324f6de6d2eb9b232410eb0d67bfafdde8ba711 ]

As SD Specifications Part1 Physical Layer Specification Version
3.01 says, CMD19 tuning is available for unlocked cards in transfer
state of 1.8V signaling mode. The small difference between v3.00
and 3.01 spec means that CMD19 tuning is also available for DDR50
mode.

Signed-off-by: Weijun Yang 
Signed-off-by: Barry Song 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: core: Simplify by adding mmc_execute_tuning()

2016-02-10T03:56:52+00:00

[ Upstream commit 63e415c64003fd62a302a1dc19f082e2c6f1b7cc ]

For each MMC, SD and SDIO there is code that
holds the clock, calls ops->execute_tuning, and
releases the clock. Simplify the code a bit by
providing a separate function to do that.

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

mmc: core: Fix error paths and messages in mmc_init_card

2016-02-10T03:56:51+00:00

[ Upstream commit 4b75bffc77c40ac3c17a3ea9bbdc3a733c34591b ]

In mmc_init_card function some of the branches in error handling paths
go to "err" label, which skips removing of newly allocated card structure,
that will actually not be used. Fix that by using proper "free_card" label.

Also, some messages in these branches are reported as warnings,
although the operation processing is not continued. Change these
messages to error level.

Signed-off-by: Andrew Gabbasov 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: mmci: fix an ages old detection error

2016-02-10T03:56:51+00:00

[ Upstream commit 0bcb7efdff63564e80fe84dd36a9fbdfbf6697a4 ]

commit 4956e10903fd ("ARM: 6244/1: mmci: add variant data and default
MCICLOCK support") added variant data for ARM, U300 and Ux500 variants.
The Nomadik NHK8815/8820 variant was erroneously labeled as a U300
variant, and when the proper Nomadik variant was later introduced in
commit 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik MMCI
variant") this was not fixes. Let's say this fixes the latter commit as
there was no proper Nomadik support until then.

Cc: stable@vger.kernel.org
Fixes: 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik...")
Signed-off-by: Linus Walleij 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci: Fix sdhci_runtime_pm_bus_on/off()

2016-02-10T03:55:41+00:00

[ Upstream commit 5c671c410c8704800f4f1673b6f572137e7e6ddd ]

sdhci has a legacy facility to prevent runtime suspend if the
bus power is on.  This is needed in cases where the power to
the card is dependent on the bus power.  It is controlled by
a pair of functions: sdhci_runtime_pm_bus_on() and
sdhci_runtime_pm_bus_off().  These functions use a boolean
variable 'bus_on' to ensure changes are always paired.
There is an additional check for 'runtime_suspended' which is
the problem.  In fact, its use is ill-conceived as the only
requirement for the logic is that 'on' and 'off' are paired,
which is actually broken by the check, for example if the bus
power is turned on during runtime resume.  So remove  the check.

Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org # v3.11+
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdio: Fix invalid vdd in voltage switch power cycle

2016-02-10T03:55:40+00:00

[ Upstream commit d9bfbb95ed598a09cf336adb0f190ee0ff802f0d ]

The 'ocr' parameter passed to mmc_set_signal_voltage()
defines the power-on voltage used when power cycling
after a failure to set the voltage.  However, in the
case of mmc_sdio_init_card(), the value passed has the
R4_18V_PRESENT flag set which is not valid for power-on
and results in an invalid vdd.  Fix by passing the card's
ocr value which does not have the flag.

Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: core: fix race condition in mmc_wait_data_done

2015-10-07T14:19:43+00:00

[ Upstream commit 71f8a4b81d040b3d094424197ca2f1bf811b1245 ]

The following panic is captured in ker3.14, but the issue still exists
in latest kernel.
---------------------------------------------------------------------
[   20.738217] c0 3136 (Compiler) Unable to handle kernel NULL pointer dereference
at virtual address 00000578
......
[   20.738499] c0 3136 (Compiler) PC is at _raw_spin_lock_irqsave+0x24/0x60
[   20.738527] c0 3136 (Compiler) LR is at _raw_spin_lock_irqsave+0x20/0x60
[   20.740134] c0 3136 (Compiler) Call trace:
[   20.740165] c0 3136 (Compiler) [] _raw_spin_lock_irqsave+0x24/0x60
[   20.740200] c0 3136 (Compiler) [] __wake_up+0x1c/0x54
[   20.740230] c0 3136 (Compiler) [] mmc_wait_data_done+0x28/0x34
[   20.740262] c0 3136 (Compiler) [] mmc_request_done+0xa4/0x220
[   20.740314] c0 3136 (Compiler) [] sdhci_tasklet_finish+0xac/0x264
[   20.740352] c0 3136 (Compiler) [] tasklet_action+0xa0/0x158
[   20.740382] c0 3136 (Compiler) [] __do_softirq+0x10c/0x2e4
[   20.740411] c0 3136 (Compiler) [] irq_exit+0x8c/0xc0
[   20.740439] c0 3136 (Compiler) [] handle_IRQ+0x48/0xac
[   20.740469] c0 3136 (Compiler) [] gic_handle_irq+0x38/0x7c
----------------------------------------------------------------------
Because in SMP, "mrq" has race condition between below two paths:
path1: CPU0: 
  static void mmc_wait_data_done(struct mmc_request *mrq)
  {
     mrq->host->context_info.is_done_rcv = true;
     //
     // If CPU0 has just finished "is_done_rcv = true" in path1, and at
     // this moment, IRQ or ICache line missing happens in CPU0.
     // What happens in CPU1 (path2)?
     //
     // If the mmcqd thread in CPU1(path2) hasn't entered to sleep mode:
     // path2 would have chance to break from wait_event_interruptible
     // in mmc_wait_for_data_req_done and continue to run for next
     // mmc_request (mmc_blk_rw_rq_prep).
     //
     // Within mmc_blk_rq_prep, mrq is cleared to 0.
     // If below line still gets host from "mrq" as the result of
     // compiler, the panic happens as we traced.
     wake_up_interruptible(&mrq->host->context_info.wait);
  }

path2: CPU1: 
  static int mmc_wait_for_data_req_done(...
  {
     ...
     while (1) {
           wait_event_interruptible(context_info->wait,
                   (context_info->is_done_rcv ||
                    context_info->is_new_req));
     	   static void mmc_blk_rw_rq_prep(...
           {
           ...
           memset(brq, 0, sizeof(struct mmc_blk_request));

This issue happens very coincidentally; however adding mdelay(1) in
mmc_wait_data_done as below could duplicate it easily.

   static void mmc_wait_data_done(struct mmc_request *mrq)
   {
     mrq->host->context_info.is_done_rcv = true;
+    mdelay(1);
     wake_up_interruptible(&mrq->host->context_info.wait);
    }

At runtime, IRQ or ICache line missing may just happen at the same place
of the mdelay(1).

This patch gets the mmc_context_info at the beginning of function, it can
avoid this race condition.

Signed-off-by: Jialing Fu 
Tested-by: Shawn Lin 
Fixes: 2220eedfd7ae ("mmc: fix async request mechanism ....")
Signed-off-by: Shawn Lin 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-esdhc: Make 8BIT bus work

2015-08-27T17:25:44+00:00

[ Upstream commit 8e91125ff3f57f15c6568e2a6d32743b3f7815e4 ]

Support for 8BIT bus with was added some time ago to sdhci-esdhc but
then missed to remove the 8BIT from the reserved bit mask which made
8BIT non functional.

Fixes: 66b50a00992d ("mmc: esdhc: Add support for 8-bit bus width and..")
Signed-off-by: Joakim Tjernlund 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: card: Fixup request missing in mmc_blk_issue_rw_rq

2015-08-04T18:35:17+00:00

[ Upstream commit 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 ]

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 
Signed-off-by: Sasha Levin