Hi,
On Tue, Sep 17, 2013 at 07:08:12PM +0200, Michael Grzeschik wrote:
> On Wed, Sep 11, 2013 at 09:01:39AM +0200, Michael Grzeschik wrote:
> > On Tue, Sep 10, 2013 at 04:19:40PM +0200, Michael Grzeschik wrote:
> > > usb_function_{de}activate makes it possible to have several "gadget
> > > functions", inside one composite device, to be able to prevent the gadget
> > > to enumerate until an prepared condition has triggered (i.e. userspace
> > > daemon has started)
> > >
> > > This patch simplifies and renames the functions to its actual meaning
> > > usb_cdev_{de}activate and fixes all its users. As the code is counting
> > > the deactivations in the current cdev.
> >
> > I was working on this also to be used in udc-core for udc_bind_to_driver.
> > Because the current implementation will call usb_gadget_connect without
> > checking for delaying functions. But for that the whole mechanism needs
> > to be ported to gadget level.
> >
> > What do you think about usb_gadget_deactivate/usb_gadget_activate ?
>
> Just a short ping on that mails. You probably mist them, as
> I replied to myself in the first place! ;-)
We could certainly add usb_gadget_activate/deactivate functions, but I'm
not sure what's best to implement:
a) entirely new functions
b) add refcounting to usb_gadget_connect/disconnect
Also, we can't simply force all functions to be deactivated and forget
about everything else. Not all functions are using
usb_function_activate/deactivate as of today. We could, rather easily,
just add those calls to such functions and force the conversion.
what do you think ?
--
balbi
Attachment:
signature.asc
Description: Digital signature
