https://bugzilla.kernel.org/show_bug.cgi?id=207065 --- Comment #6 from Alan Stern (stern@xxxxxxxxxxxxxxxxxxx) --- On Thu, 9 Apr 2020 bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > --- Comment #4 from Mathias Nyman (mathias.nyman@xxxxxxxxxxxxxxx) --- > Thanks, traces show its related to Clearing TT buffer after a STALL on > endpoint 0. > > The first stall looks like a protocol stall, not a function stall, meaning > that > endpoint isn't really halted, just that the device does not support the > request in the control transfer. > > Anyway, xhci starts clearing what it assumes is a halted endpoint, > including clearing the hub TT buffer. > > Specs are a bit unclear if TT should be cleared in this case, > or at least I couldn't find it. TTs should be cleared when an error occurs in the protocol. STALL isn't an error; a real error would be a timeout or CRC mismatch or URB cancellation, things like that -- things that might leave the TT in a busy state (because it hasn't sent its final status back to the host) when it ought to be idle. Sending a STALL isn't a protocol error and it does clear the TT status. This is discussed (not as explicitly as one might want) in sections 11.17.3 and 11.17.5 of the USB-2.0 specification. Alan Stern -- You are receiving this mail because: You are watching the assignee of the bug.
