On Mon, Apr 04 2016, Alan Stern wrote: > So there is no way to add a single function to several configurations? There is. f_mass_storage (and any other usb_function_instance) simply has to have multiple usb_function structures. > It sounds like there are two problems then. The first problem is that > struct usb_function has a ->disable() callback but no ->enable() > callback. The set_config() routine in composite.c should invoke the > ->enable() callback for each function in the config when the config is > installed. Well, there is set_alt which is called when configuration is chosen (as well as when interface’s alternative is chosen). It’s not ideal but if we had to we could work with that. > The second problem is that f_mass_storage should start the thread in > the enable callback and stop the thread in the disable callback, > rather than in fsg_bind() and fsg_free_inst() (or wherever). […] > Even after the function is bound to a configuration, the thread won't > have anything to do until the configuration is installed by the host. […] > Except that you'll have a bunch of threads hanging around with nothing > to do. They shouldn't be created until it is known that they will be > needed, and they should be destroyed when it is known that they won't > have any more work to do. I’m not sure how big of a deal that is. The flip side is that equating thread’s lifetime to the lifetime of the function instance is conceptually easier. Even with thread started in fsg_bind this is still less complex than having the thread pop in and out of existence. Furthermore, having it start and stop may lead to unnecessary delays when host switches configurations. This may be an esoteric problem though. I’m not married to any either idea, but right now my patch is a better course of action because it brings a quick fix to the bug. More dramatic changes to thread’s lifetime should be handled by separate patches. -- Best regards ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ «If at first you don’t succeed, give up skydiving» -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
