Re: [PATCH 0/6] net: qmi_wwan: MDM9x30 support

[Dan Williams <dcbw@redhat.com>]

On Thu, 2015-12-03 at 19:24 +0100, Bjørn Mork wrote:
> We add new device IDs all the time, often without any testing on
> actual hardware. This is usually OK as long as the device is similar
> to already supported devices, using the same chipset and firmware
> basis.  But the Sierra Wireless MC7455 is an example of a new chipset
> generation. Adding it based on assumed similarity with its ancestors
> proved too optimistic.
> 
> This series adds the missing bits and pieces necessary to support LTE
> Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks
> to
> Sierra Wireless for providing MC7455 samples for testing
> 
> The most important change is the "raw-ip" support. The series also
> adds a necessary control request, removes an unsupported device ID,
> and adds a driver specific entry in MAINTAINERS.
> 
> A few random notes about "raw-ip":
> 
> "I rather have these all running in raw IP mode. The 802.3 framing is
> utterly stupid." - Marcel Holtmann in Jan 2012 [1]
> 
> Marcel was right.  I should have listened to him. What more can I
> say?

The decision was less clear-cut at the time, since all the devices did
support 802.3 framing and DHCP.  And people wanted easy-1-2-3 DHCP and
bridging capability too.  We still get a lot of people asking about
issues with DHCP and even bridging.  802.3 makes it *look* simple but
of course we know it's not that simple...

> The 802.3 framing has provided a steady supply of firmware bugs for
> many years. We've added driver workarounds for many of these, but
> there are still known bugs where the workaround is so yucky that we
> have refused to apply it. But all that is over now.  The latest
> generation Qualcomm chips no longer supports 802.3 framing at all.
> 
> I had two open questions regarding the "raw-ip" userspace API:
> 
> 1) Should we continue faking an ethernet device, even if we don't use
>    the L2 headers on the USB link anymore?
> 
>    There was a vote in favour of the "headerless" device. This is the
>    honest representation of the hardware/firmware interface.

I like the approach of the current patchset where it's more like a tun
device.  Simple.

> 2) What input should the driver base its framing on?
> 
>    Snooping or directly manipulating QMI is considered out of the
>    question. We delegated all QMI handling to userspace from the
>    beginning.
> 
>    We have so far required userspace to configure the firmware for
>    "802.3" framing, or fail if that proved impossible.  This
>    requirement is now changed.  Userspace must now inform the driver
>    if it negotiates "raw-ip" framing.  Two alternative interfaces
> were
>    proposed:
>     - ethtool private driver flag, or
>     - sysfs file
> 
>    The NetworkManager/ModemManager developers were in favour of the
>    sysfs alternative.

Sysfs is the easiest for most things to touch; ethtool requires being
able to do ioctls and bit operations or shell out to ethtool.  Just
stating the reasons for my above vote.

Dan

> These questions (or any other you migh have :) are of course still
> open.  This patch set presents the solutions I currently prefer,
> considering the above.
> 
> All comments are appreciated, even simple '+1' ones.
> 
> 
> Bjørn
> 
> [1] http://www.spinics.net/lists/linux-usb/msg57056.html
> 
> 
> Bjørn Mork (6):
>   net: qmi_wwan: MDM9x30 specific power management
>   net: qmi_wwan: remove 1199:9070 device id
>   usbnet: allow mini-drivers to consume L2 headers
>   net: qmi_wwan: support "raw IP" mode
>   net: qmi_wwan: document the qmi/raw_ip sysfs file
>   MAINTAINERS: add qmi_wwan driver entry
> 
>  Documentation/ABI/testing/sysfs-class-net-qmi |  23 +++++
>  MAINTAINERS                                   |   7 ++
>  drivers/net/usb/qmi_wwan.c                    | 138
> +++++++++++++++++++++++++-
>  drivers/net/usb/usbnet.c                      |   5 +-
>  4 files changed, 169 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-net-qmi
>