diff options
author | Stephen Warren <swarren@nvidia.com> | 2014-05-29 14:53:03 -0600 |
---|---|---|
committer | Marek Vasut <marex@denx.de> | 2014-06-01 19:22:40 +0200 |
commit | 006c7026882011ba49c9a39d27c4aff3ace07847 (patch) | |
tree | 593719e6f12ae0073bb67cb844ac85ed76b481e8 /post | |
parent | a2d8f929857b7bc50528114c29e48a99cbcee1f1 (diff) | |
download | u-boot-imx-006c7026882011ba49c9a39d27c4aff3ace07847.zip u-boot-imx-006c7026882011ba49c9a39d27c4aff3ace07847.tar.gz u-boot-imx-006c7026882011ba49c9a39d27c4aff3ace07847.tar.bz2 |
usb: ci_udc: complete ep0 direction handling
handle_setup() currently assumes that the response to a Setup transaction
will be an OUT transaction, and any subsequent packet (if any) will be an
IN transaction. This appears to be valid in many cases; both USB
enumeration and Mass Storage work OK with this restriction. However, DFU
uses ep0 to transfer data in both directions. This renders the assumption
invalid; when sending data from device to host, the Data Stage is an IN
transaction, and the Status Stage is an OUT transaction. Enhance
handle_setup() to deduce the correct direction for the USB transactions
based on Setup transaction data.
ep0's request object only needs to be automatically re-queued when the
Data Stage completes, in order to implement the Status Stage. Once the
Status Stage transaction is complete, there is no need to re-queue the
USB request, so don't do that.
Don't sent USB request completion callbacks for Status Stage transactions.
These were queued by ci_udc itself, and only serve to confuse the USB
function code. For example, f_dfu attempts to interpret the 0-length data
buffers for Status Stage transactions as DFU packets. These buffers
contain stale data from the previous transaction. This causes f_dfu to
complain about a sequence number mismatch.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Diffstat (limited to 'post')
0 files changed, 0 insertions, 0 deletions