On 6/2/2017 8:21 PM, Alan Stern wrote: > On Fri, 2 Jun 2017, Shyam Sundar S K wrote: > >> on AMD platforms with SNPS 3.1 USB controller if stop endpoint command is >> issued the controller does not respond, when the EP is not in running >> state. HW completes the command execution and reports >> "Context State Error" completion code. This is as per the spec. However >> HW on receiving the second command additionally marks EP to Flow control >> state in HW which is RTL bug. The above bug causes the HW not to respond >> to any further doorbells that are rung by the driver. This causes the EP >> to not functional anymore and causes gross functional failures. >> >> As a workaround, not to hit this problem, its better we check the EP state >> and issue the stop EP command only when the EP is in running state. > Isn't there an unavoidable race? Suppose you check the EP state and > the controller says the endpoint is running. But then a STALL packet > is received and the controller stops the endpoint before you can issue > the Stop-EP command. How would you handle that?
Hi Alan, Thank you for reviewing the patch. I think, to avoid this kind of race conditions; its better to have a variable to keep track of internal state changes as rightly pointed by Mathias (as per xhci specs, section 4.8.3). But, Mathias mentioned that those changes might not be required for this workaround and that can be taken at later point in time. So, I resubmitted the patch based on his latest suggestions. Thanks, Shyam > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
