1. 26 3月, 2017 1 次提交
  2. 22 3月, 2017 2 次提交
  3. 02 3月, 2017 1 次提交
  4. 25 1月, 2017 1 次提交
  5. 03 12月, 2016 1 次提交
  6. 13 10月, 2016 1 次提交
  7. 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
  8. 18 3月, 2016 1 次提交
  9. 04 3月, 2016 1 次提交
  10. 24 2月, 2016 1 次提交
  11. 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
  12. 11 1月, 2016 1 次提交
  13. 07 1月, 2016 1 次提交
  14. 18 12月, 2015 1 次提交
  15. 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
  16. 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
  17. 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
  18. 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
  19. 03 11月, 2015 1 次提交
  20. 22 10月, 2015 1 次提交
  21. 16 9月, 2015 1 次提交
  22. 01 9月, 2015 1 次提交
  23. 18 8月, 2015 1 次提交
  24. 21 7月, 2015 2 次提交
  25. 04 3月, 2015 1 次提交
  26. 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
  27. 17 11月, 2014 1 次提交
  28. 18 7月, 2014 1 次提交
  29. 08 7月, 2014 1 次提交
  30. 07 6月, 2014 1 次提交
  31. 03 6月, 2014 2 次提交
  32. 02 6月, 2014 1 次提交
  33. 28 4月, 2014 3 次提交