Hi Michal, On 9/15/2024 12:55 AM, Michał Pecio wrote: > Hi, > >> Maybe the last sentence is not needed. When we are using the >> secondary interrupters, at least in the offload use case that I've >> verified with, the XHCI is completely unaware of what TDs have been >> queued, etc... So technically, even if we did call the default >> handler (ie xhci_handle_cmd_stop_ep), most of the routines to >> invalidate TDs are going to be no-ops. > Yes, the cancellation machinery will return immediately if there are > no TDs queued by xhci_hcd itself. > > But xhci_handle_cmd_stop_ep() does a few more things for you - it > checks if the command has actually succeeded, clears any halt condition > which may be preventing stopping the endpoint, and it sometimes retries > the command (only on "bad" chips, AFAIK). > > This new code does none of the above, so in the general case it can't > even guarantee that the endpoint is stopped when it returns zero. This > should ideally be documented in some way, or fixed, before somebody is > tempted to call it with unrealistically high expectations ;) > > As far as I see, it only works for you because isochronous never halts > and Qualcomm HW is (hopefully) free of those stop-after-restart bugs. > There will be problems if the SB tries to use any other endpoint type. So what I ended up doing was to split off the context error handling into a separate helper API, which can be also called for the sync ep stop API. From there, based on say....the helper re queuing the stop EP command, it would return a specific value to signify that it has done so. The sync based API will then re-wait for the completion of the subsequent stop endpoint command that was queued. In all other context error cases, it'd return the error to the caller, and its up to them to handle it accordingly. Thanks Wesley Cheng
