Re: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"

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

 



On Wed, Aug 13, 2014 at 09:19:31AM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Aug 13, 2014 at 10:02:08AM -0400, Alan Stern wrote:
> > > > So here's what the UDC driver should do: If the pullup routine is called
> > > > while Vbus is off, the driver should leave the D+ pullup disconnected but
> > > > remember the call.  Then when Vbus gets turned on, the driver should
> > > > activate the pullup.
> > > > 
> > > > In other words, the UDC driver should keep track of the pullup's
> > > > "logical" state.  When Vbus is off, the pullup must also be off.  When
> > > > Vbus is on, the pullup's physical state should be the same as the logical
> > > > state.
> > > > 
> > > 
> > > We had a similar discussion at last year, but Felipe " don't want to let UDC
> > > drivers call usb_gadget_connect()/disconnect() directly."
> > 
> > All right, let's see what Felipe says about my suggestion.
> 
> Keeping track of the pullup's state like that will just add complexity
> to the UDC drivers. There's really no problem in connecting pullups
> before VBUS is above session valid threshold.
> 
> The whole idea of udc-core was to handle those details generically so we
> don't have to patch every single UDC driver. The best solution, IMO,
> would be to teach every function about activate/deactivate and only
> connect pullups based on that. So that functions, and only functions,
> are responsible for managing pullups.
> 
> Functions which don't need to wait for userspace can just call
> usb_function_activate() from their bind() method, while functions
> relying on userspace can do so when the devnode is opened or whatever.


That will not solve the scenario where one composite device manage e.g.
three different functions. Lets assume we have one acm, one uvc and one ncm
(in that exact order). That will lead to one usb_function_activate,
one usb_function_deactivate and one usb_function_activate.

Not even speaking of the complexity we gain, when using g_ffs. That
is composing the composite gadget in userspace runtime.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




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

  Powered by Linux