On Mon, Nov 17, 2025, Selvarasu Ganesan wrote:

The below “No resource for ep” warning appears when a StartTransfer command is issued for bulk or interrupt endpoints in `dwc3_gadget_ep_enable` while a previous StartTransfer on the same endpoint is still in progress. The gadget functions drivers can invoke `usb_ep_enable` (which triggers a new StartTransfer command) before the earlier transfer has completed. Because the previous StartTransfer is still active, `dwc3_gadget_ep_disable` can skip the required `EndTransfer` due to `DWC3_EP_DELAY_STOP`, leading to the endpoint resources are busy for previous StartTransfer and warning ("No resource for ep") from dwc3 driver.

To resolve this, a check is added to `dwc3_gadget_ep_enable` that checks the `DWC3_EP_TRANSFER_STARTED` flag before issuing a new StartTransfer. By preventing a second StartTransfer on an already busy endpoint, the resource conflict is eliminated, the warning disappears, and potential kernel panics caused by `panic_on_warn` are avoided.

------------[ cut here ]------------ dwc3 13200000.dwc3: No resource for ep1out WARNING: CPU: 0 PID: 700 at drivers/usb/dwc3/gadget.c:398 dwc3_send_gadget_ep_cmd+0x2f8/0x76c Call trace: dwc3_send_gadget_ep_cmd+0x2f8/0x76c __dwc3_gadget_ep_enable+0x490/0x7c0 dwc3_gadget_ep_enable+0x6c/0xe4 usb_ep_enable+0x5c/0x15c mp_eth_stop+0xd4/0x11c __dev_close_many+0x160/0x1c8 __dev_change_flags+0xfc/0x220 dev_change_flags+0x24/0x70 devinet_ioctl+0x434/0x524 inet_ioctl+0xa8/0x224 sock_do_ioctl+0x74/0x128 sock_ioctl+0x3bc/0x468 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x38/0x88 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac

Fixes: a97ea994605e ("usb: dwc3: gadget: offset Start Transfer latency for bulk EPs") Cc: stable@vger.kernel.org Signed-off-by: Selvarasu Ganesan selvarasu.g@samsung.com

---

Changes in v2:

• Removed change-id.
• Updated commit message.

Link to v1: https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/20251117152812...

drivers/usb/dwc3/gadget.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 1f67fb6aead5..8d3caa71ea12 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -963,8 +963,9 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action) * Issue StartTransfer here with no-op TRB so we can always rely on No * Response Update Transfer command. */

• if (usb_endpoint_xfer_bulk(desc) ||

• 	usb_endpoint_xfer_int(desc)) {
  

• if ((usb_endpoint_xfer_bulk(desc) ||

• 	usb_endpoint_xfer_int(desc)) &&
  

• 	!(dep->flags & DWC3_EP_TRANSFER_STARTED)) {
  

  struct dwc3_gadget_ep_cmd_params params; struct dwc3_trb *trb; dma_addr_t trb_dma;

-- 2.34.1

Thanks for the catch. The problem is that the "ep_disable" process should be completed after usb_ep_disable is completed. But currently it may be an async call.

This brings up some conflicting wording of the gadget API regarding usb_ep_disable. Here's the doc regarding usb_ep_disable:

/** * usb_ep_disable - endpoint is no longer usable * @ep:the endpoint being unconfigured. may not be the endpoint named "ep0". * * no other task may be using this endpoint when this is called. * any pending and uncompleted requests will complete with status * indicating disconnect (-ESHUTDOWN) before this call returns. * gadget drivers must call usb_ep_enable() again before queueing * requests to the endpoint. * * This routine may be called in an atomic (interrupt) context. * * returns zero, or a negative error code. */

It expects all requests to be completed and given back on completion. It also notes that this can also be called in interrupt context. Currently, there's a scenario where dwc3 may not want to give back the requests right away (ie. DWC3_EP_DELAY_STOP). To fix that in dwc3, it would need to "wait" for the right condition. But waiting does not make sense in interrupt context. (We could busy-poll to satisfy the interrupt context, but that doesn't sound right either)

This was updated from process context only to may be called in interrupt context:

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

Hi Alan,

Can you help give your opinion on this?

Thanks, Thinh

On 12/4/2025 7:21 AM, Thinh Nguyen wrote:

On Wed, Dec 03, 2025, Selvarasu Ganesan wrote:

...

On 11/21/2025 8:38 AM, Alan Stern wrote:

...

On Fri, Nov 21, 2025 at 02:22:02AM +0000, Thinh Nguyen wrote:

...

On Wed, Nov 19, 2025, Alan Stern wrote:

...

->set_alt() is called by the composite core when a Set-Interface or Set-Config control request arrives from the host. It happens within the composite_setup() handler, which is called by the UDC driver when a control request arrives, which means it happens in the context of the UDC driver's interrupt handler. Therefore ->set_alt() callbacks must not sleep.

This should be changed. I don't think we can expect set_alt() to be in interrupt context only.

Agreed.

...

...

To do this right, I can't think of any approach other than to make the composite core use a work queue or other kernel thread for handling Set-Interface and Set-Config calls.

Sounds like it should've been like this initially.

I guess the nobody thought through the issues very carefully at the time the composite framework was designed. Maybe the UDCs that existed back did not require a lot of time to flush endpoints; I can't remember.

...

...

Without that ability, we will have to audit every function driver to make sure the ->set_alt() callbacks do ensure that endpoints are flushed before they are re-enabled.

There does not seem to be any way to fix the problem just by changing the gadget core.

We can have a workaround in dwc3 that can temporarily "work" with what we have. However, eventually, we will need to properly rework this and audit the gadget drivers.

Clearly, the first step is to change the composite core. That can be done without messing up anything else. But yes, eventually the gadget drivers will have to be audited.

Alan Stern

Hi Thinh,

Do you have any suggestions that might be helpful for us to try on our side? This EP resource‑conflict problem becomes easily observable when the RNDIS network test executing ifconfig rndis0 down/up is run repeatedly on the device side.

Thanks, Selva

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.

Thanks, Thinh

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 3830aa2c10a9..974573304441 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -960,11 +960,18 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action) } /*

• * Issue StartTransfer here with no-op TRB so we can always rely on No
  

• * Response Update Transfer command.
  

• * For streams, at start, there maybe a race where the
  

• * host primes the endpoint before the function driver
  

• * queues a request to initiate a stream. In that case,
  

• * the controller will not see the prime to generate the
  

• * ERDY and start stream. To workaround this, issue a
  

• * no-op TRB as normal, but end it immediately. As a
  

• * result, when the function driver queues the request,
  

• * the next START_TRANSFER command will cause the
  

• * controller to generate an ERDY to initiate the
  

• * stream.
  

  */

• if (usb_endpoint_xfer_bulk(desc) ||

• 	usb_endpoint_xfer_int(desc)) {
  

• if (dep->stream_capable) { struct dwc3_gadget_ep_cmd_params params; struct dwc3_trb *trb; dma_addr_t trb_dma;

@@ -983,35 +990,21 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action) if (ret < 0) return ret;

• if (dep->stream_capable) {
  

• 	/*
  

• 	 * For streams, at start, there maybe a race where the
  

• 	 * host primes the endpoint before the function driver
  

• 	 * queues a request to initiate a stream. In that case,
  

• 	 * the controller will not see the prime to generate the
  

• 	 * ERDY and start stream. To workaround this, issue a
  

• 	 * no-op TRB as normal, but end it immediately. As a
  

• 	 * result, when the function driver queues the request,
  

• 	 * the next START_TRANSFER command will cause the
  

• 	 * controller to generate an ERDY to initiate the
  

• 	 * stream.
  

• 	 */
  

• 	dwc3_stop_active_transfer(dep, true, true);
  

• dwc3_stop_active_transfer(dep, true, true);
  

• 	/*
  

• 	 * All stream eps will reinitiate stream on NoStream
  

• 	 * rejection.
  

• 	 *
  

• 	 * However, if the controller is capable of
  

• 	 * TXF_FLUSH_BYPASS, then IN direction endpoints will
  

• 	 * automatically restart the stream without the driver
  

• 	 * initiation.
  

• 	 */
  

• 	if (!dep->direction ||
  

• 	    !(dwc->hwparams.hwparams9 &
  

• 	      DWC3_GHWPARAMS9_DEV_TXF_FLUSH_BYPASS))
  

• 		dep->flags |= DWC3_EP_FORCE_RESTART_STREAM;
  

• }
  

• /*
  

•  * All stream eps will reinitiate stream on NoStream
  

•  * rejection.
  

•  *
  

•  * However, if the controller is capable of
  

•  * TXF_FLUSH_BYPASS, then IN direction endpoints will
  

•  * automatically restart the stream without the driver
  

•  * initiation.
  

•  */
  

• if (!dep->direction ||
  

•     !(dwc->hwparams.hwparams9 &
  

•       DWC3_GHWPARAMS9_DEV_TXF_FLUSH_BYPASS))
  

• 	dep->flags |= DWC3_EP_FORCE_RESTART_STREAM;
  

  }

out:

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.

Thread#1: usb_ep_queue  ->dwc3_gadget_ep_queue   ->__dwc3_gadget_kick_transfer    -> starting = !(dep->flags & DWC3_EP_TRANSFER_STARTED);     ->if(starting)        ->dwc3_send_gadget_ep_cmd (cmd = DWC3_DEPCMD_STARTTRANSFER)          ->dep->flags |= DWC3_EP_TRANSFER_STARTED;

Thread#2: dwc3_gadget_ep_disable  ->__dwc3_gadget_ep_disable   ->dwc3_remove_requests    ->dwc3_stop_active_transfer     ->__dwc3_stop_active_transfer      -> dwc3_send_gadget_ep_cmd (cmd =DWC3_DEPCMD_ENDTRANSFER)       ->if(!interrupt)dep->flags &= ~DWC3_EP_TRANSFER_STARTED;           ...           While Thread#2 is still running, Thread #1 starts again:

Thread#1: usb_ep_queue  ->dwc3_gadget_ep_queue   ->__dwc3_gadget_kick_transfer    -> starting = !(dep->flags & DWC3_EP_TRANSFER_STARTED);     ->if(starting)       ->dwc3_send_gadget_ep_cmd (cmd = DWC3_DEPCMD_STARTTRANSFER)        ->dep->flags |= DWC3_EP_TRANSFER_STARTED;          ... ###### Thread#2: Continuation (race)           ->__dwc3_gadget_ep_disable            ->mask = DWC3_EP_TXFIFO_RESIZED | DWC3_EP_RESOURCE_ALLOCATED;             ->dep->flags &= mask; --> // Possible of clears                 DWC3_EP_TRANSFER_STARTED flag as well without                 sending DWC3_DEPCMD_ENDTRANSFER

Thread#1:(Failure due to race) usb_ep_queue  ->dwc3_gadget_ep_queue   ->__dwc3_gadget_kick_transfer    -> starting = !(dep->flags & DWC3_EP_TRANSFER_STARTED);      ->if(starting)        ->dwc3_send_gadget_ep_cmd (cmd = DWC3_DEPCMD_STARTTRANSFER) ->                 Results in “No resource” allocation error because the                 previous transfer was never end with ENDTRANSFER.

------------[ cut here ]------------  dwc3 13200000.dwc3: No resource for ep1in  WARNING: CPU: 7 PID: 1748 at drivers/usb/dwc3/gadget.c:398 dwc3_send_gadget_ep_cmd+0x2f8/0x76c  pc : dwc3_send_gadget_ep_cmd+0x2f8/0x76c  lr : dwc3_send_gadget_ep_cmd+0x2f8/0x76c  Call trace:  dwc3_send_gadget_ep_cmd+0x2f8/0x76c  __dwc3_gadget_kick_transfer+0x2ec/0x3f4  dwc3_gadget_ep_queue+0x140/0x1f0  usb_ep_queue+0x60/0xec  mp_tx_task+0x100/0x134  mp_tx_timeout+0xd0/0x1e0  __hrtimer_run_queues+0x130/0x318  hrtimer_interrupt+0xe8/0x340  exynos_mct_comp_isr+0x58/0x80  __handle_irq_event_percpu+0xcc/0x25c  handle_irq_event+0x40/0x9c  handle_fasteoi_irq+0x154/0x2c8  generic_handle_domain_irq+0x58/0x80  gic_handle_irq+0x48/0x104  call_on_irq_stack+0x3c/0x50  do_interrupt_handler+0x4c/0x84  el1_interrupt+0x34/0x58  el1h_64_irq_handler+0x18/0x24  el1h_64_irq+0x68/0x6c  _raw_spin_unlock_irqrestore+0xc/0x4c  binder_wakeup_thread_ilocked+0x50/0xb4  binder_proc_transaction+0x308/0x6ec  binder_transaction+0x1aec/0x23b0  binder_ioctl_write_read+0xa28/0x2534  binder_ioctl+0x1fc/0xb3c  __arm64_sys_ioctl+0xa8/0xe4  invoke_syscall+0x58/0x10c  el0_svc_common+0x80/0xdc  do_el0_svc+0x1c/0x28  el0_svc+0x38/0x88  el0t_64_sync_handler+0x70/0xbc  el0t_64_sync+0x1a8/0x1ac  ---[ end trace 0000000000000000 ]---

Thanks, Selva

On 12/5/2025 6:48 AM, Thinh Nguyen wrote:

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.

Hi Thinh,

Thank you for the insightful comments. I agree that adding more checks directly in the dwc3 driver would be messy, and a comprehensive rework of the dwc3 ep disable would ultimately be the cleaner solution.

In the meantime, Introducing additional checks for DWC3_EP_TRANSFER_STARTED in dwc3 driver is the most practical way to unblock the current issue while we work toward that longer‑term fix. We have applied the patches and performed additional testing, no regressions or new issues were observed.

Could you please confirm whether below interim fix is acceptable along with your proposed earlier patch for unblocking the current development flow?

Patch 2: usb: dwc3: protect dep->flags from concurrent modify in dwc3_gadget_ep_disable =======================================================================================

Subject: [PATCH] usb: dwc3: protect dep->flags from concurrent modify in dwc3_gadget_ep_disable The below warnings in `dwc3_gadget_ep_queue` observed during the RNDIS enable/disable test is caused by a race between `dwc3_gadget_ep_disable` and `dwc3_gadget_ep_queue`. Both functions manipulate `dep->flags`, and the lock released temporarily by `dwc3_gadget_giveback` (called from `dwc3_gadget_ep_disable`) can be acquired by `dwc3_gadget_ep_queue` before `dwc3_gadget_ep_disable` has finished. This leads to an inconsistent state of the `DWC3_EP_TRANSFER_STARTED` dep->flag.

To fix this issue by add a condition check when masking `dep->flags` in `dwc3_gadget_ep_disable` to ensure the `DWC3_EP_TRANSFER_STARTED` flag is not cleared when it is actually set. This prevents the spurious warning and eliminates the race.

Thread#1: dwc3_gadget_ep_disable   ->__dwc3_gadget_ep_disable    ->dwc3_remove_requests     ->dwc3_stop_active_transfer      ->__dwc3_stop_active_transfer       -> dwc3_send_gadget_ep_cmd (cmd =DWC3_DEPCMD_ENDTRANSFER)        ->if(!interrupt)dep->flags &= ~DWC3_EP_TRANSFER_STARTED;         ->dwc3_gadget_giveback          ->spin_unlock(&dwc->lock)            ...            While Thread#1 is still running, Thread#2 starts:

Thread#2: usb_ep_queue   ->dwc3_gadget_ep_queue    ->__dwc3_gadget_kick_transfer     -> starting = !(dep->flags & DWC3_EP_TRANSFER_STARTED);      ->if(starting)        ->dwc3_send_gadget_ep_cmd (cmd = DWC3_DEPCMD_STARTTRANSFER)         ->dep->flags |= DWC3_EP_TRANSFER_STARTED;           ...            ->__dwc3_gadget_ep_disable             ->mask = DWC3_EP_TXFIFO_RESIZED |DWC3_EP_RESOURCE_ALLOCATED;              ->dep->flags &= mask; --> // Possible of clears                  DWC3_EP_TRANSFER_STARTED flag as well without                  sending DWC3_DEPCMD_ENDTRANSFER

------------[ cut here ]------------   dwc3 13200000.dwc3: No resource for ep1in   WARNING: CPU: 7 PID: 1748 at drivers/usb/dwc3/gadget.c:398 dwc3_send_gadget_ep_cmd+0x2f8/0x76c   pc : dwc3_send_gadget_ep_cmd+0x2f8/0x76c   lr : dwc3_send_gadget_ep_cmd+0x2f8/0x76c   Call trace:     dwc3_send_gadget_ep_cmd+0x2f8/0x76c     __dwc3_gadget_kick_transfer+0x2ec/0x3f4     dwc3_gadget_ep_queue+0x140/0x1f0     usb_ep_queue+0x60/0xec     mp_tx_task+0x100/0x134     mp_tx_timeout+0xd0/0x1e0     __hrtimer_run_queues+0x130/0x318     hrtimer_interrupt+0xe8/0x340     exynos_mct_comp_isr+0x58/0x80     __handle_irq_event_percpu+0xcc/0x25c     handle_irq_event+0x40/0x9c     handle_fasteoi_irq+0x154/0x2c8     generic_handle_domain_irq+0x58/0x80     gic_handle_irq+0x48/0x104     call_on_irq_stack+0x3c/0x50     do_interrupt_handler+0x4c/0x84     el1_interrupt+0x34/0x58     el1h_64_irq_handler+0x18/0x24     el1h_64_irq+0x68/0x6c

Change-Id: Ib6a77ce5130e25d0162f72d0e52c845dbb1d18f5 Signed-off-by: Selvarasu Ganesan selvarasu.g@samsung.com ---  drivers/usb/dwc3/gadget.c | 16 ++++++++++++++++  1 file changed, 16 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index b42d225b67408..1dc5798072120 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1051,6 +1051,22 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)       */      if (dep->flags & DWC3_EP_DELAY_STOP)          mask |= (DWC3_EP_DELAY_STOP | DWC3_EP_TRANSFER_STARTED); + +    /* +     * When dwc3_gadget_ep_disable() calls dwc3_gadget_giveback(), +     * the  dwc->lock is temporarily released.  If dwc3_gadget_ep_queue() +     * runs in that window it may set the DWC3_EP_TRANSFER_STARTED flag as +     * part of dwc3_send_gadget_ep_cmd. The original code cleared the flag +     * unconditionally, which could overwrite the concurrent modification. +     * +     * The added check ensures the DWC3_EP_TRANSFER_STARTED flag is only +     * cleared if it is not set already, preserving the state updated by the +     * concurrent ep_queue path and eliminating the EP resource conflict +     * warning. +     */ +    if (dep->flags & DWC3_EP_TRANSFER_STARTED) +        mask |= DWC3_EP_TRANSFER_STARTED; +      dep->flags &= mask;

/* Clear out the ep descriptors for non-ep0 */