Hi,
Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> 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 <thinhn@xxxxxxxxxxxx>
this will regress the macOS case I wrote that commit for. We need to
FIRST figure out why ClearStall command times out. Have you done that?
Do you have a testcase which constantly issues
ClearFeature(ENDPOINT_HALT) to a single endpoint and can verify that it
doesn't time out? Why does it timeout on macOS?
--
balbi
Attachment:
signature.asc
Description: PGP signature