[PATCH] fix PXA27x MMC workaround for bad CRC with 136 bit response

[Nicolas Pitre <nico@cam.org>]

... and make it depend on the response flag instead of the command type.

Signed-off-by: Nicolas Pitre <npitre@mvista.com>
---

On Sat, 12 May 2007, Pierre Ossman wrote:
> Nicolas Pitre wrote:
> > Please apply the following patch.  It is compile tested only as I don't 
> > have PXA27x hardware with MMC at the moment, but it just cannot be worse 
> > than the current code even when it was compiling.
> >
> >   
> 
> I would think that it would be better to look at just MMC_RSP_136 and
> MMC_RSP_CRC in case we get future variations.

Makes sense.

diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index d97d386..f8985c5 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -232,20 +232,14 @@ static int pxamci_cmd_done(struct pxamci_host *host, unsigned int stat)
 		/*
 		 * workaround for erratum #42:
 		 * Intel PXA27x Family Processor Specification Update Rev 001
+		 * A bogus CRC error can appear if the msb of a 136 bit
+		 * response is a one.
 		 */
-		if (cmd->opcode == MMC_ALL_SEND_CID ||
-		    cmd->opcode == MMC_SEND_CSD ||
-		    cmd->opcode == MMC_SEND_CID) {
-			/* a bogus CRC error can appear if the msb of
-			   the 15 byte response is a one */
-			if ((cmd->resp[0] & 0x80000000) == 0)
-				cmd->error = MMC_ERR_BADCRC;
-		} else {
-			pr_debug("ignoring CRC from command %d - *risky*\n",cmd->opcode);
-		}
-#else
-		cmd->error = MMC_ERR_BADCRC;
+		if (cmd->flags & MMC_RSP_136 && cmd->resp[0] & 0x80000000) {
+			pr_debug("ignoring CRC from command %d - *risky*\n", cmd->opcode);
+		} else
 #endif
+		cmd->error = MMC_ERR_BADCRC;
 	}
 
 	pxamci_disable_irq(host, END_CMD_RES);
-
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/