Re: usb function framework

On Monday 12 November 2007, Brian Swetland wrote:
> We need to do a lot of varied composite device support, something which 
> (to the best of my understanding of it) gadget does not inherently support.  
> My goal is a nice framework for being able to build individual functions
> and bolt them together (eventually dynamically) without having to fiddle
> with the common code.
> 
> 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:

  http://marc.info/?l=linux-usb-devel&m=118772860326022&w=2
  http://marc.info/?l=linux-usb-devel&m=118772861116770&w=2

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).

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.
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.)


> I think my other complain with gadget is just figuring out exactly what
> the "rules" for device controller drivers implementing the interface
> are.  I looked at a couple different ones and was unclear on what
> context various things are called from, etc.

For gadget drivers, only setup() is called from a non-sleeping
context (usually IRQ handler) ... everything else can sleep,
excepting of course request completion callbacks.  That's what
the kerneldoc currently focusses on.

For controller drivers, assume all entry points get called from
non-sleeping contexts.  That level of the interface is likely
not documented as well as one might like, since the initial
focus was on having something sane for gadget drivers ... and
strenuously avoiding any midlayer, with its consequent bloat!


> I could take some time 
> and assemble some coherent notes on things that were a bit frustrating
> to work with sometime.

Please do.

- Dave


-------------------------------------------------------------------------
This SF.net 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 >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel