On Thu, Jun 09, 2011 at 06:13:40PM +0200, Sebastian Andrzej Siewior wrote:
> Greg KH wrote:
> >On Thu, Jun 09, 2011 at 05:25:10PM +0300, Felipe Balbi wrote:
> >>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.
> >
> >Yes, we should rely on udev for automatically loading the correct
> >drivers when the hardware is found.
> >
> >But, how are we telling userspace that this driver is needed? That
> >needs to be in place for modprobe (which is what udev calls) to be able
> >to know which module to load. I don't see that change here, but I might
> >be missing it.
>
> The net2280 which Alan was referring to is a PCI device which is probed
> the usual way. The majority are platform_driver which add a
> platform_device in their board code. A few driver miss a
> MODULE_ALIAS("platform:...") but that should be it. I have a patch for
> that which needs some testing.
>
> So that should work IMHO. What we miss is the information which function
> driver to load but we are talking about UDC (device) driver atm.
What we miss is information on to which UDC controller bind the gadget
driver but that's the same we have today, it just binds to the first
(currently only) UDC available.
Now going forward we need to figure out how to be sure that users can
tie a particular gadget driver to a particular UDC, so we might need the
idea of "gadget ports" to be implemented on the udc class. We also need
to get rid of any gadget driver that's not using the composite.c
framework, so that we have one location to focus for all gadget driver
changes. By doing that we can e.g. add a module parameter to composite.c
which will tell udc class which class to load the gadget driver to.
We also need to cleanup all the ->start()/->stop() calls from all udc
controllers, then we need to uninline all the operations we have on
gadget.h, later we move the otg notifier to the udc class and notify on
every call to those functions. Later we make udc class handle the
->pullup() method correctly, so that all gadget drivers will always
start with pullups disconnected and for each function driver bound to
the gadget driver we increment the deactivations counter and every
function driver is required to activate when its ready to work, that
will be a different situation for every gadget driver, in case of f_obex
it needs an obex server on userland, in case of mass storage, if
removable == 1, it can activate on bind() time, else it needs to wait
until a file is echoed to "file" sysfs attribute and so on.
After all this is done, we need to make gadget framework handle the
start of the enumeration too. Today every gadget driver starts a
transfer on probe() time to wait for the SetAddress command so ep0
handling is always "special" and separate from all other endpoints, I
wanted to tie that to usb_ep_queue() on, maybe, composite.c so that we
don't need to start the underlying HW until we know all gadget drivers
are ready to respond. This might save a few micro-amps in runtime power
consumption too :-p
Last, but not least, we can think of a power management framework for
USB3 gadget drivers. USB3 peripherals can start lower bus states, so we
can have an API similar to what we have on USB Host side. Gadget drivers
would be required to tell udc class when they are idle, if the pm timer
expires, we request lower bus states ;-)
So this is my idea to the gadget framework for the next couple of years
at least :-p Comments are welcome and I hope everybody can help too ;-)
--
balbi
Attachment:
signature.asc
Description: Digital signature
