Adding new MBIM extension CID?

[Aleksander Morgado]

Opened a new bug for this one, so that it doesn't get lost:

https://bugs.freedesktop.org/show_bug.cgi?id=77225

On Tue, Mar 25, 2014 at 10:16 AM, Scott Lee <sclee at nvidia.com> wrote:
> 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> 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>
>> 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.
> ________________________________



-- 
Aleksander
https://aleksander.es