1. 07 Dec, 2015 6 commits
  2. 06 Dec, 2015 24 commits
  3. 05 Dec, 2015 8 commits
  4. 04 Dec, 2015 2 commits
    • David S. Miller's avatar
      Merge branch 'qmi_wwan_MDM9x30' · 2141eaf0
      David S. Miller authored
      Bjørn Mork says:
      
      ====================
      net: qmi_wwan: MDM9x30 support
      
      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 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.
      
      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.
      
      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.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2141eaf0
    • Bjørn Mork's avatar
      MAINTAINERS: add qmi_wwan driver entry · 4521b477
      Bjørn Mork authored
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4521b477