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. > > sorry, can you rephrase this a bit, I really can't get what you mean. > > DWC3 doesn't really have a pullup bit. It's got a RUN/STOP bit. Sure, it > controls the pullups but it also kills the internal DMA and quite a bit > of other internal blocks. > > The way the code is today, we will have a pullup connected when a gadget > driver is loaded and not before that. > > > There are two kinds of UDCs, dp is always pullup(UDC-A), pullup dp relies > > on vbus (UDC-B), so we may need to introduce a flag like pullup_on_vbus > > at struct usb_gadget, UDC-B needs to set this flag at .udc_start. > > > > For the whole gadget life cycle, the dp change for the two kinds of > > UDC like below: > > Process dp at UDC-A dp at UDC-B > > insmod 1 0 > > connect 1 1 > > bus_reset 1 1 > > disconnect 1 0 > > rmmod 0 0 > > > > For insmod/rmmod gadget driver, we can control dp at udc-core relies > > on flag pullup_on_vbus. > > > > For other three stages (no need to control at bus_reset), we can control dp > > at two gadget driver's API relies on flag pullup_on_vbus. > > I also can't get what you mean here. I think Peter is saying that some UDC hardware (which he calls UDC-A) automatically turns off the pullup when Vbus is absent, whereas other hardware (UDC-B) relies on software to do this. I'm not sure why this matters, however. Does anything go wrong if the driver tells UDC-A hardware to turn off the pullup when the cable is unplugged and Vbus goes away? > > Do you agree above? > > > > If you agree, the first patchset for adding reset API at usb_gadget_driver may > > do less thing, and the reset API implementation at each gadget driver is the > > same with disconnect. > > 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. Alan Stern -- 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
