Prevent attach of modem serial emulated device on USB attach?

[Hans Petter Selasky]

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