Hi Wolfram-san,
> From: Wolfram Sang, Sent: Tuesday, March 14, 2017 7:49 PM
>
> > > So, since I got no complaints about the RFC, I'll declare it a PATCH now :)
> > > Shimoda-san, is it possible for you to test it with the SD tester you once had
> > > access to? I could only test it by setting the ECC bit in the driver manually.
> >
> > Sure. I am able to bring the SD tester from other department tomorrow.
> > So, I will check this patch tomorrow.
>
> Good news, thank you very much!
I tested this patch with the SD tester. After I applied this patch, when the R1_CARD_ECC_FAILED
is set, the following message appeared:
mmcblk1: error -5 sending stop command, original cmd response 0x900, card status 0x900
However, I have a question about "ecc_err" in both mmc_blk_err_check() and mmc_blk_cmd_recovery().
Anyway, I tested this patch. And the mmc core said some error happened.
I think this is suitable behavior. So,
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx>
< Question >
In mmc_blk_cmd_recovery(), if "brq->stop.resp[0] & R1_CARD_ECC_FAILED" is true, ecc_err is set to true.
However, in mmc_blk_err_check(), ecc_err is only referred when brq->data.error is true.
So, I guess we need a patch like below as another patch. What do you think?
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 0e838b0..99c937b 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1374,7 +1374,7 @@ static enum mmc_blk_status mmc_blk_err_check(struct mmc_ca
return MMC_BLK_RETRY;
}
- if (brq->data.error) {
+ if (brq->data.error || ecc_err) {
if (need_retune && !brq->retune_retry_done) {
pr_debug("%s: retrying because a re-tune was needed\n",
req->rq_disk->disk_name);
After that, the mmc core also output the following message:
mmcblk1: error 0 transferring data, sector 0, nr 128, cmd response 0x900, card status 0x200b00
mmcblk1: retrying using single block read
Best regards,
Yoshihiro Shimoda
