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

From: Wolfgang MÃes
Date: Mon May 25 2009 - 10:59:46 EST


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.

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.

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 .

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).

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.

i. A. Wolfgang MÃes
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94
E-Mail: Wolfgang.Mues@xxxxxxxxxxxx
Auerswald GmbH & Co. KG, Vor den GrashÃfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald GeschÃftsfÃhrungsges. mbH
Registriert beim AG Braunschweig HRB 7463
GeschÃftsfÃhrer: Dipl-Ing. Gerhard Auerswald
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at