Hi, (... snip ...) > > > > You don't need all this stuff. What's the point of keeping > track of > > > names? If there are any unbound gadget drivers pending, a > newly > > > registered UDC should bind to the first one available. > > > > It's because gadget driver may be bound to usb_gadget in two > ways: > > - standard way - in this case any available udc will be picked > up > > - by name of udc, in this case only matching udc will be picked > up > > Where did this "by name" feature come from? You did not mention it > in > the patch description. > > Why bother matching by name? Why not simply take the first > available > UDC? Because you may have more than one udc. This would allow to pick one by name just like using configfs interface. > > > Main feature of my path is not only deferred binding of gadget > driver, > > but also possibility to register/unregister udc at any time. > > This is useful for user who can load, for example, udc module > > if needed and unload it safely, not touching gadget driver. > > We can already do that with the existing code. There's no need for > a > patch. > > Also, it's not clear that the existing gadget drivers will work > properly if they are unbound from one UDC and then bound again to > another one. They were not written with that sort of thing in > mind. > What you have described is one of basics configfs features. You should be able to bind and unbind your gadget whenever you want and it should work properly after doing: ## create gadget $ echo "udc.0" > UDC $ echo "" > UDC $ echo "udc.1" > UDC Function shouldn't care which udc it has been bound previously. Only current one is important and on each unbind each function should cleanup its state and prepare to be bound to another udc. Configfs interface doesn't prohibit this and I haven't seen any info about such restriction. If some function is not working in such situation there is a bug in that function and it should be fixed. I have tried to test this on my odroid with dwc2 and dummy_hcd. Most of functions seems to be working but for example ecm isn't. After some digging with Robert we found that it's always reusing endpoints received in first bind(). Once again in my opinion it's a bug which should be fixed and not treated as general assumption. -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics k.opasiak@xxxxxxxxxxx -- 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
