The remaining non-composite users are: - dbgp very simple, not doing much ep0 - file_storage will be removed in v3.8 - gadgetfs Here are my problems at a central spot. So gadgetfs. Its ep0 handling can be done in kernel and some requests can be offloded to userland. Lets assume the host sends USB_REQ_SET_INTERFACE and ->usermode_setup is set. That means it returns with 0 (aka ACKs the request), wakes up the ep0 userland which might take a second. Within this second we might get a second ep0 request which will be processed as well, right? I am asking this because I would expect USB_GADGET_DELAYED_STATUS as the return code. So am I missing something or has the user land no control to stall _this_ request? However, I'm not sure how much sense it would make gadgetfs use composite. A couple of requests would be moved from userland into kernel and can not be overridden like USB_REQ_GET_DESCRIPTOR + USB_DT_STRING. Others have no callback like USB_REQ_SET_INTERFACE. I *guess* it makes no sense to touch it all. Now while browsing through the tree I noticed functionfs. This looks like a different gadget, seems to be a filesystem as well and is using composite. The API in userland seems to be different between those two. It seems to have the same ACK only behavior in ffs_func_setup() like gadgetfs does unless I miss a detail here as well. At this point the cleaning lady in my woke up: May I please remove inode.c, please? We don't need two APIs for the same thing. Having only composite based gadgets would maybe easy things for future rework and multiple gadgets. Adding USB3 support is probably easier to add this into functionfs (unless I can introduce antother user space API :)). Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
