-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USBUS: Add URB support #17091
USBUS: Add URB support #17091
Conversation
16a98b1
to
4b9278a
Compare
4b9278a
to
963f7dd
Compare
rebased, no longer waiting for other PRs |
It is useful for any kind of data transfer over USB where the payload to be transferred is larger than the maximum endpoint size (64 bytes) and must be split into multiple transfers. The URB code here moves the state machine that would have to be implemented by the class code into the main USBUS code by allowing to submit a single URB with a length larger than what the underlying endpoint can handle in a single transfer and be notified only when the whole set of transfers have been completed.
The CDC ECM code makes use of this to receive the full ethernet frame from the host with a single call to usbus. I expect that one to still work. I haven't found a good test case yet for IN type transfers testing the ZLP functionality. I haven't found other use cases so far, but I've heard that @dylad might want to use this for his msc implementation. |
One day, I swear, I will update this PR... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please squash
cdb4c3d
to
703dc6e
Compare
703dc6e
to
f9a11bf
Compare
Squashed, thanks for the fixups |
still needs a rebase |
This commit adds support for URBs (USB Request/Response Blocks). These allow for submitting multi-transfer sized buffers with USBUS handling the individual usbdev xmits. Multiple URBs can be queued at once for a single endpoint and USBUS will handle them in the order of submission. OUT endpoint URBs must always consist of a whole number of full-sized transfers (N x MaxEndpointSize). They will automatically finish after the endpoint received a transfer less than the endpoint size. IN endpoints can be arbitrary-sized and do not have to consist of a whole number of full-sized transmissions. They support a flag to indicate that the last transfer in the sequence must be less than a full sized transfer (USBUS_URB_FLAG_AUTO_ZLP) and this adds a zero length transfer at the end of the transmissions if the last transfer was equal to the maximum transfer size. URBs can be cancelled, but if the URB is already being processed it will be cancelled after the current transmission within the URB is finished. If it is still in the queue it will immediately be removed from the queue.
f9a11bf
to
ba88608
Compare
And rebased |
Bors merge |
Build succeeded: |
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=kaspar030 a=gschorcht ### Contribution description This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device. #### Background In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work. #### Solution Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert. ### Testing procedure 1. Green CI 2. Compilation of ```python USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm ``` should lead to compilation error ```python sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded" _Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS, ^~~~~~~~~~~~~~ Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed ``` while compilation of ``` USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm ``` should work. ### Issues/PRs references Fixes issue #19359 partially. 19382: tests/pkg_nanors: use static allocation r=kaspar030 a=benpicco 19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=kaspar030 a=gschorcht ### Contribution description This PR disables the DMA mode for HS cores due to several problems found: - The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in #17085 (comment) - The Enumeration fails for CDC ECM interface which uses URB support (PR #17091) ### Testing procedure Use a STM32 board with USH OTG HS interface: ```python USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash ``` Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`) ```python [377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd [377629.854349] usb 1-2.3: device descriptor read/all, error -71 [377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd [377630.038261] usb 1-2.3: device descriptor read/all, error -71 [377630.038711] usb 1-2-port3: attempt power cycle [377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd [377630.666066] usb 1-2.3: device descriptor read/8, error -71 [377630.794076] usb 1-2.3: device descriptor read/8, error -71 [377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd [377631.002092] usb 1-2.3: device descriptor read/8, error -71 [377631.130091] usb 1-2.3: device descriptor read/8, error -71 [377631.238344] usb 1-2-port3: unable to enumerate USB device ``` or the enumeration of the CDC ECM interface stops with error. ```python [377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd [377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [377972.929230] usb 1-2.3: Product: stm32f723e-disco [377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org [377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32 [377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd ``` With this PR the enumeration should work as it should: ```python [378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd [378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd [378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [378484.395301] usb 1-2.3: Product: stm32f723e-disco [378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org [378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba [378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0 ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <gunar@schorcht.net> Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=kaspar030 a=gschorcht ### Contribution description This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device. #### Background In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work. #### Solution Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert. ### Testing procedure 1. Green CI 2. Compilation of ```python USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm ``` should lead to compilation error ```python sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded" _Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS, ^~~~~~~~~~~~~~ Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed ``` while compilation of ``` USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm ``` should work. ### Issues/PRs references Fixes issue #19359 partially. 19382: tests/pkg_nanors: use static allocation r=kaspar030 a=benpicco 19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=kaspar030 a=gschorcht ### Contribution description This PR disables the DMA mode for HS cores due to several problems found: - The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in #17085 (comment) - The Enumeration fails for CDC ECM interface which uses URB support (PR #17091) ### Testing procedure Use a STM32 board with USH OTG HS interface: ```python USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash ``` Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`) ```python [377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd [377629.854349] usb 1-2.3: device descriptor read/all, error -71 [377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd [377630.038261] usb 1-2.3: device descriptor read/all, error -71 [377630.038711] usb 1-2-port3: attempt power cycle [377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd [377630.666066] usb 1-2.3: device descriptor read/8, error -71 [377630.794076] usb 1-2.3: device descriptor read/8, error -71 [377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd [377631.002092] usb 1-2.3: device descriptor read/8, error -71 [377631.130091] usb 1-2.3: device descriptor read/8, error -71 [377631.238344] usb 1-2-port3: unable to enumerate USB device ``` or the enumeration of the CDC ECM interface stops with error. ```python [377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd [377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [377972.929230] usb 1-2.3: Product: stm32f723e-disco [377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org [377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32 [377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd ``` With this PR the enumeration should work as it should: ```python [378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd [378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd [378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [378484.395301] usb 1-2.3: Product: stm32f723e-disco [378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org [378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba [378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0 ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <gunar@schorcht.net> Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=kaspar030 a=gschorcht ### Contribution description This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device. #### Background In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work. #### Solution Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert. ### Testing procedure 1. Green CI 2. Compilation of ```python USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm ``` should lead to compilation error ```python sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded" _Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS, ^~~~~~~~~~~~~~ Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed ``` while compilation of ``` USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm ``` should work. ### Issues/PRs references Fixes issue #19359 partially. 19382: tests/pkg_nanors: use static allocation r=kaspar030 a=benpicco 19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=kaspar030 a=gschorcht ### Contribution description This PR disables the DMA mode for HS cores due to several problems found: - The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in #17085 (comment) - The Enumeration fails for CDC ECM interface which uses URB support (PR #17091) ### Testing procedure Use a STM32 board with USH OTG HS interface: ```python USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash ``` Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`) ```python [377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd [377629.854349] usb 1-2.3: device descriptor read/all, error -71 [377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd [377630.038261] usb 1-2.3: device descriptor read/all, error -71 [377630.038711] usb 1-2-port3: attempt power cycle [377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd [377630.666066] usb 1-2.3: device descriptor read/8, error -71 [377630.794076] usb 1-2.3: device descriptor read/8, error -71 [377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd [377631.002092] usb 1-2.3: device descriptor read/8, error -71 [377631.130091] usb 1-2.3: device descriptor read/8, error -71 [377631.238344] usb 1-2-port3: unable to enumerate USB device ``` or the enumeration of the CDC ECM interface stops with error. ```python [377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd [377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [377972.929230] usb 1-2.3: Product: stm32f723e-disco [377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org [377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32 [377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd ``` With this PR the enumeration should work as it should: ```python [378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd [378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd [378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [378484.395301] usb 1-2.3: Product: stm32f723e-disco [378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org [378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba [378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0 ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <gunar@schorcht.net> Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=gschorcht a=gschorcht ### Contribution description This PR disables the DMA mode for HS cores due to several problems found: - The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in #17085 (comment) - The Enumeration fails for CDC ECM interface which uses URB support (PR #17091) ### Testing procedure Use a STM32 board with USH OTG HS interface: ```python USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash ``` Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`) ```python [377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd [377629.854349] usb 1-2.3: device descriptor read/all, error -71 [377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd [377630.038261] usb 1-2.3: device descriptor read/all, error -71 [377630.038711] usb 1-2-port3: attempt power cycle [377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd [377630.666066] usb 1-2.3: device descriptor read/8, error -71 [377630.794076] usb 1-2.3: device descriptor read/8, error -71 [377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd [377631.002092] usb 1-2.3: device descriptor read/8, error -71 [377631.130091] usb 1-2.3: device descriptor read/8, error -71 [377631.238344] usb 1-2-port3: unable to enumerate USB device ``` or the enumeration of the CDC ECM interface stops with error. ```python [377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd [377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [377972.929230] usb 1-2.3: Product: stm32f723e-disco [377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org [377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32 [377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd ``` With this PR the enumeration should work as it should: ```python [378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd [378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd [378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 [378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00 [378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [378484.395301] usb 1-2.3: Product: stm32f723e-disco [378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org [378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B [378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device [378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba [378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0 ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
void usbus_urb_submit(usbus_t *usbus, usbus_endpoint_t *endpoint, usbus_urb_t *urb) | ||
{ | ||
(void)usbus; | ||
assert(!(clist_find(&endpoint->urb_list, &urb->list))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assertion triggers when the host reboots #19663 😕
Contribution description
This commit adds support for URBs (USB Request/Response Blocks). These
allow for submitting multi-transfer sized buffers with USBUS handling
the individual usbdev xmits. Multiple URBs can be queued at once for a
single endpoint and USBUS will handle them in the order of submission.
OUT endpoint URBs must always consist of a whole number of full-sized
transfers (N x MaxEndpointSize). They will automatically finish after
the endpoint received a transfer less than the endpoint size.
IN endpoints can be arbitrary-sized and do not have to consist of a
whole number of full-sized transmissions. They support a flag to
indicate that the last transfer in the sequence must be less than a full
sized transfer (USBUS_URB_FLAG_AUTO_ZLP) and this adds a zero length
transfer at the end of the transmissions if the last transfer was equal
to the maximum transfer size.
URBs can be cancelled, but if the URB is already being processed it will
be cancelled after the current transmission within the URB is finished.
If it is still in the queue it will immediately be removed from the
queue.
Testing procedure
tests/usbus_cdc_ecm
should still work. Testing one of the usbdev-supported platform should be sufficient here.Issues/PRs references
Needs #17064