[PATCH] Add DEVICE_OPEN_FLAG_DATA_FORMAT

[Aleksander Morgado]

>>>> Ah, looks like we are.  I didn't go to that level of granularity
>>>>> because it didn't seem like our current drivers supported any other
>>>>> mode.
>>>>>
>>>>> The QMI drivers from Sierra Wireless (modified versions of the
>>>>> CodeAurora drivers), explicitly set it to these values regardless of
>>>>> the QMI_CTL version and will fail if unsuccessful.  I can say that
>>>>> SetDataFormat is at least in v1.4 of QMI_CTL.
>>> Yeah, I was working on this earlier this week for the Pantech UML290,
>>> for which the Windows drivers also set RawIP + no-QOS.  Our Linux
>>> drivers expect 802.3 + no-QOS.
>>>
>>> The reason I did the separate flags are:
>>>
>>> 1) at some point, maybe we do want to allow RawIP or QoS headers; I
>>> think QoS headers are most likely because we might want to handle that
>>> better in the future.  I'm not sure we have a case for RawIP yet, until
>>> we find a device that really doesn't support DHCP on the network port.
>>> Plus we don't actually have RawIP support in the kernel yet.
>>>
>>> 2) The Set Data Format command requires both TLVs, so we do need to
>>> allow userspace to pass both options in, which requires that:
>>>
>>> 3) We don't want probing to change the port, so we need to the flags to
>>> affirmatively specify whether to change or not.  That, in conjunction
>>> with (2) caused me to break them out separately.
>>>
>>> In the end, our patches are quite similar, and Aleksander could take
>>> either one.  I put my enums into qmi-enums.h, because we're trying not
>>> to expose the CTL service to clients (they don't really need it) and
>>> there these enums are mostly private due to that; thus it didn't make a
>>> lot of sense to me to create a new qmi-enums-ctl.h just for stuff that's
>>> supposed to be private.
>>
>> Robert, what do you think of Dan's patch? Any problem with including
>> that one instead of yours? The only different really seems to be the
>> extended flags for qmi_device_open().
> 
> My MM patches are also in the MM 'dcbw' branch, FWIW.
> 

I just went on and merged Dan's libqmi and MM branches.

Thanks to both! :-)

-- 
Aleksander