Hi, Peter Chen wrote: > On 20-04-27 15:27:41, Thinh Nguyen wrote: >> A transfer is composed of one or more usb_requests. Currently, only the >> function driver knows this based on its implementation and its class >> protocol. However, some usb controllers need to know this to update its >> resources. For example, the DWC3 controller needs this info to update >> its internal resources and initiate different streams. >> >> Introduce a new field is_last to usb_request to inform the controller >> driver whether the request is the last of its transfer. >> >> Signed-off-by: Thinh Nguyen <thinhn@xxxxxxxxxxxx> >> --- >> include/linux/usb/gadget.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h >> index e959c09a97c9..742c52f7e470 100644 >> --- a/include/linux/usb/gadget.h >> +++ b/include/linux/usb/gadget.h >> @@ -50,6 +50,7 @@ struct usb_ep; >> * @short_not_ok: When reading data, makes short packets be >> * treated as errors (queue stops advancing till cleanup). >> * @dma_mapped: Indicates if request has been mapped to DMA (internal) >> + * @is_last: Indicates if this request is the last of a transfer. > Would you please describe the use case for it, and what's 'transfer' > and 'request' in your use case? > The transfer size is defined by a class protocol. The function driver will determine how many usb_requests are needed to fulfill that transfer. For example, in MSC, a READ/WRITE command can request for a transfer size up to (512 * 2^31-1) bytes. It'd be too large for a single usb_request, which is why the mass_storage function driver limits each request to 16KB max by default. A MSC command itself is a transfer, same with its status. This is a similar case for UASP. However, the f_tcm and the target drivers current implementation only use a single request per transfer. (This needs to be fixed, along with some other issues in f_tcm). The use case here is that DWC3x controller needs to update its resources whenever a transfer is completed. This is a requirement for streams when it needs to free up some resources for different stream transfers. The function driver must pass this information to the controller driver for streams to work properly. Potentially, another use case for this is to update the documentation on usb_dequeue_request(). By providing the concept of a transfer, we can say that dequeuing an in-flight request will cancel the transfer, and any incomplete request within the transfer must be given back to the function driver. This would make sense for controllers that use TRB ring buffer and dequeue/enqueue TRB pointers. But this idea still needs more thoughts. BR, Thinh
