Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors

[Pierre Ossman]

On Mon, 25 May 2009 16:59:17 +0200
Wolfgang MÃes <wolfgang.mues@xxxxxxxxxxxx> wrote:

> Pierre,
> 
> Am Montag, 25. Mai 2009 schrieb Pierre Ossman:
> > I don't remember why
> > mmc_spi is looking at responses to begin with.
> 
> Because responses are very different.
> 
> First of all, responses in SD mode and SPI mode are different.
> 

MMC and SD aren't identical either, but we don't delegate that to the
host drivers.

> Second, responses in SD mode are CRC-7 protected, so that it is easy to check 
> for transmission errors.
> 
> SPI mode responses (R1...) are without any CRC.
> 

This however is more relevant. But OTOH, I don't think mmc_spi has a
better idea if the status can be trusted or not than a higher layer.

> Third, if you have SD mode, you use a hardware host controller which manages 
> all command/data/response actions, and what you typically get is the content 
> of the status register of the host controller (which is different from the
> error code of the SD card).
> 
> So it is very natural that every host controller driver mapps the responses 
> from the host controller to a common representation (== error code). The 
> error codes with special meanings for MMC/SD are summed up in mmc/core.h .
> 

But the other drivers don't attempt to interpret the response from the
card. They just give the response back up and let the next layer deal
with it.

> The SPI host driver is a recent addition to the linux kernel, and the fact 
> that SPI responses are not CRC-protected was not accounted for in the code.
> 
> As it makes no sense to code the retry logic in every driver, the prefered way 
> is to code the retry logic in block.c. The non-SPI-mode-drivers will profit 
> from this logic, because they are getting retries for EILSEQ (CRC error) and
> ETIMEDOUT (card has not understand the command).

Indeed. But I don't like the fact that we're hiding interpretation of
responses down in the driver. It should be up to the layer issuing the
MMC request how the response should be interpreted.

But that's an issue that can be left for another day...

> 
> The biggest problem in the error codes is that EINVAL is used by the SPI 
> driver both for recoverable and for non-recoverable errors, which has to be 
> splitted IMHO.
> 

Indeed. I'll queue up the patch.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Attachment: signature.asc
Description: PGP signature