From: Matt Fleming <matt@console-pimps.org>
To: "Wolfgang Mües" <wolfgang.mues@auerswald.de>
Cc: Pierre Ossman <drzeus@drzeus.cx>,
Andrew Morton <akpm@linux-foundation.org>,
David Brownell <dbrownell@users.sourceforge.net>,
Mike Frysinger <vapier.adi@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors
Date: Tue, 19 May 2009 12:29:48 +0100 [thread overview]
Message-ID: <20090519112948.GB28564@console-pimps.org> (raw)
In-Reply-To: <200905141324.27908.wolfgang.mues@auerswald.de>
On Thu, May 14, 2009 at 12:24:27PM +0100, Wolfgang Mües wrote:
> From: Wolfgang Muees <wolfgang.mues@auerswald.de>
>
> o This patch changes the reported error code for the responses
> to a command from EINVAL/EIO to EILSEQ, as EINVAL is reserved
> for non-recoverable host errors, and the responses from
> the SD/MMC card may be because of recoverable transmission
> errors in the command or in the response. Response codes
> are NOT protected by a checksum, so don't trust them.
>
> Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de>
>
> ---
> diff -uprN 2_6_29_rc7_patch_wearout_speedup/drivers/mmc/host/mmc_spi.c 2_6_29_rc7_patch_EILSEQ/drivers/mmc/host/mmc_spi.c
> --- 2_6_29_rc7_patch_wearout_speedup/drivers/mmc/host/mmc_spi.c 2009-04-08 11:11:20.000000000 +0200
> +++ 2_6_29_rc7_patch_EILSEQ/drivers/mmc/host/mmc_spi.c 2009-05-14 12:49:42.000000000 +0200
> @@ -334,17 +334,18 @@ checkstatus:
> cmd->error = 0;
>
> /* Status byte: the entire seven-bit R1 response. */
> - if (cmd->resp[0] != 0) {
> - if ((R1_SPI_PARAMETER | R1_SPI_ADDRESS
> - | R1_SPI_ILLEGAL_COMMAND)
> - & cmd->resp[0])
> - value = -EINVAL;
> - else if (R1_SPI_COM_CRC & cmd->resp[0])
> - value = -EILSEQ;
> - else if ((R1_SPI_ERASE_SEQ | R1_SPI_ERASE_RESET)
> - & cmd->resp[0])
> - value = -EIO;
> - /* else R1_SPI_IDLE, "it's resetting" */
> + /*
> + * Note that we have a problem here: as the response is NOT protected
> + * by a CRC or checksum, a transmission error in the response will
> + * be interpreted as an error code. So we map all error codes to
> + * EILSEQ here, to allow for the upper layer to retry the command.
> + * If one of these error codes is a non-recoverable error, retries
> + * will do no harm.
> + */
> +
> + /* Allow only 0 and R1_SPI_IDLE here */
> + if (cmd->resp[0] & ~R1_SPI_IDLE) {
> + value = -EILSEQ;
> }
>
> switch (mmc_spi_resp_type(cmd)) {
Hmm, always returning -EILSEQ is devious. What happens if we sent an
illegal command? The value of "value" is passed up to the callers via
cmd->error and so may eventually get printed in the pr_debug() call in
mmc_request_done(), line 86.
Whereas before the error would display EINVAL for an illegal command
now it'll display EILSEQ, which makes no sense. Seeing EILSEQ in my
log when really the error is EINVAL is gonna really confuse me.
IMHO always assuming that command errors are caused by transmission
problems is not the right solution.
next prev parent reply other threads:[~2009-05-19 11:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-14 11:24 Wolfgang Mües
2009-05-19 11:29 ` Matt Fleming [this message]
2009-05-19 11:47 ` Wolfgang Mües
2009-05-20 7:53 ` Matt Fleming
2009-05-20 4:49 ` David Brownell
2009-05-20 8:35 ` Wolfgang Mües
2009-05-20 9:20 ` David Brownell
2009-05-20 10:08 ` Pierre Ossman
2009-05-21 2:02 ` David Brownell
2009-05-25 9:04 ` Wolfgang Mües
2009-05-25 9:43 ` David Brownell
2009-05-25 10:18 ` Wolfgang Mües
2009-05-25 11:50 ` Pierre Ossman
2009-05-25 14:59 ` Wolfgang Mües
2009-06-09 18:07 ` Pierre Ossman
2009-06-10 7:29 ` Wolfgang Mües
2009-06-10 7:37 ` Matt Fleming
2009-06-13 10:57 ` Pierre Ossman
2009-05-25 11:48 ` Pierre Ossman
2009-05-20 10:31 ` Wolfgang Mües
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090519112948.GB28564@console-pimps.org \
--to=matt@console-pimps.org \
--cc=akpm@linux-foundation.org \
--cc=dbrownell@users.sourceforge.net \
--cc=drzeus@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=vapier.adi@gmail.com \
--cc=wolfgang.mues@auerswald.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®