[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1350570852-10398-6-git-send-email-andriy.shevchenko@linux.intel.com>
Date: Thu, 18 Oct 2012 17:34:11 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Viresh Kumar <viresh.linux@...il.com>,
Vinod Koul <vinod.koul@...el.com>,
linux-kernel@...r.kernel.org,
spear-devel <spear-devel@...t.st.com>, balbi@...com
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: [PATCHv3 5/6] dw_dmac: change dev_crit to dev_WARN in dwc_handle_error
In case of handling a bad descriptor the dwc_handle_error() will dump a stack
as well. It's a lot more verbose and more likely to get user's attention.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
---
drivers/dma/dw_dmac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 180ffd5..826ff8d 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -485,14 +485,14 @@ static void dwc_handle_error(struct dw_dma *dw, struct dw_dma_chan *dwc)
dwc_dostart(dwc, dwc_first_active(dwc));
/*
- * KERN_CRITICAL may seem harsh, but since this only happens
+ * WARN may seem harsh, but since this only happens
* when someone submits a bad physical address in a
* descriptor, we should consider ourselves lucky that the
* controller flagged an error instead of scribbling over
* random memory locations.
*/
- dev_crit(chan2dev(&dwc->chan), "Bad descriptor submitted for DMA!\n");
- dev_crit(chan2dev(&dwc->chan), " cookie: %d\n", bad_desc->txd.cookie);
+ dev_WARN(chan2dev(&dwc->chan), "Bad descriptor submitted for DMA!\n"
+ " cookie: %d\n", bad_desc->txd.cookie);
dwc_dump_lli(dwc, &bad_desc->lli);
list_for_each_entry(child, &bad_desc->tx_list, desc_node)
dwc_dump_lli(dwc, &child->lli);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists