Adding new MBIM extension CID?

Scott Lee sclee at nvidia.com
Tue Mar 25 02:16:00 PDT 2014


Thanks Arnaud for the patch.
Yes we're doing exactly the same thing -- although we are using a different hack for internal test.
We modified "mbim_message_command_new" so we pass UUID as parameter instead by getting it from whitelist.
This way we don't need to register anything and let our device to parse and verify the UUID and CID.

Cheers,
Scott

From: benchan at google.com [mailto:benchan at google.com] On Behalf Of Ben Chan
Sent: Tuesday, March 25, 2014 12:53 AM
To: Dan Williams
Cc: Aleksander Morgado; Scott Lee; libmbim-devel at lists.freedesktop.org; Arnaud Desmier
Subject: Re: Adding new MBIM extension CID?



On Mon, Mar 24, 2014 at 8:40 AM, Dan Williams <dcbw at redhat.com<mailto:dcbw at redhat.com>> wrote:
On Mon, 2014-03-24 at 16:18 +0100, Aleksander Morgado wrote:
> On Mon, Mar 24, 2014 at 12:25 PM, Arnaud Desmier <adesmier at sequans.com<mailto:adesmier at sequans.com>> wrote:
> > We get into the same troubles on our side but it's for UUID, not CID. you
> > can try attached patch to allow you to register custom UUID and so get
> > access to your own CID.
> >
> >  * use mbim_register_custom_service API to register a new UUID
> >  * use mbim_unregister_custom_service API unregister it
>
>
> I believe we should make this logic part of libmbim. What do others think?
> That patch would need some cleanup to follow coding style and other
> minor things, though.
Yeah, agreed.

For a library API perspective, it's not a bad idea to add hooks in libmbim, which would allow an application to implement custom device services using libmbim.

The extensibility in MBIM is unavoidable for practical reasons but does come at a cost, IMHO. Let's hope subsequent MBIM specifications would standardize more common services, so that we don't end up having many versions of the same service, like we did to AT.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140325/ffefc20f/attachment.html>


More information about the libmbim-devel mailing list