On Friday 31 March 2006 7:18 am, Alan Stern wrote: > On Thu, 30 Mar 2006, David Brownell wrote: > > > On Thursday 30 March 2006 1:55 pm, Alan Stern wrote: > > > On Thu, 30 Mar 2006, David Brownell wrote: > > > > > > > > Actually, I'd say it's OK to assume that. It's an error if the > > > > gadget driver issues more than one response to a setup() callback, > > > > or issues a response when no setup() is pending. > > > > > > But what if the gadget driver issues a single response in two parts? > > > That > > > is, instead of issuing a single 128-byte response, it queues two 64-byte > > > responses? > > > > Doesn't change anything. How would the gadget driver know that > > there's going to be more than one buffer in the response? It's > > completely legit for wLength to be 128 and issue just 64 bytes... > > This is a non-sequitur. Of course the gadget driver knows how many > buffers will be in the response, because the gadget driver is the code > responsible for creating the response in the first place!
I meant to type "controller driver" not "gadget driver", sorry for the confusion. > And yes, it's legitimate for wLength to be 128 and the response to be only > 64 bytes, but so what? I was pointing out that it's also legitimate for > the response to be 128 bytes, queued as two separate 64-byte requests. No it isn't. A single 128 byte buffer, sure; two separate ones, no. :) The question of how that would work is still open though: if there were two buffers, how would the lower level (controller) driver know? With the current "one response" rule, it's easy to know when the last response comes: there will only ever be one. > > The "one response" rule is simple and easy to implement and > > explain. Anything else would be complex, and thus error prone. > > But there's nothing in the gadget API that says a driver can't split its > response between two buffers. If so that's a doc bug. > I don't see the additional complexity being all that great. UDC drivers > already need the ability to queue multiple requests for endpoints other > than ep0. Why shouldn't they be able to queue multiple requests for ep0 > as well? Getting EP0 code to work correctly is already a huge PITA, and that would increase the complexity. I've written (or debugged) enough of them to know that all too well. > > Plus it'd be rather nonportable. > > Why? Because it relies on splitting only at packet boundaries? Drivers > can portably assume that ep0 maxpacket will always be a divisor of 64. Because all the existing drivers follow the "only one response to a setup packet" rule, and changing that rule would imply creating new tests for them ... as well as changing the API, and re-testing lots of drivers. - 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
