Re: usb function framework

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

On Mon, 12 Nov 2007 13:59:50 -0800, David Brownell <david-b@xxxxxxxxxxx>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:> >>> > 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 alwayswork 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 coursemanufacturers 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 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 >>> _______________________________________________> linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx> To unsubscribe, use the last form field at:> Best Regards,
Felipe Balbihttp://felipebalbi.comme@xxxxxxxxxxxxxxx

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