[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190403102359.27698-1-nicolas.ferre@microchip.com>
Date: Wed, 3 Apr 2019 12:23:57 +0200
From: Nicolas Ferre <nicolas.ferre@...rochip.com>
To: <dmaengine@...r.kernel.org>, Vinod Koul <vkoul@...nel.org>
CC: Ludovic Desroches <ludovic.desroches@...rochip.com>,
<linux-arm-kernel@...ts.infradead.org>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
<linux-kernel@...r.kernel.org>,
"Nicolas Ferre" <nicolas.ferre@...rochip.com>
Subject: [PATCH v3 1/3] dmaengine: at_xdmac: remove BUG_ON macro in tasklet
Even if this case shouldn't happen when controller is properly programmed,
it's still better to avoid dumping a kernel Oops for this.
As the sequence may happen only for debugging purposes, log the error and
just finish the tasklet call.
Signed-off-by: Nicolas Ferre <nicolas.ferre@...rochip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@...rochip.com>
---
v3: no change
v2: added Ludovic's tag
drivers/dma/at_xdmac.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index fe69dccfa0c0..37a269420435 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1606,7 +1606,11 @@ static void at_xdmac_tasklet(unsigned long data)
struct at_xdmac_desc,
xfer_node);
dev_vdbg(chan2dev(&atchan->chan), "%s: desc 0x%p\n", __func__, desc);
- BUG_ON(!desc->active_xfer);
+ if (!desc->active_xfer) {
+ dev_err(chan2dev(&atchan->chan), "Xfer not active: exiting");
+ spin_unlock_bh(&atchan->lock);
+ return;
+ }
txd = &desc->tx_dma_desc;
--
2.17.1
Powered by blists - more mailing lists