From owner-freebsd-usb@FreeBSD.ORG Wed Nov 20 04:13:31 2013 Return-Path: Delivered-To: freebsd-usb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0753A11 for ; Wed, 20 Nov 2013 04:13:31 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 844282A5F for ; Wed, 20 Nov 2013 04:13:31 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAK4DKNx002908; Tue, 19 Nov 2013 20:13:24 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311200413.rAK4DKNx002908@gw.catspoiler.org> Date: Tue, 19 Nov 2013 20:13:20 -0800 (PST) From: Don Lewis Subject: Re: U3GINIT_SCSIEJECT quirk To: hps@bitfrost.no In-Reply-To: <5285CE2A.2020609@bitfrost.no> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-usb@FreeBSD.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 04:13:31 -0000 On 15 Nov, Hans Petter Selasky wrote: > On 11/15/13 00:37, Don Lewis wrote: >> My first question is how does U3GINIT_SCSIEJECT manage to ever work? It >> seems like there would be chicken vs. egg issue here. The quirk is on >> the u3g device, so how would it get activated until the u3g device is >> attached? The u3g device doesn't appear until the umass device is >> ejected. > > Hi, > > Check the VID and PID of your USB device using usbconfig. Maybe it is > not the same value in both cases? > > U3G patch looks OK. Ok, I've committed the u3g patch. > The SCSI quirk is not needed. This should be fixed in the SCSI stack! I'm holding off committing the SCSI quirk. I did figure out why the eject isn't happening the first time that the device is plugged in. The problem is that u3g_driver_loaded() isn't getting called (to register the event handler) until the u3g device appears. This device first shows up as a umass device, and the u3g device doesn't appear until I do "camcontrol eject". It works the next time the device is plugged in because the event handler is already registered. I've got u3g built into my kernel. I don't know if it might work better if I was using u3g as a module, but I think it would be racy. Plugging in the device would cause devd to kldload the module, which would then register the event handler. I don't know if that would happen before usb_probe_and_attach() called EVENT_HANDLER_INVOKE(), but that sounds unlikely. If u3g is built in, I think the best fix would be to somehow register the event handler during the boot sequence before we start attaching the USB devices.