Hi Patrice, Thank you for the patch and for finding this bug.
On Tue, Jun 16, 2026 at 14:57, Patrice Chotard <[email protected]> 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 <[email protected]> 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. > --- > 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 <[email protected]>
