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@xxxxxxxxxxxx>
Signed-off-by: Wesley Cheng <quic_wcheng@xxxxxxxxxxx>
---
Link:
https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/1a1a5485-790e-79ce-f5a6-1e96d9b49a47@xxxxxxxxxxxx/__;!!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
