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

mmc: block: Fix is_waiting_last_req set incorrectly

2017-03-30T07:44:09+00:00

commit 2602b740e45cc64feb55d5a9ee8db744ab3becbb upstream.

Commit 15520111500c ("mmc: core: Further fix thread wake-up") allowed a
queue to release the host with is_waiting_last_req set to true. A queue
waiting to claim the host will not reset it, which can result in the
queue getting stuck in a loop.

Fixes: 15520111500c ("mmc: core: Further fix thread wake-up")
Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-pci: Do not disable interrupts in sdhci_intel_set_power

2017-03-30T07:44:07+00:00

commit 027fb89e61054b4aedd962adb3e2003dec78a716 upstream.

Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when Intel host controllers wait for the present
state to propagate.

The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.

Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Tested-by: Ludovic Desroches 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: Do not disable interrupts while waiting for clock

2017-03-30T07:44:07+00:00

commit e2ebfb2142acefecc2496e71360f50d25726040b upstream.

Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when sdhci changes clock frequency because it
waits for the clock to become stable under a spin lock.

The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.

Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Tested-by: Ludovic Desroches 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-of-arasan: fix incorrect timeout clock

2017-03-30T07:44:07+00:00

commit 16681037e75ce08f2980ac5dbb03414429c7a55d upstream.

sdhci_arasan_get_timeout_clock() divides the frequency it has with (1 <<
(13 + divisor)).

However, the divisor is not some Arasan-specific value, but instead is
just the Data Timeout Counter Value from the SDHCI Timeout Control
Register.

Applying it here like this is wrong as the sdhci driver already takes
that value into account when calculating timeouts, and in fact it *sets*
that register value based on how long a timeout is wanted.

Additionally, sdhci core interprets the .get_timeout_clock callback
return value as if it were read from hardware registers, i.e. the unit
should be kHz or MHz depending on SDHCI_TIMEOUT_CLK_UNIT capability bit.
This bit is set at least on the tested Zynq-7000 SoC.

With the tested hardware (SDHCI_TIMEOUT_CLK_UNIT set) this results in
too high a timeout clock rate being reported, causing the core to use
longer-than-needed timeouts. Additionally, on a partitioned MMC
(therefore having erase_group_def bit set) mmc_calc_max_discard()
disables discard support as it looks like controller does not support
the long timeouts needed for that.

Do not apply the extra divisor and return the timeout clock in the
expected unit.

Tested with a Zynq-7000 SoC and a partitioned Toshiba THGBMAG5A1JBAWR
eMMC card.

Signed-off-by: Anssi Hannula 
Fixes: e3ec3a3d11ad ("mmc: arasan: Add driver for Arasan SDHCI")
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-of-at91: Support external regulators

2017-03-30T07:44:06+00:00

commit 2ce0c7b65505e0d915e99389cced45b478dc935d upstream.

The SDHCI controller in the SAMA5D2 chip requires a valid voltage set
in the power control register, otherwise commands will fail with a
timeout error.

When using the regulator framework to specify the regulator used by the
mmc device, the voltage is not configured, and it is not possible to use
the connected device.

Implement a custom 'set_power' function for this specific hardware, that
configures the voltage in the register in all cases.

Signed-off-by: Romain Izard 
Acked-by: Ludovic Desroches 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: core: Fix access to HS400-ES devices

2017-03-30T07:44:05+00:00

commit 773dc118756b1f38766063e90e582016be868f09 upstream.

HS400-ES devices fail to initialize with the following error messages.

mmc1: power class selection to bus width 8 ddr 0 failed
mmc1: error -110 whilst initialising MMC card

This was seen on Samsung Chromebook Plus. Code analysis points to
commit 3d4ef329757c ("mmc: core: fix multi-bit bus width without
high-speed mode"), which attempts to set the bus width for all but
HS200 devices unconditionally. However, for HS400-ES, the bus width
is already selected.

Cc: Anssi Hannula 
Cc: Douglas Anderson 
Cc: Brian Norris 
Fixes: 3d4ef329757c ("mmc: core: fix multi-bit bus width ...")
Signed-off-by: Guenter Roeck 
Reviewed-by: Douglas Anderson 
Reviewed-by: Shawn Lin 
Tested-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: ushc: fix NULL-deref at probe

2017-03-30T07:44:05+00:00

commit 181302dc7239add8ab1449c23ecab193f52ee6ab upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver")
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-acpi: support deferred probe

2017-03-12T05:44:06+00:00

commit e28d6f048799acb0014491e6b74e580d84bd7916 upstream.

With commit 67bf5156edc4 ("gpio / ACPI: fix returned error from
acpi_dev_gpio_irq_get()"), mmc_gpiod_request_cd() returns -EPROBE_DEFER if
GPIO is not ready when sdhci-acpi driver is probed, and sdhci-acpi driver
should be probed again later in this case.

This fixes an order issue when both GPIO and sdhci-acpi drivers are built
as modules.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177101
Tested-by: Jonas Aaberg 
Signed-off-by: Zhang Rui 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: core: fix multi-bit bus width without high-speed mode

2017-02-14T07:50:10+00:00

Commit 577fb13199b1 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().

However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.

This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.

Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.

Tested with a Zynq-7000 PicoZed 7020 board.

Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula 
Cc: 
Signed-off-by: Ulf Hansson

mmc: mmci: avoid clearing ST Micro busy end interrupt mistakenly

2017-02-08T11:22:27+00:00

This fixes a race condition that may occur whenever ST micro busy end
interrupt is raised just after being unmasked but before leaving mmci
interrupt context.

A dead-lock has been found if connecting mmci ST Micro variant whose amba
id is 0x10480180 to some new eMMC that supports internal caches.  Whenever
mmci driver enables cache control by programming eMMC's EXT_CSD register,
block driver may request to flush the eMMC internal caches causing mmci
driver to send a MMC_SWITCH command to the card with FLUSH_CACHE operation.
And because busy end interrupt may be mistakenly cleared while not yet
processed, this mmc request may never complete.  As a result, mmcqd task
may be stuck forever.

Here is an instance caught by lockup detector which shows that mmcqd task
was hung while waiting for mmc_flush_cache command to complete:

..
[  240.251595] INFO: task mmcqd/1:52 blocked for more than 120 seconds.
[  240.257973]       Not tainted 4.1.13-00510-g9d91424 #2
[  240.263109] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.270955] mmcqd/1         D c047504c     0    52      2 0x00000000
[  240.277359] [] (__schedule) from [] (schedule+0x40/0x98)
[  240.284418] [] (schedule) from [] (schedule_timeout+0x148/0x188)
[  240.292191] [] (schedule_timeout) from [] (wait_for_common+0xa4/0x170)
[  240.300491] [] (wait_for_common) from [] (mmc_wait_for_req_done+0x4c/0x13c)
[  240.309224] [] (mmc_wait_for_req_done) from [] (mmc_wait_for_cmd+0x64/0x84)
[  240.317953] [] (mmc_wait_for_cmd) from [] (__mmc_switch+0xa4/0x2a8)
[  240.325964] [] (__mmc_switch) from [] (mmc_switch+0x28/0x30)
[  240.333389] [] (mmc_switch) from [] (mmc_flush_cache+0x54/0x80)
[  240.341073] [] (mmc_flush_cache) from [] (mmc_blk_issue_rq+0x114/0x4e8)
[  240.349459] [] (mmc_blk_issue_rq) from [] (mmc_queue_thread+0xc0/0x180)
[  240.357844] [] (mmc_queue_thread) from [] (kthread+0xdc/0xf4)
[  240.365339] [] (kthread) from [] (ret_from_fork+0x14/0x2c)
..
..
[  240.664311] INFO: task partprobe:564 blocked for more than 120 seconds.
[  240.670943]       Not tainted 4.1.13-00510-g9d91424 #2
[  240.676078] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.683922] partprobe       D c047504c     0   564    486 0x00000000
[  240.690318] [] (__schedule) from [] (schedule+0x40/0x98)
[  240.697396] [] (schedule) from [] (schedule_timeout+0x148/0x188)
[  240.705149] [] (schedule_timeout) from [] (wait_for_common+0xa4/0x170)
[  240.713446] [] (wait_for_common) from [] (submit_bio_wait+0x58/0x64)
[  240.721571] [] (submit_bio_wait) from [] (blkdev_issue_flush+0x60/0x88)
[  240.729957] [] (blkdev_issue_flush) from [] (blkdev_fsync+0x34/0x44)
[  240.738083] [] (blkdev_fsync) from [] (do_fsync+0x3c/0x64)
[  240.745319] [] (do_fsync) from [] (ret_fast_syscall+0x0/0x3c)
..

Here is the detailed sequence showing when this issue may happen:

1) At probe time, mmci device is initialized and card busy detection based
on DAT[0] monitoring is enabled.

2) Later during run time, since card reported to support internal caches, a
MMCI_SWITCH command is sent to eMMC device with FLUSH_CACHE operation. On
receiving this command, eMMC may enter busy state (for a relatively short
time in the case of the dead-lock).

3) Then mmci interrupt is raised and mmci_irq() is called:

MMCISTATUS register is read and is equal to 0x01000440. So the following
status bits are set:
- MCI_CMDRESPEND (= 6)
- MCI_DATABLOCKEND (= 10)
- MCI_ST_CARDBUSY (= 24)

Since MMCIMASK0 register is 0x3FF, status variable is set to 0x00000040 and
BIT MCI_CMDRESPEND is cleared by writing MMCICLEAR register.

Then mmci_cmd_irq() is called. Considering the following conditions:
- host->busy_status is 0,
- this is a "busy response",
- reading again MMCISTATUS register gives 0x1000400,
MMCIMASK0 is updated to unmask MCI_ST_BUSYEND bit.

Thus, MMCIMASK0 is set to 0x010003FF and host->busy_status is set to wait
for busy end completion.

Back again in status loop of mmci_irq(), we quickly go through
mmci_data_irq() as there are no data in that case.  And we finally go
through following test at the end of while(status) loop:

/*
 * Don't poll for busy completion in irq context.
 */
if (host->variant->busy_detect && host->busy_status)
	status &= ~host->variant->busy_detect_flag;

Because status variable is not yet null (is equal to 0x40), we do not leave
interrupt context yet but we loop again into while(status) loop. So we run
across following steps:

a) MMCISTATUS register is read again and this time is equal to 0x01000400.
So that following bits are set:
- MCI_DATABLOCKEND (= 10)
- MCI_ST_CARDBUSY (= 24)

Since MMCIMASK0 register is equal to 0x010003FF:

b) status variable is set to 0x01000000.
c) MCI_ST_CARDBUSY bit is cleared by writing MMCICLEAR register.

Then, mmci_cmd_irq() is called one more time. Since host->busy_status is
set and that MCI_ST_CARDBUSY is set in status variable, we just return from
this function.

Back again in mmci_irq(), status variable is set to 0 and we finally leave
the while(status) loop. As a result we leave interrupt context, waiting for
busy end interrupt event.

Now, consider that busy end completion is raised IN BETWEEN steps 3.a) and
3.c). In such a case, we may mistakenly clear busy end interrupt at step
3.c) while it has not yet been processed. This will result in mmc command
to wait forever for a busy end completion that will never happen.

To fix the problem, this patch implements the following changes:

Considering that the mmci seems to be triggering the IRQ on both edges
while monitoring DAT0 for busy completion and that same status bit is used
to monitor start and end of busy detection, special care must be taken to
make sure that both start and end interrupts are always cleared one after
the other.

1) Clearing of card busy bit is moved in mmc_cmd_irq() function where
unmasking of busy end bit is effectively handled.
2) Just before unmasking busy end event, busy start event is cleared by
writing card busy bit in MMCICLEAR register.
3) Finally, once we are no more busy with a command, busy end event is
cleared writing again card busy bit in MMCICLEAR register.

This patch has been tested with the ST Accordo5 machine, not yet supported
upstream but relies on the mmci driver.

Signed-off-by: Sarang Mairal 
Signed-off-by: Jean-Nicolas Graux 
Reviewed-by: Linus Walleij 
Tested-by: Ulf Hansson 
Signed-off-by: Ulf Hansson