Dear All, v3: This is the third version of RFC for a usb gadget configured through configfs. Changes since v2: - improved ufg_gadget_bind - some attributes have real values instead of dummy values - added interfaces and endpoints directories in configfs - added a local header file in drivers/usb/gadget This is a work in progress. The layout of directories remains the same as in the previous version because of this: http://www.spinics.net/lists/linux-usb/msg71416.html Of course it can be discussed, though. The interfaces directories are located in their respective function's main group, e.g.: /cfg/usb-function-gadget/G1/C1/F1/interface00 The endpoint directories are located in their respective interface directory, e.g.: /cfg/usb-function-gadget/G1/C1/F1/interface00/endpoint81 This layout has such an implication that names for functions like "interface00" are illegal. This can be mitigated by adding another level of nesting but given previous discussions I was not sure I wanted making the directory hierarchy deeper. If desired, I can add it. The directories for interfaces and endpoints are created programatically without user's intervention, and so are removed on deconfiguring the gagdet. An example port of f_mass_storage is provided. Its code is still #include'd. I intend to build the ufg from independent files when Sebastian finishes his works related to libcomposite. I kindly ask for a review and comments. v2: This is the second version of RFC for a usb gadget configured through configfs. It is a follow-up to this thread: http://www.spinics.net/lists/linux-usb/msg65972.html It is meant to replace all gadgets with one, configurable through configfs. By doing so, it will also make ccg obsolete. It uses libcomposite v4 from Sebastian and is rebased onto ed9cbda63d45638b69ce62412e3a3c7b00644835. There are three patches: a small addtion to composite.c, the usb functions gadget proper, and an example (and quick-and-dirty) port of the mass storage function to the proposed framework. I kindly ask for a review and for answering these questions: 1) Is this the right way to go? If yes, should I start porting more functions to the proposed framework? 2) In order to provide compatibility for older userspace, a bunch of "adapter" modules would be created, providing the legacy interface. E.g., for mass storage, inserting the g_mass_storage module would set everything up programmatically with configfs. Is this a good approach? 3) In the previous discussion http://www.spinics.net/lists/linux-usb/msg69879.html handling multiple UDCs has been touched. This patch series as of now does not change the udc-core interface. And this interface only provides the "first available" UDC. In order to provide users with ability to choose among available UDCs, udc-core should be changed. Here is the idea: Whenever usb_add_gadget_udc is called, a configfs entity is created in /cfg/usb-gadget/udcs. Binding a gadget to an udc would be done by creating a symlink in /cfg/usb-gadget/udcs/udcX, pointing to the /cfg/usb-gadget/gadgets/GadgetX of interest. The framework needs to ensure that no udc handles more than 1 gadget at a time, and that no gadget is handled by more than 1 udc - this seems feasible since in configfs we have control over creating the symlinks. And here is the question: does it sound reasonable? Andrzej Pietrasiewicz (2): usb: gadget: Add USB Functions Gadget usb: gadget: example port of mass storage to UFG drivers/usb/gadget/Kconfig | 12 + drivers/usb/gadget/Makefile | 2 + drivers/usb/gadget/f_mass_storage.c | 635 ++++++++++--------- drivers/usb/gadget/storage_common.c | 337 ++++++---- drivers/usb/gadget/usb_functions.c | 1204 +++++++++++++++++++++++++++++++++++ drivers/usb/gadget/usb_functions.h | 32 + 6 files changed, 1795 insertions(+), 427 deletions(-) create mode 100644 drivers/usb/gadget/usb_functions.c create mode 100644 drivers/usb/gadget/usb_functions.h -- 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
