linux-stable.git/drivers/mmc, branch v4.9.2

mmc: sd: Meet alignment requirements for raw_ssr DMA

2017-01-09T07:32:17+00:00

commit e85baa8868b016513c0f5738362402495b1a66a5 upstream.

The mmc_read_ssr() function results in DMA to the raw_ssr member of
struct mmc_card, which is not guaranteed to be cache line aligned & thus
might not meet the requirements set out in Documentation/DMA-API.txt:

  Warnings:  Memory coherency operates at a granularity called the cache
  line width.  In order for memory mapped by this API to operate
  correctly, the mapped region must begin exactly on a cache line
  boundary and end exactly on one (to prevent two separately mapped
  regions from sharing a single cache line).  Since the cache line size
  may not be known at compile time, the API will not enforce this
  requirement.  Therefore, it is recommended that driver writers who
  don't take special care to determine the cache line size at run time
  only map virtual regions that begin and end on page boundaries (which
  are guaranteed also to be cache line boundaries).

On some systems where DMA is non-coherent this can lead to us losing
data that shares cache lines with the raw_ssr array.

Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc
will ensure the buffer is suitably aligned, allowing the DMA to be
performed without any loss of data.

Signed-off-by: Paul Burton 
Fixes: 5275a652d296 ("mmc: sd: Export SD Status via “ssr” device attribute")
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: Fix recovery from tuning timeout

2017-01-09T07:32:17+00:00

commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter 
Tested-by: Dan O'Donovan 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

Revert "mmc: sdhci: Reset cmd and data circuits after tuning failure"

2017-01-09T07:32:17+00:00

commit 2ca71c27eeaeddae38efe24a84b20e22708a3d1d upstream.

This reverts commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits
after tuning failure").

A better fix is available, and it will be applied to older stable releases,
so get this out of the way by reverting it.

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

mmc: dw_mmc: fix the error handling for dma operation

2016-11-21T10:08:28+00:00

When dma->start is failed,then it has to fall back to PIO mode
for current transfer.

But Host controller was already set to bits relevant to DMA operation.
If needs to use the PIO mode, Host controller has to stop the DMA
operation. (It's more stable than now.)

When it occurred error, it's not running any request.

Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support")
Reported-by: Marek Szyprowski 
Signed-off-by: Jaehoon Chung 
Reviewed-by: Shawn Lin 
Cc:  # v4.3+
Signed-off-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson

mmc: sdhci-of-esdhc: fixup PRESENT_STATE read

2016-11-18T13:41:47+00:00

Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
cards in __mmc_switch()") the ESDHC driver is broken:
  mmc0: Card stuck in programming state! __mmc_switch
  mmc0: error -110 whilst initialising MMC card

Since this commit __mmc_switch() uses ->card_busy(), which is
sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
PRESENT_STATE register, specifically the DAT0 signal level bit. But the
ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
required to make the driver work again.

Signed-off-by: Michael Walle 
Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()")
Acked-by: Yangbo Lu 
Acked-by: Adrian Hunter 
Cc:  # v4.8+
Signed-off-by: Ulf Hansson

mmc: mxs: Initialize the spinlock prior to using it

2016-11-07T12:30:08+00:00

An interrupt may occur right after devm_request_irq() is called and
prior to the spinlock initialization, leading to a kernel oops,
as the interrupt handler uses the spinlock.

In order to prevent this problem, move the spinlock initialization
prior to requesting the interrupts.

Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Fabio Estevam 
Reviewed-by: Marek Vasut 
Signed-off-by: Ulf Hansson

mmc: mmc: Use 500ms as the default generic CMD6 timeout

2016-11-07T12:29:52+00:00

In the eMMC 4.51 version of the spec, an EXT_CSD field called
GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum
time it may need to move out from its busy state, when a CMD6 command has
been sent.

In cases when the card is compliant to versions < 4.51 of the eMMC spec,
obviously the core needs to use a fall-back value for this timeout, which
currently is set to 10 minutes. This value is completely in the wrong range
and importantly in some cases it causes a card initialization to take more
than 10 minute to complete.

Earlier this scenario was avoided as the mmc core used CMD13 to poll the
card, to find out when it stopped signaling busy. Commit 08573eaf1a70
("mmc: mmc: do not use CMD13 to get status after speed mode switch")
changed this behavior.

Instead of reverting that commit, which would cause other issues, let's
instead start by picking a simple solution for the problem, by using a
500ms default generic CMD6 timeout.

The reason for using exactly 500ms, comes from observations that shows it's
quite common for cards to specify 250ms. 500ms is two times that value so
likely it should be enough for most cards.

Cc:  # v4.8+
Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed
mode switch")
Signed-off-by: Ulf Hansson 
Tested-by: Stephen Boyd 
Tested-by: Linus Walleij

mmc: mmc_test: Fix "Commands during non-blocking write" tests

2016-11-07T12:28:38+00:00

mmc_test_check_result_async() requires that struct mmc_async_req is
contained within struct mmc_test_async_req. Fix the "Commands during
non-blocking write" tests so that is the case.

Fixes: 4bbb9aac9a9a ("mmc: mmc_test: Add tests for sending commands during transfer")
Signed-off-by: Adrian Hunter 
Tested-by: Ritesh Harjani 
Signed-off-by: Ulf Hansson

mmc: sdhci: Fix missing enhanced strobe setting during runtime resume

2016-11-07T12:26:43+00:00

Restore enhanced strobe setting during runtime resume.

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

mmc: sdhci: Reset cmd and data circuits after tuning failure

2016-11-07T12:26:43+00:00

To prevent subsequent commands failing, ensure the cmd and data circuits
are reset after a tuning timeout.

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