[PATCH 0/1] Add version check for setting ForceRM

[PATCH 0/1] Add version check for setting ForceRM

[Elson Serrao]

Hi Thinh,
 
We are observing an issue on DWC_usb31 v2.00a and v2.10a controllers where
a transfer aborted through the ep_dequeue() path continues to generate
writes even after EndTransfer has completed. In our testing, the issue was
reproduced on an OUT bulk endpoint.
 
The stale writes are not observed immediately following EndTransfer.
Instead, they are triggered when a subsequent StartTransfer is issued on
the same endpoint. Since the transfer buffer is freed as part of the
EndTransfer command-completion cleanup, these delayed writes result in an
SMMU fault when the controller accesses the already-unmapped buffer.
 
We found that issuing EndTransfer with ForceRM=0 eliminates the issue.
 
While investigating the issue, I reviewed the DWC_usb31 programming guides.
Starting with version 2.00a, section 3.2.2.7 (End Transfer) specifies that
EndTransfer should be issued with ForceRM cleared, whereas older revisions
specified ForceRM=1.
 
This appears to align with our observations, where using ForceRM=0
prevents the stale writes observed after a transfer has been aborted
through the dequeue path.
 
Based on this guidance, the patch clears ForceRM for DWC_usb31 controllers
starting from version 2.00a, while retaining the existing behavior for
older revisions where the programming guide specified ForceRM=1.
 
Since I only have access to the DWC_usb31 programming guides, I have
currently restricted the change to DWC_usb31 IP revisions. Please let me
know if this is not the right approach or if the change should also be
extended to other DWC3 IPs, and I will update the patch accordingly.
 
Thanks,
Elson

Elson Serrao (1):
  usb: dwc3: gadget: add version check for setting ForceRM

 drivers/usb/dwc3/gadget.c | 7 +++++++
 1 file changed, 7 insertions(+)

-- 
2.34.1

[PATCH 1/1] usb: dwc3: gadget: add version check for setting ForceRM

[Elson Serrao]

The ForceRM bit of the DEPCMD register controls the behavior of the
EndTransfer command used to stop an active transfer. For DWC_usb31
controllers prior to version 2.00a, the programming guide specified
ForceRM=1. Starting with version 2.00a, the programming guide
(section 3.2.2.7) specifies ForceRM=0 when issuing an EndTransfer
command.
 
With ForceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, an aborted
transfer through the ep_dequeue path was observed to remain active after
EndTransfer completion. A subsequent StartTransfer issued on the same
endpoint triggered writes associated with the aborted transfer. This
resulted in an SMMU fault because the transfer buffer had already been
unmapped during EndTransfer command-completion cleanup.
 
Using ForceRM=0 eliminates the issue and aligns driver behavior with
the programming guide requirements for DWC_usb31 2.00a and newer
revisions. Add version-based checks to select the appropriate ForceRM
setting based on the controller revision.

Fixes: 1e43c86d84fb ("usb: dwc3: core: Add DWC31 version 2.00a controller")
Cc: stable@vger.kernel.org
Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
---
 drivers/usb/dwc3/gadget.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index fa0f16ffafef..4b7bcad75d90 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1760,10 +1760,17 @@ static int __dwc3_gadget_get_frame(struct dwc3 *dwc)
  */
 static int __dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force, bool interrupt)
 {
+	struct dwc3 *dwc = dep->dwc;
 	struct dwc3_gadget_ep_cmd_params params;
 	u32 cmd;
 	int ret;
 
+	/*
+	 * Per the DWC_usb31 programming guide (section 3.2.2.7), EndTransfer
+	 * must be issued with ForceRM cleared starting from version 2.00a.
+	 */
+	force = force && (!DWC3_IP_IS(DWC31) || DWC3_VER_IS_PRIOR(DWC31, 200A));
+
 	cmd = DWC3_DEPCMD_ENDTRANSFER;
 	cmd |= force ? DWC3_DEPCMD_HIPRI_FORCERM : 0;
 	cmd |= interrupt ? DWC3_DEPCMD_CMDIOC : 0;
-- 
2.34.1

Re: [PATCH 0/1] Add version check for setting ForceRM

[Thinh Nguyen]

On Thu, Aug 06, 2026, Elson Serrao wrote:
> Hi Thinh,
>  
> We are observing an issue on DWC_usb31 v2.00a and v2.10a controllers where
> a transfer aborted through the ep_dequeue() path continues to generate
> writes even after EndTransfer has completed. In our testing, the issue was
> reproduced on an OUT bulk endpoint.
>  
> The stale writes are not observed immediately following EndTransfer.
> Instead, they are triggered when a subsequent StartTransfer is issued on
> the same endpoint. Since the transfer buffer is freed as part of the
> EndTransfer command-completion cleanup, these delayed writes result in an
> SMMU fault when the controller accesses the already-unmapped buffer.
>  
> We found that issuing EndTransfer with ForceRM=0 eliminates the issue.
>  
> While investigating the issue, I reviewed the DWC_usb31 programming guides.
> Starting with version 2.00a, section 3.2.2.7 (End Transfer) specifies that
> EndTransfer should be issued with ForceRM cleared, whereas older revisions
> specified ForceRM=1.
>  
> This appears to align with our observations, where using ForceRM=0
> prevents the stale writes observed after a transfer has been aborted
> through the dequeue path.
>  
> Based on this guidance, the patch clears ForceRM for DWC_usb31 controllers
> starting from version 2.00a, while retaining the existing behavior for
> older revisions where the programming guide specified ForceRM=1.
>  
> Since I only have access to the DWC_usb31 programming guides, I have
> currently restricted the change to DWC_usb31 IP revisions. Please let me
> know if this is not the right approach or if the change should also be
> extended to other DWC3 IPs, and I will update the patch accordingly.
>  
> Thanks,
> Elson
> 
> Elson Serrao (1):
>   usb: dwc3: gadget: add version check for setting ForceRM
> 
>  drivers/usb/dwc3/gadget.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> -- 
> 2.34.1
> 

Hi Elson,

Thanks for the patch.

This new recommendation applies to all 3.2 controllers also.

I don't recall forceRM=0 causing any issue to previous versions.

I would suggest applying this change across all IPs and IP versions to
keep consistent behavior when ending transfers since TRBs are updated on
completion. Since older IP databooks recommended setting forceRM=1, can
you also add a note in the code indicating newer programming guideline
revisions now recommend forceRM=0?

Thanks,
Thinh

Re: [PATCH 0/1] Add version check for setting ForceRM

[Elson Serrao]

On 8/6/2026 5:19 PM, Thinh Nguyen wrote:
> On Thu, Aug 06, 2026, Elson Serrao wrote:
>> Hi Thinh,
>>  
>> We are observing an issue on DWC_usb31 v2.00a and v2.10a controllers where
>> a transfer aborted through the ep_dequeue() path continues to generate
>> writes even after EndTransfer has completed. In our testing, the issue was

[...]
>> Thanks,
>> Elson
>>
>> Elson Serrao (1):
>>   usb: dwc3: gadget: add version check for setting ForceRM
>>
>>  drivers/usb/dwc3/gadget.c | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> -- 
>> 2.34.1
>>
> 
> Hi Elson,
> 
> Thanks for the patch.
> 
> This new recommendation applies to all 3.2 controllers also.
> 
> I don't recall forceRM=0 causing any issue to previous versions.
> 
> I would suggest applying this change across all IPs and IP versions to
> keep consistent behavior when ending transfers since TRBs are updated on
> completion. Since older IP databooks recommended setting forceRM=1, can
> you also add a note in the code indicating newer programming guideline
> revisions now recommend forceRM=0?
> 

Hi Thinh,

Thanks for the clarification.

Since forceRM should now always be 0, and the reset value of forceRM is
already 0, the  function parameter force=false effectively becomes a
no-op. Would you recommend we drop the 'bool force' argument from stop
active transfers API entirely (documenting the forceRM behavior in a
comment)? 
Or would you prefer we keep the parameter and just have all callers pass
'false' , so the API/framework stays in place in case a future IP/version
needs it again?

Let me know which approach you'd prefer and I'll send an updated patch.

Thanks,
Elson

Re: [PATCH 0/1] Add version check for setting ForceRM

[Thinh Nguyen]

On Mon, Aug 10, 2026, Elson Serrao wrote:
> 
> 
> On 8/6/2026 5:19 PM, Thinh Nguyen wrote:
> > On Thu, Aug 06, 2026, Elson Serrao wrote:
> >> Hi Thinh,
> >>  
> >> We are observing an issue on DWC_usb31 v2.00a and v2.10a controllers where
> >> a transfer aborted through the ep_dequeue() path continues to generate
> >> writes even after EndTransfer has completed. In our testing, the issue was
> 
> [...]
> >> Thanks,
> >> Elson
> >>
> >> Elson Serrao (1):
> >>   usb: dwc3: gadget: add version check for setting ForceRM
> >>
> >>  drivers/usb/dwc3/gadget.c | 7 +++++++
> >>  1 file changed, 7 insertions(+)
> >>
> >> -- 
> >> 2.34.1
> >>
> > 
> > Hi Elson,
> > 
> > Thanks for the patch.
> > 
> > This new recommendation applies to all 3.2 controllers also.
> > 
> > I don't recall forceRM=0 causing any issue to previous versions.
> > 
> > I would suggest applying this change across all IPs and IP versions to
> > keep consistent behavior when ending transfers since TRBs are updated on
> > completion. Since older IP databooks recommended setting forceRM=1, can
> > you also add a note in the code indicating newer programming guideline
> > revisions now recommend forceRM=0?
> > 
> 
> Hi Thinh,
> 
> Thanks for the clarification.
> 
> Since forceRM should now always be 0, and the reset value of forceRM is
> already 0, the  function parameter force=false effectively becomes a
> no-op. Would you recommend we drop the 'bool force' argument from stop
> active transfers API entirely (documenting the forceRM behavior in a
> comment)? 
> Or would you prefer we keep the parameter and just have all callers pass
> 'false' , so the API/framework stays in place in case a future IP/version
> needs it again?
> 
> Let me know which approach you'd prefer and I'll send an updated patch.
> 

Can you separate the functional changes from the cleanup changes? Please
send one patch for the forceRM=0 and a separate patch for removing the
function parameter.

Thanks,
Thinh