On Tue, Feb 18, 2014 at 3:39 PM, Julius Werner <jwerner@xxxxxxxxxxxx> wrote: >>> 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). No, it's not asynchronous. > 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. The quirk would stop the the implementation from wasting its time on the 2 second reconnect timeout on devices known to have problems recovering from a logical power session loss and simply issue the warm-reset immediately. That said, I should also look to see how long devices take to reconnect on average and if that is more than 120ms maybe it would make sense to unconditionally warm reset. -- 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
