diff options
author | Bin Meng <bin.meng@windriver.com> | 2021-02-02 10:48:47 +0800 |
---|---|---|
committer | Peng Fan <peng.fan@nxp.com> | 2021-02-19 15:07:53 +0800 |
commit | 2f22cb40e57f28b694c05c0b631cbb0c09eb03a4 (patch) | |
tree | 1433c5e7ee0f7591e1c7759e9230e4f85ae6d185 /tools/rkcommon.c | |
parent | 781aad0de93aedf94a17cc66b2f211bf156b718e (diff) | |
download | u-boot-2f22cb40e57f28b694c05c0b631cbb0c09eb03a4.zip u-boot-2f22cb40e57f28b694c05c0b631cbb0c09eb03a4.tar.gz u-boot-2f22cb40e57f28b694c05c0b631cbb0c09eb03a4.tar.bz2 |
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>
Diffstat (limited to 'tools/rkcommon.c')
0 files changed, 0 insertions, 0 deletions