user/sven/linux.git/drivers/mmc, branch v4.2.5

mmc: sdhci-pxav3: fix error handling of armada_38x_quirks

2015-10-22T21:49:33Z

commit 2162d9f41e7c4778b96b8e3b97adcedbadc861f1 upstream. In case of armada_38x_quirks error, all clocks should be cleaned-up, same as after mv_conf_mbus_windows failure. Signed-off-by: Marcin Wojtas Reviewed-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-pxav3: disable clock inversion for HS MMC cards

2015-10-22T21:49:33Z

commit fa7964147da57b2d40c2db2b6ed98fb7dc934bff upstream. According to 'FE-2946959' erratum the clock inversion option is needed to support slow frequencies when the card input hold time requirement is high. This setting is not required for high speed MMC and might cause timing violation. Signed-off-by: Nadav Haklai Reviewed-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-pxav3: remove broken clock base quirk for Armada 38x sdhci driver

2015-10-22T21:49:33Z

commit 5de76bfcb1e5ac66c57b99e8e193dacac7416f0e upstream. shci-pxav3 driver is enabling by default the SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN quirk. However this quirk is not required for Armada 38x and leads to wrong clock setting in the divider. Signed-off-by: Nadav Haklai Signed-off-by: Marcin Wojtas Reviewed-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: fix dead loop of mmc_retune

2015-10-22T21:49:32Z

commit 031277d4d33d33f0174fbb569ca8f68238175617 upstream. When get a CRC error, start the mmc_retune, it will issue CMD19/CMD21 to do tune, assume there were 10 clock phase need to try, phase 0 to phase 6 is ok, phase 7 to phase 9 is NG, we try it from 0 to 9, so the last CMD19/CMD21 will get CRC error, host->need_retune was set and cause mmc_retune was called, then dead loop of mmc_retune Signed-off-by: Chaotian Jing Acked-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: core: Don't return an error for CD/WP GPIOs when GPIOLIB is unset

2015-10-22T21:49:32Z

commit 43934ece2ea72c1dd279c0b0478c1a036d5d77ee upstream. When CONFIG_GPIOLIB is unset, its stubs will return -ENOSYS. That means when the mmc core parses DT for CD/WP GPIOs via mmc_of_parse(), -ENOSYS becomes propagated to the caller. Typically this means that the mmc host driver fails to probe. As the CD/WP GPIOs are already treated as optional, let's extend that to cover the case when CONFIG_GPIOLIB is unset. Reported-by: Michal Simek Fixes: 16b23787fc70 ("mmc: sdhci-of-arasan: Call OF parsing for MMC") Signed-off-by: Ulf Hansson Tested-by: Michal Simek Acked-by: Venu Byravarasu Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used

2015-10-22T21:49:27Z

commit 5959b32e3636f9bfe3f869d1e440bc4a4d660965 upstream. As per DW MobileStorage databook "each descriptor can transfer up to 4kB of data in chained mode", moreover buffer size that is put in "des1" is limited to 13 bits, i.e. for example on attempt to IDMAC_SET_BUFFER1_SIZE(desc, 8192) size value that's effectively written will be 0. On the platform with 8kB PAGE_SIZE I see dw_mmc gets data blocks in SG-list of 8kB size and that leads to unpredictable behavior of the SD/MMC controller. In particular on write to FAT partition of SD-card the controller will stuck in the middle of DMA transaction. Solution to the problem is simple - we need to pass large (> 4kB) data buffers to the controller via multiple descriptors. And that's what that change does. What's interesting I did try original driver on same platform but configured with 4kB PAGE_SIZE and may confirm that data blocks passed in SG-list to dw_mmc never exeed 4kB limit - that explains why nobody ever faced a problem I did. Signed-off-by: Alexey Brodkin Cc: Seungwon Jeon Cc: Jaehoon Chung Cc: Ulf Hansson Cc: arc-linux-dev@synopsys.com Cc: linux-kernel@vger.kernel.org Signed-off-by: Jaehoon Chung Signed-off-by: Greg Kroah-Hartman

mmc: core: fix race condition in mmc_wait_data_done

2015-09-29T17:33:33Z

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: sdhci: fix dma memory leak in sdhci_pre_req()

2015-09-29T17:33:33Z

commit d31911b9374a76560d2c8ea4aa6ce5781621e81d upstream. Currently one mrq->data maybe execute dma_map_sg() twice when mmc subsystem prepare over one new request, and the following log show up: sdhci[sdhci_pre_dma_transfer] invalid cookie: 24, next-cookie 25 In this condition, mrq->date map a dma-memory(1) in sdhci_pre_req for the first time, and map another dma-memory(2) in sdhci_prepare_data for the second time. But driver only unmap the dma-memory(2), and dma-memory(1) never unmapped, which cause the dma memory leak issue. This patch use another method to map the dma memory for the mrq->data which can fix this dma memory leak issue. Fixes: 348487cb28e6 ("mmc: sdhci: use pipeline mmc requests to improve performance") Reported-and-tested-by: Jiri Slaby Signed-off-by: Haibo Chen Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: also get preset value and driver type for MMC_DDR52

2015-09-29T17:33:33Z

commit 0dafa60eb2506617e6968b97cc5a44914a7fb1a6 upstream. commit bb8175a8aa42 ("mmc: sdhci: clarify DDR timing mode between SD-UHS and eMMC") added MMC_DDR52 as eMMC's DDR mode to be distinguished from SD-UHS, but it missed setting driver type for MMC_DDR52 timing mode. So sometimes we get the following error on Marvell BG2Q DMP board: [ 1.559598] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00 [ 1.569314] mmcblk0: retrying using single block read [ 1.575676] mmcblk0: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0 [ 1.585202] blk_update_request: I/O error, dev mmcblk0, sector 2 [ 1.591818] mmcblk0: error -84 transferring data, sector 3, nr 5, cmd response 0x900, card status 0x0 [ 1.601341] blk_update_request: I/O error, dev mmcblk0, sector 3 This patches fixes this by adding the missing driver type setting. Fixes: bb8175a8aa42 ("mmc: sdhci: clarify DDR timing mode ...") Signed-off-by: Jisheng Zhang Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-of-esdhc: add workaround for pre divider initial value

2015-09-29T17:33:33Z

commit 77bd2f6f6c65b4ad259394d416855ed561f21e8f upstream. For eSDHC(version < 2.3), the pre divider only could divide base clock by 2 at least. Add workaround for this to avoid unexpected issue. Signed-off-by: Yangbo Lu Acked-by: Joakim Tjernlund Fixes: bd455029d01c ("mmc: sdhci-of-esdhc: Pre divider starts at 1") Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman