bcm2835_sdhci: don't use DMA for kernel dumps

When handling a data irq, the sdhci driver calls the
sdhci_platform_will_handle() method, to determine if it should allow the
platform driver to handle the transfer or fall back to programmed I/O.
While dumping, the data irq path may be invoked directly (not from an
interrupt context), which the bcm2835_sdhci DMA code is not prepared to
handle. Return early in this case, to force the fallback to PIO.

Otherwise, the KASSERT that follows will be triggered, and the dump will
fail. On non-INVARIANTS kernels, the system will hang, waiting for a DMA
interrupt that will never arrive.

Reviewed by:	kevans
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D31893

(cherry picked from commit 806ebc9eba2a45638d63ae8a2ed20e6fb44dd06e)

1 files changed, 8 insertions, 0 deletions

diff --git a/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c b/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
index cd9b60743be3..9d8be703983d 100644
--- a/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
+++ b/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
@@ -32,6 +32,7 @@ __FBSDID("$FreeBSD$");
 #include <sys/param.h>
 #include <sys/systm.h>
 #include <sys/bus.h>
+#include <sys/conf.h>
 #include <sys/kernel.h>
 #include <sys/lock.h>
 #include <sys/malloc.h>
@@ -763,6 +764,13 @@ bcm_sdhci_will_handle_transfer(device_t dev, struct sdhci_slot *slot)
 #endif
 
 	/*
+	 * We don't want to perform DMA in this context -- interrupts are
+	 * disabled, and a transaction may already be in progress.
+	 */
+	if (dumping)
+		return (0);
+
+	/*
 	 * This indicates that we somehow let a data interrupt slip by into the
 	 * SDHCI framework, when it should not have.  This really needs to be
 	 * caught and fixed ASAP, as it really shouldn't happen.