mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Wolfgang Mües" <wolfgang.mues@auerswald.de>
To: Pierre Ossman <pierre@ossman.eu>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Matt Fleming" <matt@console-pimps.org>,
	"David Brownell" <dbrownell@users.sourceforge.net>,
	"Mike Frysinger" <vapier.adi@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mmc_spi: do propper retry managment in the block layer
Date: Tue, 14 Apr 2009 16:27:26 +0200	[thread overview]
Message-ID: <200904141627.26276.wolfgang.mues@auerswald.de> (raw)
In-Reply-To: <20090411001030.56e247c4@mjolnir.ossman.eu>

Hello Pierre,

Am Samstag, 11. April 2009 schrieb Pierre Ossman:
> NAK. Writes cannot be retried safely as upper layers rely on the fact
> that writes fail in a linear manner (a stupid assumption IMO, but
> that's the way things are).

Hmmm.... so this patch has to be improved. I think the (original) code in 
mmc_blk_issue_rq() is somewhat questionable. As far as I understand the code, 
in the case of an error, brq.data.bytes_xfered is not examined, so the code 
starts over from the very first sector of the request, and rereads all 
sectors (one after the another).

So if there is a non-recoverable write error, this code must stop and do not 
continue to write, right?

But if there is a read error, it is OK and advisable to try to read the rest 
of the sectors?

If there is a write error in the middle of a request, is it OK to do
__blk_end_request(req, 0, brq.data.bytes_xfered);
and try to retry from this point, and stop if there is a non-recoverable write 
error?

> > +		/* Invalid response. This is most likely a transmission
> > +		 * error from card to host.
> > +		 */
> > +		case -EINVAL:
>
> EINVAL is actually "host controller driver/hardware does not support
> this type of request".

"Hardware" is including the hardware of the SD card. This should NEVER happen, 
because block.c issues only valid requests, which are translated to mandatory 
commands for the mmc/sd card.

So if there is an EINVAL result from the lower layers, it comes from 
transmission errors (card has not understand the command, or host has not 
understand the response).

If EINVAL is coming from the HOST CONTROLER, a retry will not harm anyone.

I have seen EINVAL results due to spikes on the SD lines.

Please correct me if I am wrong.

best 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@Auerswald.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

  reply	other threads:[~2009-04-14 14:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-08  9:55 Wolfgang Mües
2009-04-10 22:10 ` Pierre Ossman
2009-04-14 14:27   ` Wolfgang Mües [this message]
2009-04-28 19:57     ` Pierre Ossman
2009-05-06  9:45       ` Wolfgang Mües
2009-05-13 19:45         ` Pierre Ossman

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=200904141627.26276.wolfgang.mues@auerswald.de \
    --to=wolfgang.mues@auerswald.de \
    --cc=akpm@linux-foundation.org \
    --cc=dbrownell@users.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@console-pimps.org \
    --cc=pierre@ossman.eu \
    --cc=vapier.adi@gmail.com \
    /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®