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