From owner-freebsd-usb@freebsd.org Sat Apr 30 15:20:59 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A877CB0F1E7 for ; Sat, 30 Apr 2016 15:20:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 421F119A2 for ; Sat, 30 Apr 2016 15:20:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8EEA21FE022; Sat, 30 Apr 2016 17:20:55 +0200 (CEST) Subject: Re: Prevent attach of modem serial emulated device on USB attach? To: Karl Denninger , freebsd-usb@freebsd.org References: <08f991ca-0c97-3d29-8b56-5a4ac9f904f3@denninger.net> <5724BDEB.3060502@selasky.org> <8c60b86f-de54-f80d-741d-170829dac1c8@denninger.net> From: Hans Petter Selasky Message-ID: <5724CE1D.3070105@selasky.org> Date: Sat, 30 Apr 2016 17:24:13 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <8c60b86f-de54-f80d-741d-170829dac1c8@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 15:20:59 -0000 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