On Tuesday 21 March 2006 9:08 am, Alan Stern wrote: > On Tue, 21 Mar 2006, Franck Bui-Huu wrote: > > > IMHO, sometimes it's pretty hard to know how things should be done > > that is what should be part of the gadget driver or part of the UDC > > driver. > > For a gadget driver author it's not hard at all. You simply assume that > the UDC driver does no more than what the Gadget API says it has to.
That's a good rule for any API specification. Note that not all Linux kernel APIs are very well specified ... we've tried to turn the Linux-USB stack into something well specified, since that's one of the best ways to make driver stack(s) be robust. > That's the only assumption you can make, because some UDC drivers do > indeed implement nothing more than this minimal functionality. > > For a UDC driver author there's more freedom. You can implement a minimal > driver or add some extra features. However, there's no point in adding a > feature that would (for example) disable all endpoints when a > Set-Configuration request is received. Since every gadget driver has to > disable them anyway, it would be a waste of time for the UDC driver to do > it. There is however some hardware which -- very annoyingly -- tries to take over some parts of configuration management. To paraphrase, "it would be a waste of time for the hardware to do it". But for some reason that's exactly the policy adopted by Intel PXA 25x and PXA 27x silicon; it's quite annoying, because it multiplies the opportunity for hardware bugs. (An opportunity, need I point out?, which has been well abused.) Which is why the peripheral controller (UDC) driver is allowed to disable the endpoints on SET_CONFIGURATION or SET_INTERFACE, and the gadget driver must tolerate such things: there's no alternative on some hardware. - Dave ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
