From owner-freebsd-hackers@FreeBSD.ORG Mon May 3 14:48:47 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 16EC716A4CE for ; Mon, 3 May 2004 14:48:47 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2F6643D49 for ; Mon, 3 May 2004 14:48:46 -0700 (PDT) (envelope-from ritalin@comcast.net) Received: from emachine (pcp04418869pcs.nrockv01.md.comcast.net[69.140.111.25]) by comcast.net (sccrmhc11) with SMTP id <2004050321484501100jm4a4e>; Mon, 3 May 2004 21:48:45 +0000 Message-ID: <001a01c43156$bce21c60$9402a8c0@emachine> From: "Rita Lin" To: References: <004c01c43053$2a775920$9402a8c0@emachine> <20040503120824.GG38488@cicely12.cicely.de> <008901c4314e$72b214e0$9402a8c0@emachine> <20040503211005.GJ38488@cicely12.cicely.de> Date: Mon, 3 May 2004 17:36:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 cc: freebsd-hackers@freebsd.org 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 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 21:48:47 -0000 > 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. > 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. > -- > B.Walter BWCT http://www.bwct.de > bernd@bwct.de info@bwct.de > 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. Rita