Re: [PATCH v3] usb: dwc3: gadget: don't error on dequeue of a completed request

[Cole Munz <Munzzyy1@proton.me>]

On Sat, Sep 05, 2026, Thinh Nguyen wrote:
> Why is functionfs_unbind() calling usb_ep_dequeue() unconditionally
> after the request has already completed?
>
> The change ce405d561b02 looks like a workaround for a different issue.
> Maybe the fix belongs in f_fs instead of dwc3?

The dequeue there does a real job in one case: teardown racing an ep0
read/write. ffs_ep0_read/write hold ffs->mutex while they sit in
__ffs_ep0_queue_wait(), so functionfs_unbind() dequeues before taking
the mutex. The giveback with -ECONNRESET is what wakes the parked
reader so it can return and drop the mutex, and only then can unbind
free the request. In every other teardown the request completed long
ago and the dequeue is a no-op, which is the case dwc3 complains
about.

f_fs can tell those apart itself. ep0req is only ever queued from
__ffs_ep0_queue_wait(), so set a flag there before usb_ep_queue(),
clear it in ffs_ep0_complete(), and have functionfs_unbind() dequeue
only when it's set. If the completion fires between the check and the
dequeue you can still hit the dwc3 error, but that's a rare race
window where the documented behavior is doing its job, not noise on
every unbind.

If that direction looks right to you I'll send it as an f_fs patch,
Cc'ing Udipto since it revisits ce405d561b02.

Regards,
Cole