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. 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. 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 -- 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
