linux-stable.git/drivers/mmc/core, branch linux-3.14.y

mmc: longer timeout for long read time quirk

2016-06-01T19:12:47+00:00

commit 32ecd320db39bcb007679ed42f283740641b81ea upstream.

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk

Signed-off-by: Matt Gumbel 
Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: mmc: Fix partition switch timeout for some eMMCs

2016-06-01T19:12:47+00:00

commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 upstream.

Some eMMCs set the partition switch timeout too low.

Now typically eMMCs are considered a critical component (e.g. because
they store the root file system) and consequently are expected to be
reliable.  Thus we can neglect the use case where eMMCs can't switch
reliably and we might want a lower timeout to facilitate speedy
recovery.

Although we could employ a quirk for the cards that are affected (if
we could identify them all), as described above, there is little
benefit to having a low timeout, so instead simply set a minimum
timeout.

The minimum is set to 300ms somewhat arbitrarily - the examples that
have been seen had a timeout of 10ms but were sometimes taking 60-70ms.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

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

2016-03-03T23:06:51+00:00

commit d9bfbb95ed598a09cf336adb0f190ee0ff802f0d upstream.

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 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: core: fix race condition in mmc_wait_data_done

2015-10-01T09:36:15+00:00

commit 71f8a4b81d040b3d094424197ca2f1bf811b1245 upstream.

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: Greg Kroah-Hartman

mmc: core: add missing pm event in mmc_pm_notify to fix hib restore

2015-05-17T16:53:51+00:00

commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream.

The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:

WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access

Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().

Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'mmc-updates-for-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc

2014-01-26T19:00:41+00:00

Pull MMC updates from Chris Ball:
 "MMC highlights for 3.14:

  Core:
   - Avoid get_cd() on cards marked nonremovable

  Drivers:
   - arasan: New driver for controllers found in e.g. Xilinx Zynq SoC
   - dwmmc: Support Hisilicon K3 SoC controllers
   - esdhc-imx: Support for HS200 mode, DDR modes on MX6, runtime PM
   - sdhci-pci: Support O2Micro/BayHubTech controllers used in laptops
     like Lenovo ThinkPad W540, Dell Latitude E5440, Dell Latitude E6540
   - tegra: Support Tegra124 SoCs"

* tag 'mmc-updates-for-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (55 commits)
  mmc: sdhci-pci: Fix possibility of chip->fixes being null
  mmc: sdhci-pci: Fix BYT sd card getting stuck in runtime suspend
  mmc: sdhci: Allow for long command timeouts
  mmc: sdio: add a quirk for broken SDIO_CCCR_INTx polling
  mmc: sdhci: fix lockdep error in tuning routine
  mmc: dw_mmc: k3: remove clk_table
  mmc: dw_mmc: fix dw_mci_get_cd
  mmc: dw_mmc: fix sparse non static symbol warning
  mmc: sdhci-esdhc-imx: fix warning during module remove function
  mmc: sdhci-esdhc-imx: fix access hardirq-unsafe lock in atomic context
  mmc: core: sd: implement proper support for sd3.0 au sizes
  mmc: atmel-mci: add vmmc-supply support
  mmc: sdhci-pci: add broken HS200 quirk for Intel Merrifield
  mmc: sdhci: add quirk for broken HS200 support
  mmc: arasan: Add driver for Arasan SDHCI
  mmc: dw_mmc: add dw_mmc-k3 for k3 platform
  mmc: dw_mmc: use slot-gpio to handle cd pin
  mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts
  mmc: sdhci-pci: break out definitions to header file
  mmc: tmio: fixup compile error
  ...

Conflicts:
	MAINTAINERS

mmc: sdio: add a quirk for broken SDIO_CCCR_INTx polling

2014-01-18T03:55:01+00:00

Polling SDIO_CCCR_INTx could create a fake interrupt with Marvell
SD8797 card. Add a quirk to handle this case. The fixup here is
to issue a dummy CMD52 read to function 0 register 0xff, and this
dummy read must be right after SDIO_CCCR_INTx is read.

Patch has been verified on a dw_mmc controller (Samsung Chromebook)
with MMC_CAP_SDIO_IRQ disabled.

Signed-off-by: Bing Zhao 
Reviewed-by: Paul Stewart 
Reviewed-by: Doug Anderson 
Acked-by: Ulf Hansson 
Signed-off-by: Chris Ball

mmc: core: sd: implement proper support for sd3.0 au sizes

2014-01-13T19:02:35+00:00

This reverts and updates commit 77776fd0a4cc541b9 ("mmc: sd: fix the
maximum au_size for SD3.0"). The au_size for SD3.0 cannot be achieved
by a simple bit shift, so this needs to be implemented differently.
Also, don't print the warning in case of 0 since 'not defined' is
different from 'invalid'.

Signed-off-by: Wolfram Sang 
Acked-by: Jaehoon Chung 
Reviewed-by: H Hartley Sweeten 
Cc: stable  # [3.12, 3.13]
Signed-off-by: Chris Ball

mmc: Do not call get_cd for non removable cards

2014-01-13T17:48:17+00:00

Non removable cards are always present, so do not call get_cd for them.

Signed-off-by: Sascha Hauer 
Acked-by: Ulf Hansson 
Signed-off-by: Chris Ball

mmc: core: mmc DDR mode should not depend on UHS_DDR50

2014-01-13T17:48:05+00:00

The MMC_CAP_UHS_DDR50 must work on 1.8v.
However, the eMMC DDR mode can work on either 1.8v or 3.3v and
should not depend on UHS_DDR50.
So get rid of this limitation to let controller without 1.8v
signal voltage support can also work for eMMC DDR mode if it claims.

Signed-off-by: Dong Aisheng 
Acked-by: Shawn Guo 
Acked-by: Ulf Hansson 
Signed-off-by: Chris Ball