Hi,

The existing ACM driver does not bind to the ACM subinterface because:
- It assumes that an ACM device will have a configuration consisting of
only two interfaces (ACM control & data)


There is some better CDC parsing code available, which could be grafted onto the ACM driver. See the old cdc-ether driver.


I had a look at this, but it doesn't solve the problem since it also assumes a configuration will only have two interfaces. The best way to handle it is to parse the functional descriptors that follow the ACM interface descriptor.

- It assumes the ACM interfaces are #0 and #1 in the configuration


This would be trivial to fix - you can read it from the CDC descriptor.

Again by parsing the union descriptor you can see which are the data & control interfaces. I've written a new version of the probe routine to handle this - I will post a patch shortly.

- It assumes that the protocol will be == 1. According to the CDC_WMC10
spec they could be 2-6 (all variants of AT command set). 3G mobiles will
implement 3gpp 27.007, which is protocol class 5.


The reason for this is that people expect to use AT commands, which IIRC is the protocol 1.

Yes, but protocol numbers 2-6 are all variants of the AT command set. In any case I do not think the ACM driver should refuse to bind to a device because it supports a different protocol set - there might be userspace software out there that supports other protocols.

I have not checked the audio driver. I guess drivers need to be written
for OBEX & other new goodies defined in the standard.


Presumably you can do at least the OBEX stuff in userspace. I think that there is an project working on this (OpenOBEX?).

You are correct, the OBEX stuff can be done in userspace. However a USB driver and interface will still be needed to provide access to the pipe. According to the usb-wmcd spec, the OBEX interface is the same as the ACM but with a few simplifications. It might be possible to adapt the ACM driver so it can also handle the OBEX case & present an interface eg. ttyOBEXn. In this scenario, I guess new major/minor device numbers would be needed? Or maybe use the same major device number but allocate ranges of minors for ttyACM & ttyOBEX.

Or any other ideas?

Do you actually have hardware that implements the standard? Can you say what it is?

Yes I do have a few devices that implement parts of this standard. Unfortunately, beyond saying that they are mobile phones, I can't saw what....

Regards
Mike






------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to