From owner-freebsd-usb@FreeBSD.ORG Wed Jan 10 23:35:29 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2773716A407 for ; Wed, 10 Jan 2007 23:35:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB1E13C47E for ; Wed, 10 Jan 2007 23:35:23 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe05.swip.net (CommuniGate Pro SMTP 5.0.12) with ESMTPA id 279495508; Wed, 10 Jan 2007 23:35:22 +0100 From: Hans Petter Selasky To: Luigi Rizzo Date: Wed, 10 Jan 2007 23:34:54 +0100 User-Agent: KMail/1.7 References: <20070109083450.A75138@xorpc.icir.org> <200701092137.22421.hselasky@c2i.net> <20070110044653.A87966@xorpc.icir.org> In-Reply-To: <20070110044653.A87966@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701102334.55338.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: any way to detect usb detached from a device driver ? X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 23:35:29 -0000 Hi Luigi, On Wednesday 10 January 2007 13:46, Luigi Rizzo wrote: > On Tue, Jan 09, 2007 at 09:37:21PM +0100, Hans Petter Selasky wrote: > > On Tuesday 09 January 2007 17:34, Luigi Rizzo wrote: [...] > > sorry but i cannot figure out how the above helps in the > detach case e.g. when a process is waiting for an ioctl > or read operation to complete - can you give more details ? "usb_cdev" is an abstraction layer for pluggable devices that wants to create a device under /dev, to read/write some data. It does not help unless you port your PWC driver over to using the "usb_cdev" system, instead of devfs directly. > > In my case, i did the following: > > USB_DETACH(pwc) > { > USB_DETACH_START(pwc, sc); > again: > if(sc->sc_videopipe != NULL) { > usbd_abort_pipe(sc->sc_videopipe); > usbd_close_pipe(sc->sc_videopipe); > sc->sc_videopipe = NULL; > } > sc->error_status = EPIPE; > if(sc->vopen) { > if(sc->state & PWC_ASLEEP) > wakeup(sc); > if(sc->state & PWC_POLL) { > sc->state &= ~PWC_POLL; > selwakeuppri(&sc->rsel,PZERO); > } > device_printf(sc->sc_dev, "Disconnected while webcam is in > use!\n"); usb_detach_wait(USBDEV(sc->sc_dev)); > goto again; > } > > if(sc->sc_dev_t != NULL) > destroy_dev(sc->sc_dev_t); > > mtx_destroy(&sc->ptrlock); > pwc_free_buffers(sc,1); > > usbd_add_drv_event(USB_EVENT_DRIVER_DETACH,sc->udev,USBDEV(sc->sc_dev)); > return 0; > } > > and at the end of the close routine > > ... > sc->vopen = 0; > usb_detach_wakeup(USBDEV(sc->sc_dev)); > } > > so the USB_DETACH() will wake up any process blocked, > the sc->error_status = EPIPE; should force an error and > cause the process to call close(). > > The down side is that you are still in the hands > of the process to let the detach complete. Ideally one > would just flag the descriptor as 'detach_pending' > and get rid of it at the end of the close(), while the > DETACH() could terminate without doing the free() What I do is to ensure that no thread is executing in any of the devfs callbacks. This might imply some waiting. Then I simply destroy the device using destroy_dev(). This way you don't have to wait for the userland process to call close(), which might not happen right away. See "usb_cdev_detach()" for more info. --HPS