[v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume

Message ID a04fafee-7992-ce8b-55a9-afd4c9935462@ti.com
State Accepted
Commit 498f0478aba425ba5555a72e72fe1ce9ee45a0bd
Headers show
Series
  • [v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Related show

Commit Message

Roger Quadros March 9, 2018, 12:47 p.m.
In the following test we get stuck by sleeping forever in _dwc3_set_mode()
after which dual-role switching doesn't work.

On dra7-evm's dual-role port,
- Load g_zero gadget driver and enumerate to host
- suspend to mem
- disconnect USB cable to host and connect otg cable with Pen drive in it.
- resume system
- we sleep indefinitely in _dwc3_set_mode due to.
  dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->
	dwc3_gadget_stop()->wait_event_lock_irq()

To fix this instead of waiting indefinitely with wait_event_lock_irq()
we use wait_event_interruptible_lock_irq_timeout() and print
and error message if there was a timeout.

Signed-off-by: Roger Quadros <rogerq@ti.com>

---

Changelog:

v2:
- use wait_event_interruptible_lock_irq_timeout() instead of wait_event_lock_irq()

 drivers/usb/dwc3/gadget.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Minas Harutyunyan March 17, 2018, 6:33 a.m. | #1
Hi,

On 3/16/2018 4:25 PM, Felipe Balbi wrote:
> 

> Hi,

> 

> Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> writes:

>>>>> On 09/03/18 14:47, Roger Quadros wrote:

>>>>>> In the following test we get stuck by sleeping forever in _dwc3_set_mode()

>>>>>> after which dual-role switching doesn't work.

>>>>>>

>>>>>> On dra7-evm's dual-role port,

>>>>>> - Load g_zero gadget driver and enumerate to host

>>>>>> - suspend to mem

>>>>>> - disconnect USB cable to host and connect otg cable with Pen drive in it.

>>>>>> - resume system

>>>>>> - we sleep indefinitely in _dwc3_set_mode due to.

>>>>>>     dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->

>>>>>> 	dwc3_gadget_stop()->wait_event_lock_irq()

>>>>>>

>>>>>> To fix this instead of waiting indefinitely with wait_event_lock_irq()

>>>>>> we use wait_event_interruptible_lock_irq_timeout() and print

>>>>>> and error message if there was a timeout.

>>>>>>

>>>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>

>>>>>

>>>>> Thanks for picking this for -next.

>>>>> Is it better to have this in v4.16-rc fixes?

>>>>> and also stable? v4.12+

>>>>

>>>> Well, there was no "Fixes: foobar" or "Cc: stable" lines in the commit

>>>> log ;-)

>>>>

>>>> The best we can do now, is wait for -rc1 and manually send the commit to

>>>> stable.

>>>>

>>>

>>> That's fine. Thanks.

>>>

>>

>> Same issue seen in dwc3_gadget_ep_dequeue() function where also used

>> wait_event_lock_irq() - as result infinite loop.

> 

> how did this happen? During rmmod dwc3? Or, perhaps, after you unloaded

> a gadget driver?

> 

No, not during rmmod's.
We using our internal USB testing tool. Test case; ISOC OUT, transfer 
size N frames. When host starts ISOC OUT traffic then the dwc3 based on 
"Transfer not ready" event in frame F starts transfers staring from 
frame F+4 (for bInterval=1) as result 4 requests, which already queued 
on device side, remain incomplete. Function driver on some timeout 
trying dequeue these 4 requests (without disabling EP) to complete test.
For IN ISOC's these requests completed on MISSED ISOC event, but for 
ISOC OUT required call dequeue on some timeout.

>> Actually to fix this issue I updated condition of wait function

>> from:

>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING)

>> to:

>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING & DWC3_EP_ENABLED)

> 

> you're not fixing anything. You're, essentially, removing the entire

> end transfer pending logic. 

yes, you are right, but how to overcome this infinite loop? Replace 
wait_event_lock_irq() by  wait_event_interruptible_lock_irq_timeout()?

The whole idea of this is that we can
> disable the endpoint and wait for the End Transfer interrupt. When you

> add a check for the endpoint being enabled, then that code will never

> run and, thus, never wait for the End Transfer IRQ.

> 

> If you manage to find a more reliable way of reproducing this, then make

> sure to capture dwc3 tracepoints (see the documentation for details) and

> let's start trying to figure out what's going on.

> 

> cheers

> 


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2bda4eb..7c3a6e4 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1950,6 +1950,7 @@  static int dwc3_gadget_stop(struct usb_gadget *g)
 	struct dwc3		*dwc = gadget_to_dwc(g);
 	unsigned long		flags;
 	int			epnum;
+	u32			tmo_eps = 0;
 
 	spin_lock_irqsave(&dwc->lock, flags);
 
@@ -1960,6 +1961,7 @@  static int dwc3_gadget_stop(struct usb_gadget *g)
 
 	for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
 		struct dwc3_ep  *dep = dwc->eps[epnum];
+		int ret;
 
 		if (!dep)
 			continue;
@@ -1967,9 +1969,24 @@  static int dwc3_gadget_stop(struct usb_gadget *g)
 		if (!(dep->flags & DWC3_EP_END_TRANSFER_PENDING))
 			continue;
 
-		wait_event_lock_irq(dep->wait_end_transfer,
-				    !(dep->flags & DWC3_EP_END_TRANSFER_PENDING),
-				    dwc->lock);
+		ret = wait_event_interruptible_lock_irq_timeout(dep->wait_end_transfer,
+			    !(dep->flags & DWC3_EP_END_TRANSFER_PENDING),
+			    dwc->lock, msecs_to_jiffies(5));
+
+		if (ret <= 0) {
+			/* Timed out or interrupted! There's nothing much
+			 * we can do so we just log here and print which
+			 * endpoints timed out at the end.
+			 */
+			tmo_eps |= 1 << epnum;
+			dep->flags &= DWC3_EP_END_TRANSFER_PENDING;
+		}
+	}
+
+	if (tmo_eps) {
+		dev_err(dwc->dev,
+			"end transfer timed out on endpoints 0x%x [bitmap]\n",
+			tmo_eps);
 	}
 
 out: