Greg Kroah-Hartman wrote:
From: Swaminathan S <swami.iyer@xxxxxx>
Race condition exists between the cppi_interrupt handler and
davinci_interrupt handler w.r.t completing a TX IO. Since DM646x
has seperate DMA and USB endpoint interrupts cppi_interrupt handler
needs to hold the lock while operating on the endpoint.
Update over previous patch to avoid taking the lock if already
taken. Tested on DM644x, DM355 and DM646x platforms.
Signed-off-by: Swaminathan S <swami.iyer@xxxxxx>
Acked-by: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx>
Acked-by: Anand Gadiyar <gadiyar@xxxxxx>
Signed-off-by: Felipe Balbi <felipe.balbi@xxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
[...]
diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index ef2332a..a44a450 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -1154,8 +1154,11 @@ irqreturn_t cppi_interrupt(int irq, void *dev_id)
struct musb_hw_ep *hw_ep = NULL;
u32 rx, tx;
int i, index;
+ unsigned long flags;
cppi = container_of(musb->dma_controller, struct cppi, controller);
+ if (cppi->irq)
+ spin_lock_irqsave(&musb->lock, flags);
tibase = musb->ctrl_base;
Duh, this can potentially exit cppi_interrupt() with the lock still
held, if the interrupt registers read 0 -- I have overlooked this
previously... though hopefully this does never happen with the separate CPPI
IRQ.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
