On Tue, Oct 13, 2026 at 8:15 PM Igor Opaniuk <[email protected]> wrote: > > sdhci_send_command() polls the interrupt status and gives up after > SDHCI_READ_STATUS_TIMEOUT, but it evaluates the timeout before it looks at > the status it has just read. When a single status read takes longer than > the timeout, the command is reported as timed out although the response > and transfer-complete bits are already set, and the caller aborts an > otherwise successful transfer. > > This happens on QEMU's SDHCI/eMMC model under TCG: a large ADMA transfer > runs in a timer callback while holding the big QEMU lock, so U-Boot's next > MMIO read blocks for seconds and the subsequent command appears to have > timed out ("Timeout for status update: 00000003 00000001"). > > Check for completion first and only then for the timeout. The check sits > after the SDHCI_QUIRK_BROKEN_R1B handling so that, for a busy command > without data on such a controller, the quirk keeps returning as soon as > the DAT line is idle without reading the response, exactly as before. > > Reviewed-by: Peng Fan <[email protected]> > Signed-off-by: Igor Opaniuk <[email protected]> > --- > Changes in v2: > - move the completion check below the SDHCI_QUIRK_BROKEN_R1B block so > that the quirk keeps returning as soon as DAT is idle, without reading > the response, for a busy command without data (Tanmay Kathpalia) > - add Peng Fan's Reviewed-by from v1; only the position of the check > changed > - Link to v1: > https://patch.msgid.link/20261011-upstream-mmc_sdhci_timeout_b4-v1-1-f33c02445...@oss.qualcomm.com > --- > drivers/mmc/sdhci.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) >
Reviewed-by: Bin Meng <[email protected]> FYI, an ADMA improvement patch was proposed on the QEMU side too. https://lore.kernel.org/qemu-devel/[email protected]/ Regards, Bin
