usb: device_next: Cherry-pick USB fixes #2283
Merged
+136
−28
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Cherry-picked some more commits as requested by @tmon-nordic |
jfischer-no
approved these changes
Nov 20, 2024
MarekPieta
force-pushed
the
nrf_udc_fixes
branch
from
9d68ff6
to
a9e0be8
Compare
|
Rebased |
tmon-nordic
approved these changes
Nov 21, 2024
Set Address behavior is not specified when wValue is greater than 127, or if wIndex or wLength are non-zero. USB stack did check wValue and wLength but didn't care about wIndex value. Extend the check so non-zero wIndex also results in STALL response. Signed-off-by: Tomasz Moń <[email protected]> (cherry picked from commit 54dc01153caa38de6f6065b74768bcc766879a82)
USBD peripheral automatically handles Set Address command which can lead to state mismatch between USB stack and the host. Keep track of device address and issue fake Set Address commands on mismatch. This fixes default vs addressed state mismatch that can occur due to sufficently high SETUP handling latency. The state mismatch was most commonly seen as SET CONFIGURATION failure when the enumeration happened during periods with increased latency. Signed-off-by: Tomasz Moń <[email protected]> (cherry picked from commit e3acf5fa043af0e8ac9cc911b224be6fc58613dd)
DWC2 otg OUT transfers are being used for SETUP DATA0, OUT Data Stage packets and OUT Status Stage ZLP. On High-Speed it is possible for IN Data Stage, OUT Status Stage ZLP and subsequent SETUP DATA0 to happen in very quick succession, making all the three events appear at the same time to the handler thread. The handler thread is picking up next endpoint to handle based on the least significant bit set. When OUT endpoints were on bits 0-15 and IN endpoints were on bits 16-31, the least significant bit policy favored OUT endpoints over IN endpoints. This caused problems in Completer mode (but suprisingly not in Buffer DMA mode) that lead to incorrect control transfer handling. The choice between least significant bit first or most significant bit first is arbitrary. Switching from least to most significant bit first would have resolved the issue. It would also favor higher numbered endpoints over lower numbered endpoints. Swap the order of endpoints in bitmaps to have IN on bits 0-15 and OUT on bits 16-31 to keep handling lower numbered endpoints first and resolve the control transfer handling in Completer mode. Signed-off-by: Tomasz Moń <[email protected]> (cherry picked from commit 94a6b82)
DWC2 peripherals can have TxFIFO sizes configured to any value between 16 and 32768. The value configured during synthesis is the maximum value the software can program. Designs that give full flexibility configure the TxFIFO sizes to value equal to total SPRAM size. Currently DWC2 driver does not have prior knowledge about the endpoints used within available configurations and has to come up with TxFIFO0 value up front. The original approach was to use MAX(16, max allowed). locations. Because DWC2 peripheral cannot have TxFIFO0 with size lower than 16 locations, always the max allowed was used. This logic prevented any IN endpoint other than EP0 on designs that have TxFIFO0 size set to total SPRAM size. Change the logic to MIN(2 * 16, max allowed) to have sufficient memory available on flexible designs and allow simultaneous operation if possible (i.e. when maximum TxFIFO0 size is at least 32). Signed-off-by: Tomasz Moń <[email protected]> (cherry picked from commit 19955f6)
…ith length 0 If the direction of the last setup packet is not to the device but to the host, then the transfer is not a status stage and should be queued. This is not checked and prevents a zero length control IN transfer to the host, e.g. used by the DFU class to indicate the end of the upload process. Signed-off-by: Johann Fischer <[email protected]> (cherry picked from commit 973f914)
MarekPieta
force-pushed
the
nrf_udc_fixes
branch
from
a9e0be8
to
eef9ac9
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR cherry-picks: