From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16027 invoked by alias); 20 May 2009 14:54:53 -0000 Received: (qmail 16013 invoked by uid 22791); 20 May 2009 14:54:51 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from elasmtp-spurfowl.atl.sa.earthlink.net (HELO elasmtp-spurfowl.atl.sa.earthlink.net) (209.86.89.66) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 14:54:44 +0000 Received: from [66.47.90.38] (helo=[192.168.0.5]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M6nBY-0002Kv-Rc; Wed, 20 May 2009 10:54:25 -0400 Message-ID: <4A1419A0.3010806@mindspring.com> Date: Wed, 20 May 2009 14:54:00 -0000 From: Frank Pagliughi User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Chris Holgate CC: Andrew Lunn , Simon Kallweit , ecos-devel@sourceware.org Subject: Re: STM32 USB support References: <4A11CAAA.8040900@intefo.ch> <4A11D861.8090206@zynaptic.com> <4A11E5DF.2000403@intefo.ch> <4A129C34.9090606@zynaptic.com> <20090519120004.GI20046@lunn.ch> <4A12D3CC.1070707@zynaptic.com> <4A137430.2010903@mindspring.com> <4A13D90F.2000600@zynaptic.com> In-Reply-To: <4A13D90F.2000600@zynaptic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 4d82f965df0f6dd9e3f977c6d1ea408f0a9da525759e26543b6ceeb639e9f71b5be731f6bcbc8514666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00057.txt.bz2 > My main bugbear is the way in which class drivers currently access > device endpoints. At the moment you need to know which low level driver > is in use and the completely arbitrary names of the exported static > endpoint data structures. This should really be hidden behind a generic > API which is defined by usbs.h. I think that this would be an easy > change and would require mimimal additions to the existing drivers. > Existing drivers could add the endpoint 'getter' functions and still > export their static endpoint data structures for legacy class drivers. > In addition, it's difficult to specify endpoints which can be used for either direction. I believe several drivers specify that all their generic endpoints are "rx endpoints" and if you want to use one to transmit data you must overlay a "tx endpoint" on top of it. That's not a big problem, but it's confusing. In addition, then rx/tx data structures lack a few fields to completely (easily) handle a generic endpoint, like the endpoint number, and maybe some intermediate buffer pointers to handle a single transfer. So each driver has to add this functionality in one way or another. >> IIRC, at the time I had fairly convinced myself that what was needed was >> an entirely new USB subsystem that would: >> - make it much easier to work with the flexible new chips >> - handle much more of the device enumeration >> > > There's quite a bit of code in the STM32 driver which addresses these > issues within the existing framework. Maybe the thing to do would be to > factor it out into a device driver utility library which can be used > alongside the existing framework. > Agreed that this is actually more realistic. And, keep in mind, there are a few additional tricky issues to which the driver writer is exposed, which can be delegated out to a common package. I don't think any of the drivers properly deal with the state change callback - most appear to emit a "current/new state" enumerated value (USBS_STATE_xxx) rather than a state change value (USBS_STATE_CHANGE_xxx). And the way in which transfers for bulk and interrupt endpoints need to be ended - in regard to short and zero packets - can get a little messy, but is common to all devices. With a more complete, common endpoint structure, this decision making could be handed off to a single, common set of routines. >> - provide a very specific callbacks structure (like read/write an >> endpoint, respond to a bus reset, set the chips' address, etc) >> - handle more of the buffering >> > > While the existing callback setup may not be the easiest to use, it does > provide all the required information. As for buffering, this is > something which I think should be a matter for the class driver writer. > Again, this could all be made easier by better documentation and a > possible class driver utility library. > True, though I worry that even the existing drivers have a number of bugs and deficiencies, especially since they're left to handle some common control messages on their own. And, since each new driver is written using an old one as a template, the bugs are perpetuated. But no one - my self included - wants to fix the old drivers since they're mostly for chips that are obsolete or no longer viable. Frank