[PATCH] Add DEVICE_OPEN_FLAG_DATA_FORMAT

[Marcel Holtmann]

Hi Bjorn,

> >> 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.
> 
> I'll save us both some time and just assume that you are correct this
> time as well :-) Snooping the QMI messages is probably not a good idea.
> 
> But I do not think an ioctl is wise either.  Please see
> http://www.spinics.net/lists/netdev/msg209401.html
> 
> I like the way davem leaves no doubt :-)

actually ioctl are not as bad as some kernel developers try to make them
out. They are still used and we are adding them for multiple drivers
every single day. Same goes for sysfs.

Some of the netdev developers that propose netlink for everything are
also confused btw. ;)

That said, I am fine with ethtool approach as well. If that API can be
used for this task, then by all means use an existing one.

> While testing the features, I used the new ethtool --show-priv-flags/
> --set-priv-flags.  Such an implemetation may be accepted upstream, and
> would probably fit your needs as well?  It would use one flag per
> feature (RawIP, QoS) and allow you to query and set these using the
> ethtool API.

Yes, ethtool API seems a good fit. The important point from my side was
to let userspace drive this.

> But I still believe adding this at all should be based on need, like
> some firmware failing in 802.3 mode or someone actually finding a use
> for the QoS header (and documents its usage!).  I don't think we are
> there yet.

Works for me.

Regards

Marcel