Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, Minas Harutyunyan writes: >>> 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 best way here would be to figure why we're missing command complete IRQ in those cases. According to documentation, we *should* receive that interrupt, so why is it missing? >>> >>> Additional info on test. Core configuration is HS only mode, test speed >>> HS, core version v2.90a. Maybe it will help to understand cause of issue. >>> BTW, currently to pass above describe ISOC OUT test we just commented >>> wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function and >>> successfully received request completion in function driver. >>> Thanks, >>> Minas >>> >> >> One more info: while function driver call dequeue, host periodically >> send control read command to get status of test from function - test In >> Progress or Finished. >> Thanks, >> Minas >> > > Your last dwc3 patch series allow us to successfully dequeuing remaining > requests without falling in to infinite loop. that's cool, thanks :-) I'll just fix the documentation bug I introduced heh :-) -- balbi signature.asc Description: PGP signature
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi Filipe, On 3/19/2018 5:53 PM, Minas Harutyunyan wrote: > Hi, > > On 3/19/2018 3:36 PM, Minas Harutyunyan wrote: >> Hi, >> >> On 3/19/2018 12:55 PM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Minas Harutyunyan writes: > 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. >>> >>> okay >>> >> 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 best way here would be to figure why we're missing command complete >>> IRQ in those cases. According to documentation, we *should* receive that >>> interrupt, so why is it missing? >>> >> >> Additional info on test. Core configuration is HS only mode, test speed >> HS, core version v2.90a. Maybe it will help to understand cause of issue. >> BTW, currently to pass above describe ISOC OUT test we just commented >> wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function and >> successfully received request completion in function driver. >> Thanks, >> Minas >> > > One more info: while function driver call dequeue, host periodically > send control read command to get status of test from function - test In > Progress or Finished. > Thanks, > Minas > Your last dwc3 patch series allow us to successfully dequeuing remaining requests without falling in to infinite loop. Thank you, Minas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, On 3/19/2018 3:36 PM, Minas Harutyunyan wrote: > Hi, > > On 3/19/2018 12:55 PM, Felipe Balbi wrote: >> >> Hi, >> >> Minas Harutyunyan writes: 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. >> >> okay >> > 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 best way here would be to figure why we're missing command complete >> IRQ in those cases. According to documentation, we *should* receive that >> interrupt, so why is it missing? >> > > Additional info on test. Core configuration is HS only mode, test speed > HS, core version v2.90a. Maybe it will help to understand cause of issue. > BTW, currently to pass above describe ISOC OUT test we just commented > wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function and > successfully received request completion in function driver. > Thanks, > Minas > One more info: while function driver call dequeue, host periodically send control read command to get status of test from function - test In Progress or Finished. Thanks, Minas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, On 3/19/2018 12:55 PM, Felipe Balbi wrote: > > Hi, > > Minas Harutyunyan writes: >>> 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. > > okay > 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 best way here would be to figure why we're missing command complete > IRQ in those cases. According to documentation, we *should* receive that > interrupt, so why is it missing? > Additional info on test. Core configuration is HS only mode, test speed HS, core version v2.90a. Maybe it will help to understand cause of issue. BTW, currently to pass above describe ISOC OUT test we just commented wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function and successfully received request completion in function driver. Thanks, Minas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, Minas Harutyunyan writes: >> 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. okay >>> 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 best way here would be to figure why we're missing command complete IRQ in those cases. According to documentation, we *should* receive that interrupt, so why is it missing? -- balbi signature.asc Description: PGP signature
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, On 3/16/2018 4:25 PM, Felipe Balbi wrote: > > Hi, > > Minas Harutyunyan 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 > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, Minas Harutyunyan 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 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? > 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. 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 -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, On 3/16/2018 3:03 PM, Roger Quadros wrote: > On 16/03/18 13:00, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros writes: >> >>> Hi Felipe, >>> >>> 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 >>> >>> 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. 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) Not, sure that this fix is fully correct because I'm familiar with dwc3, but this fix allow us to go forward with request dequeue. I think, need deeper investigation of infinite loop to catch root cause of it, before accept any of fixes. Thanks, Minas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
On 16/03/18 13:00, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: > >> Hi Felipe, >> >> 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 >> >> 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. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi, Roger Quadros writes: > Hi Felipe, > > 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 > > 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. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Hi Felipe,
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
Thanks for picking this for -next.
Is it better to have this in v4.16-rc fixes?
and also stable? v4.12+
> ---
>
> 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(-)
>
> 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:
>
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
