linux-stable.git/drivers/mmc/core, branch v5.3

Revert "mmc: core: do not retry CMD6 in __mmc_switch()"

2019-09-03T14:53:28+00:00

Turns out the commit 3a0681c7448b ("mmc: core: do not retry CMD6 in
__mmc_switch()") breaks initialization of a Toshiba THGBMNG5 eMMC card,
when using the meson-gx-mmc.c driver on a custom board based on Amlogic
A113D.

The CMD6 that switches the card into HS200 mode is then one that fails and
according to the below printed messages from the log:

[    1.648951] mmc0: mmc_select_hs200 failed, error -84
[    1.648988] mmc0: error -84 whilst initialising MMC card

After some analyze, it turns out that adding a delay of ~5ms inside
mmc_select_bus_width() but after mmc_compare_ext_csds() has been executed,
also fixes the problem. Adding yet some more debug code, trying to figure
out if potentially the card could be in a busy state, both by using CMD13
and ->card_busy() ops concluded that this was not the case.

Therefore, let's simply revert the commit that dropped support for retrying
of CMD6, as this also fixes the problem.

Fixes: 3a0681c7448b ("mmc: core: do not retry CMD6 in __mmc_switch()")
Cc: stable@vger.kernel.org
Signed-off-by: Jan Kaisrlik 
Signed-off-by: Ulf Hansson

mmc: core: Fix init of SD cards reporting an invalid VDD range

2019-08-30T07:17:53+00:00

The OCR register defines the supported range of VDD voltages for SD cards.
However, it has turned out that some SD cards reports an invalid voltage
range, for example having bit7 set.

When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
the invalid VDD range, this triggers the core to run a power cycle of the
card to try to initialize it at the lowest common supported voltage.
Obviously this fails, since the card can't support it.

Let's fix this problem, by clearing invalid bits from the read OCR register
for SD cards, before proceeding with the VDD voltage negotiation.

Cc: stable@vger.kernel.org
Reported-by: Philip Langdale 
Signed-off-by: Ulf Hansson 
Reviewed-by: Philip Langdale 
Tested-by: Philip Langdale 
Tested-by: Manuel Presnitz

mmc: mmc_spi: Enable stable writes

2019-07-22T13:31:00+00:00

While using the mmc_spi driver occasionally errors like this popped up:

mmcblk0: error -84 transferring data end_request: I/O error, dev mmcblk0, sector 581756

I looked on the Internet for occurrences of the same problem and came
across a helpful post [1]. It includes source code to reproduce the bug.
There is also an analysis about the cause. During transmission data in the
supplied buffer is being modified. Thus the previously calculated checksum
is not correct anymore.

After some digging I found out that device drivers are supposed to report
they need stable writes. To fix this I set the appropriate flag at queue
initialization if CRC checksumming is enabled for that SPI host.

[1]
https://groups.google.com/forum/#!msg/sim1/gLlzWeXGFr8/KevXinUXfc8J

Signed-off-by: Andreas Koop 
[shihpo: Rebase on top of v5.3-rc1]
Signed-off-by: ShihPo Hung 
Cc: Paul Walmsley 
CC: stable@vger.kernel.org
Signed-off-by: Ulf Hansson

Merge tag 'mmc-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

2019-07-12T01:11:21+00:00

Pull MMC updates from Ulf Hansson:
 "MMC core:
   - Let the dma map ops deal with bouncing and drop dma_max_pfn() from
     the dma-mapping interface for ARM
   - Convert the generic MMC DT doc to YAML schemas
   - Drop questionable support for powered-on re-init of SDIO cards at
     runtime resume and for SDIO HW reset
   - Prevent questionable re-init of powered-on removable SDIO cards at
     system resume
   - Cleanup and clarify some SDIO core code

  MMC host:
   - tmio: Make runtime PM enablement more flexible for variants
   - tmio/renesas_sdhi: Rename DT doc tmio_mmc.txt to renesas,sdhi.txt
     to clarify
   - sdhci-pci: Add support for Intel EHL
   - sdhci-pci-o2micro: Enable support for 8-bit bus
   - sdhci-msm: Prevent acquiring a mutex while holding a spin_lock
   - sdhci-of-esdhc: Improve clock management and tuning
   - sdhci_am654: Enable support for 4 and 8-bit bus on J721E
   - sdhci-sprd: Use pinctrl for a proper signal voltage switch
   - sdhci-sprd: Add support for HS400 enhanced strobe mode
   - sdhci-sprd: Enable PHY DLL and allow delay config to stabilize the
     clock
   - sdhci-sprd: Add support for optional gate clock
   - sunxi-mmc: Convert DT doc to YAML schemas
   - meson-gx: Add support for broken DRAM access for DMA

  MEMSTICK core:
   - Fixup error path of memstick_init()"

* tag 'mmc-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (52 commits)
  mmc: sdhci_am654: Add dependency on MMC_SDHCI_AM654
  mmc: alcor: remove a redundant greater or equal to zero comparison
  mmc: sdhci-msm: fix mutex while in spinlock
  mmc: sdhci_am654: Make some symbols static
  dma-mapping: remove dma_max_pfn
  mmc: core: let the dma map ops handle bouncing
  dt-binding: mmc: rename tmio_mmc.txt to renesas,sdhi.txt
  mmc: sdhci-sprd: Add pin control support for voltage switch
  dt-bindings: mmc: sprd: Add pinctrl support
  mmc: sdhci-sprd: Add start_signal_voltage_switch ops
  mmc: sdhci-pci: Add support for Intel EHL
  mmc: tmio: Use dma_max_mapping_size() instead of a workaround
  mmc: sdio: Drop unused in-parameter from mmc_sdio_init_card()
  mmc: sdio: Drop unused in-parameter to mmc_sdio_reinit_card()
  mmc: sdio: Don't re-initialize powered-on removable SDIO cards at resume
  mmc: sdio: Drop powered-on re-init at runtime resume and HW reset
  mmc: sdio: Move comment about re-initialization to mmc_sdio_reinit_card()
  mmc: sdio: Drop mmc_claim|release_host() in mmc_sdio_power_restore()
  mmc: sdio: Turn sdio_run_irqs() into static
  mmc: sdhci: Fix indenting on SDHCI_CTRL_8BITBUS
  ...

mmc: core: let the dma map ops handle bouncing

2019-07-10T11:17:30+00:00

Just like we do for all other block drivers. Especially as the limit
imposed at the moment might be way to pessimistic for iommus.

This also means we are not going to set a bounce limit for the queue, in
case we have a dma mask. On most architectures it was never needed, the
major hold out was x86-32 with PAE, but that has been fixed by now.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Ulf Hansson

mmc: sdio: Drop unused in-parameter from mmc_sdio_init_card()

2019-07-10T11:20:17+00:00

The "powered_resume" in-parameter to mmc_sdio_init_card() has now become
redundant as all callers set it to 0. Therefore let's just drop it.

Signed-off-by: Ulf Hansson 
Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson

mmc: sdio: Drop unused in-parameter to mmc_sdio_reinit_card()

2019-07-10T11:19:57+00:00

The "powered_resume" in-parameter to mmc_sdio_reinit_card() has now become
redundant as all callers set it to 0. Therefore let's just drop it.

Signed-off-by: Ulf Hansson 
Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson

mmc: sdio: Don't re-initialize powered-on removable SDIO cards at resume

2019-07-10T11:19:31+00:00

It looks like the original idea behind always doing a re-initialization of
a removable SDIO card during system resume in mmc_sdio_resume(), is to try
to play safe to detect whether the card has been removed.

However, this seems like a really a bad idea as it will most likely screw
things up, especially when the card is expected to remain powered on during
system suspend by the SDIO func driver.

Let's fix this, simply by trusting that the detect work checks if the card
is alive and inserted, which is being scheduled at the PM_POST_SUSPEND
notification anyway.

Signed-off-by: Ulf Hansson 
Tested-by: Douglas Anderson 
Reviewed-by: Douglas Anderson

mmc: sdio: Drop powered-on re-init at runtime resume and HW reset

2019-07-10T11:18:56+00:00

To use the so called powered-on re-initialization of an SDIO card, the
power to the card must obviously have stayed on. If not, the initialization
will simply fail.

In the runtime suspend case, the card is always powered off. Hence, let's
drop the support for powered-on re-initialization during runtime resume, as
it doesn't make sense.

Moreover, during a HW reset, the point is to cut the power to the card and
then do fresh re-initialization. Therefore drop the support for powered-on
re-initialization during HW reset.

Signed-off-by: Ulf Hansson 
Fixes: ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs are enabled")
Tested-by: Douglas Anderson

mmc: sdio: Move comment about re-initialization to mmc_sdio_reinit_card()

2019-07-10T11:18:29+00:00

The comment in mmc_sdio_power_restore() belongs in mmc_sdio_reinit_card(),
which was created during a previous commit that re-factored some code. Fix
this by moving the comment into mmc_sdio_reinit_card().

Signed-off-by: Ulf Hansson 
Reviewed-by: Douglas Anderson