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

mmc: jz4740: Fix race condition in IRQ mask update

2018-05-23T01:36:33+00:00

[ Upstream commit a04f0017c22453613d5f423326b190c61e3b4f98 ]

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: Sasha Levin

mmc: avoid removing non-removable hosts during suspend

2018-05-23T01:33:51+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

mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR()

2018-05-23T01:33:49+00:00

[ Upstream commit ec5ab8933772c87f24ad62a4a602fe8949f423c2 ]

devm_pinctrl_get() returns error pointers, it never returns NULL.

Fixes: 455e5cd6f736 ("mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x")
Signed-off-by: Dan Carpenter 
Reviewed-by: Kishon Vijay Abraham I 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: core: Do not leave the block driver in a suspended state

2017-12-08T23:01:15+00:00

[ Upstream commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea ]

The block driver must be resumed if the mmc bus fails to suspend the card.

Signed-off-by: Adrian Hunter 
Reviewed-by: Linus Walleij 
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: s3cmci: include linux/interrupt.h for tasklet_struct

2017-12-07T02:19:54+00:00

[ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ]

I got this new build error on today's linux-next

drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type
  struct tasklet_struct pio_tasklet;
drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration]

While I haven't found out why this happened now and not earlier, the
solution is obvious, we should include the header that defines
the structure.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdio: fix alignment issue in struct sdio_func

2017-11-06T04:54:16+00:00

[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]

Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.

Signed-off-by: Heiner Kallweit 
Tested-by: Helmut Klein 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-iproc: suppress spurious interrupt with Multiblock read

2017-06-08T10:12:47+00:00

[ Upstream commit f5f968f2371ccdebb8a365487649673c9af68d09 ]

The stingray SDHCI hardware supports ACMD12 and automatically
issues after multi block transfer completed.

If ACMD12 in SDHCI is disabled, spurious tx done interrupts are seen
on multi block read command with below error message:

Got data interrupt 0x00000002 even though no data
operation was in progress.

This patch uses SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable
ACM12 support in SDHCI hardware and suppress spurious interrupt.

Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Adrian Hunter 
Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Cc: 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

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

2017-05-17T19:07:43+00:00

[ Upstream commit e2ebfb2142acefecc2496e71360f50d25726040b ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Tested-by: Ludovic Desroches 
Signed-off-by: Sasha Levin

mmc: ushc: fix NULL-deref at probe

2017-05-17T19:07:02+00:00

[ Upstream commit 181302dc7239add8ab1449c23ecab193f52ee6ab ]

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: stable 	# 2.6.37
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

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

2017-03-06T22:31:14+00:00

[ Upstream commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 ]

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 
Signed-off-by: Sasha Levin