Greg Suarez <
gpsuarez2512 gmail com> writes:
> On Mon, Jul 16, 2012 at 12:28 AM, Bjørn Mork <
bjorn mork no> wrote:
>
>> If I understand this correctly, MBIM devices will combine CDC NCM with a
>> MBIM control channel in the exact same way QMI devices combine CDC ECM
>> with a QMI control channel. That means that the driver support could be
>> done as simple as combining cdc_ncm with the cdc_wdm subdriver (either
>> in the existing cdc_ncm driver, or as a new separate driver reusing code
>> from cdc_ncm).
>>
>> If this was done, then we would have the MBIM control channel exported
>> to userspace as a /dev/cdc-wdmX device, exactly like qmi_wwan exports
>> its QMI control channel. Leaving MBIM control protocol implementation
>> for userspace make sense for the same reasons it made sense to leave QMI
>> implementation for userspace. Boy, am I happy Marcel and others
>> convinced me to do that :-)
>>
>
> I was on the same line of thinking but wasn't aware of the QMI driver.
> Could you point out its location to me?
It's in mainline from 3.4:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/net/usb/qmi_wwan.c
The approach is pretty simple: Reuse the existing cdc_wdm driver as a
subdriver, giving it full ownership of the status interrupt endpoint.
cdc_wdm exports whatever protocol is encapsulated in CDC directly as a
character device. The driver does not care about the contents at all,
leaving that to userspace. The bulk endpoints are handled by a normal
usbnet based minidriver. The only difference from any other minidriver
like cdc_ether, is that the status endpoint is unavailable. But the CDC
notifications are pretty useless anyway, when you have access to a full
management protocol like QMI or MBIM.
The exact same should work equally well for MBIM. The network driver
part must of course be different, and a lot more complex. But most of
it is already done in cdc_ncm. Add push/pull of an ethernet
pseudo-header to make the raw IP packets appear as ethernet (there are
other options, but I believe adding a dummy header is best), and the
registration of the subdriver, and that's it!
Execpt of course for everything I forgot :-)
If I had a device, I would have started with a very simple usbnet +
cdc_wdm driver, verifying that userspace access to the MBIM protocol
worked as assumed. In fact, qmi_wwan qualifies as that simple driver.
Just add a MBIM class matching rule there and go test MBIM management
from userspace.
The network interface will of course be non-functional. To add support
for that, I would look thoroughly at cdc_ncm to find out which parts
could be reused and how to best do that without copying any code. Then
I would start exporting the parts of cdc_ncm that I needed and integrate
them in the new driver.
Another approach, which might result in simpler code and therefore be
better, would be adding a few extra functions to cdc_ncm and just add
another driver instance there for MBIM. Might be best, given the amount
of code that could and should be shared between these two drivers.
Last, there is the question of whether you should bother with the
Microsoft specific descriptors (the magic 0xee string descriptor and
it's friends) or not. I don't think that is necessary, and there are
some reasons to stay away. But then I haven't seen a MBIM device yet.
Could be that you need those descriptors to figure out the different
settings, in particular how to enable the alternate functions.
>> A question back to you, Greg: Why do you ask?
>
>
> I ask because I've been assigned to either come up with a MBIM driver or
> help with an existing effort.
Ah, good. Then that's solved :-)
May I ask who assigns such fun tasks?
>> Do you know of any
>> device? Or planned device? Where can I get one? :-)
>>
>
> I should be getting a dev board sometime in the next few weeks. I don't
> even know the manufacturer.
> Where can you get one? no idea.
OK. I'll see what pops up.
Bjørn
