On Mon, 7 Oct 2013, Sarah Sharp wrote: > On Thu, Oct 03, 2013 at 07:18:42PM -0000, hemantk@xxxxxxxxxxxxxx wrote: > > > On Thu, Oct 03, 2013 at 06:00:50PM -0000, hemantk@xxxxxxxxxxxxxx wrote: > > >> We have devices which require to send zero length packet in data stage > > >> to > > >> host in certain cases. We were not seeing any issue when we were using > > >> ehci based controller. When we switched to XHCI here is what we are > > >> observing:- > > >> > > >> For IN DATA dir control xfer XHCI sets ISP so xhci updates actual_length > > >> for short packet in data stage using event->transfer_len. > > >> > > >> But for data packets not short xhci directly uses > > >> urb->transfer_buffer_length as actual_length.This is done assuming data > > >> stage will never have zero length (short packet) data packet. Once > > >> Device > > >> sends zero length packet in data stage > > >> ISP triggers and actual_length is updated with value 0. Then later in > > >> status stage (since urb->actual_length is zero) driver incorrectly sets > > >> actual_length with urb->transfer_buffer_length. > > What should urb->actual_length be set to instead? The device sent zero > bytes in the data stage and urb->transfer_buffer_length *is* zero, so it No, urb->transfer_buffer_length > 0. That's the point. If I understand the OP correctly, he is saying that a 0-length response to (for example) an 8-byte control-in transfer will end up with urb->actual_length set to 8 rather than 0. > makes sense that urb->actual_length would be set to zero. 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
