On Tue, Feb 18, 2014 at 2:40 PM, Julius Werner <jwerner@xxxxxxxxxxxx> wrote: >> Can you take a look at it, and see if it would address your issue? I >> think it will catch the case where we transition from SS.Inactive -> >> RxDetect -> Polling. > > I don't think that's targeting the same problem. Hans seems to be > describing a situation where the device connects again even though he > doesn't want it to -- in our case, the device doesn't connect even > though we want that. His patch shouldn't do anything for our issue > since he checks for PORT_STAT_CONNECTION, and that bit will be unset > when the host port is stuck in RxDetect/Polling. Yes, agreed. > >> > It is a valid transitional state, unfortunately, but in a working case >> > it should resolve itself within a few milliseconds (probably less than >> > 10). Maybe we should try to differentiate between USB 2.0 and 3.0 >> > devices in hub_port_debounce()? I think due to the built-in link >> > training in USB 3.0, the classic debouncing doesn't really make sense >> > anymore (and wastes a lot of time since SuperSpeed links can train >> > really fast when they work). >> > >> > As for this patch, I think the best approach would be to wait for the >> > device to come back in usb_port_runtime_resume() (through >> > hub_port_debounce() or something else), and if it doesn't show up >> > always set the bit to warm reset the port (regardless of LTSSM state, >> > since even if it says RxDetect I wouldn't be sure that there is really >> > nothing connected). We could then also use those bits in the "lost >> > power" case of xhci_resume() to try and work around the problems with >> > that Synopsys controller. >> >> That's a lot of changes to the hub core. Would an xHCI quirk be >> simpler? Is there some scenario I'm missing that the S3 resume quirk >> wouldn't handle? > > 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. -- 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
