[PATCH] Add DEVICE_OPEN_FLAG_DATA_FORMAT

[Dan Williams]

On Thu, 2012-09-06 at 13:09 -0700, Marcel Holtmann wrote:
> Hi Bjorn,
> 
> > > Some devices (like Sierra's MC7700 w/the latest AT&T firmware), default
> > > to a packet data format that's incompatable with qmi_wwan/usbnet.  This results
> > > in us being unable to get a DHCP address or otherwise use the virtual ethernet
> > > port.  Add DEVICE_OPEN_FLAG_DATA_FORMAT to set the data format
> > > to default (no-QoS) and data mode to ethernet when opening.
> > 
> > Explicitly setting the expected mode seems to be wise in any case.
> > 
> > But I am curious: What is the new default?  Raw IP and no QoS? Did
> > anyone find any use for the QoS mode, BTW?
> > 
> > I am asking because it seems we have to add some data interception hooks
> > to cdc_wdm to support MBIM, and I am playing with the idea to let the
> > qmi_wwan snoop on "Set Data Format" messages and just support whatever
> > mode you set.  It can most certainly be done, and it won't be much code
> > either.
> 
> instead of doing some magic snooping, I would prefer that we add some
> ioctl that allows us to list supported modes and allow them to change.
> So userspace can make the call here. And not the kernel doing some magic
> behind the scenes.

Userspace should make this call, but at the moment we're going the 802.3
route on the network interface in the drivers to keep allowing DHCP.
Not all the RawIP mode support is in the kernel, and at least for now, I
don't think it's really necessary to support it, as long as the devices
all support 802.3 mode.  The efficiency argument just isn't that
relevant IMHO.  The CodeAurora trees do have some raw IP support, but
that depends on some icky stuff that's not upstream.  Plus it would
certainly be nice not to have to do magic ioctls if we can help it.

Bjorn: for the QoS stuff, I'd imagine if we get multi-interface devices,
we'd be using the QoS headers to map into Linux SKB priorites during TX
and RX.  That way, if a dedicated bearer is set up with different QoS
values, we can actually follow that all the way through to the TCP/IP
stack on the host side and maybe get some QoS for VOIP.

Dan