On AM3517, tx and rx interrupt are detected together with
the disconnect event. This generates a kernel panic in musb_interrupt,
because rx / tx are handled after disconnect.
This issue was seen with Technexion's TAM3517 SOM. Unplugging a device,
tx / rx interrupts togetehr with disconnect are detected. This brings
to kernel panic like this:
[ 68.526153] Unable to handle kernel NULL pointer dereference at virtual
address 00000011
[ 68.534698] pgd = c0004000
[ 68.537536] [00000011] *pgd=00000000
[ 68.541351] Internal error: Oops: 17 [#1] ARM
[ 68.545928] Modules linked in:
[ 68.549163] CPU: 0 Not tainted (3.6.0-rc5-00020-g9e05905 #178)
[ 68.555694] PC is at rxstate+0x8/0xdc
[ 68.559539] LR is at musb_interrupt+0x98/0x858
[ 68.564239] pc : [<c035cd88>] lr : [<c035af1c>] psr: 40000193
[ 68.564239] sp : ce83fb40 ip : d0906410 fp : 00000000
[ 68.576293] r10: 00000000 r9 : cf3b0e40 r8 : 00000002
[ 68.581817] r7 : 00000019 r6 : 00000001 r5 : 00000001 r4 : 000000d4
[ 68.588684] r3 : 00000000 r2 : 00000000 r1 : ffffffcc r0 : cf23c108
[ 68.595550] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment ke
Note: this behavior is not seen with a USB hub, while it is
easy to reproduce connectict a USB-poen directly to the USB-A of
the board.
Drop tx / rx interrupts if disconnect is detected.
Signed-off-by: Stefano Babic <sba...@denx.de>
CC: Felipe Balbi <ba...@ti.com>
---
drivers/usb/musb/am35x.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index b9b165b..b5c813a 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -312,6 +312,12 @@ static irqreturn_t am35x_musb_interrupt(int irq, void *hci)
ret = IRQ_HANDLED;
}
+ /* Drop spurious RX and TX if device is disconnected */
+ if (musb->int_usb & MUSB_INTR_DISCONNECT) {
+ musb->int_tx = 0;
+ musb->int_rx = 0;
+ }
+
if (musb->int_tx || musb->int_rx || musb->int_usb)
ret |= musb_interrupt(musb);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
