On Mon, Sep 26, 2011 at 3:57 PM, Oliver Neukum <oneukum@xxxxxxx> wrote: > Am Montag, 26. September 2011, 07:45:40 schrieb Xiaofan Chen: > >> I was actually thinking about this yesterday. I recently ran across this >> bit of code in Linux's cdc-acm.c: >> >> case USB_CDC_CALL_MANAGEMENT_TYPE: >> call_management_function = buffer[3]; >> call_interface_num = buffer[4]; >> if ( (quirks & NOT_A_MODEM) == 0 && >> (call_management_function & 3) != 3) >> dev_err(&intf->dev, "This device cannot do >> calls on its own. It is not a modem.\n"); >> break; >> >> Is it really a standards compliant way to indicate a communication >> class device is not a modem? It seems almost too good to be true!? > > Occasionally something good happens. > >> I pulled up a copy of the spec, and I believe the relevant part is >> section 5.2.3.2 on page 34 to 35. Here is what the spec says >> regarding that byte: >> >> The capabilities that this configuration >> supports: >> >> D7..D2: RESERVED (Reset to zero) >> D1: 0 - Device sends/receives call >> management information only over >> the Communication Class >> interface. >> 1 - Device can send/receive call >> management information over a >> Data Class interface. >> D0: 0 - Device does not handle call >> management itself. >> 1 - Device handles call >> management itself. >> >> The previous bits, in combination, identify >> which call management scenario is used. If bit >> D0 is reset to 0, then the value of bit D1 is >> ignored. In this case, bit D1 is reset to zero for >> future compatibility. >> >> So this does seem to say that if the byte is zero (or the lowest bit >> is zero), the device does not handle call management, which seems >> to mean it can not possibly be a modem. The Linux check should > > Yes. > >> probably only look at the lowest bit, since 0x01 would indicate a >> modem that requires the call management ("AT" commands if ACM) >> sent on the communication interface rather than the data interface >> (which Linux's driver doesn't support). > > Exactly. Using the control endpoint is not a coding problem, as the necessary > code is present in cdc-wdm, but how would you present this to user space. > The assumption that payload and AT commands go through the same character > device is built in pretty hard. > >> Then again, maybe this interpretation of the communication class >> spec is colored by my desire for better usability for non-modem >> devices? > > Not at all, this code path is rarely triggered, but I cannot remember > false positives. > >> Could it really be this easy, just a single bit: 1 = modem, >> 0 = something not a modem. > > In theory it is that simple. > >> Of course, if there's an ECM or other networking descriptor, then >> the network prefs dialog should obviously apply. But if there's an >> ACM descriptor and no ECM or other networking, and that bit is 0, >> is that a good enough standards compliant way to avoid popping >> up the network prefs which causes user confusion when the device >> isn't a modem? > > The capability is already exported via sysfs > > /* > * attributes exported through sysfs > */ > static ssize_t show_caps > (struct device *dev, struct device_attribute *attr, char *buf) > { > struct usb_interface *intf = to_usb_interface(dev); > struct acm *acm = usb_get_intfdata(intf); > > return sprintf(buf, "%d", acm->ctrl_caps); > } > static DEVICE_ATTR(bmCapabilities, S_IRUGO, show_caps, NULL); > > User space just has to look. > > Regards > Oliver > Thanks a lot for the detail explanations. Now Paul has submitted this bug to Apple as Issue #10187399. It is a long thread and Apple initially denied the request by various CDC-ACM users. Once they see your response, I think they are kind of convinced. http://lists.apple.com/archives/usb/2011//Sep/msg00031.html http://lists.apple.com/archives/usb/2011//Sep/msg00032.html http://lists.apple.com/archives/usb/2011//Sep/msg00034.html -- Xiaofan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html