From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2601 invoked by alias); 1 May 2008 17:22:35 -0000 Received: (qmail 2590 invoked by uid 22791); 1 May 2008 17:22:34 -0000 X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from elasmtp-curtail.atl.sa.earthlink.net (HELO elasmtp-curtail.atl.sa.earthlink.net) (209.86.89.64) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 17:22:14 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YZNlWZeoVlCIVUSIvR5c2rv1at+G+i2182pDIb42otoU8LZZFzwEUCnKt2gtc7sq; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [71.80.44.180] (helo=[192.168.0.5]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JrcU0-0000UC-Ra; Thu, 01 May 2008 13:22:12 -0400 Message-ID: <4819FC43.5000905@mindspring.com> Date: Thu, 01 May 2008 17:22:00 -0000 From: Frank Pagliughi User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Andrew Lunn CC: eCos Devel Subject: Re: "usbhid-ups" programing problem... References: <20080429181922.GG2044@freenet.de> <20080501100353.GK9097@lunn.ch> <4819DEFF.2040007@mindspring.com> <20080501155138.GA14773@lunn.ch> In-Reply-To: <20080501155138.GA14773@lunn.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 4d82f965df0f6dd9e3f977c6d1ea408f0a9da525759e265427cb4ea4dc72b2ca3f2cad6a42dd9e94a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.80.44.180 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: 2008-05/txt/msg00005.txt.bz2 > >> For that matter, the usb subsystem could use a bit of an upgrade to make >> drivers easier to write. >> > > Others have said that as well. But it needs somebody to actually do > it. A lot depends on the complexity of the driver. I recently wrote a > simple driver and a Linux kernel counterpart without too much effort. > > Yes, when the USBS framework was specified (ten years ago?) most USB chips were ugly beasts, with predefined endpoints, lots of limitations, and lots of bugs. Most of the recent chips that I've seen appear to have a control endpoint and some number of fairly generic endpoints. Combining the usbs_rx_endpoint and usbs_tx_endpoint into a single thing (usbs_endpoint), adding an endpoint number and direction, and things like that would be helpful. I could make a list. Many of the ideas could break the existing USBS drivers. Would this be OK? But, if we wanted to get fancy, most of the events that a USBS driver respond to are the same: - Respond to a bus reset - Set the address - Read an RX endpoint - Fill a TX endpoint. ... A common code base for USB drivers might be really helpful. I could do this work, but would it be accepted? Frank