On Mon, Apr 30, 2018 at 11:08:42PM +0200, Paul Kocialkowski wrote: > Hi, > > Le samedi 21 avril 2018 à 09:34 -0500, Bin Liu a écrit : > > Okay, this came down to an argument that whether we should require > > loading a gadget driver on a dual-role port to work in host mode, > > which is currently required on musb since a long long time ago. > > > > I understand the requirement is kinda unnecessary, but since it > > already > > exists on musb stack for a long time, I don't plan to change it. > > Because I > > cannot think of a use case in real products that doesn't automatically > > load a gadget function on the dual-role port. > > > > If you can explain a use case in real world (not a engineering lab) > > that the gadget driver will not be loaded at linux booting up, but > > later based on user's input, I will reconsider my decision. To remove > > this requirement from musb stack, the work is more than this patch. > > My use case here is to support common GNU/Linux-based distributions, not > use-case-specific varieties of GNU/Linux-based rootfs. So my point here > would be that most distros will (and probably should) ship g_ether as a > module but without any particular reason to autoload it, or any other > gadget module in particular, since the system is general-purpose. This is the case I called it "in a engineering lab", not a real product. > Then, imagine a user wants to plug a USB device through OTG (say, > because it's the only USB port available at all on the tablet they're > using), it simply won't work. It won't be obvious to that user that this > is because no gadget is loaded, since what they want to do does not > involve using gadget mode at any point. If a tablet has a dual-role usb port, it is designed to use a gadget driver, which has to be loaded at some point. In the case you described above, when the gadget driver will be loaded? and how? If a gadget driver will never be used, a host-only port should be on the board, not a dual-role port. > Do you think this is a valid use case? It surely is a common one and > perfectly depicts my situation. As I explained above, I don't think so. > Note that in addition to Allwinner devices, I also have omap3/4/5 > devices for testing things. I don't think I have other MUSB-enabled Much more than what I have ;) > devices in my collection though, but I would be willing to test fixes to > this issue on the ones I have. Appreciated it, but someone has to make the patches first. The one you posted might be a good start, but it is not complete. The first problem I see is that musb_start() will be called twice, one in the place you patched, the other is when the gadget driver is bound to the UDC. Regards, -Bin. -- 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
