Date: Sat, 30 Apr 2016 17:24:13 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Karl Denninger <karl@denninger.net>, freebsd-usb@freebsd.org Subject: Re: Prevent attach of modem serial emulated device on USB attach? Message-ID: <5724CE1D.3070105@selasky.org> In-Reply-To: <8c60b86f-de54-f80d-741d-170829dac1c8@denninger.net> References: <08f991ca-0c97-3d29-8b56-5a4ac9f904f3@denninger.net> <5724BDEB.3060502@selasky.org> <8c60b86f-de54-f80d-741d-170829dac1c8@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/30/16 17:08, Karl Denninger wrote: > > > On 4/30/2016 09:15, Hans Petter Selasky wrote: >> On 04/30/16 16:06, Karl Denninger wrote: >>> So I have managed to get access via ugen to one of the USB devices I >>> want to talk to. >>> >>> I would like to generalize that in a library, but am confounded by a >>> /second /device that comes up "looking like a modem", although it is >>> not. This is convenient if you want to open and deal with it like a >>> modem, but unfortunately that attachment appears to prevent me from >>> successfully using it with the ugen interface at the same time, as the >>> attachment looks like it "eats" the inbound byte stream. >>> >>> Is there a reasonably-easy way to /prevent /FreeBSD from declaring this >>> device eligible to be attached as if it was a character-style modem, >>> leaving it only on ugen? I have figured out how to use devd to change >>> permissions on attach, but not how to prevent it from attaching a >>> generic USB device to a specific driver. >>> >> >> Hi, >> >> Did you try: >> >> libusb_detach_kernel_driver() or >> >> libusb20_dev_detach_kernel_driver() >> >> --HPS > > I can probably code that into the application but what I'm looking for > is something that can be stuck into devd's config (or similar) that will > prevent the attachment in the first place when the device is plugged in. > > The issue is that I have multiple "things" that I want to talk to in > this application at the same time, multiplexing them via threads and > select(). One of them is only a serial driven thing, and thus I have to > live with the reality of a USB serial dongle for those machines that > don't have a built-in serial port. Ideally, I'd like to talk to > everything that can come up on USB native via the ugen interface, which > (for my purposes) is quite good since I don't mind having a second file > handle open for write and, what's better, is that since I can open the > control instance without blowing things up if someone else has the > device open for some purpose I can make very sure I have the right > device with the vendor and product Ids before I start trying to talk to it. > > Unfortunately if it's a serial port all I can do is try to probe it, and > hope that my off-baud (if I get it wrong) inquiry strings don't cause > the device to go insane since (and here's the really bad news) the > serial-only one doesn't honor modem control lines as a means of insuring > a hard reset. Unfortunately since serial USB interfaces have no > consistent order, especially if plugged in after boot, I can't hard-code > a config file entry either. > > If I can prevent this other device from attaching in the first place to > a modem port via umodem then at application start I can iterate over the > /dev/usb/x.y.0 nodes and, when I find the rights ones, open them up. > This leaves me only one possibility in the supported interfaces for a > device that appears as a serial interface which will greatly reduce the > risk of making that particular device insane. > > While I can "detach" at program start this doesn't help me with a > hot-plug possibility; if I can't prevent the attachment in the first > place then I may as well live with the risk of fraggling the "wrong" > serial device since if someone plugs or unplugs while it's running I > have to accept that risk anyway. > Hi, This sounds like an USB quirk. We currently don't have such a quirk, but feel free to make a PR for it. A temporary workaround is to unconfigure the device in devd, until the real driver comes around: usbconfig -d X.Y set_config 255 We could possibly add a quirk to leave devices unconfigured after plug. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5724CE1D.3070105>