Re: [PATCH v2 4/4] mmc: host: tmio: fill in response from auto cmd12

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

Shimoda-san, Ulf,

On Tue, Feb 14, 2017 at 10:06:47AM +0000, Yoshihiro Shimoda wrote:
> Hi,
> 
> > From: Wolfram Sang [mailto:wsa+renesas@sang-engineering.com]
> > 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@verge.net.au>
> > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> 
> 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@renesas.com>

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.

Regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]