On Wed, Nov 11, 2020 at 06:07:16PM +0100, Ingo Rohloff wrote: > I am working on a platform (Xilinx Zynq Ultrascale+), which > is supposed to work as a pure USB Device (not dual-role). > > To get fast USB bulk transfers I wanted to have something similar > like USBDEVFS_SUBMITURB/USBDEVFS_REAPURB, but for an USB Device. > > I now implement two new ioctls for FunctionFS: > FUNCTIONFS_SUBMITBULKURB > FUNCTIONFS_REAPBULKURB > which provide simliar functionality. > > A similar functionality is already implemented via AIO. But: To use this > API, your user space environment needs to know how to use these system > calls. So instead you created a new interface which requires different system calls? Doing it in a different way is "interesting", but you are duplicating existing functionality here. What is wrong with the AIO interface that we currently have that keeps you from using it, other than it being "different" than some other user/kernel interfaces that people are familiar with? > Additionally the semantics of the ioctls is slightly different: > Usually you can only access a FunctionFS file if the FunctionFS is > already bound to an UDC (USB Device Controller) and the USB Device is > connected to a USB Host (which then enables the appropriate configuration > and USB endpoints). > These new ioctls behave different: You already can submit URBs before the > Function is bound to an UDC and before the USB Device is connected. > These "pending" URBs will be activated once the endpoints become active. > > When the endpoints become deactivated (either by a disconnect from the > USB Host or by unbinding the UDC), active URBs are cancelled. > > A user space program will then get a notification, that the URBs have > been cancelled and the status will indicate to the user space program, > that the connection was lost. > Via this mechanism a user space program can keep precise track, which > URBs succeeded and which URBs failed. So, it implements AIO in a different way? > The final goal here is to be able to directly let user space provide data > buffers (via mmap I guess), which are then transferred via USB; but this > is the next step. Isn't that kind of what the AIO inteface provides today? :) thanks, greg k-h
