Hi again, Felipe Balbi <[email protected]> writes: > Thinh Nguyen <[email protected]> writes: >> This patch fixes a commit that causes a hang from device waiting for >> data with the wrong sequence number. The commit ffb80fc672c3 ("usb: >> dwc3: gadget: skip Set/Clear Halt when invalid") adds a check to return >> early depending on DWC3_EP_STALL is set or not, prevent sending the ep >> halt command to HW endpoint to do CLEAR_FEATURE(ENDPOINT_HALT) request. >> This was to workaround the issue for macOS where the device hangs from >> sending DWC3 clear stall command. >> >> In USB 3.1 spec, 9.4.5, CLEAR_FEATURE(ENDPOINT_HALT) request always >> results in the data sequence being reinitialized to zero regardless >> whether the endpoint has been halted or not. Some device class depends >> on this feature for its protocol. For instance, in mass storage class, >> there is MSC reset protocol that does CLEAR_FEATURE(ENDPOINT_HALT) on >> bulk endpoints. This protocol reinitializes the data sequence and >> ensures that whatever pending data requested from previous CBW will be >> reset. Otherwise this will cause a hang as the device can wait for the >> data with the wrong sequence number from the previous CBW. We found this >> failure in USB CV: MSC Error Recovery Test with f_mass_storage. >> >> This patch fixes this issue by checking to see whether the set/halt ep >> call is a protocol call before early exit to make sure that set/clear >> halt endpoint command can go through if it is a device class protocol. >> >> Fixes: ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt when invalid") >> Signed-off-by: Thinh Nguyen <[email protected]> > > this will regress the macOS case I wrote that commit for. We need to
no wait, it won't regress macOS, but we're still left with the problem of host and peripheral being able to get DataToggle/SeqN out of sync. -- balbi
signature.asc
Description: PGP signature
