Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
In-Reply-To: <410670D7E743164D87FA6160E7907A560113ABBA4B@am04wembxa.internal.synopsys.com>
References: <1519730526-22274-1-git-send-email-rogerq@ti.com> <a04fafee-7992-ce8b-55a9-afd4c9935462@ti.com> <69517684-bd39-e945-0c9e-ccd52b8050d5@ti.com> <87y3isffog.fsf@linux.intel.com> <5ea0ad17-d538-72ec-ed59-004242c4cd26@ti.com> <410670D7E743164D87FA6160E7907A560113ABB478@am04wembxa.internal.synopsys.com> <87zi38438h.fsf@linux.intel.com> <410670D7E743164D87FA6160E7907A560113ABBA4B@am04wembxa.internal.synopsys.com>
Date:   Mon, 19 Mar 2018 10:54:34 +0200
Message-ID: <87d100qwc5.fsf@linux.intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha512; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


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.
>>=20
>> how did this happen? During rmmod dwc3? Or, perhaps, after you unloaded
>> a gadget driver?
>>=20
> No, not during rmmod's.
> We using our internal USB testing tool. Test case; ISOC OUT, transfer=20
> size N frames. When host starts ISOC OUT traffic then the dwc3 based on=20
> "Transfer not ready" event in frame F starts transfers staring from=20
> frame F+4 (for bInterval=3D1) as result 4 requests, which already queued=
=20
> on device side, remain incomplete. Function driver on some timeout=20
> trying dequeue these 4 requests (without disabling EP) to complete test.
> For IN ISOC's these requests completed on MISSED ISOC event, but for=20
> 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)
>>=20
>> you're not fixing anything. You're, essentially, removing the entire
>> end transfer pending logic.=20
> yes, you are right, but how to overcome this infinite loop? Replace=20
> 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?

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlqvesoACgkQzL64meEa
mQbJhw/8DAGqXP8g8zqUOV8LBuA4l2yVQrKn9FlgSdTG5+GkfICZftGBjMqUFjCW
YVIGGl7BbUooaj2dVCl2HsAWhYYyhJH9Ij22MB21wxM4baX8Qf0wO4lm8n++F8cg
hodJMv+GJ7tvtReg4dxAKTLhO54CPZgUdQiLqo4ANseFCZ+FFGLNGkneGlJSq70o
0unrQrioFY0Sr9WeY5BwqkLxZVhr6IEbH8l2iZ9nVOfpaQTk43e5BdQ8NT2KpKii
RgXMZQregqTh4U7ZZmg2siZf0McQ9wIIvvYLrnPT6y0LBqwKqwR2k28VGaXzpxYO
KPUhzHgPEMwkz4RGW6HpiGYJ3MXaBuoqBQhWEFqgNLX8Ncvy2Gh3unatdupUtd35
vSZuYxVkelVAkZ7wgaE2JLMuQnSeCqNch/9S6F4vx5a6+MMVH8ciu0oUEOojfm3R
wh5hGpjcxcn1J5ZYVsD6u58v4AmK/0hIXlyonVu9kVIgxTiQ9GD5Sk3H204RMQwu
YcsBusF8P7i+9rIWBWet3FkxnAHArtbv1cgZi9aCbHdUkYQy48E1w2oNov1v9kXd
76joh02a+ILdr/9BS3C5FPQZJe0NuzcpY1azdyL7YlAEJfnzn5dknHQJsnRWnBJ5
rL4Kd4tQ2v7e0XMcGVdM3VGgHs/BKbP3Wf7St6g3059idF25O2w=
=yCfT
-----END PGP SIGNATURE-----
--=-=-=--