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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Regards,

   Wolfram

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux