Adding new MBIM extension CID?

[Arnaud Desmier]

Can you point me what is wrong in this patch about coding guidelines and 
the other things?

Arnaud

On 09/04/2014 09:16, Aleksander Morgado wrote:
> 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.
>> ________________________________
>
>



-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140409/02af76dc/attachment.html>