Page MenuHomeFreeBSD

mmcspi: fix STOP retry
Needs ReviewPublic

Authored by br on Jun 9 2025, 12:35 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 13, 6:55 AM
Unknown Object (File)
Sun, Sep 21, 11:04 PM
Unknown Object (File)
Sep 13 2025, 5:04 AM
Unknown Object (File)
Sep 4 2025, 8:59 AM
Unknown Object (File)
Aug 25 2025, 10:59 AM
Unknown Object (File)
Aug 7 2025, 3:14 PM
Unknown Object (File)
Jul 25 2025, 4:52 AM
Unknown Object (File)
Jul 21 2025, 10:16 PM
Subscribers
None

Details

Reviewers
pkelsey
Summary

Currently, "retry on crc error" code is not reached, but this is needed on CVA6 where the first attempt to READ/WRITE multiple blocks always return CRC error.

To fix that, do not alter "retries" variable of entire command (which is set to 0), instead retry static amount of times (default 5) the stop command only in case of CRC errors.

Test Plan

Tested on CVA6 synthesized on Genesys II board

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

br requested review of this revision.Jun 9 2025, 12:35 PM
br created this revision.

Re: "the first attempt to READ/WRITE multiple blocks always return CRC error" -

Are you saying the first attempts to read/write multiple blocks return a CRC error for the stop command, or for a data block, or both? One reason I am asking is that the stop command is only used for write multiple if there is a block CRC error returned, so if retrying the stop command was relevant in that case it would mean both a block being written and the stop command itself experienced CRC errors.

Overall, I am wondering if there isn't some underlying issue with the behavior of this mmc device or this board that is being papered over with this change without being completely understood. It would be interesting to see logs captured with all tracing in this file enabled showing the affected commands that are returning CRC errors.

sys/dev/mmc/mmcspi.c
174

typo: reponse -> response

1439

I don't have any argument against separating the STOP_TRANSMISSION retry policy from the retry policy for the command it is being used to stop, and it seems that your empirical results support doing this.

1451

Agree with changing this to a check for MMC_ERR_BADCRC above. It looks like this is code that was not properly updated after checking for CRC error response was folded into mmcspi_send_cmd().

1622

typo: respone -> response

Thanks @pkelsey. I will look at this once again (I did not forget about this but need to restore my CVA6 setup).