From owner-freebsd-usb@FreeBSD.ORG Sun Mar 20 20:17:47 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82AFD16A4CE for ; Sun, 20 Mar 2005 20:17:47 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 8A48D43D2D for ; Sun, 20 Mar 2005 20:17:46 +0000 (GMT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 20 Mar 2005 20:17:45 +0000 (GMT) To: "M. Warner Losh" In-Reply-To: Your message of "Sun, 20 Mar 2005 10:04:17 MST." <20050320.100417.27675329.imp@bsdimp.com> Date: Sun, 20 Mar 2005 20:17:44 +0000 From: Ian Dowse Message-ID: <200503202017.aa93108@salmon.maths.tcd.ie> cc: sebastien.b@swissinfo.org cc: freebsd-usb@freebsd.org Subject: Re: Can we block in USB_ATTACH context ? X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2005 20:17:47 -0000 In message <20050320.100417.27675329.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <200503201517.33598.sebastien.b@swissinfo.org> > Sebastien B writes: >: Hello, >: Can I call functions that will block (ie. waiting for condition variables, >: acquiring MTX_DEF mutexes, ...) inside the USB_ATTACH section of a driver ? >: Or should I use a software interrupt handler that will perform the >: initialization of my USB device instead of doing this directly in >: USB_ATTACH ? (Lots of transfers have to be made before the device is ready.. >. >: setting up the NET2280 PCI bridge, uploading a ~30kbyte firmware, reading >: configuration options of the device...) > >It is safe to block in usb_attach routines. You will block all other >usb attachment activity, however. I believe that other usb transfers >will continue, but haven't verified it. This doesn't seem to be entirely true for devices attached at boot time though. It is safe to perform any USB transfers, because the USB host controller drivers automatically enable polling at boot time (i.e. usbd_transfer() will never return USBD_IN_PROGRESS). It should also be safe to lock mutexes, since during boot there will be no contention. However, tsleep(), msleep(), callouts, or any inter-thread synchronisation will not work, because no context switches are allowed during the "cold" phase of booting. If you call tsleep() or msleep() at this time they will just return immediately. That's how I understand how it works anyway, but I may have some of the details wrong. Ian