[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98623d02-cde4-b036-a85c-9325b58c7eab@quicinc.com>
Date: Thu, 21 Jul 2022 15:13:17 -0700
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
"balbi@...nel.org" <balbi@...nel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"quic_jackp@...cinc.com" <quic_jackp@...cinc.com>
Subject: Re: [PATCH v2 4/5] usb: dwc3: Allow end transfer commands to be sent
during soft disconnect
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@...opsys.com>
>> Signed-off-by: Wesley Cheng <quic_wcheng@...cinc.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.
Thanks
Wesley Cheng
Powered by blists - more mailing lists