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

mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus

2018-05-30T05:51:48+00:00

commit 3de06d5a1f05c11c94cbb68af14dbfa7fb81d78b upstream.

The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to
properly reset the host controller (reset all) on initialization
after exiting deep sleep.

Signed-off-by: Corneliu Doban 
Signed-off-by: Scott Branden 
Reviewed-by: Ray Jui 
Reviewed-by: Srinath Mannam 
Fixes: c833e92bbb60 ("mmc: sdhci-iproc: support standard byte register accesses")
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register

2018-05-30T05:51:48+00:00

commit 5f651b870485ee60f5abbbd85195a6852978894a upstream.

When the host controller accepts only 32bit writes, the value of the
16bit TRANSFER_MODE register, that has the same 32bit address as the
16bit COMMAND register, needs to be saved and it will be written
in a 32bit write together with the command as this will trigger the
host to send the command on the SD interface.
When sending the tuning command, TRANSFER_MODE is written and then
sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and
write it again resulting in wrong value to be written because the
initial write value was saved in a shadow and the read-back returned
a wrong value, from the register.
Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE
when a saved value exist.
Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are
saved for a different reason, although a scenario that will cause the
mentioned problem on this registers is not probable.

Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Signed-off-by: Corneliu Doban 
Signed-off-by: Scott Branden 
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-iproc: remove hard coded mmc cap 1.8v

2018-05-30T05:51:48+00:00

commit 4c94238f37af87a2165c3fb491b4a8b50e90649c upstream.

Remove hard coded mmc cap 1.8v from platform data as it is board specific.
The 1.8v DDR mmc caps can be enabled using DTS property for those
boards that support it.

Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data")
Signed-off-by: Srinath Mannam 
Signed-off-by: Scott Branden 
Reviewed-by: Ray Jui 
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-pci: Only do AMD tuning for HS200

2018-04-24T07:36:38+00:00

commit 300ad8992913025b4294d4fc37b6bfff4a8b7ad1 upstream.

Commit c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode
on AMD, eMMC-4.5.1") added a HS200 tuning method for use with AMD SDHCI
controllers.  As described in the commit subject, this tuning is specific
for HS200.  However, as implemented, this method is used for all host
timings, because platform_execute_tuning, if it exists, is called
unconditionally by sdhci_execute_tuning().  This breaks tuning when using
the AMD controller with, for example, a DDR50 SD card.

Instead, we can implement an amd execute_tuning wrapper callback, and
then conditionally do the HS200 specific tuning for HS200, and otherwise
call back to the standard sdhci_execute_tuning().

Signed-off-by: Daniel Kurtz 
Acked-by: Shyam Sundar S K 
Acked-by: Adrian Hunter 
Fixes: c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode on AMD, eMMC-4.5.1")
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: tmio: Fix error handling when issuing CMD23

2018-04-24T07:36:33+00:00

commit fc167daff581c01ebce8695e9618231cae3561a1 upstream.

If an error was detected when CMD23 was issued, command sequence should
be terminated with errors and CMD23 should be issued after retuning.

Fixes: 8b22c3c18be5 ("mmc: tmio: add CMD23 support")
Signed-off-by: Masaharu Hayakawa 
Signed-off-by: Wolfram Sang 
Cc:  # 4.13+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: jz4740: Fix race condition in IRQ mask update

2018-04-24T07:36:33+00:00

commit a04f0017c22453613d5f423326b190c61e3b4f98 upstream.

A spinlock is held while updating the internal copy of the IRQ mask,
but not while writing it to the actual IMASK register. After the lock
is released, an IRQ can occur before the IMASK register is written.
If handling this IRQ causes the mask to be changed, when the handler
returns back to the middle of the first mask update, a stale value
will be written to the mask register.

If this causes an IRQ to become unmasked that cannot have its status
cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ,
then we can end up stuck with the same IRQ repeatedly being fired but
not handled. Normally the MMC IRQ handler attempts to clear any
unexpected IRQs by writing IREG, but for those that cannot be cleared
in this way then the IRQ will just repeatedly fire.

This was resulting in lockups after a while of using Wi-Fi on the
CI20 (GitHub issue #19).

Resolve by holding the spinlock until after the IMASK register has
been updated.

Cc: stable@vger.kernel.org
Link: https://github.com/MIPS/CI20_linux/issues/19
Fixes: 61bfbdb85687 ("MMC: Add support for the controller on JZ4740 SoCs.")
Tested-by: Mathieu Malaterre 
Signed-off-by: Alex Smith 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

sdhci: Advertise 2.0v supply on SDIO host controller

2018-04-12T10:32:20+00:00

[ Upstream commit 2a609abe71ca59e4bd7139e161eaca2144ae6f2e ]

On Intel Edison the Broadcom Wi-Fi card, which is connected to SDIO,
requires 2.0v, while the host, according to Intel Merrifield TRM,
supports 1.8v supply only.

The card announces itself as

  mmc2: new ultra high speed DDR50 SDIO card at address 0001

Introduce a custom OCR mask for SDIO host controller on Intel Merrifield
and add a special case to sdhci_set_power_noreg() to override 2.0v supply
by enforcing 1.8v power choice.

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

mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs

2018-03-28T16:24:32+00:00

commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream.

It was found that in IDMAC mode after soft-reset driver switches
to PIO mode.

That's what happens in case of DTO timeout overflow calculation failure:
1. soft-reset is called
2. driver restarts dma
3. descriptors states are checked, one of descriptor is owned by the IDMAC.
4. driver can't use DMA and then switches to PIO mode.

Failure was already fixed in:
https://www.spinics.net/lists/linux-mmc/msg48125.html.

Behaviour while soft-reset is not something we except or
even want to happen. So we switch from dw_mci_idmac_reset
to dw_mci_idmac_init, so descriptors are cleaned before starting dma.

And while at it explicitly zero des0 which otherwise might
contain garbage as being allocated by dmam_alloc_coherent().

Signed-off-by: Evgeniy Didin 
Cc: Jaehoon Chung 
Cc: Ulf Hansson 
Cc: Andy Shevchenko 
Cc: Jisheng Zhang 
Cc: Shawn Lin 
Cc: Alexey Brodkin 
Cc: Eugeniy Paltsev 
Cc: linux-snps-arc@lists.infradead.org
Cc:  # 4.4+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433

2018-03-28T16:24:31+00:00

commit e22842dd64bf86753d3f2b6ea474d73fc1e6ca24 upstream.

Before enabling the clock, dwmmc exynos driver is trying to access the
register. Then the kernel panic can be occurred.

Signed-off-by: Jaehoon Chung 
Reviewed-by: Chanwoo Choi 
Tested-by: Chanwoo Choi 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systems

2018-03-28T16:24:31+00:00

commit c7151602255a36ba07c84fe2baeef846fdb988b8 upstream.

The commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
and commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
made changes, which cause multiply overflow for 32-bit systems. The broken
timeout calculations leads to unexpected ETIMEDOUT errors and causes
stacktrace splat (such as below) during normal data exchange with SD-card.

| Running :  4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1
| -  Info: Finished target initialization.
| mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd
| response 0x900, card status 0x0

DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so
code gets compiled on all 32-bit platforms as opposed to usage of
DIV_ROUND_UP when we may only compile stuff on a very few arches.

Lets cast this multiply to u64 type to prevent the overflow.

Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
Fixes: 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
Tested-by: Vineet Gupta 
Reported-by: Vineet Gupta  # ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files
Signed-off-by: Evgeniy Didin 
Cc:  # 4.14
Reviewed-by: Andy Shevchenko 
Reviewed-by: Douglas Anderson 
Reviewed-by: Shawn Lin 
Reviewed-by: Jisheng Zhang 
Acked-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman