On 4/27/2016 11:48 PM, Felipe Balbi wrote: > > Hi, > > (we don't top-post on this forum ;-) > > "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. 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 itself? Exposing the sysfs as an API function would work too. Though 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 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 :) John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
