> From: Matthijs Kooijman [mailto:matthijs@xxxxxxxx] > Sent: Tuesday, April 16, 2013 12:03 PM > > > No, the interrupt is strictly a host interrupt. But due to the > > design of the hardware, there's a race condition: Say the user > > unplugs the A connector from the host. The disconnect interrupt gets > > triggered, and the driver starts to process it. But unplugging the > > A connector also causes the core to switch to device mode, on its > > own, without any input from the driver. So by the time the CPU > > gets to the point in dwc2_hcd_intr() where it checks to see what > > mode the core is in, it could now be in device mode, even though > > the interrupt was triggered while in host mode. > > Ah, right. This sounds like its the same as for the DISCONNINT. Perhaps > the handling for PRTINT can be the same as you proposed for DISCONNINT: > handle it in dwc_hcd_intr, but before the check for host mode? Yes. Actually, it would probably be best to check the core's mode at the start of the host interrupt handler, and if it's in device mode, just clear ALL asserted host-only interrupts and return without doing anything further. According to the databook, the host-only interrupts are DisconnInt, PTxFEmp, HChInt, and PrtInt. DisconnInt is cleared via the GINTSTS register, HChInt is cleared via the HCINTn register, and PrtInt is cleared via the HPRT register. PTxFEmp can't be cleared without writing data to the FIFO, so I guess that one should just be disabled in GINTMSK. Want to take a crack at that? -- Paul -- 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
