Re: [PATCH 2/2] usb: gadget: convert all users to the new udc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux