Hi Opaniuk, On 13-10-2026 17:44, Igor Opaniuk 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
Thanks for incorporating the feedback. Reviewed-by: Tanmay Kathpalia <[email protected]>
