lkml.org 
[lkml]   [2009]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
On Thu, May 28, 2009 at 10:28:29AM +0200, Wolfgang Mües wrote:
> Pierre,
>
> Am Mittwoch, 27. Mai 2009 schrieb Pierre Ossman:
>

[...]

> > > + /* Do retries for all sort of transmission errors */
> > > + switch (error) {
> > >
> > > - /*
> > > - * A block was successfully transferred.
> > > + case 0: /* no error: continue, reset error variables */
> > > + disable_multi = 0;
> > > + retries = 3;
> > > + break;
> > > +
> > > + /* Card has not understand command. As we do only send
> > > + * valid commands, this must be a transmission error. */
> > > + case -EPROTO: /* fall through */
> >
> > This indicates a layering problem. The host driver should not be aware
> > of anything but pure bit errors.
> >
> > Also, this special meaning should be documented in core.h should we
> > decide to keep it.
>
> This is not MY error code. EPROTO is send from mmc_spi_writeblock(), and I
> have listed it here because it is a transmission error.
>
> So there seems to be contrary objections: Matt Flemming has requested that the
> exact cause of error is reported by the driver (because otherwise the caller
> will loose information), and you requested to distinguish only between
> transmission errors and the rest.
>
> Matt Flemming has pointed out that further changes in the code will request to
> get the exact cause of error in the block layer, and that error codes might
> have interpreted different according to the command class, so IMHO it is
> better to transport the exact error cause into block.c and do the error
> handling here, according to the type of request.
>

When I said "report the correct error" I was objecting to using EILSEQ
as The One True Error Code based on the fact that a transmission error
may, or may not, have occurred.

That is not contrary to Pierre's comments. I was not advocating
layering violations ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-05-28 11:21    [W:0.070 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site