> > 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. > Thanks for your information. If 'transfer size' here is software concept, why controller needs to know? The general controller internal logic doesn't care class protocol, it only cares TRB chain software prepares. > 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. > Does the controller case about stream information or the transfer information? > 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. > I think class driver needs to consider that, the controller driver only needs to handle request and related TRBs. Peter
