Recent versions of the fastboot tool will query the partition type before doing an operation on a partition (such as erase, flash, etc). It will then submit the operation as soon as the response for the partition type is received.
Usually, the MUSB controller will see that the partition type request return status was read by the host at the very same time as the actual operation request is submitted by the host. However, the operation will be read first (int_rx is handled first in musb_interrupt) and after it is completed, the fastboot USB gadget driver will send another return status. Hence, this happens before the musb gadget framework has had a chance to handle the previous acknowledgement that the host read the return status and dequeue the request.
The host will then usually empty the FIFO by the time musb_interrupt gets around handling the return status acknowledgement (for the previous request, this is still on the same musb_interrupt call), so no other interrupt is generated and the most recent return status acknowledgement remains unaccounted for.
It will then be used as a response for the next command, and the proper response for it will be delayed to the next command, and so on.
Dequeuing the previous IN request in the fastboot code ensures that no previous return status remains. It is acceptable to do it since there is no callback to it anyways.
Signed-off-by: Paul Kocialkowski contact@paulk.fr --- drivers/usb/gadget/f_fastboot.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index b9a9099..60c846d 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -311,6 +311,9 @@ static int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
memcpy(in_req->buf, buffer, buffer_size); in_req->length = buffer_size; + + usb_ep_dequeue(fastboot_func->in_ep, in_req); + ret = usb_ep_queue(fastboot_func->in_ep, in_req, 0); if (ret) printf("Error %d on queue\n", ret);