On Thu, Sep 04, 2014 at 11:04:38AM -0400, Alan Stern wrote:
> On Thu, 4 Sep 2014, Peter Chen wrote:
> 
> > Hi Felipe & Alan, how about using below steps for this reset/vbus/pullup
> > changes? It mainly uses Alan's suggestion.
> > 
> > Step 1:
> >     The initial implementation in the four gadget
> >     drivers can be very simple: It calls the disconnect handler.
> >     the ->reset is mandatory for all gadget drivers (currently,
> >     only four, they are composite, configfs, gadgetfs , dbgp.
> > Step 2:
> >     Add routines to udc-core to handle Vbus changes, function
> >     activation changes, and resets. It will include three sub-steps,
> >     from easy to hard: reset handler, vbus handler, and activation
> >     handler.
> 
> Perhaps the activation handler can be delayed until step 4.  It won't 
> get used until composite.c is modified to call it.
> 
> > Step 3:
> >     Modify all UDCs to call udc-core's reset and vbus handler, delete
> >     usb_gadget_connect/usb_gadget_disconnect operation at all UDC drivers,
> >             and delete invoking usb_gadget_connect unconditional at 
> > udc_bind_to_driver
> > Step 4: 
> >     Modify the composite.c to disable pullup for adding every function, and
> >     enable pullup when necessary.
> 
> Actually, composite.c should be modified to call the activation handler 
> in udc-core, and then _that_ routine would adjust the pullup as 
> necessary.
> 
> This plan is okay with me.
> 

OK, let's put the function activation change to the last. If the Felipe has
no other comments, I will send the patch for step one next Monday. 

-- 
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to