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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 May 2009 16:59:17 +0200
From:	Wolfgang Mües <wolfgang.mues@...rswald.de>
To:	Pierre Ossman <pierre@...man.eu>
Cc:	"David Brownell" <david-b@...bell.net>,
	"Matt Fleming" <matt@...sole-pimps.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Mike Frysinger" <vapier.adi@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors

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.

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.

regards

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@...rswald.de
Web: http://www.auerswald.de

--------------------------------------------------------------
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/