I have been looking at support for the USB mass storage class, and I think some API changes may be required in order to properly implement the bulk-only protocol. In particular, the error handling behavior for this protocol requires stalling the endpoints, and also overriding behavior for the standard endpoint CLEAR_FEATURE control message in some cases (to ignore attempts by the host to clear the endpoint STALL flag when the device is in a state where it is waiting for reset recovery). The spec for the protocol can be found here: https://usb.org/document-library/mass-storage-bulk-only-10
This is somewhat low priority for me, but I figured I would open an issue just to keep track of some of the APIs that seem like they would be needed:
The EndpointIn and EndpointOut classes seem like they need a set_stalled() method to allow endpoints to set the stall flag.
Control handlers need to be able to override the current handling of the endpoint CLEAR_FEATURE request, so that they do not clear the stall flag when the mass storage class is in a reset recovery state. It seems like it might be useful to pass in a reference to the Bus into the control handler, to allow them to modify the stall flag via the Bus object.
There needs to be an API to explicitly flush the USB endpoint TX buffers. When a MASS_STORAGE_RESET control request is received, any data pending to be sent should be dropped. (In particular, in some error situations the device may want to STALL the OUT endpoint, then queue a CSW response to be sent to the host once the host clears the STALL flag. If a MASS_STORAGE_RESET request is received instead, I believe we will need to explicitly flush this CSW response that may now be pending in the TX buffer.) For the mass storage class use case, it seems like we would probably want this to be an API on the Bus rather than on the Endpoint objects: we need to flush the buffers before accepting the MASS_STORAGE_RESET request. It seems like the receive buffers should probably be flushed too.
The bulk-only transport protocol is superseded these days by the UAS protocol, which doesn't ever stall endpoints for error handling. However, UAS appears to require operating at high speed or super speed, so bulk-only transport seems like it is potentially still necessary for devices that only support full-speed operation.
I have been looking at support for the USB mass storage class, and I think some API changes may be required in order to properly implement the bulk-only protocol. In particular, the error handling behavior for this protocol requires stalling the endpoints, and also overriding behavior for the standard endpoint CLEAR_FEATURE control message in some cases (to ignore attempts by the host to clear the endpoint STALL flag when the device is in a state where it is waiting for reset recovery). The spec for the protocol can be found here: https://usb.org/document-library/mass-storage-bulk-only-10
This is somewhat low priority for me, but I figured I would open an issue just to keep track of some of the APIs that seem like they would be needed:
The bulk-only transport protocol is superseded these days by the UAS protocol, which doesn't ever stall endpoints for error handling. However, UAS appears to require operating at high speed or super speed, so bulk-only transport seems like it is potentially still necessary for devices that only support full-speed operation.