Hi, On Wed, Aug 13, 2014 at 10:02:08AM -0400, Alan Stern wrote: > > > So here's what the UDC driver should do: If the pullup routine is called > > > while Vbus is off, the driver should leave the D+ pullup disconnected but > > > remember the call. Then when Vbus gets turned on, the driver should > > > activate the pullup. > > > > > > In other words, the UDC driver should keep track of the pullup's > > > "logical" state. When Vbus is off, the pullup must also be off. When > > > Vbus is on, the pullup's physical state should be the same as the logical > > > state. > > > > > > > We had a similar discussion at last year, but Felipe " don't want to let UDC > > drivers call usb_gadget_connect()/disconnect() directly." > > All right, let's see what Felipe says about my suggestion.
Keeping track of the pullup's state like that will just add complexity to the UDC drivers. There's really no problem in connecting pullups before VBUS is above session valid threshold. The whole idea of udc-core was to handle those details generically so we don't have to patch every single UDC driver. The best solution, IMO, would be to teach every function about activate/deactivate and only connect pullups based on that. So that functions, and only functions, are responsible for managing pullups. Functions which don't need to wait for userspace can just call usb_function_activate() from their bind() method, while functions relying on userspace can do so when the devnode is opened or whatever. -- balbi
signature.asc
Description: Digital signature
