Hi, > > Alan Stern wrote: > > > How do you deal with the fact that after this change, > > > > > > modprobe gadget_driver > > > > > > will fail if the UDC driver isn't already loaded? This could break > > > some userspace scripts. > > > > The driver should be loaded by udev. There could be some breakage if I like the idea of depending on udev. I remember I had a discussion with Greg before and he told me we should rely on udev for these things. I mean, it's the same on your PC right ? if you drop udev, ehci/ohci won't load automatically and you'll have host drivers binding with usbcore and no ehci/ohci loaded. > > people are not using udev and rely on the fact that the gadget_driver will > > pull in the only available gadget driver. > > > > In case we want to keep this behavior then it could be fixed. As of now > > there can be only on udc selected at a time. We could use this information > > and call try_then_request_module(). I'm not sure this will be good. You'll need ifdefs to request the correct module ? How will you fetch the name of the driver to load ? What if someone decides to change the name of th driver ? > > If we do this, how long do we want to keep this compatibility? I guess we > > can defer the question to this once someone wants a multi-gadget kernel :) > > This deserves a high-level discussion; it would be good to hear from > Greg, Felipe, and other people. > > Maybe there could be a CONFIG_MULTI_UDC option (marked EXPERIMENTAL). Could be, but my view of this was to make something similar to the host API. That's why initially I had called it usb_add_udc() and stuff like that. Which means, that it should be possible to have multi-udc without any option needed. This will allow us to have full object orientation on the Gadget Controller drivers. See that today all of them have a static pointer to their own structure due to usb_gadget_probe_driver() and its sibbling only passing a pointer to the driver. > If it's not set (the normal case) then there can be only one UDC driver > configured, and the UDC core would automatically load it as needed, the > way you described. Sounds weird to me. We already have something similar by marking a dependent config Y instead of M and besides, we should allow for all drivers to be compiled otherwise we can't have distro-like kernels for embedded devices. > If the option is set then more than one UDC driver can be configured > and the user will be responsible for loading the appropriate UDC > driver(s) before loading any gadget drivers. I'm not sure. I still think we should be relying on udev to do the right thing based on device creation. Recently, I have been testing my usb3 controller driver (you can see in my dwc3 branch on usb.git on k.org) and it's quite useful to have udev load things correctly. All I have to do is turn on the machine which has my prototype attached to PCIe and all drivers are correctly loaded, I only have to load a gadget driver :-) Still, I'm open for discussion :-D -- balbi
Attachment:
signature.asc
Description: Digital signature
