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. > > > > 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? Like I replied at last email, the UDC-A has no chance to pullup dp again after cable has connected if there is no vbus handler to do it (.vbus_session). If we don't no pullup dp, there will be no interrupt, the line state is SE0 after cable has connected. > > > > 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 > -- 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
