linux-stable.git/drivers/mmc, branch linux-4.8.y

mmc: sdhci: Fix recovery from tuning timeout

2017-01-09T07:21:46+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

mmc: sdhci-of-esdhc: fixup PRESENT_STATE read

2016-12-02T08:10:32+00:00

commit b0921d5c9ed6ffa8a4d6afc5ee5f136b87445f14 upstream.

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

mmc: mxs: Initialize the spinlock prior to using it

2016-11-18T09:51:52+00:00

commit f91346e8b5f46aaf12f1df26e87140584ffd1b3f upstream.

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

mmc: sdhci-msm: Fix error return code in sdhci_msm_probe()

2016-11-18T09:51:51+00:00

commit d1f63f0c81c22ba705fcd149a1fcec37b734d818 upstream.

Fix to return a negative error code from the platform_get_irq_byname()
error handling case instead of 0, as done elsewhere in this function.

Fixes: ad81d3871004 ("mmc: sdhci-msm: Add support for UHS cards")
Signed-off-by: Wei Yongjun 
Acked-by: Adrian Hunter 
Acked-by: Georgi Djakov 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

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

2016-11-18T09:51:46+00:00

commit fe1b5700c70faac6e027982d59667bc6020de5a8 upstream.

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.

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

mmc: sdhci: Fix unexpected data interrupt handling

2016-11-18T09:51:46+00:00

commit 69b962a65a547690a356f9f76bc4f53db538ac49 upstream.

In the busy response case (i.e. !host->data), an unexpected data interrupt
would result in clearing the data command as though it had completed but
without informing the upper layers and thus resulting in a hang.  Fix by
only clearing the data command for data interrupts that are expected.

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

mmc: sdhci: Fix CMD line reset interfering with ongoing data transfer

2016-11-18T09:51:46+00:00

commit 6ebebeab5185f50d55c6a24d0abe47e5dac1b191 upstream.

CMD line reset during an ongoing data transfer can cause the data transfer
to hang.  Fix by delaying the reset until the data transfer is finished.

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

mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference

2016-11-10T15:38:53+00:00

commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream.

platform_get_resource can be returned the NULL pointer.
Then regs->start should be referred to NULL Pointer.
devm_ioremap_resource() checks whether res is NULL or not.

Signed-off-by: Jaehoon Chung 
Reviewed-by: Shawn Lin 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led

2016-10-28T07:45:30+00:00

commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 upstream.

Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device,
must be done when it's runtime resumed. Currently this isn't case when
changing the led, so let's fix this by adding a pm_runtime_get_sync() and
a pm_runtime_put() around those operations.

Reported-by: Ritesh Raj Sarraf 
Tested-by: Ritesh Raj Sarraf 
Cc: Alan Stern 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused

2016-10-28T07:45:30+00:00

commit 31cf742f515c275d22843c4c756e048d2b6d716c upstream.

The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no
SD card is inserted. This is wrong, as it could cause the device to remain
runtime resumed when it's unused. Fix this behaviour.

Tested-by: Ritesh Raj Sarraf 
Cc: Alan Stern 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman