| Message ID | 144e3c053990dae825b7e06f5340e04bf7d81163.1436855646.git.nsekhar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c index d75a66c72750..20c5b9c4c288 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -1285,7 +1285,7 @@ static int omap8250_runtime_suspend(struct device *dev) return -EBUSY; } - if (up->dma) + if (up->dma && up->dma->rxchan) omap_8250_rx_dma(up, UART_IIR_RX_TIMEOUT); priv->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE; @@ -1310,7 +1310,7 @@ static int omap8250_runtime_resume(struct device *dev) if (loss_cntx) omap8250_restore_regs(up); - if (up->dma) + if (up->dma && up->dma->rxchan) omap_8250_rx_dma(up, 0); priv->latency = priv->calc_latency;
omap_device infrastructure has a suspend_noirq hook which runtime suspends all devices late in the suspend cycle (see _od_suspend_noirq() in arch/arm/mach-omap2/omap_device.c) This leads to a NULL pointer exception in 8250_omap driver since by the time omap8250_runtime_suspend() is called, 8250_dma driver has already set rxchan to NULL via serial8250_release_dma(). Make an explicit check to see if rxchan is NULL in runtime_{suspend|resume} hooks to fix this. Signed-off-by: Sekhar Nori <nsekhar@ti.com> --- v2: - updated subject line according to subsystem conventions drivers/tty/serial/8250/8250_omap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)