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? nope, nothing bad should happen. > > > 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. 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. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
