Hi, John Youn <John.Youn@xxxxxxxxxxxx> writes: >> "Du, Changbin" <changbin.du@xxxxxxxxx> writes: >>> Hi, Balbi, >>> >>> The step to reproduce this issue is: >>> 1) connect device to a host and wait its enumeration. >>> 2) trigger software disconnect by calling function >>> usb_gadget_disconnect(), which finally call >>> dwc3_gadget_pullup(false). Do not reconnect device >>> (I mean no enumeration go on, keep bit Run/Stop 0.). >>> >>> At here, gadget driver's disconnect callback should be >>> Called, right? We has been disconnected. But no, as >>> You said " not generating disconnect IRQ after you >>> drop Run/Stop is expected". >>> >>> And I am testing on an Android device, Android only >>> use dwc3_gadget_pullup(false) to issue a soft disconnection. >>> This confused user that the UI still show usb as connected >>> State, caused by missing a disconnect event. >> >> okay, so I know what this is. This is caused by Android gadget itself >> not notifying the gadget that a disconnect has happened. Just look at >> udc-core's soft_connect implementation for the sysfs interface, and >> you'll see what I mean. >> >> This should be fixed at Android gadget itself. The only thing we could >> do is introduce a new usb_gadget_soft_connect()/disconnect() to wrap the >> logic so it's easier for Android gadget to use; but even that I'm a >> little bit reluctant to do because Android should be using our >> soft_connect interface instead of reimplementing it (wrongly) by its >> own. >> > > We've run in to the same issue with our usb_gadget_driver. > > If the usb_gadget_disconnect() API function, which seems like it is > intended to be called by the gadget_driver, does cause the gadget to > disconnect, it seems reasonable to expect the gadget or the UDC core > to notify the gadget_driver via the callback. Well, the API is supposed to disconnect D+ pullup and that's about it. > As you mentioned this is handled in the soft_disconnect sysfs. Why > shouldn't usb_gadget_disconnect() do the same thing, if not the gadget because there might be cases where we don't need/want the gadget to know about this disconnect. > itself? Exposing the sysfs as an API function would work too. Though it already _is_ exported. I just don't know why people are re-inventing the same solution :-) > both functions are "soft" disconnects and both are called > "disconnect". > > In our gadget_driver we do the workaround where we notify ourself that > we called the usb_gadget_disconnect() and that we should now be you could just rely on the sysfs interface, right ? :-) > disconnected. It just seems more correct that we shouldn't have to > handle that. > > By the way, I'm not completely sure of the correct terminology, but > I'm referring to the struct usb_gadget (dwc3, dwc2, etc) as the > "gadget" and the struct usb_gadget_driver as the "gadget_driver" > (normally this would be the composite gadget framework, but we are > using our own driver in this case). Is there a less confusing way to > refer to these :) what I've been doing is that I refer to dwc3, dwc3, etc as UDC (as in USB Device Controller) and g_mass_storage, g_ether, g_zero, etc as gadget driver. -- balbi
Attachment:
signature.asc
Description: PGP signature
