summaryrefslogtreecommitdiffstats
path: root/drivers/mtd/ssfdc.c
diff options
context:
space:
mode:
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>2014-09-29 20:06:45 +0200
committerVinod Koul <vinod.koul@intel.com>2014-10-15 20:55:04 +0530
commit639559ada6194b722304fe267455b5bdf75c2f90 (patch)
tree591b19fff5dd83dc097f6402cc927117fe5eafe6 /drivers/mtd/ssfdc.c
parent2a52f6e49e5e400ed98a79503193d81207009647 (diff)
downloadlinux-639559ada6194b722304fe267455b5bdf75c2f90.tar.bz2
dmaengine: edma: check for echan->edesc => NULL in edma_dma_pause()
I added book keeping of whether or not the 8250-dma driver has an RX transfer pending or not so we don't BUG here if it calls dmaengine_pause() on a channel which has not a pending transfer. Guess what, this is not enough. The following can be triggered with a busy RX channel and hackbench in background: - DMA transfer completes. The callback is delayed via vchan_cookie_complete() into a tasklet so it das not happen asap. - hackbench keeps the system busy so the tasklet does not run "soon". - the UART collected enough data and generates an "timeout"-interrupt. Since 8250-dma *thinks* the DMA-transfer is still pending it tries to cancel it via invoking dmaengine_pause() first. This causes the segfault because echan->edesc is NULL now that the transfer completed (however the callback did not run yet). With this patch we don't BUG in the scenario described. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Diffstat (limited to 'drivers/mtd/ssfdc.c')
0 files changed, 0 insertions, 0 deletions