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

[Thinh Nguyen]

On Sat, Sep 05, 2026, Cole Munz wrote:
> 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.
> 

I don't feel strongly about the print. Just wanted to raise the question
on the f_fs logic. Downgrading to dev_dbg() is fine. The intention was
to catch gadget driver misuse of dequeue(), not to flag a fatal error.

Thanks,
Thinh