On Wed, Jun 8, 2016 at 9:02 AM, Peter Chen <hzpeterchen@xxxxxxxxx> wrote: > On Tue, Jun 07, 2016 at 11:59:57AM +0200, Krzysztof Opasiak wrote: >> Hi, >> >> On Tue, Jun 7, 2016 at 11:06 AM, Peter Chen <peter.chen@xxxxxxx> wrote: >> > >> > >> >>-----Original Message----- >> >>From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] >> >>On Behalf Of Krzysztof Opasiak >> >>Sent: Tuesday, June 07, 2016 3:46 PM >> >>To: Peter Chen <hzpeterchen@xxxxxxxxx> >> >>Cc: Krzysztof Opasiak <k.opasiak@xxxxxxxxxxx>; balbi@xxxxxxxxxx; Greg Kroah- >> >>Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Andrzej Pietrasiewicz >> >><andrzej.p@xxxxxxxxxxx>; Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>; >> >>linux-usb@xxxxxxxxxxxxxxx >> >>Subject: Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and >> >>legacy gadgets >> >> >> >>Hi, >> >> >> >>On Tue, Jun 7, 2016 at 3:27 AM, Peter Chen <hzpeterchen@xxxxxxxxx> wrote: >> >>> On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote: >> >>>> Currently it is possible to build in some subset of usb functions >> >>>> *OR* some gadget module. This is limited only by Kconfig not any >> >>>> functionality. >> >>>> >> >>>> This patch removes this limitation. With this patch it is possible to >> >>>> set up all build combinations: >> >>>> 1) Multiple gadgets build in >> >>> >> >>> If that, what the user will expect if choosing multiple gadgets? >> >>> Eg, if he chooses g_ncm and g_mass_storage, will he expect his udc has >> >>> both mass_storage and ncm function, but it is not the fact, only the >> >>> first gadget function will work. >> >>> >> >> >> >>Not exactly one. You may build in multiple modules and use those multiple modules if >> >>you have multiple udcs. >> >> >> > >> > My concern is: with your patch, the user may get unexpected results if he builds in >> > multiple gadgets for this single udc. At current code, the user can't do that, then he will >> > not get unexpected results. How do you consider that? >> > >> >> That's true but even without this patch user may build multiple >> gadgets as a modules. >> >> Even more, after commit (855ed04 "usb: gadget: udc-core: independent >> registration of >> gadgets and gadget drivers") it is possible to load multiple gadget >> modules even if we have one UDC. >> >> So why would you like to disallow building in multiple gadgets if user >> can build them as a modules and simply load? > > For module, the user can control which one to load, he or she can choose > which function he needs. But if they are build-in, the user may make > mistake and choose multiple gadgets, and get the unexpected results. > This is only I concern. > If we add udc param to module then we can get something quite similar using kernel cmd line. Let's say that mostly you are using g_ether but sometime you would like to use g_hid. For first case you set kernel cmd line to: g_ether.udc="my_udc", g_hid.udc="non existent udc" When you would like to use g_hid, then you could edit cmd line to: g_hid.udc="my_udc", g_ether.udc="non existent udc" and of course reboot. So it would be possible to choose which function you need. Even more if you have multiple UDC (recently I often have 3 of them: real one - dwc2, dummy_udc for testing and vudc) then you will be able to build in multiple gadgets and assign each one to udc of your choice;) > I just do not see the benefits that allow building in multiple gadgets, > If you have some use cases, then that's reason for doing that:) > Well yes, I have a use case. It's not related to multiple gadgets build in but rather coexistent of build in legacy gadget and additional usb function as a modules. I have a board which use some vendor specific legacy style gadget (Yes I know it should be ported to configfs I would love to do this but currently there is no agreement/resources;)) and for some reasons this module has to be build in. But I also need to run some tests on that platform which requires dummy_hcd and configfs based gadget and functionfs. As it is required only for testing dummy_hcd and usb_f_fs should be build as a module. Without this patch I was unable to do this. With this patch it can be easily done and it's working;) >> >> If you concern about order of probing and binding to udc, I think that >> we can add udc module param to all legacy gadgets so user can specify >> in kernel cmd line where each gadget should be bound. >> > > Yes, currently, we can't do that even the gadget is module, but the > change may not be small. Now, we have configfs, it is not so necessary > to add this future. > Well in my humble opinion this change will be quite small;) it may be useful for people who have multiple udc and has to use legacy gadgets for some reason. I will try to do this and send a patch today;) -- Best regards, Krzysztof Opasiak -- 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
