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. BR, Thinh
