On Wed, Sep 03, 2014 at 01:53:23PM -0400, Alan Stern wrote:
> On Wed, 3 Sep 2014, Peter Chen wrote:
>
> > > Okay. Let's start by adding the reset field to struct
> > > usb_gadget_driver. The initial implementation in the four gadget
> > > drivers can be very simple: It calls the disconnect handler. (At some
> > > later time we can add a ->reset callback to struct
> > > usb_composite_driver; then the reset handler in composite.c can invoke
> > > that callback for all function drivers that define it.)
> > >
> > > Next, add routines to udc-core to handle Vbus changes, function
> > > activation changes, and resets. The Vbus routine will invoke the
> > > gadget driver's ->disconnect callback when Vbus goes off and then call
> > > usb_gadget_disconnect. The activation routine will call
> > > usb_gadget_disconnect if any functions are deactivated, and
> > > usb_gadget_connect if all the functions are activated (basically, do
> > > whatever composite.c would do). And the reset routine will invoke the
> > > gadget driver's ->reset callback. I suppose we'll also have to add
> > > fields to struct usb_gadget, to store the current Vbus and activation
> > > statuses.
> >
> > If the usb_gadget_disconnect will be not called at gadget driver's
> > ->disconnect, it has no much meaning we still have gadget driver's
> > ->reset, since the content of its ->disconnect and ->reset are the
> > same if we don't consider to add function's reset handler.
>
> No, they aren't always the same. For example, g_mass_storage ought to
> flush its dirty buffers when a disconnect occurs, but it doesn't have
> to flush them when a reset occurs.
>
> > > Then modify all the UDC drivers; make them invoke the new udc-core
> > > routines whenever there's a change in Vbus status or a reset, instead
> > > of invoking the gadget driver's callbacks directly. At the same time
> > > we can remove the code that turns off the pullup when Vbus
> > > goes down, because now the udc-core routine will take care of it.
> >
> > Why we need to record the reset at udc-core?
>
> We don't really need to. But it seems like a good idea to have events
> that affect the entire device (including connect, disconnect, reset,
> and probably also bus suspend and bus resume) all pass through
> udc-core.
>
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.
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.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
