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! 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. That's what Franck originally asked about: whether a gadget driver would ever queue more than one request in response to a SETUP. > Or 33 bytes and 95 bytes? Linux-USB doesn't combine buffers to > create packets, it would need to check for cases like that too. The gadget driver obviously would have to be smart enough not to split responses anywhere but on packet boundaries. That's specifically why I chose 64 bytes as the length of the first request in my example. (It would also have to be smart enough not to set the ->zero flag for the first request.) > 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. The API certainly doesn't try to rule out all error-prone behaviors. If it did, g_file_storage wouldn't be able to STALL a bulk endpoint! 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? > 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. Alan Stern ------------------------------------------------------- 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
