Should tud_control_status consider the wLength of the request?

[kira-live]

We are developing with TinyUSB and using Vendor Control Transfers to execute certain commands. We noticed that when an IN transfer is initiated with a requested length (wLength) of 0, the device stops responding on the control endpoint.

After reviewing the USB specification and the TinyUSB source code, my understanding is that a request with wLength == 0 should always have its status stage as an IN transaction. However, in the status_stage_xact function, the response direction seems to be inverted. Could this cause an IN request's status stage to be incorrectly handled as an OUT transaction?

The strange part is the inconsistency across different systems using the same firmware and the same host application (WebUSB):

At my workplace, it fails (stops responding) on both Windows and macOS.
At home, it works perfectly on a Windows machine.

I am not entirely sure if this is a bug, so I would like to start a discussion first to clarify my understanding.

[hathach]

Which request has zero length and dir bit set ?

[kira-live]

Thanks for your reply.
Here is my example:
I built a website that using the WebUSB interfaces controlTransferOut and controlTransferIn. With the requestType set to vendor, recipient to interface, value to 0, length to 0, and request to 03 , the received Setup packets are C1 03 00 00 00 00 00 00 and 41 03 00 00 00 00 00 00.
I'm not sure if this is the information you need.
My program logic is as follows: I use a vendor request to get the buffer length, then initiate a second request to retrieve the buffer content. When the buffer is empty, a request with a length of 0 is accidentally triggered. Our requests are being sent to the interface rather than a specific endpoint, similar to how the BOS descriptor and Microsoft OS 2.0 Descriptors are handled, because we have already run out of available endpoints. While I know I can prevent this through host-side constraints, I am wondering if TinyUSB should also handle this edge case.

[kira-live]

If any one have same problem, you can check out this #3615 pr