All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@console-pimps.org>
To: "Wolfgang Mües" <wolfgang.mues@auerswald.de>
Cc: Pierre Ossman <pierre@ossman.eu>,
	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: do propper retry managment in the block layer - 3rd try
Date: Sat, 30 May 2009 23:16:13 +0100	[thread overview]
Message-ID: <20090530221613.GA642@console-pimps.org> (raw)
In-Reply-To: <200905281152.26191.wolfgang.mues@auerswald.de>

On Thu, May 28, 2009 at 11:52:26AM +0200, Wolfgang Mües wrote:
> 
> So somewhere I will need to have an error code filter based on the issued 
> command (class). Should this be in the driver(s)? Or should it be at the 
> location of the caller, in block.c?
> 

It should be in the function/file that makes the most sense.

> The advantages of putting it in block.c is that
> a) The command (class) is typically implicit given in the function, and no 
> need for a switch() statement.
> b) Only one handling for different drivers, not scattered through all(?) host 
> drivers.
> 

You know what, I was going to say that only block transaction stuff is
in block.c, but that's not true, there's loads of MMC protocol
knowledge in there too. I don't think there's a better place than
mmc/drivers/card/block.c, currently.

I would expect all this error handling and intimate knowledge of the
MMC/SD protocol to be in drivers/mmc/core, but that's not the
case. Which just seems strange to me.

> I must admit that I have difficulties to see a clear layering violation.
> There is no clear definition of which error codes should be reported to the 
> block layer. There is only a short list of codes with special meaning, but 
> not a full list of all used codes.
> 
> And some drivers are reporting codes like ENOMEM etc...
> 
> I see that Pierre wants to have a more smaller interface between drivers and 
> the upper layer, reporting only classes of errors, to have a more smaller and 
> cleaner code in the upper layer. But I think that this is a patch of its own, 
> and not in the context of the retry patch.
> 

I agree. That could be a separate patch.

  reply	other threads:[~2009-05-30 22:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-26 11:11 [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try Wolfgang Mües
2009-05-27 19:49 ` Pierre Ossman
2009-05-28  8:28   ` Wolfgang Mües
2009-05-28  9:19     ` Matt Fleming
2009-05-28  9:52       ` Wolfgang Mües
2009-05-30 22:16         ` Matt Fleming [this message]
2009-06-30 14:14     ` 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=20090530221613.GA642@console-pimps.org \
    --to=matt@console-pimps.org \
    --cc=akpm@linux-foundation.org \
    --cc=dbrownell@users.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre@ossman.eu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.