Hello Mathias, On Tue, Mar 26, 2019 at 11:12:46AM +0200, Mathias Nyman wrote: > Hi > > > > > > > > link went to U3. Why would xhci put the link to U3 now? We're still > > > > working fine. > > > > > > This looks like a pretty crazy set of transitions. I'm unfamiliar with > > > LPM. Is this sequence of events normal for a transition to U3? > > > > See figure 7-14 on USB 3.1 spec. This shows that from U2 we had LFPS > > timeout which forced link to SS.Inactive. Then, link *must* go through > > RX.Detect to restart a session. From there, a condition called RX Detect > > Overlimit happens, which forces the port to SS.Disabled. > > > > Link is, then, moved to U0 by the host. Then RX.Detect, then U3. This is > > all under host side control. DWC3 is simply reporting the states. > > > > > During this particular run, I was not performing any operations on the > > > mass storage device besides mounting it on my computer. No reading or > > > writing besides that. Would this sort of inactivity have something to do > > > with the transition to U3? > > > > No. XHCI shouldn't put anything into U3 by default. Mathias can give > > more details here. > > > > So System and runtime suspend sets link to U3, but it is also set for USB3 > devices when we want to disable the device. > This is because USB3 does not have any "disabled" link state like USB2 that will > avoid negotiating a connection with a plugged-in cable, and signal the host > when the cable is unplugged. > > This is done when the device is ejected/safely removed, or in case something already > went wrong and we want to "disable" the device. Does it look like something has gone wrong here? Or do you need more information? Soon I'll be reproducing this issue and gathering xhci_hcd tracepoints so hopefully that will provide more clarity. Cheers, Rob Weber
