> Julius, are you sure the Synopsys host will actually power off the > ports? The Intel hosts need some special ACPI methods, so I'm not sure > if Dan's issue with ports after power on could even be seen on the > Synopsys host. > > The Synopsys issue (as I remember it, please correct me if I'm wrong) > would only be triggered if the host lost power during S3, and was halted > and reset after a register restore failure. I think the solution we > agreed to was to implement a Synopsys host quirk that would warm reset > all ports unconditionally on register restore failure. Was that right? > > Then there's Dan's issue. Dan, does the port go into SS.Inactive before > the host starts to cycle between RxDetect and Polling and U0 for this > case? Sorry, I didn't mean to pull the Synopsys issue into this thread... we should probably keep that separate in https://lkml.org/lkml/2013/12/9/336 , or this will get too confusing. Some aspects of that issue are definitely different, e.g. there's no port power being turned off there (on the contrary, the problem is that the power session stays alive during suspend but the xHC gets reset and forgets about it). I just wanted to point out that both issues can lead to the same state (by different means) where the port status cycles between RxDetect and Polling, because they both reset the host controller's port state to RxDetect in a way that the device might not notice (or not react correctly to). I think whenever the host port state gets forced back to RxDetect while the device is in SS.Inactive (or anything that can lead to SS.Inactive after a few unexpected packets) you will get into this state, and you will only get back out of there through a warm reset (or by physically cutting off VBUS). > Hans also ran into this issue (or at least a variation of it), and > proposed a patch to fix it. > > https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-next-streams&id=3fd14185404e3a298a3f6b6c6f21ff8d41bb2747 > > 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. > > 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.) -- 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
