Re: [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- From: Matt Fleming <matt@xxxxxxxxxxxxxxxxx>
- Date: Thu, 28 May 2009 10:19:24 +0100
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- From: Wolfgang Mües
- Re: [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- References:
- [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- From: Wolfgang Mües
- Re: [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- From: Pierre Ossman
- Re: [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- From: Wolfgang Mües
- [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- Prev by Date: Re: Analyzed/Solved/Bisected: Booting 2.6.30-rc2-git7 very slow
- Next by Date: Re: [PATCH] sched: Support current clocksource handling in fallback sched_clock().
- Previous by thread: Re: [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- Next by thread: Re: [PATCH] mmc_spi: do propper retry managment in the block layer - 3rd try
- Index(es):
Relevant Pages
|
