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

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

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

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