The USB core reuses the I/O buffer space occupied by the USB setup packet to hold the completion status for message transfers, assuming that the message() method will always strip the setup packet before returning. This assumption is correct for all of the hardware controller drivers (XHCI, EHCI, and UHCI), since these drivers are able to enqueue the transfer as a separate action from waiting for the transfer to complete. The EFI_USB_IO_PROTOCOL does not allow us to separate actions in this way: there is only a single blocking method that both enqueues and waits for completion. Our usbio driver therefore currently defers stripping the setup packet until the control endpoint is polled. This causes a bug if a message transfer is enqueued but never polled and is subsequently cancelled, since the cancellation will be reported with the I/O buffer still containing the setup packet. This breaks the assumption that the setup packet has been stripped, and triggers an assertion failure in usb_control_complete(). Fix by always stripping the setup packet in usbio_endpoint_message(), and adjusting usbio_control_poll() to match. Signed-off-by: Michael Brown <mcb30@ipxe.org>tags/v1.20.1
|
|
||
351 |
|
351 |
|
352 |
|
352 |
|
353 |
|
353 |
|
354 |
|
|
|
355 |
|
|
|
|
354 |
|
|
356 |
|
355 |
|
357 |
|
356 |
|
358 |
|
357 |
|
|
|
||
995 |
|
994 |
|
996 |
|
995 |
|
997 |
|
996 |
|
|
997 |
|
|
|
998 |
|
|
|
999 |
|
|
|
1000 |
|
|
|
1001 |
|
|
998 |
|
1002 |
|
999 |
|
1003 |
|
1000 |
|
1004 |
|