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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201311200413.rAK4DKNx002908>