On 6/13/2017 3:31 PM, Paul Zimmerman wrote:
> On Tue, 13 Jun 2017 21:57:42 +0000, John Youn <john.y...@synopsys.com> wrote:
>
>> On 6/13/2017 2:39 PM, Paul Zimmerman wrote:
>>> On Tue, 13 Jun 2017 18:33:09 +0000, John Youn <john.y...@synopsys.com>
>>> wrote:
>>>
>>>> On 6/13/2017 12:32 AM, Felipe Balbi wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thinh Nguyen <thinh.ngu...@synopsys.com> writes:
>>>>>>>>>>>>>>>> this could be, I don't remember if I checked this or not :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Really, the best way here, IMHO, would be to re-verify what's
>>>>>>>>>>>>>>>> going on
>>>>>>>>>>>>>>>> with macOS and revert my orignal patch since it's, rather
>>>>>>>>>>>>>>>> clearly,
>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sure. Are you going to make a revert patch or I am?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well, after we really know what's going on with macOS and have a
>>>>>>>>>>>>>> better
>>>>>>>>>>>>>> fix, then who makes the revert is less important as long as
>>>>>>>>>>>>>> problems get
>>>>>>>>>>>>>> sorted out :-) Either way is fine for me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you have any update on this issue?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The patch ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt
>>>>>>>>>>>> when
>>>>>>>>>>>> invalid") still causes a regression for us. As there hasn't any
>>>>>>>>>>>> update
>>>>>>>>>>>> for the macOS issue, can I submit a revert patch for this?
>>>>>>>>>>>
>>>>>>>>>>> I just came back from vacations ;-) I'll get back to this. Reverting
>>>>>>>>>>> that commit won't do any good as we'd be exchanging one regression
>>>>>>>>>>> for
>>>>>>>>>>> another. We really need to understand what's going on.
>>>>>>>>>>
>>>>>>>>>> Hi Felipe,
>>>>>>>>>>
>>>>>>>>>> I think we worked around this same issue in the Synopsys vendor
>>>>>>>>>> driver
>>>>>>>>>> after a customer reported a problem with
>>>>>>>>>> CLEAR_FEATURE(ENDPOINT_HALT).
>>>>>>>>>> I no longer have access to either the databook or the codebase, so I
>>>>>>>>>> can't be sure about what the workaround was, but if either John or
>>>>>>>>>> Thinh
>>>>>>>>>> can have a look at the Clear Stall code in the vendor driver they
>>>>>>>>>> should
>>>>>>>>>> be able to figure it out.
>>>>>>>>
>>>>>>>> Thanks a lot Paul :-) Good to see you still have a look here every once
>>>>>>>> in a while :-)
>>>>>>>>
>>>>>>>> John, Thinh could either of you check what Paul mentions here?
>>>>>>>>
>>>>>>>> cheers
>>>>>>>>
>>>>>>>
>>>>>>> Can you provide more detail on the issue you see on MAC OS? and how to
>>>>>>> reproduce the issue?
>>>>>>>
>>>>>>
>>>>>> This issue has been a regression for us for a few months now, do you
>>>>>> have any update on this?
>>>>>
>>>>> ordered a mac to test this again. It'll take a few days.
>>>>>
>>>>
>>>> Thanks Felipe.
>>>>
>>>> Let us know if we can help in any way. If you can give details on your
>>>> setup with macOS we can look into running it as well.
>>>>
>>>> Also curious whether or not you are seeing the same regression? It
>>>> should apply to anyone using dwc3 running USB mass-storage CV.
>>>
>>> Hi John,
>>>
>>> Did you have a look at the Synopsys driver like I mentioned above?
>>> I'm pretty sure I fixed something similar to this there.
>>>
>>
>> Hi Paul,
>>
>> I haven't checked, but Thinh looked and couldn't find anything
>> relating to the macOS issue. Which is why we want more information
>> about the problem.
>>
>> I can take a look at it too later today when I get a chance.
>>
>> When you say you fixed the issue in the vendor driver, do you mean the
>> macOS problem (multiple clear stalls) or the regression that it caused
>> when it was fixed (the MSC data sequence issue)?
>
> Hi John,
>
> The issue was with the host sending a CLEAR_FEATURE(ENDPOINT_HALT) when the
> EP was not actually halted. The host does this to reset the EP data toggle /
> sequence number to 0, and it is allowed by some USB spec. The problem was
> that for DWC3 if you issue a Clear Stall when the EP is not halted, nothing
> happens. I *think* the fix was to issue a Set EP Config command instead,
> which does reset the sequence number, but I'm not 100% sure about that.
>
Hi Paul,
Ok thanks, that will definitely help looking into it.
Though our issue seems the opposite. Since Felipe's macOS patch
prevents the clear stall when already halted, but *without* that, the
controller doesn't clear the sequence number and fails the MSC CV
test.
John
--
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
