public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>,
	Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>,
	Roger Quadros <rogerq@ti.com>
Cc: "linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Date: Mon, 19 Mar 2018 10:54:34 +0200	[thread overview]
Message-ID: <87d100qwc5.fsf@linux.intel.com> (raw)
In-Reply-To: <410670D7E743164D87FA6160E7907A560113ABBA4B@am04wembxa.internal.synopsys.com>

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


Hi,

Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> 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

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

  reply	other threads:[~2018-03-19  8:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27 11:22 [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume Roger Quadros
2018-02-28  3:04 ` Baolin Wang
2018-02-28  9:55   ` Roger Quadros
2018-02-28  7:53 ` Felipe Balbi
2018-02-28  9:59   ` Roger Quadros
2018-03-05  8:49     ` Felipe Balbi
2018-03-05  9:45       ` Roger Quadros
2018-03-05 10:41         ` Baolin Wang
2018-03-05 11:03           ` Roger Quadros
2018-03-05 11:06           ` Felipe Balbi
2018-03-05 11:14             ` Roger Quadros
2018-03-05 11:25               ` Baolin Wang
2018-03-05 11:27                 ` Felipe Balbi
2018-03-09  9:19                   ` Roger Quadros
2018-03-09  9:23                     ` Felipe Balbi
2018-03-09  9:26                       ` Roger Quadros
2018-03-09  9:49                         ` Roger Quadros
2018-03-09 10:39                           ` Felipe Balbi
2018-03-09 10:36                         ` Felipe Balbi
2018-03-05 11:25               ` Felipe Balbi
2018-03-09 12:47 ` [PATCH v2] " Roger Quadros
2018-03-16 10:34   ` Roger Quadros
2018-03-16 11:00     ` Felipe Balbi
2018-03-16 11:03       ` Roger Quadros
2018-03-16 11:43         ` Minas Harutyunyan
2018-03-16 12:25           ` Felipe Balbi
2018-03-17  6:33             ` Minas Harutyunyan
2018-03-19  8:54               ` Felipe Balbi [this message]
2018-03-19 11:36                 ` Minas Harutyunyan
2018-03-19 13:53                   ` Minas Harutyunyan
2018-04-10  6:29                     ` Minas Harutyunyan
2018-04-10  7:31                       ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d100qwc5.fsf@linux.intel.com \
    --to=balbi@kernel.org \
    --cc=Minas.Harutyunyan@synopsys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rogerq@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox