[PATCH v2 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

[PATCH v2 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

[Baolin Wang]

When system has stpped the gadget, we should avoid queuing any requests
which will cause tranfer failed. Thus adding some disconnect checking to
avoid this situation.

Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
Changes since v1:
 - Split into 2 separate ptaches.
 - Choose complete mechanism instead of polling.
---
 drivers/usb/dwc3/ep0.c    |    8 ++++++++
 drivers/usb/dwc3/gadget.c |   12 +++++++++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index fe79d77..632e5a4 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -228,6 +228,14 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct usb_request *request,
 	int				ret;
 
 	spin_lock_irqsave(&dwc->lock, flags);
+	if (!dwc->pullups_connected) {
+		dwc3_trace(trace_dwc3_ep0,
+			"queuing request %p to %s when gadget is disconnected",
+			request, dep->name);
+		ret = -ESHUTDOWN;
+		goto out;
+	}
+
 	if (!dep->endpoint.desc) {
 		dwc3_trace(trace_dwc3_ep0,
 				"trying to queue request %p to disabled %s",
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 1783406..1a33308 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1040,6 +1040,13 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
 	struct dwc3		*dwc = dep->dwc;
 	int			ret;
 
+	if (!dwc->pullups_connected) {
+		dwc3_trace(trace_dwc3_gadget,
+			"queuing request %p to %s when gadget is disconnected",
+			&req->request, dep->endpoint.name);
+		return -ESHUTDOWN;
+	}
+
 	if (!dep->endpoint.desc) {
 		dwc3_trace(trace_dwc3_gadget,
 				"trying to queue request %p to disabled %s",
@@ -1984,13 +1991,12 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc, struct dwc3_ep *dep,
 		if (ret)
 			break;
 	}
-
 	/*
 	 * Our endpoint might get disabled by another thread during
 	 * dwc3_gadget_giveback(). If that happens, we're just gonna return 1
 	 * early on so DWC3_EP_BUSY flag gets cleared
 	 */
-	if (!dep->endpoint.desc)
+	if (!dep->endpoint.desc || !dwc->pullups_connected)
 		return 1;
 
 	if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
@@ -2064,7 +2070,7 @@ static void dwc3_endpoint_transfer_complete(struct dwc3 *dwc,
 	 * dwc3_gadget_giveback(). If that happens, we're just gonna return 1
 	 * early on so DWC3_EP_BUSY flag gets cleared
 	 */
-	if (!dep->endpoint.desc)
+	if (!dep->endpoint.desc || !dwc->pullups_connected)
 		return;
 
 	if (!usb_endpoint_xfer_isoc(dep->endpoint.desc)) {
-- 
1.7.9.5

[PATCH v2 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

[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>
---
 drivers/usb/dwc3/core.c   |    1 +
 drivers/usb/dwc3/core.h   |    2 ++
 drivers/usb/dwc3/ep0.c    |    2 ++
 drivers/usb/dwc3/gadget.c |   21 +++++++++++++++++++++
 4 files changed, 26 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 057739d..22787b6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -999,6 +999,7 @@ static int dwc3_probe(struct platform_device *pdev)
 		goto err0;
 
 	spin_lock_init(&dwc->lock);
+	init_completion(&dwc->ep0_completed);
 
 	if (!dev->dma_mask) {
 		dev->dma_mask = dev->parent->dma_mask;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b2317e7..858e661 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_completed: One control tranfer is completed
  * @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_completed;
 
 	/* device lock */
 	spinlock_t		lock;
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 632e5a4..baf932d 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -286,6 +286,7 @@ static void dwc3_ep0_stall_and_restart(struct dwc3 *dwc)
 
 	dwc->ep0state = EP0_SETUP_PHASE;
 	dwc3_ep0_out_start(dwc);
+	complete(&dwc->ep0_completed);
 }
 
 int __dwc3_gadget_ep0_set_halt(struct usb_ep *ep, int value)
@@ -935,6 +936,7 @@ static void dwc3_ep0_complete_status(struct dwc3 *dwc,
 
 	dwc->ep0state = EP0_SETUP_PHASE;
 	dwc3_ep0_out_start(dwc);
+	complete(&dwc->ep0_completed);
 }
 
 static void dwc3_ep0_xfer_complete(struct dwc3 *dwc,
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 1a33308..c9026ce 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1441,6 +1441,15 @@ 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) {
+		reinit_completion(&dwc->ep0_completed);
+		return -EBUSY;
+	}
+
 	reg = dwc3_readl(dwc->regs, DWC3_DCTL);
 	if (is_on) {
 		if (dwc->revision <= DWC3_REVISION_187A) {
@@ -1491,10 +1500,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
 
 	is_on = !!is_on;
 
+try_again:
 	spin_lock_irqsave(&dwc->lock, flags);
 	ret = dwc3_gadget_run_stop(dwc, is_on, false);
 	spin_unlock_irqrestore(&dwc->lock, flags);
 
+	if (ret == -EBUSY) {
+		ret = wait_for_completion_timeout(&dwc->ep0_completed,
+						  msecs_to_jiffies(100));
+		if (ret == 0) {
+			dev_err(dwc->dev, "timeout to stop gadget.\n");
+			return -ETIMEDOUT;
+		} else {
+			goto try_again;
+		}
+	}
+
 	return ret;
 }
 
-- 
1.7.9.5

Re: [PATCH v2 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]


Hi,

Baolin Wang <baolin.wang@linaro.org> writes:
> When system has stpped the gadget, we should avoid queuing any requests
> which will cause tranfer failed. Thus adding some disconnect checking to
> avoid this situation.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>

do you mind if we discuss this for a little longer?

> ---
> Changes since v1:
>  - Split into 2 separate ptaches.
>  - Choose complete mechanism instead of polling.
> ---
>  drivers/usb/dwc3/ep0.c    |    8 ++++++++
>  drivers/usb/dwc3/gadget.c |   12 +++++++++---
>  2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index fe79d77..632e5a4 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -228,6 +228,14 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct usb_request *request,
>  	int				ret;
>  
>  	spin_lock_irqsave(&dwc->lock, flags);
> +	if (!dwc->pullups_connected) {
> +		dwc3_trace(trace_dwc3_ep0,
> +			"queuing request %p to %s when gadget is disconnected",
> +			request, dep->name);
> +		ret = -ESHUTDOWN;
> +		goto out;
> +	}

I have been thinking about this branch here. It's not a problem to queue
a request with pullups disconnected. It's only a problem to issue
START_TRANSFER without RUN_STOP bit set.

So maybe this check should be done in dwc3_send_gadget_ep_cmd(). By
doing that we also make sure to do the check in one place and one place
only because all endpoints rely dwc3_send_gadget_ep_cmd().

> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 1783406..1a33308 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1040,6 +1040,13 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
>  	struct dwc3		*dwc = dep->dwc;
>  	int			ret;
>  
> +	if (!dwc->pullups_connected) {
> +		dwc3_trace(trace_dwc3_gadget,
> +			"queuing request %p to %s when gadget is disconnected",
> +			&req->request, dep->endpoint.name);
> +		return -ESHUTDOWN;
> +	}
> +
>  	if (!dep->endpoint.desc) {
>  		dwc3_trace(trace_dwc3_gadget,
>  				"trying to queue request %p to disabled %s",
> @@ -1984,13 +1991,12 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc, struct dwc3_ep *dep,
>  		if (ret)
>  			break;
>  	}
> -

trailing change.

>  	/*
>  	 * Our endpoint might get disabled by another thread during
>  	 * dwc3_gadget_giveback(). If that happens, we're just gonna return 1
>  	 * early on so DWC3_EP_BUSY flag gets cleared
>  	 */
> -	if (!dep->endpoint.desc)
> +	if (!dep->endpoint.desc || !dwc->pullups_connected)

I'm still considering this as well. Sure, we kill pullups before the
descriptor is set to NULL, but that shouldn't be a problem. What will
happen is:

usb_gadget_disconnect();
udc->driver->disconnect();
 for_each_ep() {
  for_each_request() {
   usb_ep_dequeue();
  }
  usb_ep_disable();
   dep->endpoint.desc = NULL;
 }
udc->driver->unbind();
usb_gadget_udc_stop();

I don't see a problem here. Did you manage to trigger any failure when
you didn't have this check? Care to show some logs? We might have a bug
elsewhere which we don't want to mask by adding this check here.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

Re: [PATCH v2 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3006 bytes --]


Hi,

Baolin Wang <baolin.wang@linaro.org> writes:
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 057739d..22787b6 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -999,6 +999,7 @@ static int dwc3_probe(struct platform_device *pdev)
>  		goto err0;
>  
>  	spin_lock_init(&dwc->lock);
> +	init_completion(&dwc->ep0_completed);

this should be done only when gadget is required; meaning that this
should be moved to dwc3_gadget_init()

> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index b2317e7..858e661 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h

[...]

> @@ -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_completed;

when you call this "ep0_completed" it seems like you're defining a flag,
but you're not :) How about "ep0_in_setup" instead? That conveys the
idea that we're waiting for ep0 to reach setup phase.

> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 632e5a4..baf932d 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -286,6 +286,7 @@ static void dwc3_ep0_stall_and_restart(struct dwc3 *dwc)
>  
>  	dwc->ep0state = EP0_SETUP_PHASE;
>  	dwc3_ep0_out_start(dwc);
> +	complete(&dwc->ep0_completed);

no, this is wrong. I see what you're trying to do here, but we don't
want to duplicate this call to complete() right? One thing we can
realize is that *always* after STATUS phase or after a STALL, we will go
through dwc3_ep0_out_start(), this mean we can call complete() before
starting the following SETUP phase.

Single place to call complete() ;-)

> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 1a33308..c9026ce 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1441,6 +1441,15 @@ 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) {
> +		reinit_completion(&dwc->ep0_completed);

this seems unnecessary to me. Also, why return here so the caller has to
wait? You could just have called wait_for_completion() here straight
away:

	if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
		/* should this be interruptible? */
		ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
                		msecs_to_jiffies(500));
                if (ret == 0) {
                	dwc3_trace(trace_dwc3_gadget, "RUN/STOP timeout");
			return -ETIMEDOUT;
		}
	}               

There's also no need for that "try_again" trickery. We either can halt
the controller within 500ms or we cannot.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

Re: [PATCH v2 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

[Baolin Wang]

Hi Felipe,

Sorry for late reply due to my holiday.

On 9 September 2016 at 18:47, Felipe Balbi <balbi@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.wang@linaro.org> writes:
>> When system has stpped the gadget, we should avoid queuing any requests
>> which will cause tranfer failed. Thus adding some disconnect checking to
>> avoid this situation.
>>
>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>
> do you mind if we discuss this for a little longer?

Sure.

>
>> ---
>> Changes since v1:
>>  - Split into 2 separate ptaches.
>>  - Choose complete mechanism instead of polling.
>> ---
>>  drivers/usb/dwc3/ep0.c    |    8 ++++++++
>>  drivers/usb/dwc3/gadget.c |   12 +++++++++---
>>  2 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index fe79d77..632e5a4 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -228,6 +228,14 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct usb_request *request,
>>       int                             ret;
>>
>>       spin_lock_irqsave(&dwc->lock, flags);
>> +     if (!dwc->pullups_connected) {
>> +             dwc3_trace(trace_dwc3_ep0,
>> +                     "queuing request %p to %s when gadget is disconnected",
>> +                     request, dep->name);
>> +             ret = -ESHUTDOWN;
>> +             goto out;
>> +     }
>
> I have been thinking about this branch here. It's not a problem to queue
> a request with pullups disconnected. It's only a problem to issue
> START_TRANSFER without RUN_STOP bit set.
>
> So maybe this check should be done in dwc3_send_gadget_ep_cmd(). By
> doing that we also make sure to do the check in one place and one place
> only because all endpoints rely dwc3_send_gadget_ep_cmd().

OK, that makes sense to me.

>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 1783406..1a33308 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1040,6 +1040,13 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
>>       struct dwc3             *dwc = dep->dwc;
>>       int                     ret;
>>
>> +     if (!dwc->pullups_connected) {
>> +             dwc3_trace(trace_dwc3_gadget,
>> +                     "queuing request %p to %s when gadget is disconnected",
>> +                     &req->request, dep->endpoint.name);
>> +             return -ESHUTDOWN;
>> +     }
>> +
>>       if (!dep->endpoint.desc) {
>>               dwc3_trace(trace_dwc3_gadget,
>>                               "trying to queue request %p to disabled %s",
>> @@ -1984,13 +1991,12 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc, struct dwc3_ep *dep,
>>               if (ret)
>>                       break;
>>       }
>> -
>
> trailing change.

Ah, sorry. Will remove it.

>
>>       /*
>>        * Our endpoint might get disabled by another thread during
>>        * dwc3_gadget_giveback(). If that happens, we're just gonna return 1
>>        * early on so DWC3_EP_BUSY flag gets cleared
>>        */
>> -     if (!dep->endpoint.desc)
>> +     if (!dep->endpoint.desc || !dwc->pullups_connected)
>
> I'm still considering this as well. Sure, we kill pullups before the
> descriptor is set to NULL, but that shouldn't be a problem. What will
> happen is:
>
> usb_gadget_disconnect();
> udc->driver->disconnect();
>  for_each_ep() {
>   for_each_request() {
>    usb_ep_dequeue();
>   }
>   usb_ep_disable();
>    dep->endpoint.desc = NULL;
>  }
> udc->driver->unbind();
> usb_gadget_udc_stop();
>
> I don't see a problem here. Did you manage to trigger any failure when
> you didn't have this check? Care to show some logs? We might have a bug
> elsewhere which we don't want to mask by adding this check here.

If we did not add this 'pullups_connected' checking here, it maybe
will kick one transfer to cause a problem of TART_TRANSFER, but it
also can be removed if we check in dwc3_send_gadget_ep_cmd() as you
suggested. Thanks for your comments and I will send out the new patch.


-- 
Baolin.wang
Best Regards

Re: [PATCH v2 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

[Baolin Wang]

Hi Felipe,

On 9 September 2016 at 19:03, Felipe Balbi <balbi@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.wang@linaro.org> writes:
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 057739d..22787b6 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -999,6 +999,7 @@ static int dwc3_probe(struct platform_device *pdev)
>>               goto err0;
>>
>>       spin_lock_init(&dwc->lock);
>> +     init_completion(&dwc->ep0_completed);
>
> this should be done only when gadget is required; meaning that this
> should be moved to dwc3_gadget_init()

OK.

>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index b2317e7..858e661 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>
> [...]
>
>> @@ -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_completed;
>
> when you call this "ep0_completed" it seems like you're defining a flag,
> but you're not :) How about "ep0_in_setup" instead? That conveys the
> idea that we're waiting for ep0 to reach setup phase.

Make sense and will change it.

>
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index 632e5a4..baf932d 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -286,6 +286,7 @@ static void dwc3_ep0_stall_and_restart(struct dwc3 *dwc)
>>
>>       dwc->ep0state = EP0_SETUP_PHASE;
>>       dwc3_ep0_out_start(dwc);
>> +     complete(&dwc->ep0_completed);
>
> no, this is wrong. I see what you're trying to do here, but we don't
> want to duplicate this call to complete() right? One thing we can
> realize is that *always* after STATUS phase or after a STALL, we will go
> through dwc3_ep0_out_start(), this mean we can call complete() before
> starting the following SETUP phase.
>
> Single place to call complete() ;-)

Make sense to me and I will fix that in next version.

>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 1a33308..c9026ce 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1441,6 +1441,15 @@ 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) {
>> +             reinit_completion(&dwc->ep0_completed);
>
> this seems unnecessary to me. Also, why return here so the caller has to

We should re-init the completion due to it will complete control
transfer many times before we try to stop gadget.

> wait? You could just have called wait_for_completion() here straight
> away:
>
>         if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
>                 /* should this be interruptible? */
>                 ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
>                                 msecs_to_jiffies(500));
>                 if (ret == 0) {
>                         dwc3_trace(trace_dwc3_gadget, "RUN/STOP timeout");
>                         return -ETIMEDOUT;
>                 }
>         }
>
> There's also no need for that "try_again" trickery. We either can halt
> the controller within 500ms or we cannot.

But this is in atomic context and we can not issue
wait_for_completion_timeout() in atomic context, then we should just
return here.

-- 
Baolin.wang
Best Regards

Re: [PATCH v2 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]


Hi,

Baolin Wang <baolin.wang@linaro.org> writes:
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 1a33308..c9026ce 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -1441,6 +1441,15 @@ 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) {
>>> +             reinit_completion(&dwc->ep0_completed);
>>
>> this seems unnecessary to me. Also, why return here so the caller has to
>
> We should re-init the completion due to it will complete control
> transfer many times before we try to stop gadget.

not sure I get this comment, care to furter explain what you mean?

>> wait? You could just have called wait_for_completion() here straight
>> away:
>>
>>         if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
>>                 /* should this be interruptible? */
>>                 ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
>>                                 msecs_to_jiffies(500));
>>                 if (ret == 0) {
>>                         dwc3_trace(trace_dwc3_gadget, "RUN/STOP timeout");
>>                         return -ETIMEDOUT;
>>                 }
>>         }
>>
>> There's also no need for that "try_again" trickery. We either can halt
>> the controller within 500ms or we cannot.
>
> But this is in atomic context and we can not issue
> wait_for_completion_timeout() in atomic context, then we should just
> return here.

heh, good point. Missed that :-)

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

Re: [PATCH v2 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

[Baolin Wang]

Hi Felipe,

On 19 September 2016 at 17:58, Felipe Balbi <balbi@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.wang@linaro.org> writes:
>>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>>> index 1a33308..c9026ce 100644
>>>> --- a/drivers/usb/dwc3/gadget.c
>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>> @@ -1441,6 +1441,15 @@ 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) {
>>>> +             reinit_completion(&dwc->ep0_completed);
>>>
>>> this seems unnecessary to me. Also, why return here so the caller has to
>>
>> We should re-init the completion due to it will complete control
>> transfer many times before we try to stop gadget.
>
> not sure I get this comment, care to furter explain what you mean?

Sorry for confusing comment. What I mean is it will issue
'complete(&dwc->ep0_completed)' when one control transfer is
completed, and it will increase the completion->done when every
'complete()' function is issued.

If there are seveal control transfers are completed (completion->done
is not 0 bow) and dwc->ep0state is not in EP0_SETUP_PHASE satus when
we want to stop gadget, then we should wait for completion. If we
don't call 'reinit_completion(&dwc->ep0_completed)' (it will reset
completion->done as 0 ), it will not wait for 500ms in
wait_for_completion_timeout() funtion. Hope I make it clear.

>
>>> wait? You could just have called wait_for_completion() here straight
>>> away:
>>>
>>>         if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
>>>                 /* should this be interruptible? */
>>>                 ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
>>>                                 msecs_to_jiffies(500));
>>>                 if (ret == 0) {
>>>                         dwc3_trace(trace_dwc3_gadget, "RUN/STOP timeout");
>>>                         return -ETIMEDOUT;
>>>                 }
>>>         }
>>>
>>> There's also no need for that "try_again" trickery. We either can halt
>>> the controller within 500ms or we cannot.
>>
>> But this is in atomic context and we can not issue
>> wait_for_completion_timeout() in atomic context, then we should just
>> return here.
>
> heh, good point. Missed that :-)

OK:)

-- 
Baolin.wang
Best Regards