Re: [PATCH v2] usb: dwc3: gadget: Prevent EPs resource conflict during StartTransfer

[Thinh Nguyen]

On Fri, Dec 05, 2025, Thinh Nguyen wrote:
> On Thu, Dec 04, 2025, Selvarasu Ganesan wrote:
> > 
> > On 12/4/2025 7:21 AM, Thinh Nguyen wrote:
> > > At the moment, I can't think of a way to workaround for all cases. Let's
> > > just leave bulk streams alone for now. Until we have proper fixes to the
> > > gadget framework, let's just try the below.
> > >
> > 
> > 
> > Hi Thinh,
> > 
> > Thanks for the changes. We understand the given fix and have verified 
> > that the original issue is resolved, but a similar below warning appears 
> > again in `dwc3_gadget_ep_queue` when we run a long duration our test. 
> > And we confirmed this is not due to this new given changes.
> > 
> > This warning is caused by a race between `dwc3_gadget_ep_disable` and 
> > `dwc3_gadget_ep_queue` that manipulates `dep->flags`.
> > 
> > Please refer the below sequence for the reference.
> > 
> > The warning originates from a race condition between 
> > dwc3_gadget_ep_disable and dwc3_send_gadget_ep_cmd from 
> > dwc3_gadget_ep_queue that both manipulate dep->flags. Proper 
> > synchronization or a check is needed when masking (dep->flags &= mask) 
> > inside dwc3_gadget_ep_disable.
> > 
> 
> I was hoping that the dwc3_gadget_ep_queue() won't come early to run
> into this scenario. What I've provided will only mitigate and will not
> resolve for all cases. It seems adding more checks in dwc3 will be
> more messy.
> 
> Probably we should try rework the usb gadget framework instead of
> workaround the problem in dwc3. Here is a potential solution I'm
> thinking: introduce usb_ep_disable_with_flush().
> 

Actually, no. Let's just revert this:

b0d5d2a71641 ("usb: gadget: udc: core: Revise comments for USB ep enable/disable")

Reword the implementation in dwc3 and audit where usb_ep_disable() is used.

Thanks,
Thinh