From: Elson Serrao <elson.serrao@oss.qualcomm.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/1] Add version check for setting ForceRM
Date: Mon, 10 Aug 2026 13:44:02 -0700 [thread overview]
Message-ID: <3ae42f16-ead2-4811-9b5e-da42bf81d477@oss.qualcomm.com> (raw)
In-Reply-To: <anUevdJ3ZNaYyB61@vbox>
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
next prev parent reply other threads:[~2026-08-10 20:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 23:40 [PATCH 0/1] Add version check for setting ForceRM Elson Serrao
2026-08-06 23:40 ` [PATCH 1/1] usb: dwc3: gadget: add " Elson Serrao
2026-08-07 0:19 ` [PATCH 0/1] Add " Thinh Nguyen
2026-08-10 20:44 ` Elson Serrao [this message]
2026-08-10 22:35 ` Thinh Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ae42f16-ead2-4811-9b5e-da42bf81d477@oss.qualcomm.com \
--to=elson.serrao@oss.qualcomm.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.