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 <sbabic@xxxxxxx> CC: Felipe Balbi <balbi@xxxxxx> --- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html