Hi, On Thu, Aug 25, 2011 at 02:46:55PM +0200, Michal Nazarewicz wrote: > On Thu, 25 Aug 2011 01:04:19 +0200, Felipe Balbi <balbi@xxxxxx> wrote: > >there's one catch. As of today, we always start UDCs with data pullups > >connected, which means that we could connect to a host even before a > >gadget driver is loaded. My point in moving to udc_start/udc_stop is > >that the above would be take care of. See udc-core.c: [...] > > Honestly I'm not quite sure why udc_start/udc_stop is needed here. Even > without those the UDC driver can start with all hw disabled and turn it > on only after the gadget driver's bind callback finishes. > > >If all UDCs are converted to udc_start()/udc_stop() we get the guarantee > >that they will only conect to host after gadget driver is fully loaded > >for free. > > >We can also, finally, properly use the usb_function_deactivate/ > >usb_function_activate properly. So for each registered function, > >composite.c calls usb_function_deactivate() and function is _required_ > >to call usb_function_activate when it's ready. > > I'm not really sure why that would be beneficial. Also, it would still > require disconnect-connect cycle if some function decides to (de)activate > itself while gadget is connected. > > >Then, when on gadget driver's bind() we can take this kind of speed > >decision and pass that on to UDC driver. > > So can we leave things as they are for now and wait for UDCs to be > converted > and once this is done, do all kinds of magic we want in copomiset's bind > callback? sure. -- balbi
Attachment:
signature.asc
Description: Digital signature
