Hi Thinh, I'm only getting back to this now. Thank you for your insights, they were very helpful! I've added linux-samsung-soc@ as remaining issues might be specific to Exynos, see below. On Tue, 2024-08-13 at 23:06 +0000, Thinh Nguyen wrote: > On Mon, Aug 12, 2024, André Draszik wrote: > > Hi Thinh, > > > > On Fri, 2024-08-09 at 23:10 +0000, Thinh Nguyen wrote: > > > On Fri, Aug 09, 2024, André Draszik wrote: > > > > > > > Which part of the stack should be responsible / the entry point for > > > > triggering > > > > the dequeuing? > > > > > > When there's a disconnect, the UDC driver will notify the gadget > > > driver > > > via the gadget driver's disconnect() callback. The gadget driver is > > > supposed to do the teardown and cleanup. This includes disabling > > > active > > > endpoints. If the gadget driver disables the endpoint, then all the > > > active requests will be returned properly. Check documentation on > > > usb_ep_disable() for more info. > > > > Thank you Thinh for that. > > > > I think the problem I'm having is that nothing is actually detecting > > the disconnect. Based on the above, I believe I should get a > > dwc3_gadget_interrupt() with event->type == DWC3_DEVICE_EVENT_DISCONNECT > > as the entry point for the disconnect sequence? > > Ok. > > > > > This doesn't happen, I just get one interrupt and there is just one > > event with type == 6 (DWC3_DEVICE_EVENT_SUSPEND), see attached trace. > > > > In this trace, I've configured a network interface using CDC_ECM, and > > then > > am disconnecting the USB cable @ ~158 > > > > Any idea what could be the reason? For testing, I've also added > > > > snps,dis-u1-entry-quirk; > > snps,dis-u2-entry-quirk; > > You're limitting the gadget driver to operate in usb2 speed, so > disabling U1/U2 won't do anything. > > > snps,usb2-gadget-lpm-disable; > > > > to my DT, but that doesn't seem to make a difference. > > > > > > > > > If you don't see a disconnect event, check your connector. Check the > logic for vbus detection of your connector and see why it did not clear > the vbusvalid signal properly on disconnect. Looks like you're using > UTMI, check your utmisrp_bvalid or utmiotg_vbusvalid signal on > disconnect. I'm a little bit further, thanks to your pointers Thinh. So in my case, vbus is not connected to the DWC3 (or phy) directly. It looks like we can trigger a few signals via certain bits in the phy, though: UTMICTRL register: force_vbusvalid [5] RW Overriding vbusvalid signal force_bvalid [4] RW Overriding bvalid signal HSPCTRL register: VBUSVLDEXTSEL [13] RW External VBUS valid select VBUSVLDEXT [12] RW External VBUS valid indicator To make things work at all, the Exynos phy driver forces all 4 to be enabled during init. If I clear three of them (force_bvalid force_vbusvalid VBUSVLDEXT) on USB cable disconnect, I observe the expected DWC3_DEVICE_EVENT_DISCONNECT interrupt, and the stack shuts everything down. So far so good. Unfortunately, this only works once: After restoring those bits and reconnecting the cable, USB comes up as expected, but a subsequent disconnect with the same sequence as during the first disconnect doesn't trigger the DWC3_DEVICE_EVENT_DISCONNECT event anymore (others still happen, like DWC3_DEVICE_EVENT_SUSPEND). Kinda looks to me like either I'm still missing something, or e.g. the event is somehow masked. I anybody aware of anything related by any chance? Thanks! Andre
