From b5d9913241046764855ed49450dfed51dbf309a3 Mon Sep 17 00:00:00 2001 From: Vincent Palatin Date: Wed, 13 Sep 2017 18:05:08 +0200 Subject: [PATCH] g: fix short packets on USB control endpoint In the USB 2.0 specification, the "8.5.3 Control Transfers" chapter says that "When all of the data structure is returned to the host, the function should indicate that the Data stage is ended by returning a packet that is shorter than the MaxPacketSize for the pipe. If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function will return a zero-length packet to indicate the end of the Data stage." When doing a 'Control Read' transfer and the returned data (in IN packets) was a multiple of MaxPacketSize, we were omitting the zero-length packet and so the host was blocked waiting for a successful IN transaction. This corner-case was a regression introduced by the re-writing of the control transfer handling done by CL 318864. So the STM32 USB code which is similar to the former code is dealing properly with this case. Signed-off-by: Vincent Palatin BRANCH=cr50 BUG=none TEST=manual, extend the configuration descriptor to be exactly 64 bytes, and see the enumeration is no longer failing. Change-Id: I108e8c6bb9eb727c41f3e1c607f0919fa1192d5a Reviewed-on: https://chromium-review.googlesource.com/664814 Commit-Ready: Vincent Palatin Tested-by: Vincent Palatin Reviewed-by: Marius Schilder Reviewed-by: Vadim Bendebury Reviewed-by: Shawn N --- chip/g/usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chip/g/usb.c b/chip/g/usb.c index 5f5e595e4b..532128dc24 100644 --- a/chip/g/usb.c +++ b/chip/g/usb.c @@ -388,7 +388,7 @@ static void got_RX_packet(void) int load_in_fifo(const void *source, uint32_t len) { uint8_t *buffer = ep0_in_buf; - int zero_packet = !len; + int zero_packet = (len % USB_MAX_PACKET_SIZE) == 0; int d, l; /* Copy the data into our FIFO buffer */