On Monday 28 November 2005 11:53 am, Alan Stern wrote: > On Mon, 28 Nov 2005, David Brownell wrote: > > > On Monday 21 November 2005 6:00 am, Olav Kongas wrote: > > > > > Suppose, HC requests N bytes of data from device. Suppose, > > > device sends M bytes as a response. The following happens: > > > > > > 1) if M == N; then no zero length packet is sent by device > > > regardless of whether N is multiple of MaxPacketSize or not. > > > That's because the HCD, which requested N bytes of the data, > > > has got all of it. > > > > That "regardless" is incorrect. It's appropriate for the data > > stage of control transfers, but for e.g. bulk or interrupt > > transfers the peripheral's protocol may say otherwise. > > I disagree. The USB spec isn't as clear on this as it could be, but still > section 5.7.3 says: > > An interrupt transfer is complete when the endpoint does > one of the following: > > . Has transferred exactly the amount of data expected > > . Transfers a packet with a payload size less than wMaxPacketSize > or transfers a zero-length packet
And in terms of the USB spec, "interrupt transfer" is a single schedule segment, e.g. one frame at full speed. Yes? It doesn't talk about "URB". So what I said is fully compatible with an "urb->transfer_length" that may consist of multiple transfer segments. Even if that spec talks about an "interrupt transfer" which can take several frames. > Section 5.8.3 says the same thing about bulk transfers. When M == N the > first case applies; the transfer is complete _before_ a zero-length packet > could be sent. The spec doesn't make allowances for class-specific > protocol exceptions. Neither does it talk about "URB" at all. And the way specs are normally interpreted, it would take a "device protocols MUST NOT..." statement to disallow the conventional usage of zero length packets. > > Same thing ... this is specific to the protocol. Sometimes > > protocols specify that ALL transfers are terminated by a > > short packet. When that's the case, and M is an integral > > multiple of the packet size, that means a zero length packet > > must be sent. > > Such protocols would appear to be in violation of the USB specification. > These things do happen, of course. And there are devices that violate > both the spec and their class protocol. I don't see any violation ... the behaviors described in the USB spec are implemented, but that spec does not cover protocol policy questions like how to build "higher level" transfers out of several "lower level" ones. One example of a class spec that requires use of ZLPs in the usual way is the CDC Ethernet class. A 1024 byte Ethernet frame is encapsulated by a number of full-length packets (at high speed, two), followed by a zero length packet. Of course _in practice_ there's a lot of hardware and software that mis-handles ZLPs, so the Linux CDC-Ethernet code won't issue them; it adds an extra byte at the end of the packet. - Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
