[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().

-- 
Aleksander