Messages in this thread | | | Date | Thu, 28 May 2009 10:19:24 +0100 | From | Matt Fleming <> | Subject | Re: [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/
| |