linux-stable.git/drivers/mmc, branch v5.4.174

mmc: core: Fixup storing of OCR for MMC_QUIRK_NONSTD_SDIO

2022-01-27T08:19:44+00:00

[ Upstream commit 8c3e5b74b9e2146f564905e50ca716591c76d4f1 ]

The mmc core takes a specific path to support initializing of a
non-standard SDIO card. This is triggered by looking for the card-quirk,
MMC_QUIRK_NONSTD_SDIO.

In mmc_sdio_init_card() this gets rather messy, as it causes the code to
bail out earlier, compared to the usual path. This leads to that the OCR
doesn't get saved properly in card->ocr. Fortunately, only omap_hsmmc has
been using the MMC_QUIRK_NONSTD_SDIO and is dealing with the issue, by
assigning a hardcoded value (0x80) to card->ocr from an ->init_card() ops.

To make the behaviour consistent, let's instead rely on the core to save
the OCR in card->ocr during initialization.

Reported-by: H. Nikolaus Schaller 
Signed-off-by: Ulf Hansson 
Signed-off-by: H. Nikolaus Schaller 
Link: https://lore.kernel.org/r/e7936cff7fc24d187ef2680d3b4edb0ade58f293.1636564631.git.hns@goldelico.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: meson-mx-sdio: add IRQ check

2022-01-27T08:19:35+00:00

[ Upstream commit 8fc9a77bc64e1f23d07953439817d8402ac9706f ]

The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.

Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoC")
Signed-off-by: Sergey Shtylyov 
Reviewed-by: Martin Blumenstingl 
Link: https://lore.kernel.org/r/20211217202717.10041-3-s.shtylyov@omp.ru
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-pci: Add PCI ID for Intel ADL

2022-01-16T08:15:38+00:00

commit e53e97f805cb1abeea000a61549d42f92cb10804 upstream.

Add PCI ID for Intel ADL eMMC host controller.

Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211124094850.1783220-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: core: Disable card detect during shutdown

2021-12-29T11:23:37+00:00

commit 66c915d09b942fb3b2b0cb2f56562180901fba17 upstream.

It's seems prone to problems by allowing card detect and its corresponding
mmc_rescan() work to run, during platform shutdown. For example, we may end
up turning off the power while initializing a card, which potentially could
damage it.

To avoid this scenario, let's add ->shutdown_pre() callback for the mmc host
class device and then turn of the card detect from there.

Reported-by: Al Cooper 
Suggested-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211203141555.105351-1-ulf.hansson@linaro.org
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-tegra: Fix switch to HS400ES mode

2021-12-29T11:23:37+00:00

commit 4fc7261dbab139d3c64c3b618262504e16cfe7ee upstream.

When CMD13 is sent after switching to HS400ES mode, the bus
is operating at either MMC_HIGH_26_MAX_DTR or MMC_HIGH_52_MAX_DTR.
To meet Tegra SDHCI requirement at HS400ES mode, force SDHCI
interface clock to MMC_HS200_MAX_DTR (200 MHz) so that host
controller CAR clock and the interface clock are rate matched.

Signed-off-by: Prathamesh Shete 
Acked-by: Adrian Hunter 
Fixes: dfc9700cef77 ("mmc: tegra: Implement HS400 enhanced strobe")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211214113653.4631-1-pshete@nvidia.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: Fix ADMA for PAGE_SIZE >= 64KiB

2021-12-01T08:23:29+00:00

commit 3d7c194b7c9ad414264935ad4f943a6ce285ebb1 upstream.

The block layer forces a minimum segment size of PAGE_SIZE, so a segment
can be too big for the ADMA table, if PAGE_SIZE >= 64KiB. Fix by writing
multiple descriptors, noting that the ADMA table is sized for 4KiB chunks
anyway, so it will be big enough.

Reported-and-tested-by: Bough Chen 
Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211115082345.802238-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: mxs-mmc: disable regulator on error and in the remove function

2021-11-17T08:48:38+00:00

[ Upstream commit ce5f6c2c9b0fcb4094f8e162cfd37fb4294204f7 ]

The 'reg_vmmc' regulator is enabled in the probe. It is never disabled.
Neither in the error handling path of the probe nor in the remove
function.

Register a devm_action to disable it when needed.

Fixes: 4dc5a79f1350 ("mmc: mxs-mmc: enable regulator for mmc slot")
Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/4aadb3c97835f7b80f00819c3d549e6130384e67.1634365151.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-omap: Fix NULL pointer exception if regulator is not configured

2021-11-17T08:48:37+00:00

[ Upstream commit 8e0e7bd38b1ec7f9e5d18725ad41828be4e09859 ]

If sdhci-omap is configured for an unused device instance and the device
is not set as disabled, we can get a NULL pointer dereference:

Unable to handle kernel NULL pointer dereference at virtual address
00000045
...
(regulator_set_voltage) from [] (mmc_regulator_set_ocr+0x44/0xd0)
(mmc_regulator_set_ocr) from [] (sdhci_set_ios+0xa4/0x490)
(sdhci_set_ios) from [] (sdhci_omap_set_ios+0x124/0x160)
(sdhci_omap_set_ios) from [] (mmc_power_up.part.0+0x3c/0x154)
(mmc_power_up.part.0) from [] (mmc_start_host+0x88/0x9c)
(mmc_start_host) from [] (mmc_add_host+0x58/0x7c)
(mmc_add_host) from [] (__sdhci_add_host+0xf0/0x22c)
(__sdhci_add_host) from [] (sdhci_omap_probe+0x318/0x72c)
(sdhci_omap_probe) from [] (platform_probe+0x58/0xb8)

AFAIK we are not seeing this with the devices configured in the mainline
kernel but this can cause issues for folks bringing up their boards.

Fixes: 7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver")
Signed-off-by: Tony Lindgren 
Link: https://lore.kernel.org/r/20210921110029.21944-2-tony@atomide.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: winbond: don't build on M68K

2021-11-17T08:48:20+00:00

[ Upstream commit 162079f2dccd02cb4b6654defd32ca387dd6d4d4 ]

The Winbond MMC driver fails to build on ARCH=m68k so prevent
that build config. Silences these build errors:

../drivers/mmc/host/wbsd.c: In function 'wbsd_request_end':
../drivers/mmc/host/wbsd.c:212:28: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration]
  212 |                 dmaflags = claim_dma_lock();
../drivers/mmc/host/wbsd.c:215:17: error: implicit declaration of function 'release_dma_lock'; did you mean 'release_task'? [-Werror=implicit-function-declaration]
  215 |                 release_dma_lock(dmaflags);

Signed-off-by: Randy Dunlap 
Cc: Pierre Ossman 
Cc: Geert Uytterhoeven 
Cc: Arnd Bergmann 
Link: https://lore.kernel.org/r/20211017175949.23838-1-rdunlap@infradead.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: dw_mmc: Dont wait for DRTO on Write RSP error

2021-11-17T08:48:17+00:00

commit 43592c8736e84025d7a45e61a46c3fa40536a364 upstream.

Only wait for DRTO on reads, otherwise the driver hangs.

The driver prevents sending CMD12 on response errors like CRCs. According
to the comment this is because some cards have problems with this during
the UHS tuning sequence. Unfortunately this workaround currently also
applies for any command with data. On reads this will set the drto timer,
which then triggers after a while. On writes this will not set any timer
and the tasklet will not be scheduled again.

I cannot test for the UHS workarounds need, but even if so, it should at
most apply to reads. I have observed many hangs when CMD25 response
contained a CRC error. This patch fixes this without touching the actual
UHS tuning workaround.

Signed-off-by: Christian Loehle 
Reviewed-by: Jaehoon Chung 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/af8f8b8674ba4fcc9a781019e4aeb72c@hyperstone.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman