On Wed, Aug 13, 2014 at 12:02:05PM -0400, Alan Stern wrote: > On Wed, 13 Aug 2014, Felipe Balbi wrote: > > > 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. > > Except that doing so violates the hardware test suite Peter mentioned. > That was the starting point of this discussion. oh ok. > > 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. > > usb_function_activate() is part of libcomposite. Do we still have any > of the old-style gadgets that don't use libcomposite? Aside from > inode.c, it doesn't look like there are any... > > If you want libcomposite to handle the pullups on behalf of the > function drivers, there has to be a way for the UDC driver to tell > libcomposite when Vbus turns on and off. Add a new callback to the > usb_gadget_driver structure? usb_gadget_driver, why ? We need a way for udc-core to ask the PHY if VBUS is already above session valid threshold. My fear is that we might end up implementing this by polling this PHY method until it's valid. Are we starting to see a need for a kgadgetd which gets awaken on different conditions ? Any other ideas ? -- balbi
Attachment:
signature.asc
Description: Digital signature
