linux.git/drivers/mmc, branch v4.9-rc2

mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led

2016-10-17T13:43:03+00:00

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: 
Cc: Alan Stern 
Signed-off-by: Ulf Hansson

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

2016-10-17T13:42:25+00:00

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: 
Cc: Alan Stern 
Signed-off-by: Ulf Hansson

mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error

2016-10-17T13:16:20+00:00

Potentially overflowing expression 1000000 * data->timeout_clks with
type unsigned int is evaluated using 32-bit arithmetic, and then used
in a context that expects an expression of type unsigned long long.

To avoid overflow, cast 1000000U to type unsigned long long.
Special thanks to Coverity.

Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)")
Signed-off-by: Haibo Chen 
Cc: stable@vger.kernel.org # v3.15+
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: sdhci-esdhc-imx: Correct two register accesses

2016-10-13T06:58:03+00:00

- The DMA error interrupt bit is in a different position as
   compared to the sdhci standard.  This is accounted for in
   many cases, but not handled in the case of clearing the
   INT_STATUS register by writing a 1 to that location.
 - The HOST_CONTROL register is very different as compared to
   the sdhci standard.  This is accounted for in the write
   case, but not when read back out (which it is in the sdhci
   code).

Signed-off-by: Dave Russell 
Signed-off-by: Aaron Brice 
Acked-by: Dong Aisheng 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: sdhci-pci: Fix bus power failing to enable for some Intel controllers

2016-10-10T12:20:52+00:00

Some Intel controllers (e.g. BXT) might fail to set bus power after a
D3 -> D0 transition due to the present state not yet having propagated.
Retry for up to 2 milliseconds.

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

mmc: sdhci-pci: Let devices define their own sdhci_ops

2016-10-10T12:20:48+00:00

Let devices define their own sdhci_ops so that device-specific variations
can be implemented without adding quirks.

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

mmc: sdhci: Rename sdhci_set_power() to sdhci_set_power_noreg()

2016-10-10T12:20:41+00:00

Unlike other cases, sdhci_set_power() does not reflect the default
implementation of the ->set_power() callback. Rename it and create
sdhci_set_power() that is the default implementation.

Signed-off-by: Adrian Hunter 
Cc: Jisheng Zhang 
Signed-off-by: Ulf Hansson

mmc: sdhci: Fix SDHCI_QUIRK2_STOP_WITH_TC

2016-10-10T12:20:34+00:00

Multi-block data transfers can specify the number of blocks either using a
Set Block Count command (CMD23) or by sending a STOP command (CMD12) after
the required number of blocks has transferred. CMD23 is preferred, but some
cards don't support it. CMD12 with R1b response is used for writes, and
R1 response for reads.

Some SDHCI host controllers give a Transfer Complete (TC) interrupt for the
STOP command (CMD12) whether or not a R1b response has been specified. The
quirk SDHCI_QUIRK2_STOP_WITH_TC identifies those host controllers, but the
implementation only considers the case where the TC interrupt arrives at
the same time as the Command Complete (CC) interrupt. However,
occasionally TC arrives before CC. That is harmless, but does generate an
error message "Got data interrupt 0x00000002 even though no data operation
was in progress".

A simpler approach is to force R1b response onto all STOP commands, because
SDHCI will handle TC before CC in the general case, so do that.

Signed-off-by: Adrian Hunter 
Cc: Giuseppe Cavallaro 
Signed-off-by: Ulf Hansson

mmc: core: Annotate cmd_hdr as __le32

2016-10-10T12:14:49+00:00

Commit f68381a70bb2 (mmc: block: fix packed command header endianness)
correctly fixed endianness handling of packed_cmd_hdr in
mmc_blk_packed_hdr_wrq_prep.

But now, sparse complains about incorrect types:
drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
drivers/mmc/card/block.c:1613:27:    expected unsigned int [unsigned] [usertype] 
drivers/mmc/card/block.c:1613:27:    got restricted __le32 [usertype] 
...

So annotate cmd_hdr properly using __le32 to make everyone happy.

Signed-off-by: Jiri Slaby 
Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness)
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson

mmc: sdhci-of-arasan: add sdhci_arasan_voltage_switch for arasan, 5.1

2016-10-10T12:01:33+00:00

Per the vendor's requirement, we shouldn't do any setting for
1.8V Signaling Enable, otherwise the interaction/behaviour between
phy and controller will be undefined. Mostly it works fine if we do
that, but we still see failures. Anyway, let's fix it to meet the
vendor's requirement. The error log looks like:

 [   93.405085] mmc1: unexpected status 0x800900 after switch
 [   93.408474] mmc1: switch to bus width 1 failed
 [   93.408482] mmc1: mmc_select_hs200 failed, error -110
 [   93.408492] mmc1: error -110 during resume (card was removed?)
 [   93.408705] PM: resume of devices complete after 213.453 msecs

Signed-off-by: Shawn Lin 
Acked-by: Adrian Hunter 
Reviewed-by: Douglas Anderson 
Signed-off-by: Ulf Hansson