On Mon, 2 Jan 2017, Mathias Nyman wrote: > On 30.12.2016 14:01, Felipe Balbi wrote: > > > > Hi Mathias, > > > > So the problem I found with v4.10-rc1 doesn't appear to be a > > regression. I can't, however, trigger it with Broadwell, only Skylake > > and Kabylake. > > > > According to tracepoints, our Reset Device Command sometimes completes > > with "Context State Error", which tells us that we're issuing Reset > > Device Command when we shouldn't. > > This could happen if reset device is issued twice, > > xhci reset device command only works for slots in Addressed or > Configured states. Reset device sets the slot to "Defult" state. Doesn't the xHCI hardware automatically assign addresses to devices? And send a Set-Address request after a reset has completed? And doesn't this mean the slot should automatically go from the Default state to the Addressed state? It should remain in the Default state only for a brief time, while the Set-Address request is in progress. Unless there's something wrong with the device, and it doesn't accept the Set-Address request. In which case, usbcore would naturally retry the reset. Is that what happened here? > If the slot is already in Default state when a reset device command > is issued xHC will return a "Context State Error" > > > > > Another thing I noticed is that we're clearing PortFeature(PortReset) > > less than 20ms after setting it. Full tracepoint data attached (slot 28 > > is the device in question. Slot 12, AFAICT, it's parent hub), but here's > > a snippet showing both problems: > > The device is connected to a external hub. I think this should be handled > by usb core. > > hub_port_reset() in usb core should have 10ms TDRST to drive resume > and 10 ms TRSTRCY for reset recovery, (looks like it has 10+40ms for recovery) > > I haven't checked, but I think it should be ok to ask the hub about the port status > GetPortStatus() even during reset recovery, as long as we don't communicate with the > device behind the hut that is being reset. Sure, it would be okay, but what's the reason? Alan Stern -- 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
