mmc: mmc_spi: Fix potential spec violation in receiving card response
authorBin Meng <bin.meng@windriver.com>
Tue, 2 Feb 2021 02:48:47 +0000 (10:48 +0800)
committerPeng Fan <peng.fan@nxp.com>
Fri, 19 Feb 2021 07:07:53 +0000 (15:07 +0800)
commit2f22cb40e57f28b694c05c0b631cbb0c09eb03a4
tree1433c5e7ee0f7591e1c7759e9230e4f85ae6d185
parent781aad0de93aedf94a17cc66b2f211bf156b718e
mmc: mmc_spi: Fix potential spec violation in receiving card response

After command is sent and before card response shows up on the line,
there is a variable number of clock cycles in between called Ncr.
The spec [1] says the minimum is 1 byte and the maximum is 8 bytes.

Current logic in mmc_spi_sendcmd() has a flaw that it could only work
with certain SD cards with their Ncr being just 1 byte.

When resp_match is false, the codes try to receive only 1 byte from
the SD card. On the other hand when resp_match is true, the logic
happens to be no problem as it loops until timeout to receive as many
bytes as possible to see a match of the expected resp_match_value.
However not every call to mmc_spi_sendcmd() is made with resp_match
being true hence this exposes a potential issue with SD cards that
have a larger Ncr value.

Given no issue was reported as of today, we can reasonably conclude
that all cards being used on the supported boards happen to have a 1
byte Ncr timing requirement. But a broken case can be triggered by
utilizing QEMU to emulate a larger value of Ncr (by default 1 byte
Ncr is used on QEMU). This commit fixes such potential spec violation
to improve the card compatibility.

[1] "Physical Layer Specification Version 8.00"
     chapter 7.5.1: Command / Response
     chapter 7.5.4: Timing Values

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
drivers/mmc/mmc_spi.c