* [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget
@ 2016-10-14 9:11 Baolin Wang
2016-10-17 10:10 ` Felipe Balbi
0 siblings, 1 reply; 5+ messages in thread
From: Baolin Wang @ 2016-10-14 9:11 UTC (permalink / raw)
To: balbi; +Cc: gregkh, broonie, linux-usb, linux-kernel, baolin.wang
When we change the USB function with configfs dynamically, we possibly met this
situation: one core is doing the control transfer, another core is trying to
unregister the USB gadget from userspace, we must wait for completing this
control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
Changes since v3:
- Remove the patch 1 which will cause start gadget failed.
- Remove try_again and refactor the code.
Changes since v2:
- Move disconnect checking into dwc3_send_gadget_ep_cmd().
- Rename completion name and issue complete() at one place.
- Move completion initialization into dwc3_gadget_init().
Changes since v1:
- Split into 2 separate ptaches.
- Choose complete mechanism instead of polling.
---
drivers/usb/dwc3/core.h | 2 ++
drivers/usb/dwc3/ep0.c | 2 ++
drivers/usb/dwc3/gadget.c | 28 +++++++++++++++++++++++++++-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b2317e7..23765a1 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -745,6 +745,7 @@ struct dwc3_scratchpad_array {
* @ep0_usb_req: dummy req used while handling STD USB requests
* @ep0_bounce_addr: dma address of ep0_bounce
* @scratch_addr: dma address of scratchbuf
+ * @ep0_in_setup: one control transfer is completed and enter setup phase
* @lock: for synchronizing
* @dev: pointer to our struct device
* @xhci: pointer to our xHCI child
@@ -843,6 +844,7 @@ struct dwc3 {
dma_addr_t ep0_bounce_addr;
dma_addr_t scratch_addr;
struct dwc3_request ep0_usb_req;
+ struct completion ep0_in_setup;
/* device lock */
spinlock_t lock;
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index fe79d77..06c167a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -311,6 +311,8 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
ret = dwc3_ep0_start_trans(dwc, 0, dwc->ctrl_req_addr, 8,
DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret < 0);
+
+ complete(&dwc->ep0_in_setup);
}
static struct dwc3_ep *dwc3_wIndex_to_dep(struct dwc3 *dwc, __le16 wIndex_le)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 1783406..3722c90 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1434,6 +1434,13 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
if (pm_runtime_suspended(dwc->dev))
return 0;
+ /*
+ * Per databook, when we want to stop the gadget, if a control transfer
+ * is still in process, complete it and get the core into setup phase.
+ */
+ if (!is_on && dwc->ep0state != EP0_SETUP_PHASE)
+ return -EBUSY;
+
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
if (is_on) {
if (dwc->revision <= DWC3_REVISION_187A) {
@@ -1480,11 +1487,28 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
{
struct dwc3 *dwc = gadget_to_dwc(g);
unsigned long flags;
- int ret;
+ int ret = 0;
is_on = !!is_on;
spin_lock_irqsave(&dwc->lock, flags);
+ if (!is_on && !pm_runtime_suspended(dwc->dev) &&
+ dwc->ep0state != EP0_SETUP_PHASE) {
+ reinit_completion(&dwc->ep0_in_setup);
+ ret = -EBUSY;
+ }
+ spin_unlock_irqrestore(&dwc->lock, flags);
+
+ if (ret == -EBUSY) {
+ ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
+ msecs_to_jiffies(500));
+ if (ret == 0) {
+ dev_err(dwc->dev, "timeout to wait for setup phase.\n");
+ return -ETIMEDOUT;
+ }
+ }
+
+ spin_lock_irqsave(&dwc->lock, flags);
ret = dwc3_gadget_run_stop(dwc, is_on, false);
spin_unlock_irqrestore(&dwc->lock, flags);
@@ -2911,6 +2935,8 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err4;
}
+ init_completion(&dwc->ep0_in_setup);
+
dwc->gadget.ops = &dwc3_gadget_ops;
dwc->gadget.speed = USB_SPEED_UNKNOWN;
dwc->gadget.sg_supported = true;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget
2016-10-14 9:11 [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget Baolin Wang
@ 2016-10-17 10:10 ` Felipe Balbi
2016-10-17 11:47 ` Baolin Wang
0 siblings, 1 reply; 5+ messages in thread
From: Felipe Balbi @ 2016-10-17 10:10 UTC (permalink / raw)
To: Baolin Wang; +Cc: gregkh, broonie, linux-usb, linux-kernel, baolin.wang
[-- Attachment #1: Type: text/plain, Size: 4335 bytes --]
Hi,
Baolin Wang <baolin.wang@linaro.org> writes:
> When we change the USB function with configfs dynamically, we possibly met this
> situation: one core is doing the control transfer, another core is trying to
> unregister the USB gadget from userspace, we must wait for completing this
> control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Can you make sure this still works?
8<------------------------------------------------------------------------
From 797c7caab630f650b9ab5e462e8588462e055073 Mon Sep 17 00:00:00 2001
From: Baolin Wang <baolin.wang@linaro.org>
Date: Fri, 14 Oct 2016 17:11:33 +0800
Subject: [PATCH] usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to
do so
When we change the USB function with configfs dynamically, we possibly
met this situation: one core is doing the control transfer, another core
is trying to unregister the USB gadget from userspace, we must wait for
completing this control tranfer, or it will hang the controller to set
the DEVCTRLHLT flag.
[ felipe.balbi@linux.intel.com: several fixes to the patch
- call complete() before starting following SETUP transfer
- add a macro for ep0_in_setup's timeout
- change commit subject slightly
- break lines at 72 characters (git adds an 8-character tab)
- avoid changes to dwc3_gadget_run_stop() ]
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
---
drivers/usb/dwc3/core.h | 3 +++
drivers/usb/dwc3/ep0.c | 2 ++
drivers/usb/dwc3/gadget.c | 17 +++++++++++++++++
3 files changed, 22 insertions(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2f6f7c4bc8d4..80e4e9aa2d33 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -38,6 +38,7 @@
#define DWC3_MSG_MAX 500
/* Global constants */
+#define DWC3_PULL_UP_TIMEOUT 500 /* ms */
#define DWC3_ZLP_BUF_SIZE 1024 /* size of a superspeed bulk */
#define DWC3_EP0_BOUNCE_SIZE 512
#define DWC3_ENDPOINTS_NUM 32
@@ -756,6 +757,7 @@ struct dwc3_scratchpad_array {
* @ep0_usb_req: dummy req used while handling STD USB requests
* @ep0_bounce_addr: dma address of ep0_bounce
* @scratch_addr: dma address of scratchbuf
+ * @ep0_in_setup: one control transfer is completed and enter setup phase
* @lock: for synchronizing
* @dev: pointer to our struct device
* @xhci: pointer to our xHCI child
@@ -853,6 +855,7 @@ struct dwc3 {
dma_addr_t ep0_bounce_addr;
dma_addr_t scratch_addr;
struct dwc3_request ep0_usb_req;
+ struct completion ep0_in_setup;
/* device lock */
spinlock_t lock;
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 5e642d65a3b2..417cfd3f04ab 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -284,6 +284,8 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
{
int ret;
+ complete(&dwc->ep0_in_setup);
+
ret = dwc3_ep0_start_trans(dwc, 0, dwc->ctrl_req_addr, 8,
DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret < 0);
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index b53712cbc499..da79716be50d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1557,6 +1557,21 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
is_on = !!is_on;
+ /*
+ * Per databook, when we want to stop the gadget, if a control transfer
+ * is still in process, complete it and get the core into setup phase.
+ */
+ if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
+ reinit_completion(&dwc->ep0_in_setup);
+
+ ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
+ msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT));
+ if (ret == 0) {
+ dev_err(dwc->dev, "timed out waiting for SETUP phase\n");
+ return -ETIMEDOUT;
+ }
+ }
+
spin_lock_irqsave(&dwc->lock, flags);
ret = dwc3_gadget_run_stop(dwc, is_on, false);
spin_unlock_irqrestore(&dwc->lock, flags);
@@ -2954,6 +2969,8 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err4;
}
+ init_completion(&dwc->ep0_in_setup);
+
dwc->gadget.ops = &dwc3_gadget_ops;
dwc->gadget.speed = USB_SPEED_UNKNOWN;
dwc->gadget.sg_supported = true;
--
2.10.0.440.g21f862b
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget
2016-10-17 10:10 ` Felipe Balbi
@ 2016-10-17 11:47 ` Baolin Wang
2016-10-17 11:53 ` Felipe Balbi
0 siblings, 1 reply; 5+ messages in thread
From: Baolin Wang @ 2016-10-17 11:47 UTC (permalink / raw)
To: Felipe Balbi; +Cc: Greg KH, Mark Brown, USB, LKML
Hi,
On 17 October 2016 at 18:10, Felipe Balbi <balbi@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.wang@linaro.org> writes:
>> When we change the USB function with configfs dynamically, we possibly met this
>> situation: one core is doing the control transfer, another core is trying to
>> unregister the USB gadget from userspace, we must wait for completing this
>> control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
>>
>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>
> Can you make sure this still works?
With applying this patch, It can work well on my platform, but I have
some worries about the risk of accessing 'dwc->ep0state' without lock
protection in dwc3_gadget_pullup() function.
>
> 8<------------------------------------------------------------------------
> From 797c7caab630f650b9ab5e462e8588462e055073 Mon Sep 17 00:00:00 2001
> From: Baolin Wang <baolin.wang@linaro.org>
> Date: Fri, 14 Oct 2016 17:11:33 +0800
> Subject: [PATCH] usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to
> do so
>
> When we change the USB function with configfs dynamically, we possibly
> met this situation: one core is doing the control transfer, another core
> is trying to unregister the USB gadget from userspace, we must wait for
> completing this control tranfer, or it will hang the controller to set
> the DEVCTRLHLT flag.
>
> [ felipe.balbi@linux.intel.com: several fixes to the patch
> - call complete() before starting following SETUP transfer
> - add a macro for ep0_in_setup's timeout
> - change commit subject slightly
> - break lines at 72 characters (git adds an 8-character tab)
> - avoid changes to dwc3_gadget_run_stop() ]
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
> ---
> drivers/usb/dwc3/core.h | 3 +++
> drivers/usb/dwc3/ep0.c | 2 ++
> drivers/usb/dwc3/gadget.c | 17 +++++++++++++++++
> 3 files changed, 22 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 2f6f7c4bc8d4..80e4e9aa2d33 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -38,6 +38,7 @@
> #define DWC3_MSG_MAX 500
>
> /* Global constants */
> +#define DWC3_PULL_UP_TIMEOUT 500 /* ms */
> #define DWC3_ZLP_BUF_SIZE 1024 /* size of a superspeed bulk */
> #define DWC3_EP0_BOUNCE_SIZE 512
> #define DWC3_ENDPOINTS_NUM 32
> @@ -756,6 +757,7 @@ struct dwc3_scratchpad_array {
> * @ep0_usb_req: dummy req used while handling STD USB requests
> * @ep0_bounce_addr: dma address of ep0_bounce
> * @scratch_addr: dma address of scratchbuf
> + * @ep0_in_setup: one control transfer is completed and enter setup phase
> * @lock: for synchronizing
> * @dev: pointer to our struct device
> * @xhci: pointer to our xHCI child
> @@ -853,6 +855,7 @@ struct dwc3 {
> dma_addr_t ep0_bounce_addr;
> dma_addr_t scratch_addr;
> struct dwc3_request ep0_usb_req;
> + struct completion ep0_in_setup;
>
> /* device lock */
> spinlock_t lock;
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 5e642d65a3b2..417cfd3f04ab 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -284,6 +284,8 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
> {
> int ret;
>
> + complete(&dwc->ep0_in_setup);
> +
> ret = dwc3_ep0_start_trans(dwc, 0, dwc->ctrl_req_addr, 8,
> DWC3_TRBCTL_CONTROL_SETUP, false);
> WARN_ON(ret < 0);
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index b53712cbc499..da79716be50d 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1557,6 +1557,21 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
>
> is_on = !!is_on;
>
> + /*
> + * Per databook, when we want to stop the gadget, if a control transfer
> + * is still in process, complete it and get the core into setup phase.
> + */
> + if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
> + reinit_completion(&dwc->ep0_in_setup);
> +
> + ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
> + msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT));
> + if (ret == 0) {
> + dev_err(dwc->dev, "timed out waiting for SETUP phase\n");
> + return -ETIMEDOUT;
> + }
> + }
> +
> spin_lock_irqsave(&dwc->lock, flags);
> ret = dwc3_gadget_run_stop(dwc, is_on, false);
> spin_unlock_irqrestore(&dwc->lock, flags);
> @@ -2954,6 +2969,8 @@ int dwc3_gadget_init(struct dwc3 *dwc)
> goto err4;
> }
>
> + init_completion(&dwc->ep0_in_setup);
> +
> dwc->gadget.ops = &dwc3_gadget_ops;
> dwc->gadget.speed = USB_SPEED_UNKNOWN;
> dwc->gadget.sg_supported = true;
> --
> 2.10.0.440.g21f862b
>
>
>
> --
> balbi
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget
2016-10-17 11:47 ` Baolin Wang
@ 2016-10-17 11:53 ` Felipe Balbi
2016-10-18 2:40 ` Baolin Wang
0 siblings, 1 reply; 5+ messages in thread
From: Felipe Balbi @ 2016-10-17 11:53 UTC (permalink / raw)
To: Baolin Wang; +Cc: Greg KH, Mark Brown, USB, LKML
[-- Attachment #1: Type: text/plain, Size: 891 bytes --]
Hi,
Baolin Wang <baolin.wang@linaro.org> writes:
>> Baolin Wang <baolin.wang@linaro.org> writes:
>>> When we change the USB function with configfs dynamically, we possibly met this
>>> situation: one core is doing the control transfer, another core is trying to
>>> unregister the USB gadget from userspace, we must wait for completing this
>>> control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
>>>
>>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>>
>> Can you make sure this still works?
>
> With applying this patch, It can work well on my platform, but I have
> some worries about the risk of accessing 'dwc->ep0state' without lock
> protection in dwc3_gadget_pullup() function.
hmm, I might be missing something, but I think there's no risk here. If
anything, a wmb() is probably enough before reading ep0state. No?
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget
2016-10-17 11:53 ` Felipe Balbi
@ 2016-10-18 2:40 ` Baolin Wang
0 siblings, 0 replies; 5+ messages in thread
From: Baolin Wang @ 2016-10-18 2:40 UTC (permalink / raw)
To: Felipe Balbi; +Cc: Greg KH, Mark Brown, USB, LKML
Hi,
On 17 October 2016 at 19:53, Felipe Balbi <balbi@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.wang@linaro.org> writes:
>>> Baolin Wang <baolin.wang@linaro.org> writes:
>>>> When we change the USB function with configfs dynamically, we possibly met this
>>>> situation: one core is doing the control transfer, another core is trying to
>>>> unregister the USB gadget from userspace, we must wait for completing this
>>>> control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
>>>>
>>>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>>>
>>> Can you make sure this still works?
>>
>> With applying this patch, It can work well on my platform, but I have
>> some worries about the risk of accessing 'dwc->ep0state' without lock
>> protection in dwc3_gadget_pullup() function.
>
> hmm, I might be missing something, but I think there's no risk here. If
> anything, a wmb() is probably enough before reading ep0state. No?
OK, I agree with you and I think a wmb() is not useful here.
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-18 2:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-14 9:11 [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget Baolin Wang
2016-10-17 10:10 ` Felipe Balbi
2016-10-17 11:47 ` Baolin Wang
2016-10-17 11:53 ` Felipe Balbi
2016-10-18 2:40 ` Baolin Wang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox