On 14 February 2017 at 11:52, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > Shimoda-san, Ulf, > > On Tue, Feb 14, 2017 at 10:06:47AM +0000, Yoshihiro Shimoda wrote: >> Hi, >> >> > From: Wolfram Sang [mailto:wsa+renesas@xxxxxxxxxxxxxxxxxxxx] >> > Sent: Tuesday, February 14, 2017 3:04 AM >> > >> > After we received the dataend interrupt, R1 response register carries >> > the value from the automatically generated stop command. Report that >> > info back to the MMC block layer, so we will be notified in case of e.g. >> > ECC errors which happened during the last transfer. >> > >> > Reviewed-by: Simon Horman <horms+renesas@xxxxxxxxxxxx> >> > Signed-off-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> >> >> I tested this patch with a SD tester (SGDK320). >> As the commit log, this patch could pass the R1 response. So, >> >> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx> > > Thank you very much for testing! > >> However, I think the MMC block layer should check the brq->stop.resp[0] >> because brq->stop.error should be zero in this case and mmc_blk_cmd_recovery() >> is not called in mmc_blk_err_check(). > > I see. Ulf, do you think it makes sense to extend the condition when to > call mmc_blk_cmd_recovery() with checking if stop.resp[0] has one of the > R1_* bits set which are marked with 'ex' (and probably 'erx', too)? I > agree with Shimoda-san, that the core is a good place to do it, since it > is about parsing the R1 and not the status bits of the host hardware. The method we use to indicate a stop command error to the mmc core, is to set ->stop.error in the host driver before completing the request. Perhaps set it to -EIO or -EILSEQ. In that way mmc_blk_err_check() sees the error and invokes the mmc_blk_cmd_recovery() to deal with it (response parsing etc). Does that work for you? Kind regards Uffe -- 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
