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. 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. -Mathias -- 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
