Closed jamesadevine closed 1 year ago
Would be good to double check my assertion above. I think the docs are a bit misleading here.
Certainly, it was the case for me that a driver was blocked waiting for a write to complete successfully. Is there a kernel driver we can learn from?
The docs are not misleading if you use your brain to read them :smile: silly me...
I interpreted it as in the case where the direction is USBIP_DIR_OUT, n is 0, therefore, one would assume actual_length
should also be zero. What it actually says is that for USBIP_DIR_OUT, actual_length
is always the length of the origin URB transaction. In the case where the direction is USBIP_DIR_OUT, n is 0, because there is no payload; actual_length
is still the length of the URB transaction..
Hey!
It looks like when returning a URB response to an IN request, you need to write the length of the bytes written as the urb data length:
https://www.kernel.org/doc/html/latest/usb/usbip_protocol.html
Currently, we use the returned response, which in the case of a write is an empty vector. So if a driver etc. writes n bytes and expects n to be returned, it will always see 0.
I have a patch but it is, as per usual, not a small one...