>> We don't need to change hub_port_debounce() right away... that was >> just an additional suggestion to make things more efficient for >> SuperSpeed devices in general. I think for now (in order to solve >> Dan's problem), it would be best if he just calls hub_port_debounce() >> in usb_port_runtime_resume() (which should bring a connected device >> back in the majority of cases), and always queues up a warm reset if >> that fails. (This is essentially what his patch is already doing, just >> get rid of the extra check for USB_SS_PORT_LS_POLLING in the error >> path which I think might be a little too specific and overlook cases >> where the RxDetect/Polling cycle just happens to be at RxDetect in >> that moment.) > > That's the plan, and I also want to test a usb device quirk flag to > unconditionally warm reset on power-session loss since it does seem to > be device specifc in my case. For what it's worth, I think you might not need a quirk flag since you are not really loosing anything in that case. If the first hub_port_debounce() fails to reconnect, the device is either quirky or there is no device attached at all. In the first case we want the warm reset, and in the second case the warm reset is pointless but also doesn't cost us anything (assuming it runs totally asynchronous, which I think your patch guarantees). The only case where we really need to avoid wasting those 100ms is on ports which are connected and already usable, but those should be caught by hub_port_debounce() already. -- 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
