On Wed, Apr 30, 2014 at 01:43:35PM -0400, Alan Stern wrote: > On Wed, 30 Apr 2014, Felipe Balbi wrote: > > > > We still have unsolved problem with deferred probe in UDC drivers, so > > > there is real need for some fixes. > > > > sure, we do need a fix, but it's very difficult to know when we can > > allow for gadget drivers to be loaded. Think of it this way: > > > > say you have a system with a single UDC controller, and we allow for > > gadget driver probe deferral. First gadget driver you load binds to the > > UDC, second gadget driver you load will defer forever, but will still > > "probe" (in a sense). lsmod will show two gadget drivers. > > > > Now say you want to use that gadget driver which is deferred, you unload > > first gadget driver and then nothing happens because you have no way to > > tell that gadget driver that you want it to bind to the UDC which is now > > available. > > > > see the problem ? > > This is the sort of thing that could be fixed by creating a "gadget" > bus type. The user would be able to force a gadget to bind to a UDC > by writing to the appropriate sysfs file. > > Of course, I suppose you could always implement the same sort of > functionality with a special-purpose sysfs file, without going to all > the effort of adding a new bus type. Maybe the bus type is what we need to do, something along the lines of i2c_bus_type, perhaps ? The difficulty will be with matching a gadget driver to a particular UDC. How would we be able to load g_zero to dwc3 and g_mass_storage to dummy ? Or maybe we load gadgets to the bus and always bind through configfs ?!? dunno, anyway back to Tracepoints... cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
