1. 06 Dec, 2015 24 commits
  2. 05 Dec, 2015 8 commits
  3. 04 Dec, 2015 8 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
    • Bjørn Mork's avatar
      40dd0d94
    • Bjørn Mork's avatar
      net: qmi_wwan: support "raw IP" mode · 32f7adf6
      Bjørn Mork authored
      QMI wwan devices have traditionally emulated ethernet devices
      by default. But they have always had the capability of operating
      without any L2 header at all, transmitting and receiving "raw"
      IP packets over the USB link.  This firmware feature used to be
      configurable through the QMI management protocol.
      
      Traditionally there was no way to verify the firmware mode
      without attempting to change it.  And the firmware would often
      disallow changes anyway, i.e. due to a session already being
      established.  In some cases, this could be a hidden firmware
      internal session, completely outside host control.  For these
      reasons, sticking with the "well known" default mode was safest.
      
      But newer generations of QMI hardware and firmware have moved
      towards defaulting to "raw IP" mode instead, followed by an
      increasing number of bugs in the already buggy "802.3" firmware
      implementation. At the same time, the QMI management protocol
      gained the ability to detect the current mode.  This has enabled
      the userspace QMI management application to verify the current
      firmware mode without trying to modify it.
      
      Following this development, the latest QMI hardware and firmware
      (the MDM9x30 generation) has dropped support for "802.3" mode
      entirely. Support for "raw IP" framing in the driver is therefore
      necessary for these devices, and to a certain degree to work
      around problems with the previous generation,
      
      This patch adds support for "raw IP" framing for QMI devices,
      changing the netdev from an ethernet device to an ARPHRD_NONE
      p-t-p device when "raw IP" framing is enabled.
      
      The firmware setup is fully delegated to the QMI userspace
      management application, through simple tunneling of the QMI
      protocol. The driver will therefore not know which mode has been
      "negotiated" between firmware and userspace. Allowing userspace
      to inform the driver of the result through a sysfs switch is
      considered a better alternative than to change the well established
      clean delegation of firmware management to userspace.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32f7adf6
    • Bjørn Mork's avatar
      usbnet: allow mini-drivers to consume L2 headers · 81e0ce79
      Bjørn Mork authored
      Assume the minidriver has taken care of all L2 header parsing
      if it sets skb->protocol.  This allows the minidriver to
      support non-ethernet L2 headers, and even operate without
      any L2 header at all.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81e0ce79
    • Bjørn Mork's avatar
      net: qmi_wwan: remove 1199:9070 device id · 544c8f65
      Bjørn Mork authored
      This turned out to be a bootloader device ID.  No need for
      that in this driver.  It will only provide a single serial
      function.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      544c8f65
    • Bjørn Mork's avatar
      net: qmi_wwan: MDM9x30 specific power management · 93725149
      Bjørn Mork authored
      MDM9x30 based modems appear to go into a deeper sleep when
      suspended without "Remote Wakeup" enabled.  The QMI interface
      will not respond unless a "set DTR" control request is sent
      on resume. The effect is similar to a QMI_CTL SYNC request,
      resetting (some of) the firmware state.
      
      We allow userspace sessions to span multiple character device
      open/close sequences.  This means that userspace can depend
      on firmware state while both the netdev and the character
      device are closed.  We have disabled "needs_remote_wakeup" at
      this point to allow devices without remote wakeup support to
      be auto-suspended.
      
      To make sure the MDM9x30 keeps firmware state, we need to
      keep "needs_remote_wakeup" always set. We also need to
      issue a "set DTR" request to enable the QMI interface.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93725149
    • David S. Miller's avatar
      Merge branch 'hip06-soc' · 43dd7a8b
      David S. Miller authored
      Salil Mehta says:
      
      ====================
      net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem
      
      This PATCH V7 addresses the TAB formatting comments by
      Sergei Shtylyov. Missing TABs at some other palces have
      also been corrected.
      
      PATCH V6:
      This addresses the review comments provided by
      David Miller over the existing use of ENABLE/DISABLE
      hash defines with the code. These hash defines are doing
      a similar job as implicit type bool would do. So these are
      kind of duplicate and are redundant.
      
      PATCH V5:
      This PATCH addresses the review comments by Yuval Mintz
       <Yuval.Mintz@qlogic.com>. This rework of comments are basically
       related to:
       1) styling of the code,
       2) RSS default Key initiailization related code
       3) redundant code removal
      
      PATCH V4:
      This addresses the review comment provided by
      Sergei Shtylyov. The changelog of every patch has also
      been modified.
      
      PATCH V3:
       Addresses the review comment floated by David Miller
      
      PATCH V2:
      1) Bug Fixes and Clean-up: Internally identified
      2) Addresses internal review comments by Kenneth Lee and
         by Huang Daode
      3) Addresses the review comment from "Yisen.Zhuang(Zhuangyuzeng)"
      4) Adds fix from Fengguang Wu for an error generated from
         "kbuild test robot" from Intel
      5) Ethtool support for TSO set option from Lisheng
      
      PATCH V1:
      Adds initial support of Hip06 SoC with below changes:
      This patch-set adds support of new Hisilicon Hip06 SoC to the existing
      (already part of net-next) HNS ethernet driver for Hip05 SoC. Hip06 is
      a multi-core SoC and is a derivative of Hip05 SoC with lots of new
      hardware featres supported like RSS, TSO, hardware VLAN assist etc.
      
      The changes in the driver are mainly due to following:
       1) changes in the DMA descriptor provided by the Hip06 ethernet
          hardware. These changes need to co-exist with already present
          Hip05 DMA descriptor and its operating functions. The decision
          to choose the correct type of DMA descriptor is taken dynamically
          depending upon the version of the hardware (i.e. V1/hip05 or
          V2/hip06, see already existing hisilicon-hns-nic.txt binding file
          for the detailed description version and naming).
       2) To support new features added to the Hip06 ethernet hardware:
          a. RSS (Receive Side Scaling)
          b. TSO (TCP Segment Offload)
          c. Hardware VLAN support (currently we are initializing hardware
             to not assist in stripping the vlan tag at hardware level.
             Proper support of this feature and ethtool would come after
             these patches have been accepted)
      
      Kindly note that, this patchset has been based on latest net-next.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43dd7a8b