linux-toradex.git/drivers/mmc/host, branch v4.4.44

mmc: sdhci: Fix recovery from tuning timeout

2017-01-09T07:07:43+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: mxs: Initialize the spinlock prior to using it

2016-11-18T09:48:37+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: dw_mmc-pltfm: fix the potential NULL pointer dereference

2016-11-10T15:36:35+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:01:35+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:01:35+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

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

2016-10-28T07:01:26+00:00

commit 02265cd60335a2c1417abae4192611e1fc05a6e5 upstream.

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

mmc: pxamci: fix potential oops

2016-10-07T13:23:41+00:00

commit b3802db5eb72d2a96f4aa4ff0abb937033df2acf upstream.

As reported by Dan in his report in [1], there is a potential NULL
pointer derefence if these conditions are met :
 - there is no platform_data provided, ie. host->pdata = NULL

Fix this by only using the platform data ro_invert when a gpio for
read-only is provided by the platform data.

This doesn't appear yet as every pxa board provides a platform_data, and
calls pxa_set_mci_info() with a non NULL pointer.

[1] [bug report] mmc: pxamci: fix card detect with slot-gpio API.
The commit fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio
API") from Sep 26, 2015, leads to the following static checker warning:

	drivers/mmc/host/pxamci.c:809 pxamci_probe()
	warn: variable dereferenced before check 'host->pdata' (see line 798)

Fixes: fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio API")
Reported-by: Dan Carpenter 
Signed-off-by: Robert Jarzmik 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: use resource_size_t to store physical address

2016-09-24T08:07:42+00:00

commit 260b31643691e8a58683a4ccc3bdf7abfd86f54a upstream.

The dw_mmc driver stores the physical address of the MMIO registers
in a pointer, which requires the use of type casts, and is actually
broken if anyone ever has this device on a 32-bit SoC in registers
above 4GB. Gcc warns about this possibility when the driver is built
with ARM LPAE enabled:

mmc/host/dw_mmc.c: In function 'dw_mci_edmac_start_dma':
mmc/host/dw_mmc.c:702:17: warning: cast from pointer to integer of different size
  cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);
                 ^
mmc/host/dw_mmc-pltfm.c: In function 'dw_mci_pltfm_register':
mmc/host/dw_mmc-pltfm.c:63:19: warning: cast to pointer from integer of different size
  host->phy_regs = (void *)(regs->start);

This changes the code to use resource_size_t, which gets rid of the
warning, the bug and the useless casts.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: Do not BUG on invalid vdd

2016-09-15T06:27:45+00:00

[ Upstream commit 9d5de93f6d543b356e39e225988ef443a7bce34c ]

The driver may not be able to set the power correctly but that
is not a reason to BUG().

Signed-off-by: Adrian Hunter 
Reviewed-by: Venu Byravarasu 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: 64-bit DMA actually has 4-byte alignment

2016-09-15T06:27:44+00:00

[ Upstream commit 04a5ae6fdd018af29675eb8b6c2550c87f471570 ]

The version 3.00 SDHCI spec. was a bit unclear about the
required data alignment for 64-bit DMA, whereas the version
4.10 spec. uses different language and indicates that only
4-byte alignment is required rather than the 8-byte alignment
currently implemented.  That make no difference to SD and EMMC
which invariably transfer data in sector-aligned blocks.
However with SDIO, it results in using more DMA descriptors
than necessary.  Theoretically that slows DMA slightly although
DMA is not the limiting factor for throughput, so there is no
discernable impact on performance.  Nevertheless, the driver
should follw the spec unless there is good reason not to, so
this patch corrects the alignment criterion.

There is a more complicated criterion for the DMA descriptor
table itself.  However the table is allocated by dma_alloc_coherent()
which allocates pages (i.e. aligned to a page boundary).
For simplicity just check it is 8-byte aligned, but add a comment
that some Intel controllers actually require 8-byte alignment
even when using 32-bit DMA.

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