linux-toradex.git/drivers/mmc/host, branch master

mmc: dw_mmc-rockchip: use a tighter per-command tuning timeout

2026-09-29T10:45:11+00:00

dw_mmc-rockchip's execute_tuning() scans the tuning window phase by phase
through mmc_send_tuning(), which applied the whole-sequence 150 ms
bound as the data timeout of every single CMD19/CMD21.  With HS200
eMMC the TMOUT register saturates at ~112 ms for the requested
150 ms, so every phase that misses the window stalls that long, and
multi-second boot slowdowns have been reported[1].

Use 5 ms per tuning command via mmc_send_tuning_timeout() instead:
~1.3x the spec-implied per-execution device budget (150 ms / 40 =
3.75 ms, excluding host overhead), 30x below the 150 ms ceiling, and
the reporter verified that tuning keeps passing with it.  A wrong
sampling phase normally fails fast with a CRC error anyway, so the
timeout only catches devices which never return the tuning block at
all.  This also bounds the cost of runtime re-tuning.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221781 [1]
Signed-off-by: Shawn Lin 
Signed-off-by: Ulf Hansson

mmc: sdhci-of-dwcmshc: Disable CQE error halt request for Rockchip

2026-09-29T10:30:45+00:00

In CMDQ mode an I/O error in one task (data_crc_err, data_end_bit_err,
etc.) makes the controller raise a halt request. While the halt request
is pending, the controller rejects doorbell writes with a slave response
error, which hangs the CPU (or raises SError on ARM) on Rockchip
platforms.

A software workaround[1] clears CQHCI_CTL right before ringing the
doorbell to narrow down the window, but a race remains: an I/O error can
still happen in another slot between the CQHCI_CTL write and the
doorbell kick, so the hang is not fully solved.

To fix this once and for all, newer silicon introduces
SW_ERR_HALR_REQ_DISABLE (CQHCI_CTL[1]) which stops the controller from
raising a halt request on I/O errors. Set the bit when the CQE is
enabled, which is the last CQHCI_CTL write before any doorbell write.

Older SoCs keep this bit reserved, so writing it is a no-op and nothing
changes in the wild, thus no fixes tag is needed.

[1] https://github.com/rockchip-linux/kernel/commit/4b7ea0500a1a5c186807b737fecfc6bb4d4e06f8
Signed-off-by: Shawn Lin 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: use assign_bit() where applicable

2026-09-29T10:05:59+00:00

Convert open-coded if/else with set_bit/clear_bit and their
non-atomic __set_bit/__clear_bit variants to the assign_bit/__assign_bit
API.

Done with Coccinelle semantic patch and manual fixups.

Signed-off-by: Peng Fan 
Acked-by: Aubin Constans 
Signed-off-by: Ulf Hansson

mmc: sdhci-pci: Replace deprecated PCI functions

2026-09-29T10:03:03+00:00

pcim_iomap_regions() and pcim_iomap_table() have been deprecated.
Replace them with pcim_iomap_region(), which requests and maps a single
BAR and returns the mapping directly.

pcim_iomap_region() returns an IOMEM_ERR_PTR() on failure, so check the
result with IS_ERR() and propagate the error with ERR_CAST().

Signed-off-by: Alper Ak 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: sunplus: initialise rd_crc_dly=1 for DDR modes

2026-09-29T10:00:55+00:00

After spmmc_controller_init() resets the controller, all timing
fields are zero.  The hs_en path initialises the write timing
delays (wr_cmd_dly, wr_dat_dly) but leaves the read side at zero.

In DDR52 mode, rd_crc_dly=0 causes the first write to fail with
CRC_TOKEN_CHECK_ERROR, triggering the auto-tuning retry loop and
causing a multi-second delay on the first cold-boot write.

Set rd_crc_dly=1 when enabling DDR mode to avoid this.

Tested on a LTPP3G2, booting via eMMC in DDR52 mode,
on linux-next-20260915.

Signed-off-by: Andrew Gaylard 
Signed-off-by: Ulf Hansson

mmc: Merge branch fixes into next

2026-09-28T15:58:19+00:00

Merge the mmc fixes for v7.3-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.

Signed-off-by: Ulf Hansson

mmc: cavium-thunderx: destroy slot platform devices on remove

2026-09-28T15:57:23+00:00

thunder_mmc_probe() creates host->slot_pdev[i] with
of_platform_device_create(), while thunder_mmc_remove() does not destroy
the child platform devices.

The probe failure path removes each MMC slot and destroys its associated
platform device, but the normal remove path only removes the MMC slot.
As a result, the child platform devices remain registered after the
ThunderX MMC controller is removed.

Destroy each slot platform device during removal after cleaning up the
corresponding MMC slot, matching the probe failure cleanup path. Keep an
extra device reference around of_platform_device_destroy() as done in
the existing error path.

This issue was found by manual code inspection.

Fixes: 166bac38c3c56 ("mmc: cavium: Add MMC PCI driver for ThunderX SOCs")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li 
Signed-off-by: Ulf Hansson

mmc: cavium-octeon: destroy slot platform devices on remove

2026-09-28T15:55:27+00:00

octeon_mmc_probe() creates host->slot_pdev[i] with
of_platform_device_create(), while octeon_mmc_remove() does not destroy
the child platform devices.

The probe failure path removes each MMC slot and destroys its associated
platform device, but the normal remove path only removes the MMC slot.
As a result, the child platform devices remain registered after the
Octeon MMC controller is removed.

Destroy each slot platform device during removal after cleaning up the
corresponding MMC slot, matching the probe failure cleanup path.

This issue was found by manual code inspection.

Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li 
Signed-off-by: Ulf Hansson

mmc: cavium-thunderx: Drop redundant calls to get|put_device()

2026-09-28T15:54:09+00:00

Since commit 522811e944ed ("of: platform: stop accessing invalid dev in
of_platform_device_destroy"), there is no need to take a reference for the
device before calling of_platform_device_destroy(), hence let's drop this.

Signed-off-by: Ulf Hansson 
Signed-off-by: Ulf Hansson

mmc: sdhci-sprd: disable runtime PM on remove

2026-09-28T15:20:30+00:00

sdhci_sprd_probe() enables runtime PM, while sdhci_sprd_remove() does
not perform the corresponding runtime PM cleanup.

The probe failure path disables runtime PM before disabling the clocks,
but the normal remove path directly disables clocks that are also
managed by the runtime PM callbacks. If the device is runtime
suspended, those clocks may already be disabled.

Resume the device before removal, disable runtime PM and drop the
temporary runtime PM reference before disabling the clocks.

This issue was found by manual code inspection.

Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li 
Reviewed-by: Baolin Wang 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson