| Message ID | 20240827122342.3314173-5-avri.altman@wdc.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add SDUC Support | expand |
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 8816b3f0a312..713b22eced72 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -2505,7 +2505,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, if (mmc_host_cmd23(card->host)) { if ((mmc_card_mmc(card) && card->csd.mmca_vsn >= CSD_SPEC_VER_3) || - (mmc_card_sd(card) && + (mmc_card_sd(card) && !mmc_card_ult_capacity(card) && card->scr.cmds & SD_SCR_CMD23_SUPPORT)) md->flags |= MMC_BLK_CMD23; }
The SDUC spec expects CMD22 to get squeezed between CMD23 and the read/write command, e.g. CMD23->CMD22->CMD18 and CMD23->CMD22->CMD25. At this early stage of adoption, we want to avoid an amid stream of fixes & quirks of bogus hw, that tends to apply extra logic specifically around auto-cmd12 & auto-cmd23. Let's leave close-ended out for now, and re-consider this should those cards become ubiquitous, if any. Signed-off-by: Avri Altman <avri.altman@wdc.com> --- drivers/mmc/core/block.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)