On Thu, 21 Aug 2003, David Brownell wrote: > Alan Stern wrote: > > David: > > > > It's not clear how the gadget API handles the data and status stages of a > > control transfer. The impression I have is that the queued requests are > > bi-directional; the gadget controller reads the request buffer if it gets > > an IN packet and writes the request buffer if it gets an OUT packet. > > Erm, other way around: IN to the host means the gadget writes (but the > host reads); and OUT to the device means the gadget reads (host writes).
I respectfully disagree: IN to the host means the gadget controller reads data from its request buffer and sends that data to the host. OUT to the device means the gadget controller takes the data coming from the host and writes it into the request buffer. > > But what happens for the status stage? > > It proceeds automatically, unless the gadget driver tells the controller > to stall. We can't get too fancy here because not all hardware gives as > much packet-level control for ep0 as the net2280 does ... we need more > of a "least common denominator" control model here in the API. > > The simplest way a gadget driver tells the controller driver to stall ep0 > is to return an error from the setup() callback ... that's easy when the > request is bogus or unrecognized. That will likely stall the data stage. > > But once the gadget driver writes a buffer IN to the host, the status > stage is committed to succeed. (If it weren't going to succeed, then > there would be no point in providing the IN buffer...) I'm not worried about STALLing a transfer; I'm concerned about when the status for an OUT transfer is sent. Does the controller automatically send the status acknowledgment when it receives an IN PID? Or does it keep track of setup.wLength and only acknowledge after all the OUT data has been received? Or does it wait until the gadget driver queues a request (which should have length 0)? In particular, can the gadget driver delay the status acknowledgment for an OUT transfer? Parts of the CBI specification mention circumstances in which a device might want to do that. See the fourth paragraph of 2.3.1 and the second paragraph of 2.3.2.1 for examples. Implied but not stated explicitly (it _is_ stated explicitly in the Bulk-Only spec) is that the reset command should not be acknowledged until it is complete -- and for CBI the reset command is a non-zero-length OUT control transfer. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
