Re: usb function framework

Looping in Mike Lockwood, who's involved in our USB driver work.  He's
curious if there are any newer versions of these patches, particularly
if there's anything up to date that works against 2.6.23 so he can check
out the state of the art in composite devices on top of usb_gadget and
see if it fits into our world (and we can avoid reinventing some wheels).

Some minor features that I'm interested in include not *requiring* 
modules (being able to configure a kernel with a "static" boot 
configuration for this stuff), as well as being able to "reconfigure" 
on the fly (probably meaning we have to disconnect from USB, shuffle 
things around, and then reconnect).

I understand the idea of avoiding a "bloaty" middle layer, but one of
the annoyances I have with the usb_gadget interface is the requirement
of every driver having to do (most) all their own ep0 management.

Maybe it's just not possible to cleanly have shared code for ep0 and
descriptor management, but my gut reaction to gadget is "it's awfully
complicated to write a simple usb client driver".

Our (very early prototype) function framework thing that resulted in
this email thread getting kicked off totally errs on the "far too
simple" side of things, but it sure is easy to build basic transports on
top of bulk endpoints with it.

Brian

[David Brownell <[email protected]>]
> 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: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel