On 4/28/2016 11:12 PM, Felipe Balbi wrote: > > 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. > But what if we do? >> 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 ? :-) Not from the gadget driver, at least I don't think so. The gadget driver itself is the one that wants to initiate the soft disconnect. > >> 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. > Ok thanks, that's less confusing than calling them gadgets :) 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
