> From: Matthijs Kooijman [mailto:matthijs@xxxxxxxx] > Sent: Tuesday, April 16, 2013 9:53 AM > > On Mon, Apr 15, 2013 at 10:22:12PM +0000, Paul Zimmerman wrote: > > > > > From: Matthijs Kooijman [mailto:matthijs@xxxxxxxx] > > > Sent: Monday, April 15, 2013 7:14 AM > > > > > > For host mode, this interrupt is already handled by the hcd interrupt > > > handler. The common interrupt handler additionally did a noop handling > > > (it only cleared the flag and nothing else) when in device mode. > > > > > > Since the driver currently supports only host mode, this shouldn't > > > result in any behaviour change in the driver. When device mode is > > > implemented later on, this interrupt should be properly handled by the > > > device interupt handler, if needed. > > > > > > This change allows to make a clean cut between common interrupts and > > > host interrupts, since there are no longer any interrupts handled by > > > both. > > > > Hi Matthijs, > > > > I'd rather keep this code as-is. The reason is, even though the driver > > is currently host-only, the core that it is operating may not be. In > > that case, when the USB cable is unplugged, the core will switch to > > device mode. In that case the interrupt handler for host mode will exit > > without clearing the interrupt. > Ok, so if I understand this correctly this interrupt is really not a > common interrupt, but it is a host interrupt as well as a device > interrupt? 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. So there is an inherent race condition due to the way the hardware works. > And the code in dwc2_handle_common_intr would be moved to the > device-mode interrupt handler once it gets added? If so, I could replace > this patch with a comment stating that. No, PRTINT has no meaning in device mode. > However, the fact that an interrupt can be both a host and a device > interrupt, might complicate things. I'll think a bit about this (also > considering your other comments that I haven't answered yet) and see > what this means for the separation I have been trying to achieve :-) -- 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
