On 02.01.2017 14:13, Felipe Balbi wrote:
Hi,
Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> writes:
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.
Another thing I noticed is that we're clearing PortFeature(PortReset)
less than 20ms after setting it. Full tracepoint data attached (slot 28
actually, this is not a problem. Reset is supposed to be 10ms minimum.
device-reset-2819 [002] d..1 154.868782: xhci_queue_trb: CMD: Reset Device Command: slot 28 flags C
<idle>-0 [003] d.h2 154.868832: xhci_handle_event: EVENT: TRB 00000001be2b2e60 status 'Context State Error' len 0 slot 28 ep 0 type 'Command Completion Event' flags e:C
And here's xHCI telling us that slot 28's Context was is invalid status.
I traced this down to Slot being in Default state. According to Figure
10 Slot State Diagram, Reset Device is only allow from Configured or
Addressed. Any other states, Reset Device is invalid and shouldn't be
issued.
Now I'm wondering whether we should hide this fact from USB Core, or do
we have a bigger problem with USB Core itself.
when core calls hcd->driver->reset_device() xhci
will always submit a reset device command without checking the slot state,
even if it will return context state error when slot is in a default state.
As we just checked it looks like USB2 specs, fig 9.1 allows resetting
the device is default state, so this limitation is xhci specific.
-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
