On Tue, Sep 02, 2014 at 03:25:05PM -0400, Alan Stern wrote: > On Tue, 2 Sep 2014, Felipe Balbi wrote: > > > > You know, more and more it seems like this ought to be handled by the > > > UDC core. There are two conditions for turning on the pullup: Vbus > > > must be active, and the gadget's functions must all be activated. The > > > UDC driver knows about the first and the gadget driver knows about the > > > second -- so the UDC core is where those two pieces of knowledge should > > > be brought together. > > > > I'll agree with this, 100%. > > > > > That might be more of a change than you want to make, however... > > > > I wouldn't say that. As long as regressions can be avoided, I have no > > issues modifying the framework and every single driver :-) I guess we > > won't be able to do everything in one go, however, so we might need to > > split this accross two merge windows to give people time to test all the > > changes. > > Do we need a ->connect callback in the gadget drivers? If the UDC core > does all the work of tracking the connection status, maybe we don't. > For now, I'll assume we don't need it. > > 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. > > 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? > > They don't all have to be updated at once. Unchanged UDC drivers will > continue to work exactly as before, because they will bypass the new > code in udc-core. > > How does that sound? > > Alan Stern > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
