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

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

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