On 6/9/2017 4:15 PM, Mathias Nyman wrote: > I think it's valid to check if the endpoint is already stopped from the endpoint context, and not > queue a stop endpoint command for a already stopped endpoint. Especially as your hardware can't handle it. > That code makes sense. > Thank you Mathias for the very detailed email :-) We spoke with our HW folks and they said that they are aware of the WA limitations and scenarios it cannot cover. Unfortunately, there is no way to avoid the race condition and we have to live with it. So, it is possible to take the v2 of this patch ? or is it better to add a quirk for this specific revision of AMD HW which cannot handle the scenario. Please advise. Thanks, Shyam > I also think you got a bit confused what the current code does. It does not stop same endpoint twice. > It stops endpoints 30-1 in a loop, and then endpoint 0 after the loop. > > Then I think yo need to consider the race Alan was talking about. > Let me try to clarify that race case again. > Even after checking the endpoint state from endpoint context the following could happen: > > -- xhci driver, in xhci_stop_device() --- > 1. driver checks endpoint x context shows endpoint is running > 2. driver queues a stop endpoint command for endpoint x on command ring > -- xhci hardware -- > 3. endpoint x is till running, > 4. xhci hardware gets a STALL packet on endpoint x from the device. > 5. xhci hardware sets endpoint x to HALT state > 6. xhci hardware takes stop endpoint command from command ring and start executing it > 7. xhci hardware tries to stop endpoint x which is in HALTED state > > -> possible RTL bug! > > After all this we need to take into account that xhci spec say that there can be > be a small delay before actual endpoint state is updated to the endpoint context. > The spec recommends that the driver keeps track of latest endpoint state changes. > Like when ringing a doorbell it will start the endpoint, but endpoint context state is > updated to running with a small delay > > -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
