Skip to content

shared/tinyusb: Fix dynamic USB control callbacks for wLength==0. #14253

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

Merged

Conversation

projectgus
Copy link
Contributor

In the case where an OUT control transfer triggers with wLength==0 (i.e. all data sent in the SETUP phase, and no additional data phase) the callbacks were previously implemented to return b"" (i.e. an empty buffer for the data phase).

However this didn't actually work as intended because b"" can't provide a RW buffer (needed for OUT transfers with a data phase to write data into), so actually the endpoint would stall.

The symptom was often that the device process the request (if processing it in the SETUP phase when all information was already available), but the host sees the endpoint stall and eventually returns an error.

This commit changes the behaviour so returning True from the SETUP phase of a control transfer queues a zero length status response.

@projectgus projectgus added this to the release-1.23.0 milestone Apr 5, 2024
Copy link

codecov bot commented Apr 5, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.39%. Comparing base (5114f2c) to head (f2d7ce0).
Report is 1 commits behind head on master.

❗ Current head f2d7ce0 differs from pull request most recent head d11ca09. Consider uploading reports for the commit d11ca09 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #14253   +/-   ##
=======================================
  Coverage   98.39%   98.39%           
=======================================
  Files         161      161           
  Lines       21200    21200           
=======================================
  Hits        20860    20860           
  Misses        340      340           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@projectgus
Copy link
Contributor Author

@dpgeorge Have taken the liberty of marking this fix for 1.23. It can be handled on the Python side without a code change, but it's uglier.

(Specifically, without this fix OUT control transfers with wLength==0 need the callback to return bytearray(0). With this change they can return True which makes the Python code a lot easier to follow.)

In the case where an OUT control transfer triggers with wLength==0 (i.e.
all data sent in the SETUP phase, and no additional data phase) the
callbacks were previously implemented to return b"" (i.e. an empty buffer
for the data phase).

However this didn't actually work as intended because b"" can't provide a
RW buffer (needed for OUT transfers with a data phase to write data into),
so actually the endpoint would stall.

The symptom was often that the device process the request (if processing
it in the SETUP phase when all information was already available), but the
host sees the endpoint stall and eventually returns an error.

This commit changes the behaviour so returning True from the SETUP phase of
a control transfer queues a zero length status response.

Signed-off-by: Angus Gratton <angus@redyak.com.au>
@dpgeorge dpgeorge force-pushed the bugfix/usb_device_control_xfer branch from f2d7ce0 to d11ca09 Compare April 17, 2024 03:28
@dpgeorge
Copy link
Member

I tested this with a DFU device that I wrote in Python using machine.USBDevice and it allowed me to simplify my code a little, which did need to handle the case of wLength==0.

@dpgeorge dpgeorge merged commit d11ca09 into micropython:master Apr 17, 2024
@projectgus projectgus deleted the bugfix/usb_device_control_xfer branch April 17, 2024 05:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants