Hi,

John Youn <john.y...@synopsys.com> writes:
>> Felipe Balbi <felipe.ba...@linux.intel.com> writes:
>>> At least macOS seems to be sending
>>> ClearFeature(ENDPOINT_HALT) to endpoints which
>>> aren't Halted. This makes DWC3's CLEARSTALL command
>>> time out which causes several issues for the driver.
>>>
>>> Instead, let's just return 0 and bail out early.
>>>
>>> Cc: <sta...@vger.kernel.org>
>>> Signed-off-by: Felipe Balbi <felipe.ba...@linux.intel.com>
>>> ---
>>>
>>> this falls into "has never worked before" category, so I'll be sending
>>> it together with other patches for v4.11 merge window. Still, it's a
>>> valid bug that's likely needed for stable trees.
>>>
>>>  drivers/usb/dwc3/gadget.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 6faf484e5dfc..0a664d8eba3f 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, 
>>> int value, int protocol)
>>>             unsigned transfer_in_flight;
>>>             unsigned started;
>>>
>>> +           if (dep->flags & DWC3_EP_STALL)
>>> +                   return 0;
>>> +
>>>             if (dep->number > 1)
>>>                     trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
>>>             else
>>> @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, 
>>> int value, int protocol)
>>>             else
>>>                     dep->flags |= DWC3_EP_STALL;
>>>     } else {
>>> +           if (!(dep->flags & DWC3_EP_STALL))
>>> +                   return 0;
>>>
>>>             ret = dwc3_send_clear_stall_ep_cmd(dep);
>>>             if (ret)
>>
>> Reviving this old thread here. While $subject allowed dwc3 to work when
>> attached to macOS Host, I fear that we might have more issues than not
>> in the future. The reason is that USB20 spec allows hosts to use
>> ClearFeature(ENDPOINT_HALT) as a "Reset Data Toggle/SeqN" hint.
>>
>> With this, we're basically blocking that possibility. Still, without
>> $subject, ClearStall commands were timing out. I'll try to do a local
>> revert here and check what happens in this case, but would you have any
>> idea why ClearStall would time out like that?
>>
>
> Hi Felipe,
>
> I think Thinh Nguyen e-mailed you about this before saying it caused a
> regression for us. But he has not had time to look into it further and
> follow-up yet.
>
> No idea about the timing out on Mac though. We can try to reproduce
> this when we have some time and take a look. Do you have a USB trace?

not anymore, but as soon I have some free time, I can revert the patch
locally and try to reproduce. I'll also implement a little libusb-based
test to issue that request hundreds of times in a row and see if I can
force the problem to happen ;-)

Thanks for responding so quickly :-)

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to