From: Selvarasu Ganesan <selvarasu.g@samsung.com>
To: Alan Stern <stern@rowland.harvard.edu>,
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>,
"jh0801.jung@samsung.com" <jh0801.jung@samsung.com>,
"dh10.jung@samsung.com" <dh10.jung@samsung.com>,
"naushad@samsung.com" <naushad@samsung.com>,
"akash.m5@samsung.com" <akash.m5@samsung.com>,
"h10.kim@samsung.com" <h10.kim@samsung.com>,
"eomji.oh@samsung.com" <eomji.oh@samsung.com>,
"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
"thiagu.r@samsung.com" <thiagu.r@samsung.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: gadget: Prevent EPs resource conflict during StartTransfer
Date: Wed, 3 Dec 2025 10:55:40 +0530 [thread overview]
Message-ID: <4e82c0dd-4a36-4e1d-a93a-9bef5d63aa50@samsung.com> (raw)
In-Reply-To: <f6bba9d1-2221-4bad-a7d7-564a5a311de1@rowland.harvard.edu>
On 11/21/2025 8:38 AM, Alan Stern wrote:
> On Fri, Nov 21, 2025 at 02:22:02AM +0000, Thinh Nguyen wrote:
>> On Wed, Nov 19, 2025, Alan Stern wrote:
>>> ->set_alt() is called by the composite core when a Set-Interface or
>>> Set-Config control request arrives from the host. It happens within the
>>> composite_setup() handler, which is called by the UDC driver when a
>>> control request arrives, which means it happens in the context of the
>>> UDC driver's interrupt handler. Therefore ->set_alt() callbacks must
>>> not sleep.
>> This should be changed. I don't think we can expect set_alt() to
>> be in interrupt context only.
> Agreed.
>
>>> To do this right, I can't think of any approach other than to make the
>>> composite core use a work queue or other kernel thread for handling
>>> Set-Interface and Set-Config calls.
>> Sounds like it should've been like this initially.
> I guess the nobody thought through the issues very carefully at the time
> the composite framework was designed. Maybe the UDCs that existed back
> did not require a lot of time to flush endpoints; I can't remember.
>
>>> Without that ability, we will have to audit every function driver to
>>> make sure the ->set_alt() callbacks do ensure that endpoints are flushed
>>> before they are re-enabled.
>>>
>>> There does not seem to be any way to fix the problem just by changing
>>> the gadget core.
>>>
>> We can have a workaround in dwc3 that can temporarily "work" with what
>> we have. However, eventually, we will need to properly rework this and
>> audit the gadget drivers.
> Clearly, the first step is to change the composite core. That can be
> done without messing up anything else. But yes, eventually the gadget
> drivers will have to be audited.
>
> Alan Stern
Hi Thinh,
Do you have any suggestions that might be helpful for us to try on our side?
This EP resource‑conflict problem becomes easily observable when the
RNDIS network test executing ifconfig rndis0 down/up is run repeatedly
on the device side.
Thanks,
Selva
next prev parent reply other threads:[~2025-12-03 5:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20251117160057epcas5p324eddf1866146216495186a50bcd3c01@epcas5p3.samsung.com>
2025-11-17 15:59 ` [PATCH v2] usb: dwc3: gadget: Prevent EPs resource conflict during StartTransfer Selvarasu Ganesan
2025-11-18 2:21 ` Thinh Nguyen
2025-11-18 3:58 ` Selvarasu Ganesan
2025-11-19 1:56 ` Thinh Nguyen
2025-11-18 4:20 ` Alan Stern
2025-11-19 1:49 ` Thinh Nguyen
2025-11-19 4:09 ` Alan Stern
2025-11-20 2:07 ` Thinh Nguyen
2025-11-20 3:33 ` Alan Stern
2025-11-21 2:22 ` Thinh Nguyen
2025-11-21 3:08 ` Alan Stern
2025-12-03 5:25 ` Selvarasu Ganesan [this message]
2025-12-04 1:51 ` Thinh Nguyen
2025-12-04 13:15 ` Selvarasu Ganesan
2025-12-05 0:37 ` Thinh Nguyen
2025-12-05 1:18 ` Thinh Nguyen
2025-12-05 1:19 ` Thinh Nguyen
2025-12-11 10:38 ` Selvarasu Ganesan
2025-12-12 1:21 ` Thinh Nguyen
2026-02-26 10:59 ` Selvarasu Ganesan
2026-02-26 18:41 ` Thinh Nguyen
2026-03-02 5:56 ` Selvarasu Ganesan
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=4e82c0dd-4a36-4e1d-a93a-9bef5d63aa50@samsung.com \
--to=selvarasu.g@samsung.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=akash.m5@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=dh10.jung@samsung.com \
--cc=eomji.oh@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=h10.kim@samsung.com \
--cc=jh0801.jung@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=naushad@samsung.com \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=thiagu.r@samsung.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox