From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 16:29:56 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 D35F716A4CE for ; Mon, 3 May 2004 16:29:56 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BC3043D4C for ; Mon, 3 May 2004 16:29: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)i43NTnDv008214 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 4 May 2004 01:29: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 i43NSqUi087898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2004 01:28:52 +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 i43NSqA9046087; Tue, 4 May 2004 01:28:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i43NSpZA046086; Tue, 4 May 2004 01:28:51 +0200 (CEST) (envelope-from ticso) Date: Tue, 4 May 2004 01:28:51 +0200 From: Bernd Walter To: Rita Lin Message-ID: <20040503232850.GL38488@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> <20040503222538.GK38488@cicely12.cicely.de> <006f01c43160$b84a1220$9402a8c0@emachine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006f01c43160$b84a1220$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 23:29:57 -0000 On Mon, May 03, 2004 at 06:48:14PM -0400, Rita Lin wrote: > > That is what I call a bad design. > > You waste resources because the device designer did not take the > > features he had available. > Okay, I guess so. There are also other minor things that I don't understand > why > the device is implemented the way it is. Since I don't make it, and I don't > work for > the company that makes it, it's beyond me. Obviously. I also understand that a vendor can't use an interrupt pipe for this case as USB hardware is usually limited in number and type of pipes it can handle, but USB offers much more. It's also not absolutely clear to me why you are interested in regular status information at all? > > 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. > Are you talking about USB interfaces at software layer or physical layer? I > think I'm confused here. > If it's software layer, yes, the device offers multiple USB interfaces. Each > interface has its own pipes. > But, of course, the default pipe is shared. That's what I mean - so the vendor intendend use is to attach at interface level, which means each port has it's completely own instance of driver (and also a softc on it's own) - no difference for ucom comparing to completely different devices. If you instead take the whole device at once you can't use the same driver to work with other variants of the same protocol. Maybe the vendor also has a device plus a printer interface in the future. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de