From: Mattijs Korpershoek <mkorpershoek@kernel.org>
To: Mattijs Korpershoek <mkorpershoek@kernel.org>,
Patrice Chotard <patrice.chotard@foss.st.com>,
u-boot@lists.denx.de,
Stephan Gerhold <stephan.gerhold@linaro.org>
Cc: Lukasz Majewski <lukma@denx.de>,
Mattijs Korpershoek <mkorpershoek@kernel.org>,
Marek Vasut <marex@denx.de>, Tom Rini <trini@konsulko.com>,
Jonas Karlman <jonas@kwiboo.se>,
Patrice Chotard <patrice.chotard@foss.st.com>
Subject: Re: [PATCH] usb: gadget: dwc2: reset endpoint enabled state on reinit
Date: Wed, 17 Jun 2026 12:12:38 +0200 [thread overview]
Message-ID: <87a4sth3vt.fsf@kernel.org> (raw)
In-Reply-To: <87cxxph6d1.fsf@kernel.org>
On Wed, Jun 17, 2026 at 11:19, Mattijs Korpershoek <mkorpershoek@kernel.org> wrote:
> Hi Patrice,
>
> Thank you for the patch and for finding this bug.
>
> On Tue, Jun 16, 2026 at 14:57, Patrice Chotard <patrice.chotard@foss.st.com> wrote:
>
>> Issue found with STM32MP157C-DK2 board, first usage of "ums 0 mmc 0"
>> is working, but second execution doesn't. The mass storage is not visible
>> from host side.
>>
>> Since commit 59310d1ecb9f ("usb: gadget: introduce 'enabled' flag
>> in struct usb_ep"), usb_ep_enable() returns early when ep->enabled is
>> already set.
>>
>> The DWC2 UDC driver reinitializes its endpoint software state in
>> udc_reinit(), including descriptor, stopped state and request queues, but
>> it leaves the generic usb_ep.enabled flag untouched. After stopping UMS
>> once, endpoints can therefore still look enabled to the gadget core even
>> though the DWC2 endpoint state has been reset.
>>
>> On the next "ums 0 mmc 0" run, usb_ep_enable() skips the controller
>> enable callback, so the host no longer sees a usable USB mass-storage
>> device.
>>
>> Clear ep->ep.enabled together with the rest of the DWC2 endpoint state so
>> each new gadget run programs the hardware endpoints again.
>>
>> Tested on STM32MP157c-dk2 board.
>>
>> Fixes: 59310d1ecb9f ("usb: gadget: introduce 'enabled' flag in struct usb_ep")
>> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
>
> I give this some testing and I have curious results.
>
> With commit a7830e87555a ("Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh"),
>
> I reproduce this on VIM3 (using configs/khadas-vim3_android_defconfig)
> with:
> """
> U-Boot 2026.07-rc4-00061-ga7830e87555a (Jun 17 2026 - 11:07:46 +0200) khadas-vim3
>
> Model: Khadas VIM3
> SoC: Amlogic Meson G12B (A311D) Revision 29:b (10:2)
> DRAM: 2 GiB (total 3.8 GiB)
> Core: 408 devices, 37 uclasses, devicetree: separate
> MMC: mmc@ffe03000: 0, mmc@ffe05000: 1, mmc@ffe07000: 2
> Loading Environment from MMC... Reading from MMC(2)... OK
> In: usbkbd,serial
> Out: vidconsole,serial
> Err: vidconsole,serial
> Net: eth0: ethernet@ff3f0000
>
> Hit any key to stop autoboot: 0
> => ums 0 mmc 2
> UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000
> -crq->brequest:0x0
> \
> CTRL+C - Operation aborted
> =>
> """
>
> On host (before interrupting UMS):
> $ lsblk /dev/sda
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> sda 8:0 1 29.1G 0 disk
>
> Then we restart UMS:
> """
> => ums 0 mmc 2
> UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000
> \crq->brequest:0x0
> """
>
> On host:
> $ lsblk /dev/sda
> lsblk: /dev/sda: not a block device
>
> I can also confirm that your patch solves the issue for me with UMS.
>
> However, using fastboot (which also binds to the gadget driver, I can't
> reproduce this issue):
>
> """
> U-Boot 2026.07-rc4-00061-ga7830e87555a (Jun 17 2026 - 11:15:24 +0200) khadas-vim3
>
> Model: Khadas VIM3
> SoC: Amlogic Meson G12B (A311D) Revision 29:b (10:2)
> DRAM: 2 GiB (total 3.8 GiB)
> Core: 408 devices, 37 uclasses, devicetree: separate
> MMC: mmc@ffe03000: 0, mmc@ffe05000: 1, mmc@ffe07000: 2
> Loading Environment from MMC... Reading from MMC(2)... OK
> In: usbkbd,serial
> Out: vidconsole,serial
> Err: vidconsole,serial
> Net: eth0: ethernet@ff3f0000
>
> On host (before interrupting UMS):
> Hit any key to stop autoboot: 0
> => fastboot usb 0
> crq->brequest:0x0
> """
>
> On host:
> $ fastboot devices
> C8631470D063 Android Fastboot
>
> Then: interrupt with CTRL+C and re-run:
> """
> => fastboot usb 0
> crq->brequest:0x0
> """
>
> On host:
> $ fastboot devices
> C8631470D063 Android Fastboot
>
> This makes be believe that the current patch might not be the right
> approach. Could we investigate why it works for fastboot but not for
> UMS?
>
> Maybe the commands have a different teardown mechanism.
Some debugging pointed me out to the following patch that's in linux:
https://lore.kernel.org/r/1635365407-31337-3-git-send-email-quic_wcheng@quicinc.com
I've applied that locally and to me it fixes the issue with UMS.
I'll send it to the list.
>
>> ---
>> drivers/usb/gadget/dwc2_udc_otg.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c
>> index e475b14b9ac..5752bf3ca70 100644
>> --- a/drivers/usb/gadget/dwc2_udc_otg.c
>> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
>> @@ -209,6 +209,7 @@ static void udc_reinit(struct dwc2_udc *dev)
>>
>> ep->desc = 0;
>> ep->stopped = 0;
>> + ep->ep.enabled = false;
>> INIT_LIST_HEAD(&ep->queue);
>> ep->pio_irqs = 0;
>> }
>>
>> ---
>> base-commit: badd97fe24dfb73b2728c26b433cabe315a27971
>> change-id: 20260616-ums_fix-fad8736154b6
>>
>> Best regards,
>> --
>> Patrice Chotard <patrice.chotard@foss.st.com>
next prev parent reply other threads:[~2026-06-17 10:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 12:57 [PATCH] usb: gadget: dwc2: reset endpoint enabled state on reinit Patrice Chotard
2026-06-17 9:19 ` Mattijs Korpershoek
2026-06-17 10:12 ` Mattijs Korpershoek [this message]
2026-06-17 11:16 ` Mattijs Korpershoek
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=87a4sth3vt.fsf@kernel.org \
--to=mkorpershoek@kernel.org \
--cc=jonas@kwiboo.se \
--cc=lukma@denx.de \
--cc=marex@denx.de \
--cc=patrice.chotard@foss.st.com \
--cc=stephan.gerhold@linaro.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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.