Hi, Peter Chen <hzpeterchen@xxxxxxxxx> writes: >> Peter Chen <hzpeterchen@xxxxxxxxx> 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. >> >> >> > >> > If it is a gadget driver, it can call its disconnect explicitly. >> > Another thing is the gadget driver should not call usb_gadget_disconnect >> > directly, it should call usb_gadget_deactivate or usb_function_deactivate. >> > >> > Since currently, calling usb_gadget_disconnect may not do real pull down >> > dp, Felipe, will you consider adding gadget_driver->disconnect into >> > usb_gadget_disconnect after pull down dp? >> >> this is the detail that I'm not yet entirely sure is always valid. Would >> there ever be a situation where we want to drop pull-ups but not tell >> the gadget about it ? > > Yes, we have. > > - We have enabled pullup dp default for most of platforms, and for > gadget obex and uvc will pull down it since it wants app to > control it > > - Some USB charger detection design may need it for the secondary > detection. > > After checking again for usb_gadget_disconnect and > usb_gadget_disconnect, I think there is no possible that the dp is > still pulled after we call usb_gadget_disconnect, so we don't need > to change anything:) alright, cool. So we'll keep the requirement to call gadget_driver->disconnect() for anybody who calls usb_gadget_disconnect(). Caller should know if we need to notify gadget_driver or not about that disconnect. -- balbi
Attachment:
signature.asc
Description: PGP signature
