Repository navigation
shared/tinyusb: Fix dynamic USB control callbacks for wLength==0. - #14253
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
|
@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 |
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 <[email protected]>
f2d7ce0 to
d11ca09
Compare
|
I tested this with a DFU device that I wrote in Python using |
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.