On Mon, 16 Nov 2015, Doug Anderson wrote: > --- > > usb: dwc2: host: Fix missing device insertions > > If you've got your interrupt signals bouncing a bit as you insert your > USB device, you might end up in a state when the device is connected but > the driver doesn't know it. > > Specifically, the observed order is: > 1. hardware sees connect > 2. hardware sees disconnect > 3. hardware sees connect > 4. dwc2_port_intr() - clears connect interrupt > 5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect() > > Now you'll be stuck with the cable plugged in and no further interrupts > coming in but the driver will think we're disconnected. > > We'll fix this by checking for the missing connect interrupt and > re-connecting after the disconnect is posted. We don't skip the > disconnect because if there is a transitory disconnect we really want to > de-enumerate and re-enumerate. Why do you need to do anything special here? Normally a driver's interrupt handler should query the hardware status after clearing the interrupt source. That way no transitions ever get missed. In your example, at step 5 the dwc2 driver would check the port status and see that it currently is connected. Therefore the driver would pass a "connect status changed" event to the USB core and set the port status to "connected". No extra checking is needed, and transitory connects or disconnects get handled correctly. Alan Stern
