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

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

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