Hi Udipto, On Fri, Nov 18, 2022, Udipto Goswami wrote: > Hi Thinh > > On 11/18/22 7:31 AM, Thinh Nguyen wrote: > > On Thu, Nov 17, 2022, Udipto Goswami wrote: > > > A dequeue for ep0 need to adjust the handling based on the > > > data stage and status stage. Currently if ep0 is in data/status > > > stage the handling isn't that different, driver will try giveback > > > as part of dequeue process which might potentially lead to the > > > controller accessing invalid trbs. > > > > > > Also for ep0 the requests aren't moved into the started_list, > > > which might potentially lead to the un-mapping of the request > > > buffers without sending endxfer. > > > > Maybe we need to track started_list for control endpoint? If the request > > isn't prepared yet or that the transfer had completed, then there's no > > need to issue End Tranfer command. > > > > But I believe sending End Transfer for inactive endpoint should be fine > > also. Then we maybe able to get away without checking the started list. > > If you're planning to do that, please test and note it somewhere. > > > > > > thanks for the suggestion, sure i'll do some more experiments and confirm > it. > Just curious, how do you hit/test this scenario? For other endpoint types, I can see possible scenarios where a dequeue may be needed, but I don't see one for control transfer. The host can cancel the control transfer, and the controller will see "setup_packet_pending" and handle accordingly. If there's a disconnect, that's also handled separately by the controller driver also. So, where does ep0_dequeue come into play here? Thanks, Thinh
