kernel/git/next/linux-next.git/drivers/mmc/host, branch master

Merge branch 'headers' of git://git.infradead.org/users/willy/pagecache.git

2026-09-11T15:17:01+00:00

# Conflicts: # net/ceph/osd_client.c

mmc: Merge branch fixes into next

2026-09-10T13:02:41+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: dw_mmc: expose the watchdog state in debugfs

2026-09-10T12:05:11+00:00

Debugging hangs on the request legs now means asking 'what was the watchdog guarding and until when?' Expose the awaited events, the valid states, and the absolute deadline of the current watch next to the existing pending_events/completed_events nodes; all three zero out once a leg is settled or the watch fired. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson

mmc: dw_mmc: absorb CMD11 timeout into the central watchdog

2026-09-10T12:05:11+00:00

The voltage switch (CMD11) keeps its dedicated 500ms deadline, but it is now just another arm of the central watchdog; cmd11_timer is deleted. The synthesized payload is identical to what the command leg watchdog produces (cmd_status = RTO plus EVENT_CMD_COMPLETE), so the request state machine cannot tell the difference. Behavior notes for review: * The extra jiffy in the legacy '500ms + 1' arming was pure jiffies rollover paranoia and disappears together with the jiffies math. * Since patch 1 arms the regular command watch on every RESP_EXP command -- including voltage switches -- the subsequent arm here replaces it, as documented there. For a genuinely stuck CMD11 the abort latency therefore becomes exactly 500ms instead of racing min(cto_ms, 500ms) between two timers as before; the reported error (-ETIMEDOUT either way) is unchanged. * dw_mci_cmd_interrupt() already delivers the watched events under irq_lock on any completion path, so the former out-of-lock timer_delete() next to the VOLT_SWITCH branch simply goes away. No functional change intended. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson

mmc: dw_mmc: convert DTO onto the central watchdog

2026-09-10T12:05:11+00:00

The data timeout joins the command timeout on the central watchdog; dto_timer is deleted. dw_mci_set_drto() arms DW_MCI_WD_DATA_EVENTS with EVENT_DATA_COMPLETE as its precheck mask: a DATA_ERROR that arrived while still waiting for the paired completion must not prevent the watch -- the legacy mod_timer() guard tested exactly that one bit, and the fault-injection machinery relies on this by injecting DATA_ERROR early. The EXTENDED_TMOUT quirk semantics fall out naturally now: * On quirk hosts the data-error branch delivers the whole watched set, stopping the watch since no further data events will come -- this mirrors the former conditional timer_delete() plus the manual EVENT_DATA_COMPLETE side-post. * Without the quirk nothing is delivered there and the outstanding watch keeps guarding until a genuine DATA_OVER arrives, exactly like leaving dto_timer running did. The DATA_OVER branch delivers unconditionally, superseding its unconditional timer_delete(). The stale-timer WARN_ON + timer_delete_sync() dance in dw_mci_clear_pending_data_complete() goes away for the same reason as on the command leg: a callback racing past its checks is idempotent under irq_lock. No functional change intended. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson

mmc: dw_mmc: add central watchdog and convert CTO onto it

2026-09-10T12:05:11+00:00

The driver keeps three independent fallback timers (cmd11, cto, dto) whose callbacks all re-implement the same race handling: peek MINTSTS in case the interrupt is in flight, check whether the event was delivered meanwhile, verify host->state matches the leg being guarded, and finally synthesize the missed event. This series replaces them with a single hrtimer watchdog. This first step introduces the watchdog and moves the command timeout onto it; cto_timer is deleted. Later steps convert the data timeout and the voltage-switch timer onto the same watch. The new protocol relies on two simple facts which hold for all current event producers: * every site posting EVENT_CMD_COMPLETE (dw_mci_cmd_interrupt() and the command-error branch of dw_mci_interrupt()) runs under irq_lock, * every site arming a watch does so under irq_lock as well. Consequently a watchdog callback holding irq_lock can neither miss nor race an already-delivered event: the bookkeeping part of the former 're-read MINTSTS' paranoia is subsumed by checking the awaited mask against pending_events under the same lock the producers use. The hardware-latency part of that paranoia is kept verbatim, see below. A callback that raced past every check nonetheless degrades to at most one idempotent extra state machine run instead of completing a foreign leg. The callback classifies what expired by comparing the awaited set against the named DW_MCI_WD_{CMD,DATA}_EVENTS masks so that subsequent conversions only add call sites. dw_mci_wd_arm() takes a separate 'already delivered' precheck mask because guarding the data legs must tolerate a DATA_ERROR that arrived while still waiting for the paired completion -- exactly like mod_timer() paths did before. Behavioral notes for review: * dw_mci_wd_arm() replaces any previously armed watch. During a voltage switch (CMD11) both cto_timer and cmd11_timer were armed concurrently before, racing each other with duplicated warnings; now only the last arm on that path survives. * The stale-timer defensiveness of dw_mci_clear_pending_cmd_complete() (WARN_ON + timer_delete_sync) is dropped because the callback is now idempotent by construction; timer_delete_sync from the BH would also be wrong-context sleeping on hrtimers. * Before declaring a timeout the callback re-reads MINTSTS: when the completion interrupt is already latched in hardware and only its handler has not been scheduled yet, the firing grants further DW_MCI_WD_INFLIGHT_GRACE_MS rounds instead of failing an about-to- complete transfer. This replicates the interrupt-latency paranoia of the retired cto_timer()/dto_timer() callbacks; unlike them it keeps re-watching rather than going passive, so if that latched interrupt is ultimately lost the request still unwedges with a timeout error instead of hanging forever. No functional change intended beyond the deduplication described above. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson

mmc: sdhci-msm: Use pm ops instead of macro to restore crypto keys

2026-09-10T11:57:16+00:00

Inline Crypto Engine (ICE) keys are lost after hibernation entry and this needs to be restored when hibernation exits. ICE keys are re-programmed during sdhci_msm_ice_init() but it may not cover cases where the hibernation image is already restored. Unwrap the pm ops and use directly in driver to add the call to restore Inline Crypto Engine (ICE) keys. This ensures that ICE is brought into same state as before hibernation. If hibernation image creation itself fails then device boots through normal flow where there is no need to reprogram the keys. Also set MMC_CAP2_CRYPTO_NO_REPROG to indicate that re-programming of ICE keys is not needed during MMC runtime suspend/resume or suspend-to-RAM since the rail powering the ICE will not be turned off. During CQE recovery, key would be lost only when BCR reset is performed which do not happen right now and will be taken up once it is fixed as part of recovery flow. Signed-off-by: Ram Prakash Gupta Signed-off-by: Seshu Madhavi Puppala Co-developed-by: Ram Prakash Gupta Signed-off-by: Ram Prakash Gupta Co-developed-by: Sarthak Garg Signed-off-by: Sarthak Garg Signed-off-by: Debraj Mukhopadhyay Signed-off-by: Neeraj Soni Signed-off-by: Ulf Hansson

mmc: rtsx_usb_sdmmc: start card power-up at 3.3V

2026-09-10T11:38:41+00:00

A UHS session can leave the SD pads and SD18 regulator configured for 1.8V. The power-off path disables card power and suspends the regulator, but does not restore their voltage selection. On the next power-up, this stale state remains until after the MMC core requests its initial signal voltage. Restore the SD pads and SD18 regulator to 3.3V before enabling card power, as the old rts5139 driver did. Tested: StarLite ADL with an RTS5129 tray reader; repeated 1.8V UHS sessions, power cycles, and tray removal/reinsertion. Tested: StarFighter MTL with an RTS5129 trayless reader; repeated 1.8V UHS sessions, power cycles, and card removal/reinsertion. Tested: Both systems re-enumerated the card after every cycle. Signed-off-by: Sean Rhodes Signed-off-by: Ulf Hansson

mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260

2026-09-10T11:33:39+00:00

The Realtek RTS522A card reader in the Lenovo ThinkPad X260 (subsystem 17aa:504a) incorrectly reports inserted SD cards as write-protected. This causes the MMC core to expose the card as read-only: mmcblk0: mmc0:aaaa SN256 238 GiB (ro) and /sys/block/mmcblk0/ro reports 1. Setting MMC_CAP2_NO_WRITE_PROTECT makes the card writable again. Limit the quirk to the affected Lenovo subsystem. Assisted-by: ChatGPT:GPT-5.6 Sol Signed-off-by: Florian Maillard Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson

mmc: Merge branch fixes into next

2026-09-08T16:09:16+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