Hi,

Minas Harutyunyan [off-list ref] writes:

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

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?