linux-toradex.git/drivers/mmc, branch v4.4.29

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: core: Annotate cmd_hdr as __le32

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

commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 upstream.

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)
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: block: don't use CMD23 with very old MMC cards

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

commit 0ed50abb2d8fc81570b53af25621dad560cd49b3 upstream.

CMD23 aka SET_BLOCK_COUNT was introduced with MMC v3.1.
Older versions of the specification allowed to terminate
multi-block transfers only with CMD12.

The patch fixes the following problem:

  mmc0: new MMC card at address 0001
  mmcblk0: mmc0:0001 SDMB-16 15.3 MiB
  mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900
  ...
  blk_update_request: I/O error, dev mmcblk0, sector 0
  Buffer I/O error on dev mmcblk0, logical block 0, async page read
   mmcblk0: unable to read partition table

Signed-off-by: Daniel Glöckner 
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

mmc: sdhci-acpi: Reduce Baytrail eMMC/SD/SDIO hangs

2016-09-07T06:32:37+00:00

commit 6e1c7d6103fe7031035cec321307c6356809adf4 upstream.

Baytrail eMMC/SD/SDIO host controllers have been known to
hang.  A change to a hardware setting has been found to
reduce the occurrence of such hangs.  This patch ensures
the correct setting.

This patch applies cleanly to v4.4+.  It could go to
earlier kernels also, so I will send backports to the
stable list in due course.

Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman