Felipe Balbi wrote: > Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> writes: > >> Hi Felipe, >> >> Thinh Nguyen wrote: >>> This series fixes a couple of driver issues handling ClearFeature(halt) >>> request: >>> >>> 1) A function driver often uses set_halt() to reject a class driver protocol >>> command. After set_halt(), the endpoint will be stalled. It can queue new >>> requests while the endpoint is stalled. However, dwc3 currently drops those >>> requests after CLEAR_STALL. The driver should only drop started requests. Keep >>> the pending requests in the pending list to resume and process them after the >>> host issues ClearFeature(Halt) to the endpoint. >>> >>> 2) DWC3 should issue CLEAR_STALL command _after_ END_TRANSFER command completes. >>> >>> >>> Thinh Nguyen (3): >>> usb: dwc3: gadget: Resume pending requests after CLEAR_STALL >>> usb: dwc3: gadget: END_TRANSFER before CLEAR_STALL command >> Since you're picking the fix patches for RC cycle, can you pick up these >> 2 patches of this series also? We can leave the refactoring patch in >> this series for v5.10. > just to be sure: you did run these through usbcv and usb3 compliance > suite, right? Which gadget drivers did you use? > Yes I did for chapter 9, MSC, and UASP CV. I missed this issue because "stall" was not enabled by default for mass_storage configfs. Without this fix, mass_storage function won't work with "stall" enabled. (Note: for UASP CV, it requires many fixes/enhancements in f_tcm and the target subsystem to work properly.) Thanks, Thinh
