| commit | 6d26f8260a3c06933310d9641deae782182eba24 | |
| author | Ben Dooks <ben-linux@fluff.org> | |
| Mon, 3 Nov 2008 20:19:01 +0000 (3 20:19 +0000) | ||
| committer | Ben Dooks <ben-linux@fluff.org> | |
| Mon, 3 Nov 2008 20:30:50 +0000 (3 20:30 +0000) | ||
| tree | 6a4ba910b831e971bb022ddd30c4a96ff53ff9cb | treesnapshot (tar.gz zip) |
| parent | e8b704d34687aa65ccc4f064b29786305f8427bc | commitdiff |
SDHCI: Check DMA for overruns at end of transfer
At the end of a transfer, check that the DMA engine in the
SDHCI controller actually did what it was meant to and didn't
overrun the end of the buffer.
This seems to be triggered by a timeout during an CMD25 (multiple block
write) to a card. The mmc_block module then issues a command to find out
how much data was moved and this seems to end up triggering this DMA
check. The result is the card's queue generates an OOPS as the stack has
been trampled on due to the extra data transfered.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
At the end of a transfer, check that the DMA engine in the
SDHCI controller actually did what it was meant to and didn't
overrun the end of the buffer.
This seems to be triggered by a timeout during an CMD25 (multiple block
write) to a card. The mmc_block module then issues a command to find out
how much data was moved and this seems to end up triggering this DMA
check. The result is the card's queue generates an OOPS as the stack has
been trampled on due to the extra data transfered.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
| drivers/mmc/host/sdhci.c | diffblobblamehistory |