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]

 



> > 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?

It would work, yes. Since R1 response format is hardware independent, I
wondered if checking for ECC errors wouldn't be better suited in the
core. We roughly need something like this:

	if (stop.resp[0] & R1_CARD_ECC_FAILED)
		stop.error = -EIO;

We can copy this into every driver, of course. Yet, I wondered if we
couldn't have a helper function mapping the R1 error bits to an
apropriate error value and call that just before the check in
mmc_blk_err_check().

Do you get what I mean?

Thanks,

   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