Re: usb function framework

On Monday 26 November 2007, Brian Swetland wrote:
> 
> 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).

I've not updated them recently, other than making sure the existing
patches don't break on various platforms (and the trivial include
file path change I already mentioned).  In particular, fixing that
one known-broken issue hasn't yet been done.  (There need to be three
components:  function, configuration, device.  "Configuration" is not
currently present, which is why updating Gadget Zero and Ether/RNDIS
has been problematic.)


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

That's always been possible.


> as well as being able to "reconfigure"  
> on the fly (probably meaning we have to disconnect from USB, shuffle 
> things around, and then reconnect).

That's implicit ... unregister one gadget driver, register another,
it must "just work".

Although the way to do that has, before, always been rmmod/modprobe.
Of course you could provide some unregister/reregister code yourself;
that would presumably be specific to "your" code.  The standard model
for USB is that a device doesn't change the interface it presents to
the host.  (Though it's my understanding that MS-Windows doesn't do
a very good job of understanding multiple such interfaces, which is
why various complex devices -- notably cell phones which might like
to use the WMC model -- seem to need such "reconfigure" steps.)


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

>From the perspective of writing a USB peripheral controller driver,
that's a lifesaver.  And there are a *LOT* more of those than there
are gadget drivers... they're a lot harder to develop, qualify,
change or debug, too.  (Not just because of design and implementation
bugs in the silicon, of course.)

So the priority was ensuring that lowest level driver interface was
sufficient to do pretty much anything, trusting the upper layers to
sort out the rest.  So far that seems to have been the right choice.
High speed support has been there from the beginning, as has support
for multiple configs and composite device capability.  OTG was easy
to add.  The next frontiers seem to be wireless USB, and USB 3.0 ...


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

How much of that is the fact that the USB device model itself is kind
of complex, though?  Descriptor management is really easy, at least it
is if you use that library code to assemble config descriptors and fetch
the right strings.  Understanding what descriptors to provide is more
complicated though.  The composite framework can't really change that;
at most it can only segment the problem a little bit.

Config management -- set/get configuration/altsetting -- is trickier,
and the composite framework handles some of that.  Function drivers
will still have to understand the same things:  how to start and stop
the I/O queues for their endpoints.

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

I guess I don't find it hard to do that with the current code either.
The transport is just a queue of request buffers.

The complications have rarely been at the transport level.  They've
been at the "how do you integrate the upper layer interfaces" level,
including power management and little puzzles related to the device
lifecycle model.

- Dave


> 
> 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 was a typo:  "current" broken model combines functions into
devices, vs functions into configs then configs into devices.

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



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel