On Tue, 2 Sep 2014, Felipe Balbi wrote: > > That needn't be a problem. If Peter updates the four gadget drivers, > > adding reset callbacks, then we can remove the parts of our patches > > that invoke the disconnect callback if there is no reset callback. In > > other words, we can make reset callbacks mandatory for gadget drivers. > > alright, but we need to do this in steps to avoid regressions or a > non-bisectable tree. So maybe we add ->reset as an optional method, > implement support for it to all UDC drivers, patch all gadget drivers to > implement reset, make reset mandatory. Does that work ? It would be okay, but doing things in a different order would be a little better: Add the reset callback to the usb_gadget_driver structure, implement it in all four gadget drivers, and then implement it in the UDC drivers. That way we don't have to make a second round of modifications to the UDC drivers, removing the fallback calls to ->disconnect for when ->reset is missing. The kerneldoc could state that some UDC drivers may call ->disconnect when a reset occurs, instead of calling ->reset. Then we won't have to fix up all the UDC drivers at once. If you want, you could add a remark to the kerneldoc saying that a disconnect handler generally should do everything that a reset handler does plus perhaps a few additional things. 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
