Re: usb function framework

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

On Monday 12 November 2007, Felipe Balbi wrote:
> >> One of the things we're investigating is stacking the "function"
> >> business on top of gadget (avoiding replicating the bottom layers of
> >> things).  
> > 
> > Pretty much like:
> > 
> >
> >
> > 
> > That's the most current stuff, modulo a need to switch over
> > to <linux/usb/gadget.h> in <linux/usb/composite.h> ... it's
> > more current than what Felipe and Ragner posted a ways back
> > (and is also a much cleaner version of the original concept).
> > 
> i'll have to review that code again, but it looks that g_zero will always
> work as a composite device.

Right ... basically it took the original composition patch,
updated it so it became usable (and to incorporate a few of
the ideas from your earlier updates), then used it with one
of the simplest current gadget drivers.

> > However, that particular version doesn't actually connect
> > more than one function into a configuration.  The reason is
> > that it still needs a bit of API restructure ... it should
> > combine function drivers into *configurations* which in turn
> > combine to make gadget drivers.  Instead, that code use a
> > slightly broken model, combining functions into configurations.

Typo:  broken in that it combines functions into *devices*.

Gadget Zero wouldn't be the only gadget driver to suffer
thereby, although it's only one of two multi-configuration
drivers right now.

> > That works OK until you try to handle multi-configuration
> > gadget drivers like g_ether (with RNDIS enabled).
> > 
> > The notion of "dynamic" pluggability is problematic in terms
> > of what the USB spec presents as the definition of a device,
> > with a given pair of vendor and product IDs ... it's expected
> > to be fixed function, where SET_CONFIGURATION is used to
> > change device capabilities.  (Or SET_INTERFACE.)
> > 
> agree with u here, but it should be dinamic for testin purposes, of course
> manufacturers will make it work the right way. i.e. as a single,
> "unchangeable", binary module.

One would hope that manufacturers do that.  On the other hand,
I don't see lots of motivation for testing something that should
NOT be used, rather than stuff that SHOULD be used.  ;)

However, I do seem to understand that the Microsoft USB stack
(on the host side) doesn't adhere as closely to the USB specs
as it should, and one aspect of that may be its support (or
lack thereof) for using SET_CONFIGURATION for dynamic reconfig.

- Dave

This email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
To unsubscribe, use the last form field at:

[Home]     [Video for Linux]     [Photo]     [Yosemite Forum]     [Yosemite Photos]    [Video Projectors]     [PDAs]     [Hacking TiVo]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Big List of Linux Books]     [Free Dating]

  Powered by Linux