public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@console-pimps.org>
To: "Wolfgang Mües" <wolfgang.mues@auerswald.de>,
	"David Brownell" <david-b@pacbell.net>
Cc: Pierre Ossman <drzeus@drzeus.cx>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Frysinger <vapier.adi@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors
Date: Wed, 20 May 2009 08:53:27 +0100	[thread overview]
Message-ID: <20090520075327.GA11473@console-pimps.org> (raw)
In-Reply-To: <200905192149.07778.david-b@pacbell.net> <200905191347.46026.wolfgang.mues@auerswald.de>

On Tue, May 19, 2009 at 09:49:07PM -0700, David Brownell wrote:
> On Tuesday 19 May 2009, Matt Fleming wrote:
> > 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.
> 
> True, but a pr_debug from mmc_spi could help that.  A patch doing
> that would need to be less aggressive about ripping out the current
> fault-parsing logic, but it could continue reporting -EILSEQ to
> cope with the possible response mangling.
> 

Yes, a less aggressive patch would be fine.

> > 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.
> 
> Do you have a better solution to propose though?  If Wolfgang
> is actually observing transmission errors there, I'm not sure
> a better one is to be had.
> 

You're right. It's not cool for me to criticise and not give any
suggestions. I've been trying to come up with some middle-ground
solution since yesterday.

I think if the patch was less aggressive at returning EILSEQ, it'd be
fine. For instance, returning EILSEQ if the response you get doesn't
make any sense given the command you sent or if the response is just
garbage.

It might even make sense to retry commands (say twice, and only if
it's safe to do so) and if the response codes differ in bizarre ways
then the status bits have probably been garbled on the bus and EILSEQ
is the correct error code to use. I'm less sure about this bit though,
it depends on exactly what we're trying to fix.

Wolfgang, is there a particular scenario where you're seeing the
status bits trashed by noise on the line? Or is this just a cautionary
patch?

On Tue, May 19, 2009 at 01:47:45PM +0200, Wolfgang Mües wrote:
> 
> > IMHO always assuming that command errors are caused by transmission
> > problems is not the right solution.
> 
> It's not your or my fault, it's the fault of the spi SD/MMC card protocol 
> designer. You may send him to me, already prepared: naked and in chains ;-)

This is the funniest reply I've ever read.

  reply	other threads:[~2009-05-20  7:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14 11:24 [PATCH] mmc_spi: use EILSEQ for possible transmission errors Wolfgang Mües
2009-05-19 11:29 ` Matt Fleming
2009-05-19 11:47   ` Wolfgang Mües
2009-05-20  7:53     ` Matt Fleming [this message]
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=20090520075327.GA11473@console-pimps.org \
    --to=matt@console-pimps.org \
    --cc=akpm@linux-foundation.org \
    --cc=david-b@pacbell.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