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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html