From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 819 invoked by alias); 19 May 2009 11:47:16 -0000 Received: (qmail 811 invoked by uid 22791); 19 May 2009 11:47:15 -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 nicola.2020media.com (HELO nicola.2020mail.com) (212.124.192.216) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 May 2009 11:47:09 +0000 Received: from [212.124.199.38] (helo=[192.168.0.2]) by nicola.2020mail.com with esmtp (Exim 4.22) id 1M6NmW-000EtJ-7q; Tue, 19 May 2009 12:46:52 +0100 Message-ID: <4A129C34.9090606@zynaptic.com> Date: Tue, 19 May 2009 11:47:00 -0000 From: Chris Holgate User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Simon Kallweit , ecos-devel@sourceware.org Subject: STM32 USB support References: <4A11CAAA.8040900@intefo.ch> <4A11D861.8090206@zynaptic.com> <4A11E5DF.2000403@intefo.ch> In-Reply-To: <4A11E5DF.2000403@intefo.ch> 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/msg00025.txt.bz2 Simon Kallweit wrote: > Chris Holgate schrieb: >> >> It's stable in my application using my own Linux kernel driver (several >> million bulk and interrupt transactions and counting!). >> > That sound's pretty stable to me :) OK - I've now done a bit of tidying up which I hope won't have broken it! The latest version of the package is here: http://www.zynaptic.com/ecos/packages/stm32-usb-20090519.epk There are a couple of minor TODO's which I need to revisit before a proper release, but nothing significant. >> However, I've not had much luck getting it working with the standard >> eCos test framework - although I now suspect thats a Linux usbfs issue >> rather than my driver. I also need to sort out some proper >> documentation! > > Well, I could do some testing too and see where I get. That would be very helpful, although I think that the standard host-side tests have only ever been run on a pretty old version of Linux. I'd have more confidence in testing against some standard drivers like a virtual serial port or a 'memory stick' device. >> There is a significant difference from the other USB drivers which I >> should probably flag up (and document). The endpoint configuration is >> generated dynamically from the USB descriptors. This gives a lot of >> flexibility and potentially allows support for multiple configurations >> (untested!). However, the downside is that I had to leave out devtab >> support since the devtab entries need to be set statically. >> > Don't you think it's possible to have both options? I haven't looked at > the USB subsystem or any drivers, but I think a public driver should > behave as the subsystem intends. Maybe the subsystem could be extended > for more dynamic usage though. The official docs say "To support this the device driver can provide a devtab entry for each endpoint". I took that to mean that devtab support was optional - and the dynamic endpoint configuration is a much more useful feature IMHO. Previously supported hardware has had fixed endpoint configurations which makes the static devtab entries easy to implement. However, with dynamic endpoint configuration, the low-level driver doesn't know a-priori what endpoints to generate devtab entries for - and nor should it! Copied to the list, since I'm sure there are other people who would like to comment... Chris.