On Tue, 13 Jun 2017 21:57:42 +0000, John Youn <John.Youn@xxxxxxxxxxxx> wrote:
> On 6/13/2017 2:39 PM, Paul Zimmerman wrote:
> > On Tue, 13 Jun 2017 18:33:09 +0000, John Youn <John.Youn@xxxxxxxxxxxx> wrote:
> >
> >> On 6/13/2017 12:32 AM, Felipe Balbi wrote:
> >>>
> >>> Hi,
> >>>
> >>> Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> 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.
--
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
