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

sdhci: Advertise 2.0v supply on SDIO host controller

2018-04-12T10:31:13+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:22:55+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:22:54+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:22:54+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

mmc: block: fix updating ext_csd caches on ioctl call

2018-03-28T16:22:54+00:00

commit e74ef2194b41ba5e511fab29fe5ff00e72d2f42a upstream.

PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the
currently active partition in mmc_blk_data->part_curr. These caches do
not always reflect changes if the ioctl call modifies the
PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.

Write the PARTITION_CONFIG value extracted from the ioctl call to the
cache and update the currently active partition accordingly. This
ensures that the user space cannot change the values behind the
kernel's back. The next call to mmc_blk_part_switch() will operate on
the data set by the ioctl and reflect the changes appropriately.

Signed-off-by: Bastian Stender 
Signed-off-by: Jan Luebbe 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards

2018-03-28T16:22:54+00:00

commit dbe7dc6b9b28f5b012b0bedc372aa0c52521f3e4 upstream.

Certain Micron eMMC v4.5 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.

In U-Boot, these cards are reported as

Manufacturer: Micron (ID: 0xFE)
OEM: 0x4E
Name: MMC32G
Revision: 19 (0x13)
Serial: 959241022  Manufact. date: 8/2015 (0x82)  CRC: 0x00
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 29.1 GiB
Boot Partition Size: 16 MiB
Bus Width: 8-bit

According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by
Micron.

Signed-off-by: Dirk Behme 
Signed-off-by: Mark Craske 
Cc:  # 4.8+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable

2018-03-24T10:02:49+00:00

[ Upstream commit 8d876bf472dba73c015cea9feea80dcb80626a7c ]

According to SD spec 3.00 3.6.1 signal voltage switch
procedure step 6~8,
(6) Set 1.8V Signal Enable in the Host Control 2 register.
(7) Wait 5ms. 1.8V voltage regulator shall be stable within this period.
(8) If 1.8V Signal Enable is cleared by Host Controller, go to step (12).
Host should wait 5ms after set 1.8V signal enable bit in
Host Control 2 register and check if 1.8V is stable or not.

But current code checks this bit right after set it.
On some platforms with xenon controller found the bit is
cleared right away and host reports "1.8V regulator output
did not became stable" and 5ms delay can help.

Implement voltage_switch callback for xenon controller to add 5ms
delay to make sure the 1.8V signal enable bit is set by controller.

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

mmc: block: fix logical error to avoid memory leak

2018-03-24T10:02:47+00:00

[ Upstream commit 0be55579a127916ebe39db2a74d906a2dfceed42 ]

If the MMC_DRV_OP_GET_EXT_CSD request completes successfully, then
ext_csd must be freed, but in one case it was not. Fix that.

Signed-off-by: Liu Changcheng 
Acked-by: Adrian Hunter 
Acked-by: Linus Walleij 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mmc: avoid removing non-removable hosts during suspend

2018-03-24T10:02:47+00:00

[ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]

The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.

After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.

The conditions here are:

 1. During suspend, we reach mmc_pm_notify()

 2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
    suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
    -ENOSYS because btsdio_driver does not have a suspend method.

 3. mmc_pm_notify() proceeds to remove the card

 4. Upon resume, mmc_rescan() does nothing with this host, because of
    the rescan_entered check which aims to only scan a non-removable
    device a single time (i.e. during boot).

Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.

Signed-off-by: Daniel Drake 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mmc: mmc_test: Ensure command queue is disabled for testing

2018-03-19T08:09:59+00:00

[ Upstream commit 23a185254ace8e63dc4ca36e0315aed9440ae749 ]

mmc_test disables the command queue because none of the tests use the
command queue. However the Reset Test will re-enable it, so disable it in
that case too.

Fixes: 9d4579a85c84 ("mmc: mmc_test: Disable Command Queue while mmc_test is used")
Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman