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

mmc: pwrseq: Use kmalloc_array instead of stack VLA

2018-08-03T05:55:24+00:00

[ Upstream commit 486e6661367b40f927aadbed73237693396cbf94 ]

The use of stack Variable Length Arrays needs to be avoided, as they
can be a vector for stack exhaustion, which can be both a runtime bug
(kernel Oops) or a security flaw (overwriting memory beyond the
stack). Also, in general, as code evolves it is easy to lose track of
how big a VLA can get. Thus, we can end up having runtime failures
that are hard to debug. As part of the directive[1] to remove all VLAs
from the kernel, and build with -Wvla.

Currently driver is using a VLA declared using the number of descriptors.  This
array is used to store integer values and is later used as an argument to
`gpiod_set_array_value_cansleep()` This can be avoided by using
`kmalloc_array()` to allocate memory for the array of integer values.  Memory is
free'd before return from function.

>From the code it appears that it is safe to sleep so we can use GFP_KERNEL
(based _cansleep() suffix of function `gpiod_set_array_value_cansleep()`.

It can be expected that this patch will result in a small increase in overhead
due to the use of `kmalloc_array()`

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Tobin C. Harding 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: update actual clock for mmc debugfs

2018-08-03T05:55:24+00:00

[ Upstream commit ff178981bd5fd1667f373098740cb1c6d6efa1ba ]

Respect the actual clock for mmc debugfs to help better debug
the hardware.

mmc_host mmc0: Bus speed (slot 0) = 135475200Hz (slot req 150000000Hz,
actual 135475200HZ div = 0)

cat /sys/kernel/debug/mmc0/ios
clock:          150000000 Hz
actual clock:   135475200 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      3 (8 bits)
timing spec:    9 (mmc HS200)
signal voltage: 0 (1.80 V)
driver type:    0 (driver type B)

Cc: Xiao Yao 
Cc: Ziyuan 
Signed-off-by: Shawn Lin 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: fix card threshold control configuration

2018-07-17T09:37:51+00:00

commit 7a6b9f4d601dfce8cb68f0dcfd834270280e31e6 upstream.

Card write threshold control is supposed to be set since controller
version 2.80a for data write in HS400 mode and data read in
HS200/HS400/SDR104 mode. However the current code returns without
configuring it in the case of data writing in HS400 mode.
Meanwhile the patch fixes that the current code goes to
'disable' when doing data reading in HS400 mode.

Fixes: 7e4bf1bc9543 ("mmc: dw_mmc: add the card write threshold for HS400 mode")
Signed-off-by: Qing Xia 
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

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

2018-05-30T05:50:16+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:50:16+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: jz4740: Fix race condition in IRQ mask update

2018-04-24T07:34:14+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-13T17:48:31+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:39:19+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: avoid removing non-removable hosts during suspend

2018-03-24T10:00:24+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: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a

2018-03-24T10:00:17+00:00

[ Upstream commit a627f025eb0534052ff451427c16750b3530634c ]

The ls1046a datasheet specified that the max SD clock frequency
for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet
specified it's 125MHz for ls1012a. So this patch is to add the
limitation.

Signed-off-by: Yangbo Lu 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman