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
--
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
