1. 09 8月, 2017 1 次提交
    • B
      qmi_wwan: fix NULL deref on disconnect · bbae08e5
      Bjørn Mork 提交于
      qmi_wwan_disconnect is called twice when disconnecting devices with
      separate control and data interfaces.  The first invocation will set
      the interface data to NULL for both interfaces to flag that the
      disconnect has been handled.  But the matching NULL check was left
      out when qmi_wwan_disconnect was added, resulting in this oops:
      
        usb 2-1.4: USB disconnect, device number 4
        qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' usb-0000:00:1d.0-1.4, WWAN/QMI device
        BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
        IP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
        PGD 0
        P4D 0
        Oops: 0000 [#1] SMP
        Modules linked in: <stripped irrelevant module list>
        CPU: 2 PID: 33 Comm: kworker/2:1 Tainted: G            E   4.12.3-nr44-normandy-r1500619820+ #1
        Hardware name: LENOVO 4291LR7/4291LR7, BIOS CBET4000 4.6-810-g50522254fb 07/21/2017
        Workqueue: usb_hub_wq hub_event [usbcore]
        task: ffff8c882b716040 task.stack: ffffb8e800d84000
        RIP: 0010:qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
        RSP: 0018:ffffb8e800d87b38 EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
        RDX: 0000000000000001 RSI: ffff8c8824f3f1d0 RDI: ffff8c8824ef6400
        RBP: ffff8c8824ef6400 R08: 0000000000000000 R09: 0000000000000000
        R10: ffffb8e800d87780 R11: 0000000000000011 R12: ffffffffc07ea0e8
        R13: ffff8c8824e2e000 R14: ffff8c8824e2e098 R15: 0000000000000000
        FS:  0000000000000000(0000) GS:ffff8c8835300000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00000000000000e0 CR3: 0000000229ca5000 CR4: 00000000000406e0
        Call Trace:
         ? usb_unbind_interface+0x71/0x270 [usbcore]
         ? device_release_driver_internal+0x154/0x210
         ? qmi_wwan_unbind+0x6d/0xc0 [qmi_wwan]
         ? usbnet_disconnect+0x6c/0xf0 [usbnet]
         ? qmi_wwan_disconnect+0x87/0xc0 [qmi_wwan]
         ? usb_unbind_interface+0x71/0x270 [usbcore]
         ? device_release_driver_internal+0x154/0x210
      Reported-and-tested-by: NNathaniel Roach <nroach44@gmail.com>
      Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support")
      Cc: Daniele Palmas <dnlplm@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bbae08e5
  2. 03 8月, 2017 1 次提交
  3. 16 6月, 2017 2 次提交
    • J
      networking: make skb_push & __skb_push return void pointers · d58ff351
      Johannes Berg 提交于
      It seems like a historic accident that these return unsigned char *,
      and in many places that means casts are required, more often than not.
      
      Make these functions return void * and remove all the casts across
      the tree, adding a (u8 *) cast only where the unsigned char pointer
      was used directly, all done with the following spatch:
      
          @@
          expression SKB, LEN;
          typedef u8;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - *(fn(SKB, LEN))
          + *(u8 *)fn(SKB, LEN)
      
          @@
          expression E, SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          type T;
          @@
          - E = ((T *)(fn(SKB, LEN)))
          + E = fn(SKB, LEN)
      
          @@
          expression SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - fn(SKB, LEN)[0]
          + *(u8 *)fn(SKB, LEN)
      
      Note that the last part there converts from push(...)[0] to the
      more idiomatic *(u8 *)push(...).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d58ff351
    • J
      networking: introduce and use skb_put_data() · 59ae1d12
      Johannes Berg 提交于
      A common pattern with skb_put() is to just want to memcpy()
      some data into the new space, introduce skb_put_data() for
      this.
      
      An spatch similar to the one for skb_put_zero() converts many
      of the places using it:
      
          @@
          identifier p, p2;
          expression len, skb, data;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, len);
          |
          -memcpy(p, data, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb, data;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, sizeof(*p));
          |
          -memcpy(p, data, sizeof(*p));
          )
      
          @@
          expression skb, len, data;
          @@
          -memcpy(skb_put(skb, len), data, len);
          +skb_put_data(skb, data, len);
      
      (again, manually post-processed to retain some comments)
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59ae1d12
  4. 14 6月, 2017 1 次提交
  5. 08 6月, 2017 1 次提交
    • D
      net: Fix inconsistent teardown and release of private netdev state. · cf124db5
      David S. Miller 提交于
      Network devices can allocate reasources and private memory using
      netdev_ops->ndo_init().  However, the release of these resources
      can occur in one of two different places.
      
      Either netdev_ops->ndo_uninit() or netdev->destructor().
      
      The decision of which operation frees the resources depends upon
      whether it is necessary for all netdev refs to be released before it
      is safe to perform the freeing.
      
      netdev_ops->ndo_uninit() presumably can occur right after the
      NETDEV_UNREGISTER notifier completes and the unicast and multicast
      address lists are flushed.
      
      netdev->destructor(), on the other hand, does not run until the
      netdev references all go away.
      
      Further complicating the situation is that netdev->destructor()
      almost universally does also a free_netdev().
      
      This creates a problem for the logic in register_netdevice().
      Because all callers of register_netdevice() manage the freeing
      of the netdev, and invoke free_netdev(dev) if register_netdevice()
      fails.
      
      If netdev_ops->ndo_init() succeeds, but something else fails inside
      of register_netdevice(), it does call ndo_ops->ndo_uninit().  But
      it is not able to invoke netdev->destructor().
      
      This is because netdev->destructor() will do a free_netdev() and
      then the caller of register_netdevice() will do the same.
      
      However, this means that the resources that would normally be released
      by netdev->destructor() will not be.
      
      Over the years drivers have added local hacks to deal with this, by
      invoking their destructor parts by hand when register_netdevice()
      fails.
      
      Many drivers do not try to deal with this, and instead we have leaks.
      
      Let's close this hole by formalizing the distinction between what
      private things need to be freed up by netdev->destructor() and whether
      the driver needs unregister_netdevice() to perform the free_netdev().
      
      netdev->priv_destructor() performs all actions to free up the private
      resources that used to be freed by netdev->destructor(), except for
      free_netdev().
      
      netdev->needs_free_netdev is a boolean that indicates whether
      free_netdev() should be done at the end of unregister_netdevice().
      
      Now, register_netdevice() can sanely release all resources after
      ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
      and netdev->priv_destructor().
      
      And at the end of unregister_netdevice(), we invoke
      netdev->priv_destructor() and optionally call free_netdev().
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf124db5
  6. 18 5月, 2017 1 次提交
  7. 03 5月, 2017 1 次提交
  8. 14 4月, 2017 1 次提交
  9. 04 4月, 2017 1 次提交
    • G
      net: usbnet: support 64bit stats · c8b5d129
      Greg Ungerer 提交于
      Add support for the net stats64 counters to the usbnet core. With that
      in place put the hooks into every usbnet driver to use it.
      
      This is a strait forward addition of 64bit counters for RX and TX packet
      and byte counts. It is done in the same style as for the other net drivers
      that support stats64. Note that the other stats fields remain as 32bit
      sized values (error counts, etc).
      
      The motivation to add this is that it is not particularly difficult to
      get the RX and TX byte counts to wrap on 32bit platforms.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8b5d129
  10. 26 3月, 2017 1 次提交
  11. 22 3月, 2017 2 次提交
  12. 02 3月, 2017 1 次提交
  13. 25 1月, 2017 1 次提交
  14. 03 12月, 2016 1 次提交
  15. 13 10月, 2016 1 次提交
  16. 29 3月, 2016 1 次提交
    • B
      qmi_wwan: add "D-Link DWM-221 B1" device id · e84810c7
      Bjørn Mork 提交于
      Thomas reports:
      "Windows:
      
      00 diagnostics
      01 modem
      02 at-port
      03 nmea
      04 nic
      
      Linux:
      
      T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2001 ProdID=7e19 Rev=02.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
      Reported-by: NThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e84810c7
  17. 18 3月, 2016 1 次提交
  18. 04 3月, 2016 1 次提交
  19. 24 2月, 2016 1 次提交
  20. 17 2月, 2016 1 次提交
    • B
      qmi_wwan: add "4G LTE usb-modem U901" · aac8d3c2
      Bjørn Mork 提交于
      Thomas reports:
      
      T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=05c6 ProdID=6001 Rev=00.00
      S:  Manufacturer=USB Modem
      S:  Product=USB Modem
      S:  SerialNumber=1234567890ABCDEF
      C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      Reported-by: NThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aac8d3c2
  21. 11 1月, 2016 1 次提交
  22. 07 1月, 2016 1 次提交
  23. 18 12月, 2015 1 次提交
  24. 07 12月, 2015 1 次提交
    • B
      net: qmi_wwan: should hold RTNL while changing netdev type · 6c730080
      Bjørn Mork 提交于
      The notifier calls were thrown in as a last-minute fix for an
      imagined "this device could be part of a bridge" problem. That
      revealed a certain lack of locking.  Not to mention testing...
      
      Avoid this splat:
      
      RTNL: assertion failed at net/core/dev.c (1639)
      CPU: 0 PID: 4293 Comm: bash Not tainted 4.4.0-rc3+ #358
      Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
       0000000000000000 ffff8800ad253d60 ffffffff8122f7cf ffff8800ad253d98
       ffff8800ad253d88 ffffffff813833ab 0000000000000002 ffff880230f48560
       ffff880230a12900 ffff8800ad253da0 ffffffff813833da 0000000000000002
      Call Trace:
       [<ffffffff8122f7cf>] dump_stack+0x4b/0x63
       [<ffffffff813833ab>] call_netdevice_notifiers_info+0x3d/0x59
       [<ffffffff813833da>] call_netdevice_notifiers+0x13/0x15
       [<ffffffffa09be227>] raw_ip_store+0x81/0x193 [qmi_wwan]
       [<ffffffff8131e149>] dev_attr_store+0x20/0x22
       [<ffffffff811d858b>] sysfs_kf_write+0x49/0x50
       [<ffffffff811d8027>] kernfs_fop_write+0x10a/0x151
       [<ffffffff8117249a>] __vfs_write+0x26/0xa5
       [<ffffffff81085ed4>] ? percpu_down_read+0x53/0x7f
       [<ffffffff81174c9e>] ? __sb_start_write+0x5f/0xb0
       [<ffffffff81174c9e>] ? __sb_start_write+0x5f/0xb0
       [<ffffffff81172c37>] vfs_write+0xa3/0xe7
       [<ffffffff811734ad>] SyS_write+0x50/0x7e
       [<ffffffff8145c517>] entry_SYSCALL_64_fastpath+0x12/0x6f
      
      Fixes: 32f7adf6 ("net: qmi_wwan: support "raw IP" mode")
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c730080
  25. 05 12月, 2015 3 次提交
    • B
      net: qmi_wwan: support "raw IP" mode · 32f7adf6
      Bjørn Mork 提交于
      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: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32f7adf6
    • B
      net: qmi_wwan: remove 1199:9070 device id · 544c8f65
      Bjørn Mork 提交于
      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: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      544c8f65
    • B
      net: qmi_wwan: MDM9x30 specific power management · 93725149
      Bjørn Mork 提交于
      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: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93725149
  26. 19 11月, 2015 1 次提交
    • B
      net: qmi_wwan: add XS Stick W100-2 from 4G Systems · 68242a5a
      Bjørn Mork 提交于
      Thomas reports
      "
      4gsystems sells two total different LTE-surfsticks under the same name.
      ..
      The newer version of XS Stick W100 is from "omega"
      ..
      Under windows the driver switches to the same ID, and uses MI03\6 for
      network and MI01\6 for modem.
      ..
      echo "1c9e 9b01" > /sys/bus/usb/drivers/qmi_wwan/new_id
      echo "1c9e 9b01" > /sys/bus/usb-serial/drivers/option1/new_id
      
      T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=1c9e ProdID=9b01 Rev=02.32
      S:  Manufacturer=USB Modem
      S:  Product=USB Modem
      S:  SerialNumber=
      C:  #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      
      Now all important things are there:
      
      wwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at)
      
      There is also ttyUSB0, but it is not usable, at least not for at.
      
      The device works well with qmi and ModemManager-NetworkManager.
      "
      Reported-by: NThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68242a5a
  27. 06 11月, 2015 1 次提交
    • P
      USB: qmi_wwan: Add quirk for Quectel EC20 Mini PCIe module · b3d8cf01
      Petr Štetiar 提交于
      This device has same vendor and product IDs as G2K devices, but it has
      different number of interfaces(4 vs 5) and also different interface
      layout where EC20 has QMI on interface 4 instead of 0.
      
      lsusb output:
      
      	Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000
      	Device Descriptor:
      	  bLength                18
      	  bDescriptorType         1
      	  bcdUSB               2.00
      	  bDeviceClass            0 (Defined at Interface level)
      	  bDeviceSubClass         0
      	  bDeviceProtocol         0
      	  bMaxPacketSize0        64
      	  idVendor           0x05c6 Qualcomm, Inc.
      	  idProduct          0x9215 Acer Gobi 2000 Wireless Modem
      	  bcdDevice            2.32
      	  iManufacturer           1 Quectel
      	  iProduct                2 Quectel LTE Module
      	  iSerial                 0
      	  bNumConfigurations      1
      	  Configuration Descriptor:
      	    bLength                 9
      	    bDescriptorType         2
      	    wTotalLength          209
      	    bNumInterfaces          5
      	    bConfigurationValue     1
      	    iConfiguration          0
      	    bmAttributes         0xa0
      	      (Bus Powered)
      	      Remote Wakeup
      	    MaxPower              500mA
      Signed-off-by: NPetr Štetiar <ynezz@true.cz>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3d8cf01
  28. 03 11月, 2015 1 次提交
  29. 22 10月, 2015 1 次提交
  30. 16 9月, 2015 1 次提交
  31. 01 9月, 2015 1 次提交
  32. 18 8月, 2015 1 次提交
  33. 21 7月, 2015 2 次提交
  34. 04 3月, 2015 1 次提交
  35. 03 1月, 2015 1 次提交
    • K
      qmi_wwan: Set random MAC on devices with buggy fw · 531ad428
      Kristian Evensen 提交于
      Some buggy firmwares export an incorrect MAC address (00:a0:c6:00:00:00). This
      makes for example checking devices for random MAC addresses tricky, and you
      might end up with multiple network interfaces with the same address.
      
      This patch tries to fix, or at least improve, the situation by setting the MAC
      address of devices with this firmware bug to a random address. I tested the
      patch with two devices that has this firmware bug (Huawei E398 and E392), and
      network traffic worked fine after changing the address.
      Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      531ad428