On Tue, 30 Jun 2015, Peter Chen wrote: > Hi Alan, > > When reading the code (at qh_urb_transaction) about zero-length packet > for EHCI, would you please help me on below questions: > > - I have not found the zero-length qtd prepared for control read (eg, > the transfer size is multiple of wMaxPacketSize), Am I missing > something? The status stage transaction for a control-IN transfer has length 0, but I guess that's not what you mean. Control-IN transfers don't have a zero-length QTD in the data stage because IN transfers _never_ have a zero-length QTD. > - Why the IN transfer doesn't need to prepare zero-length qtd? > In the 2.0 spec, it does not say it is only for OUT. > > Ch 5.7.3 & Ch 5.8.3 > A bulk (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 Right. The host doesn't know beforehand how much data the device will send during an IN transfer. It only knows how much data to expect -- the device might send less than that amount. Therefore the host must prepare QTDs for all the data it expects. Suppose the host expects the device will send 525 bytes. Then it prepares a 525-byte QTD. If the device sends a 512-byte packet followed by a 13-byte packet, all is well. But what if the device wants to send only 512 bytes? Then it sends a 512-byte packet followed by a 0-byte packet. When the host controller sees the 0-byte packet, it knows the transfer is over -- but we still had to prepare a full 525-byte QTD, because we didn't know beforehand that the device would send only 512 bytes. To put it another way, the sender indicates that he will send less data than expected by sending a short packet. If the amount of data he wants to send is _not_ a multiple of the maxpacket size, then nothing special needs to happen. The last packet will automatically be shorter than the maxpacket size. But if the amount of data he wants to send _is_ a multiple of the maxpacket size, then after sending all the data he still needs to send a short packet. Since there is no more data left to send, he is forced to send a zero-length packet. Thus, when the host is the sender (i.e., for an OUT transfer), the host has to send a zero-length packet if the amount of data is shorter than the device expects and is a multiple of the maxpacket size. When the host is the receiver (i.e., for an IN transfer), the _device_ is responsible for sending a zero-length packet -- not the host. > Ch 5.6.4 > An isochronous IN endpoint must return a zero-length packet whenever > data is requested at a faster interval > than the specified interval and data is not available. That's right, but you don't see it in ehci-hcd because for isochronous transfers, the packet lengths are always specified by the class driver in the urb_iso_packet_descriptor structures. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
