From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 15:26:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 463E016A4CE for ; Mon, 3 May 2004 15:26:57 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D9B343D2D for ; Mon, 3 May 2004 15:26:56 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0)i43MQnDv005921 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 4 May 2004 00:26:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i43MPdUi087474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2004 00:25:40 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i43MPdOZ045772; Tue, 4 May 2004 00:25:39 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i43MPckM045771; Tue, 4 May 2004 00:25:39 +0200 (CEST) (envelope-from ticso) Date: Tue, 4 May 2004 00:25:38 +0200 From: Bernd Walter To: Rita Lin Message-ID: <20040503222538.GK38488@cicely12.cicely.de> References: <004c01c43053$2a775920$9402a8c0@emachine> <20040503120824.GG38488@cicely12.cicely.de> <008901c4314e$72b214e0$9402a8c0@emachine> <20040503211005.GJ38488@cicely12.cicely.de> <001a01c43156$bce21c60$9402a8c0@emachine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01c43156$bce21c60$9402a8c0@emachine> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cicely12.cicely.de cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: USB device driver question: timeout() and usbd_do_request() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 22:26:57 -0000 On Mon, May 03, 2004 at 05:36:47PM -0400, Rita Lin wrote: > > Igh - that sounds like a very bad device design then. > > There would have been lots a ways to do in a clean way without > > additional pipes - such as transfering 0 sized packets to trigger a > > status inquiry or by adding status bytes in each packet. > > For what purpose do you need to poll the status in case for this device? > I would not say it's a very bad device design. However, I do agree with you > that there are numerous way to implement it. Most devices generate > interrupts > when there is a modem status change. This particular device does > not support interrupts. That is what I call a bad design. You waste resources because the device designer did not take the features he had available. > > Yes that's possible as long a you have separate pipes for each channel. > > But if you have separate pipes for each channel then the device could > > use separate USB interfaces as well so you can attach seprate instances > > of your driver as well without doing special handling. > > > That is correct provided that xxx_softc is handled correctly, otherwise, you > will end up handling wrong ucom_softc each time when driver specific > routines are called. I didn't do any special handling in my driver methods. > > As I mentioned earlier, I only did a trick in declaring the xxx_softc. > ucom_attach() attaches one instance of my driver. I made this comment > because I saw some earlier posts about ucom needed modification to support > multiple ports. If this is a device level driver yes. But I still think that a device with multiple ports and separate pipes per port should also offer multiple USB interfaces. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de