STM32MP257F-EV1: USB gadget (UVC) never attaches on CN15 — dwc3 stuck in device mode but DCTL.RUN_STOP never set despite correct Type-C/UCSI neg
Board: STM32MP257F-EV1
Image: FLASH-stm32mp2-openstlinux-6.6-yocto-scarthgap-mpu-v26.06.10
Kernel: Linux 6.6.129
USB port: CN15 (USB_DRD, Type-C)
I'm trying to run a USB gadget (UVC, via configfs/libcomposite) on CN15, and
the UDC never attaches, even though every layer up to dwc3's pullup step
looks correct:
- Type-C/UCSI (M33 firmware USBPD_DRP_UCSI_CM33_NonSecure_stripped.elf,
ucsi-stm32g0-i2c driver) correctly negotiates the port as UFP/device:
/sys/class/typec/port0/data_role = host [device]
/sys/class/typec/port0/power_role = source [sink]
A partner is detected, and the UCSI power-supply object confirms VBUS at
5V. This all live-updates correctly on physical cable unplug/replug.
- dwc3 correctly switches to device mode:
/sys/kernel/debug/usb/48300000.usb/mode → "device"
- But the pullup never actually happens:
/sys/class/udc/48300000.usb/state stays "not attached" indefinitely
Manually retrying via soft_connect just logs "UDC had already started" —
the UDC core believes the connect step already ran, but the hardware
register was never actually written.
I reproduced this identically across several devicetree configurations
(static role-switch-default-mode="peripheral" with the Type-C controller
disabled, dynamic UCSI-only, and both combined) — same result every time,
which rules out a devicetree/overlay misconfiguration on my end.
Questions:
1. Is there a known issue in the dwc3-stm32 glue driver (or the
USBPD_DRP_UCSI_CM33 firmware's notification path) on kernel 6.6.129 /
OpenSTLinux v26.06.10 preventing dwc3_gadget_pullup()/DCTL.RUN_STOP from
being asserted after a successful Type-C role switch to device?
2. Is the M33 UCSI firmware required for USB2 peripheral-mode gadget
operation on CN15, or should the static role-switch-default-mode path
work standalone?
3. Is there a newer OpenSTLinux release that addresses this?
