Date: Tue, 19 Nov 2013 20:13:20 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: hps@bitfrost.no Cc: freebsd-usb@FreeBSD.org Subject: Re: U3GINIT_SCSIEJECT quirk Message-ID: <201311200413.rAK4DKNx002908@gw.catspoiler.org> In-Reply-To: <5285CE2A.2020609@bitfrost.no>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201311200413.rAK4DKNx002908>