<div dir="ltr">If we take a step back and think how users will be best served by the mechanism, I think there are several things we could consider as components:<div><br></div><div>*  Could ModemManager perhaps wait X seconds before trying to grab a device (allowing others to have "first pick")?</div>
<div>*  Could it be possible that if someone plugs in a modem, there may (most often) be so big human interaction actions already happening that an interactive mode - potentially with a "remember decision" functionality would be prefectly fine.  It's very seldom that a modem just does a plug'n'play and connect without at least some interaction.</div>
<div>*  (already mentioned) - CDC descriptors to be used for detection - at least having a combination that knowledgable developers can use to 100% tell ModemManager to either white- or blacklist on the fly?</div><div><br>
</div><div>- Lars</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 21, 2014 at 2:36 PM, Bjørn Mork <span dir="ltr"><<a href="mailto:bjorn@mork.no" target="_blank">bjorn@mork.no</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Sven Köhler <<a href="mailto:sven.koehler@gmail.com">sven.koehler@gmail.com</a>> writes:<br>
<br>
> The value of ATTR{bmCapabilities} you find below may be from the CDC ACM<br>
> descriptor instead of the CDC Call Management descriptor.<br>
> At least for my UMTS card that is true, and I see a value of 7 instead<br>
> of 3. My best guess is, that udev doesn't handle it very well if there<br>
> are two fields of the same name in different descriptors of the same device.<br>
<br>
</div>Ah, you're right.  Thanks for clearing that up.  Then it's not going to<br>
be that simple to write a rule processing the CDC Call Management<br>
bmCapabilities.<br>
<br>
This doesn't really have much to do with udev.  It's the driver that<br>
parses the descriptors and export some functional descriptor fields as<br>
sysfs attributes.<br>
<br>
The code making this appear in sysfs/udev is:<br>
<br>
static ssize_t show_caps<br>
(struct device *dev, struct device_attribute *attr, char *buf)<br>
{<br>
        struct usb_interface *intf = to_usb_interface(dev);<br>
        struct acm *acm = usb_get_intfdata(intf);<br>
<br>
        return sprintf(buf, "%d", acm->ctrl_caps);<br>
}<br>
static DEVICE_ATTR(bmCapabilities, S_IRUGO, show_caps, NULL);<br>
<br>
..<br>
                case USB_CDC_ACM_TYPE:<br>
                        ac_management_function = buffer[3];<br>
                        break;<br>
                case USB_CDC_CALL_MANAGEMENT_TYPE:<br>
                        call_management_function = buffer[3];<br>
                        call_interface_num = buffer[4];<br>
                        if ((quirks & NOT_A_MODEM) == 0 && (call_management_function & 3) != 3)<br>
                                dev_err(&intf->dev, "This device cannot do calls on its own. It is not a modem.\n");<br>
                        break;<br>
..<br>
<br>
        acm->ctrl_caps = ac_management_function;<br>
        if (quirks & NO_CAP_LINE)<br>
                acm->ctrl_caps &= ~USB_CDC_CAP_LINE;<br>
<br>
<br>
<br>
So the driver parse and use USB_CDC_CALL_MANAGEMENT_TYPE descriptor, but<br>
it doesn't export any of it.  If MM or other userspace tools want to<br>
inspect it, then the only option is to parse it again out of either the<br>
"descriptors" sysfs field or the /dev/bus/usb character device.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Bjørn<br>
</font></span></blockquote></div><br></div>