[Bug 235257] snd_uaudio not getting loaded automatically after migration to devmatch

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235257

            Bug ID: 235257
           Summary: snd_uaudio not getting loaded automatically after
                    migration to devmatch
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: usb
          Assignee: usb at FreeBSD.org
          Reporter: maxsteciuk at gmail.com

Certain USB modules such as snd_uaudio, uplcom are not loading automatically
since /etc/devd/usb.conf was replaced by devmatch. When running devmatch tool
with no arguments (as /etc/rc.d/devmatch script has) it does not return any
matches. 

I checked /boot/kernel/linker.hints has the pnpinfo string for uaudio. Also
/sys/dev/sound/usb/uaudio.c has call to USB_PNP_HOST_INFO(uaudio_dev) macro.

>>>audio
>>>snd_uaudio.ko
>>>uhub
>>>M:mask;I:vendor;I:product;L:release;G:release;I:devclass;I:devsubclass;I:devpr>>>oto;I:intclass;I:intsubclass;I:intprotocol;T:mode=host

Yet devmatch was not able to match module by the parsed fields. When debugging 
I noticed the following mismatch condition for type 'I' was hit (values were
different)

/sbin/devmatch/devmatch.c:319-328
>>>ival = getint(&ptr);
>>>...
>>>v = pnpval_as_int(cp + 2, pnpinfo);
>>>...
>>> case 'I':
>>>     if(v != ival) notme++; 

BSDCan 2018 devmatch presentation  mentioned some USB module issues due to
pnpinfo string being too long for 128 byte limit. Is this one of the cases? Or
is this because vendorID/productID of my device is not in the uaudio module 
table?

Could you please help me understand how devmatch is supposed to work for such
cases? Do I need to configure anything else?


Please let me know if additional information is needed.


The environment:
OS:                13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC-NODEBUG  amd64
Build date/time:   2019/01/21 16:38:41

Thanks,
Max

-- 
You are receiving this mail because:
You are the assignee for the bug.