On Wed, Sep 15, 2021 at 08:50:21AM +0000, Christian Löhle wrote: > I did not test the patch but want to make you aware of the comment in dw_mmc: > /* > * During UHS tuning sequence, sending the stop > * command after the response CRC error would > * throw the system into a confused state > * causing all future tuning phases to report > * failure. > * > * In such case controller will move into a data > * transfer state after a response error or > * response CRC error. Let's let that finish > * before trying to send a stop, so we'll go to > * STATE_SENDING_DATA. > * > * Although letting the data transfer take place > * will waste a bit of time (we already know > * the command was bad), it can't cause any > * errors since it's possible it would have > * taken place anyway if this tasklet got > * delayed. Allowing the transfer to take place > * avoids races and keeps things simple. > */ > The message in 46d179525a1f6d16957dcb4624517bc04142b3e7 > does not mention which card was causing problem, unfortunately. Thank you for the pointer! This is interesting, in deed. As I understand, it is a limitation of the controller which always goes into data transfer state even after CRC errors. However, because the controller driver is not using mmc_send_abort_data(), it will not be affected by my patch series. My patch series only extends the optional MMC core helper to be used for SD cards, too, in addition to eMMC. If I missed something else, please let me know.
Attachment:
signature.asc
Description: PGP signature
