On Wed, Aug 27, 2014 at 03:29:20PM -0500, Felipe Balbi wrote: > On Wed, Aug 27, 2014 at 04:20:25PM -0400, Alan Stern wrote: > > On Wed, 27 Aug 2014, Felipe Balbi wrote: > > > > > > Hi Alan & Felipe, > > > > > > > > During the changing UDC drivers process, I find we can't simply move > > > > usb_gadget_disconnect to usb_gadget_driver.disconnect, some UDC > > > > drivers (like dwc3) will be no chance to set software pullup bit > > > > (dp control always means software dp pullup bit if no specific at below) > > > > again between disconnection and re-connection. > > > > > > > > > that's why we never had a ->reset() callback so far. From a gadget > > > driver perspective, it's the same as disconnect followed by a connect. > > > > > > > At the second patchset, we introduce the flag pullup_on_vbus, connect API > > > > at usb_gadget_driver, change the disconnect implementation at > > > > each gadget driver, and add control dp through function driver. > > > > > > IIRC, only mass storage gadget was showing a need for a ->reset() > > > callback, why would you need to modify every gadget driver ? > > > > The mass-storage gadget is a function driver, not a gadget driver. > > Even g_mass_storage.c is simply a single-function wrapper; it still > > relies on the composite layer. > > > > There are only four gadget drivers in the tree: composite, configfs, > > gadgetfs, and dbgp. > > right, but those are the only ones which should be modified. For all > gadget drivers which are composed of function drivers (even single > function drivers) they should rely on the function knowing what to do, > otherwise we might still mistakenly connect to the host when some > userspace daemon isn't ready yet. > Yes, like Alan said, we only need to modify above four gadget drivers for changing dp pullup strategies, other legacy drivers will rely on their function drivers. -- Best Regards, Peter Chen -- 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
