From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24901 invoked by alias); 20 May 2009 16:06:07 -0000 Received: (qmail 24891 invoked by uid 22791); 20 May 2009 16:06:06 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from alicia.2020media.com (HELO alicia.2020mail.com) (212.124.192.215) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 16:06:00 +0000 Received: from [212.124.199.38] (helo=[192.168.0.2]) by alicia.2020mail.com with esmtp (Exim 4.30; FreeBSD) id 1M6oIb-000NC4-NN; Wed, 20 May 2009 17:05:45 +0100 Message-ID: <4A142A62.7040202@zynaptic.com> Date: Wed, 20 May 2009 16:06:00 -0000 From: Chris Holgate User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Frank Pagliughi 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> <4A1419A0.3010806@mindspring.com> In-Reply-To: <4A1419A0.3010806@mindspring.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00063.txt.bz2 Frank Pagliughi wrote: > >> 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. >> > 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. It does make a bit of a mockery of type safety, though. To the user, Tx and Rx endpoints are fundamentally different things and it's good to try and prevent Tx calls to Rx endpoints and vice versa. If the driver writer feels they must use the same data structure for each, then this should be hidden from the user. With the STM32 driver, it is possible to have Tx and Rx endpoints with the same logical endpoint ID but they will be implemented on different physical endpoints[1]. The user doesn't need to know this - they just tell the tx or rx endpoint getter function the logical endpoint number they want and the corresponding, correctly typed data structure is returned. > 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. Yeah - that would have saved me from a lot of pain! Chris. [1] The distinction being that logical endpoints are the endpoint numbers seen by the host and physical endpoints are the actual endpoint state machines on the chip.