Prevent attach of modem serial emulated device on USB attach?

[Karl Denninger]

On 4/30/2016 10:24, Hans Petter Selasky wrote:
> 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

Is that persistent (and if so, where is it written?)  I didn't find
documentation on that command in usbconfig's man page...

I don't think sending a PR for this is the right thing to do since other
people who use this same device may *want* the serial interface
emulation.....

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20160430/b216a471/attachment.bin>