Re: usb function framework

hi,

On Mon, 12 Nov 2007 13:59:50 -0800, David Brownell <[email protected]>
wrote:
> 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).
> 

i'll have to review that code again, but it looks that g_zero will always
work as a composite device.

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

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.

> 
>> 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
-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
[email protected]


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