Messages in this thread | | | Date | Thu, 21 Jul 2022 17:04:38 -0700 | Subject | Re: [PATCH v2 4/5] usb: dwc3: Allow end transfer commands to be sent during soft disconnect | From | Wesley Cheng <> |
| |
Hi Thinh,
On 7/21/2022 5:00 PM, Thinh Nguyen wrote: > On 7/21/2022, Wesley Cheng wrote: >> Hi Thinh, >> >> On 7/21/2022 3:20 PM, Thinh Nguyen wrote: >>> On 7/21/2022, Wesley Cheng wrote: >>>> Hi Thinh, >>>> >>>> On 7/21/2022 3:08 PM, Thinh Nguyen wrote: >>>>> Hi Wesley, >>>>> >>>>> On 7/12/2022, Wesley Cheng wrote: >>>>>> If soft disconnect is in progress, allow the endxfer command to be >>>>>> sent, >>>>>> without this, there is an issue where the stop active transfer call >>>>>> (during pullup disable) wouldn't actually issue the endxfer command, >>>>>> while clearing the DEP flag. >>>>>> >>>>>> In addition, if the DWC3_EP_DELAY_STOP flag was set before soft >>>>>> disconnect >>>>>> started (i.e. from the dequeue path), ensure that when the EP0 >>>>>> transaction >>>>>> completes during soft disconnect, to issue the endxfer with the force >>>>>> parameter set, as it does not expect a command complete event. >>>>>> >>>>>> Fixes: e4cf6580ac740 ("usb: dwc3: gadget: Wait for ep0 xfers to >>>>>> complete during dequeue") >>>>>> Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> >>>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>>>>> --- >>>>>> Link: >>>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/1a1a5485-790e-79ce-f5a6-1e96d9b49a47@synopsys.com/__;!!A4F2R9G_pg!cXW2TlALYWnXNPg-NoMFUrQ8K1egEZiQizZ5CA1DOM1Gcw4tfOULy-_2eMGvL8pQPte5dScFON-0wxH2eXu8ijEQUbs$ >>>>>> >>>>>> >>>>>> drivers/usb/dwc3/ep0.c | 3 +-- >>>>>> drivers/usb/dwc3/gadget.c | 5 ++++- >>>>>> 2 files changed, 5 insertions(+), 3 deletions(-) >>>>>> >>>>>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c >>>>>> index 506ef717fdc0..5851b0e9db0a 100644 >>>>>> --- a/drivers/usb/dwc3/ep0.c >>>>>> +++ b/drivers/usb/dwc3/ep0.c >>>>>> @@ -290,8 +290,7 @@ void dwc3_ep0_out_start(struct dwc3 *dwc) >>>>>> if (!(dwc3_ep->flags & DWC3_EP_DELAY_STOP)) >>>>>> continue; >>>>>> - dwc3_ep->flags &= ~DWC3_EP_DELAY_STOP; >>>>> >>>>> If we don't clear this flag here, >>>>> >>>> >>>> This is why I added the dwc->connected argument to control the >>>> "interrupt" argument. >>>> >>>>>> - dwc3_stop_active_transfer(dwc3_ep, true, true); >>>>>> + dwc3_stop_active_transfer(dwc3_ep, true, dwc->connected); >>>>>> } >>>>>> } >>>>>> diff --git a/drivers/usb/dwc3/gadget.c >>>>>> b/drivers/usb/dwc3/gadget.c >>>>>> index ee85b773e3fe..41b7007358de 100644 >>>>>> --- a/drivers/usb/dwc3/gadget.c >>>>>> +++ b/drivers/usb/dwc3/gadget.c >>>>>> @@ -1693,6 +1693,7 @@ static int __dwc3_stop_active_transfer(struct >>>>>> dwc3_ep *dep, bool force, bool int >>>>>> dep->flags &= ~DWC3_EP_TRANSFER_STARTED; >>>>>> else if (!ret) >>>>>> dep->flags |= DWC3_EP_END_TRANSFER_PENDING; >>>>>> + dep->flags &= ~DWC3_EP_DELAY_STOP; >>>>>> return ret; >>>>>> } >>>>>> @@ -3686,8 +3687,10 @@ void dwc3_stop_active_transfer(struct dwc3_ep >>>>>> *dep, bool force, >>>>>> if (dep->number <= 1 && dwc->ep0state != EP0_DATA_PHASE) >>>>>> return; >>>>>> + if (interrupt && (dep->flags & DWC3_EP_DELAY_STOP)) >>>>>> + return; >>>>>> + >>>>> >>>>> then it may not go through here. I think I made this same mistake >>>>> in my >>>>> previous suggestion. >>>>> >>>> >>>> Since dwc->connected is set to FALSE before we call stop active >>>> transfers, if we ever run into a situation where delayed stop is set >>>> already, then it should go through. >>>> >>> >>> Then the check for request dequeue that we did previously will not work >>> anymore. >>> >> >> Could you help clarify? The pullup refactor kind of shifted some of >> the previous checks we had in the dequeue path, and combined with with >> the stop active transfer checks. >> >> I think there was an issue w/ the patch I submitted though. the above >> snippet should be replacing what is there: >> >> void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force, >> bool interrupt) >> { >> ... >> if (!(dep->flags & DWC3_EP_TRANSFER_STARTED) || >> /* Following should be removed --- (dep->flags & >> DWC3_EP_DELAY_STOP) || */ >> (dep->flags & DWC3_EP_END_TRANSFER_PENDING)) >> return; >> > > Request dequeue can occur while the device is connected. The > DWC3_EP_DELAY_STOP intention is to delay sending the End Transfer > command until the SETUP stage is prepared. If we don't clear the flag > before the flag check, then the End Transfer command will not go through. >
Thanks, got it. Understand what you mean now. Let me think about how to go about it. I probably don't see any issues as of now, because my test does the soft disconnect, which will do the stop active transfers forcefully.
Thanks Wesley Cheng
| |