[PATCH] Add DEVICE_OPEN_FLAG_DATA_FORMAT

[Dan Williams]

On Fri, 2012-09-07 at 22:04 +0200, Aleksander Morgado wrote:
> >> 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.

Dan