Date: Sun, 20 Mar 2005 20:17:44 +0000 From: Ian Dowse <iedowse@maths.tcd.ie> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org Subject: Re: Can we block in USB_ATTACH context ? Message-ID: <200503202017.aa93108@salmon.maths.tcd.ie> In-Reply-To: Your message of "Sun, 20 Mar 2005 10:04:17 MST." <20050320.100417.27675329.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20050320.100417.27675329.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <200503201517.33598.sebastien.b@swissinfo.org> > Sebastien B <sebastien.b@swissinfo.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503202017.aa93108>