1. 03 May, 2013 1 commit
  2. 19 Apr, 2013 3 commits
    • Bjørn Mork's avatar
      net: qmi_wwan: prevent duplicate mac address on link (firmware bug workaround) · cc6ba5fd
      Bjørn Mork authored
      
      
      We normally trust and use the CDC functional descriptors provided by a
      number of devices.  But some of these will erroneously list the address
      reserved for the device end of the link.  Attempting to use this on
      both the device and host side will naturally not work.
      
      Work around this bug by ignoring the functional descriptor and assign a
      random address instead in this case.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc6ba5fd
    • Bjørn Mork's avatar
      net: qmi_wwan: fixup destination address (firmware bug workaround) · 6483bdc9
      Bjørn Mork authored
      
      
      Received packets are sometimes addressed to 00:a0:c6:00:00:00
      instead of the address the device firmware should have learned
      from the host:
      
      321.224126 77.16.85.204 -> 148.122.171.134 ICMP 98 Echo (ping) request  id=0x4025, seq=64/16384, ttl=64
      
      0000  82 c0 82 c9 f1 67 82 c0 82 c9 f1 67 08 00 45 00   .....g.....g..E.
      0010  00 54 00 00 40 00 40 01 57 cc 4d 10 55 cc 94 7a   .T..@.@.W.M.U..z
      0020  ab 86 08 00 62 fc 40 25 00 40 b2 bc 6e 51 00 00   ....b.@%.@..nQ..
      0030  00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15   ..k.............
      0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !"#$%
      0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345
      0060  36 37                                             67
      
      321.240607 148.122.171.134 -> 77.16.85.204 ICMP 98 Echo (ping) reply    id=0x4025, seq=64/16384, ttl=55
      
      0000  00 a0 c6 00 00 00 02 50 f3 00 00 00 08 00 45 00   .......P......E.
      0010  00 54 00 56 00 00 37 01 a0 76 94 7a ab 86 4d 10   .T.V..7..v.z..M.
      0020  55 cc 00 00 6a fc 40 25 00 40 b2 bc 6e 51 00 00   U...j.@%.@..nQ..
      0030  00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15   ..k.............
      0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !"#$%
      0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345
      0060  36 37                                             67
      
      The bogus address is always the same, and matches the address
      suggested by many devices as a default address.  It is likely a
      hardcoded firmware default.
      
      The circumstances where this bug has been observed indicates that
      the trigger is related to timing or some other factor the host
      cannot control. Repeating the exact same configuration sequence
      that caused it to trigger once, will not necessarily cause it to
      trigger the next time. Reproducing the bug is therefore difficult.
      This opens up a possibility that the bug is more common than we can
      confirm, because affected devices often will work properly again
      after a reset.  A procedure most users are likely to try out before
      reporting a bug.
      
      Unconditionally rewriting the destination address if the first digit
      of the received packet is 0, is considered an acceptable compromise
      since we already have to inspect this digit.  The simplification will
      cause unnecessary rewrites if the real address starts with 0, but this
      is still better than adding additional tests for this particular case.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6483bdc9
    • Bjørn Mork's avatar
      net: qmi_wwan: fixup missing ethernet header (firmware bug workaround) · 6ff509af
      Bjørn Mork authored
      
      
      A number of LTE devices from different vendors all suffer from the
      same firmware bug: Most of the packets received from the device while
      it is attached to a LTE network will not have an ethernet header. The
      devices work as expected when attached to 2G or 3G networks, sending
      an ethernet header with all packets.
      
      This driver is not aware of which network the modem attached to, and
      even if it were there are still some packet types which are always
      received with the header intact.
      
      All devices supported by this driver have severely limited
      networking capabilities:
       - can only transmit IPv4, IPv6 and possibly ARP
       - can only support a single host hardware address at any time
       - will only do point-to-point communcation with the host
      
      Because of this, we are able to reliably identify any bogus raw IP
      packets by simply looking at the 4 IP version bits.  All we need to
      do is to avoid 4 or 6 in the first digit of the mac address.  This
      workaround ensures this, and fix up the received packets as necessary.
      
      Given the distribution of the bug, it is believed that the source is
      the chipset vendor.  The devices which are verified to be affected are:
       Huawei E392u-12 (Qualcomm MDM9200)
       Pantech UML290  (Qualcomm MDM9600)
       Novatel USB551L (Qualcomm MDM9600)
       Novatel E362    (Qualcomm MDM9600)
      
      It is believed that the bug depend on firmware revision, which means
      that possibly all devices based on the above mentioned chipset may be
      affected if we consider all available firmware revisions.
      
      The information about affected devices and versions is likely
      incomplete.  As the additional overhead for packets not needing this
      fixup is very small, it is considered acceptable to apply the
      workaround to all devices handled by this driver.
      Reported-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ff509af
  3. 25 Mar, 2013 1 commit
  4. 13 Mar, 2013 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: set correct altsetting for Gobi 1K devices · b701f16d
      Bjørn Mork authored
      commit bd877e48 ("net: qmi_wwan: use a single bind function for
      all device types") made Gobi 1K devices fail probing.
      
      Using the number of endpoints in the default altsetting to decide
      whether the function use one or two interfaces is wrong.  Other
      altsettings may provide more endpoints.
      
      With Gobi 1K devices, USB interface #3's altsetting is 0 by default, but
      altsetting 0 only provides one interrupt endpoint and is not sufficent
      for QMI.  Altsetting 1 provides all 3 endpoints required for qmi_wwan
      and works with QMI. Gobi 1K layout for intf#3 is:
      
          Interface Descriptor:  255/255/255
            bInterfaceNumber        3
            bAlternateSetting       0
            Endpoint Descriptor:  Interrupt IN
          Interface Descriptor:  255/255/255
            bInterfaceNumber        3
            bAlternateSetting       1
            Endpoint Descriptor:  Interrupt IN
            Endpoint Descriptor:  Bulk IN
            Endpoint Descriptor:  Bulk OUT
      
      Prior to commit bd877e48, we would call usbnet_get_endpoints
      before giving up finding enough endpoints. Removing the early
      endpoint number test and the strict functional descriptor
      requirement allow qmi_wwan_bind to continue until
      usbnet_get_endpoints has made the final attempt to collect
      endpoints.  This restores the behaviour from before commit
      bd877e48
      
       without losing the added benefit of using a single bind
      function.
      
      The driver has always required a CDC Union functional descriptor
      for two-interface functions. Using the existence of this
      descriptor to detect two-interface functions is the logically
      correct method.
      Reported-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Tested-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b701f16d
  5. 18 Feb, 2013 1 commit
  6. 12 Feb, 2013 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: add Yota / Megafon M100-1 4g modem · 1bf014e5
      Bjørn Mork authored
      
      
      Interface layout:
      
       00 CD-ROM
       01 debug COM port
       02 AP control port
       03 modem
       04 usb-ethernet
      
      Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#=  4 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=0408 ProdID=ea42 Rev= 0.00
      S:  Manufacturer=Qualcomm, Incorporated
      S:  Product=Qualcomm CDMA Technologies MSM
      S:  SerialNumber=353568051xxxxxx
      C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1bf014e5
  7. 06 Feb, 2013 1 commit
  8. 30 Jan, 2013 1 commit
  9. 19 Jan, 2013 1 commit
  10. 16 Jan, 2013 1 commit
  11. 28 Dec, 2012 1 commit
  12. 19 Dec, 2012 1 commit
  13. 17 Dec, 2012 1 commit
  14. 28 Nov, 2012 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: add Huawei E173 · ba695af0
      Bjørn Mork authored
      
      
      The Huawei E173 is a QMI/wwan device which normally appear
      as 12d1:1436 in Linux. The descriptors displayed in that
      mode will be picked up by cdc_ether.  But the modem has
      another mode with a different device ID and a slightly
      different set of descriptors. This is the mode used by
      Windows like this:
      
      3Modem:      USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
      Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001
      Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002
      PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
      Reported-by: default avatarThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba695af0
  15. 26 Oct, 2012 1 commit
  16. 18 Oct, 2012 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: adding more ZTE devices · c6846ee1
      Bjørn Mork authored
      
      
      Analyzed a few Windows driver description files, supporting
      this long list of devices:
      
      %ztewwan.DeviceDesc0002%    = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
      %ztewwan.DeviceDesc0012%    = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
      %ztewwan.DeviceDesc0017%    = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
      %ztewwan.DeviceDesc0021%    = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
      %ztewwan.DeviceDesc0025%    = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
      %ztewwan.DeviceDesc0031%    = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
      %ztewwan.DeviceDesc0042%    = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
      %ztewwan.DeviceDesc0049%    = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
      %ztewwan.DeviceDesc0052%    = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
      %ztewwan.DeviceDesc0055%    = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
      %ztewwan.DeviceDesc0058%    = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
      %ztewwan.DeviceDesc0063%    = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
      %ztewwan.DeviceDesc2002%    = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
      %ztewwan.DeviceDesc0104%    = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
      %ztewwan.DeviceDesc0113%    = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
      %ztewwan.DeviceDesc0118%    = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
      %ztewwan.DeviceDesc0121%    = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
      %ztewwan.DeviceDesc0123%    = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
      %ztewwan.DeviceDesc0124%    = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
      %ztewwan.DeviceDesc0125%    = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
      %ztewwan.DeviceDesc0126%    = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
      %ztewwan.DeviceDesc1008%    = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
      %ztewwan.DeviceDesc1010%    = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
      %ztewwan.DeviceDesc1012%    = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
      %ztewwan.DeviceDesc1402%    = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
      %ztewwan.DeviceDesc0157%    = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
      %ztewwan.DeviceDesc0158%    = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
      %ztewwan.DeviceDesc1401%    = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
      %ztewwan.DeviceDesc0130%    = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
      %ztewwan.DeviceDesc0133%    = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
      %ztewwan.DeviceDesc0176%    = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
      %ztewwan.DeviceDesc0178%    = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
      %ztewwan.DeviceDesc0168%    = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
      ;EuFi890
      %ztewwan.DeviceDesc0191%    = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
      ;AL621
      %ztewwan.DeviceDesc0167%    = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
      ;MF821
      %ztewwan.DeviceDesc0199%    = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
      %ztewwan.DeviceDesc0200%    = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
      %ztewwan.DeviceDesc0257%    = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
      ;MF821V
      %ztewwan.DeviceDesc1018%    = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
      ;MF91
      %ztewwan.DeviceDesc1426%    = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
      ;0141
      %ztewwan.DeviceDesc1247%    = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
      %ztewwan.DeviceDesc1425%    = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
      %ztewwan.DeviceDesc1424%    = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
      %ztewwan.DeviceDesc1252%    = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
      %ztewwan.DeviceDesc1254%    = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
      %ztewwan.DeviceDesc1255A%   = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
      %ztewwan.DeviceDesc1255B%   = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
      %ztewwan.DeviceDesc1256%    = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
      %ztewwan.DeviceDesc1245%    = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
      %ztewwan.DeviceDesc1021%    = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
      
      Adding the ones we were missing.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6846ee1
  17. 21 Sep, 2012 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200 · 42d94dcb
      Bjørn Mork authored
      
      
      One of the modes of Huawei E367 has this QMI/wwan interface:
      
       I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=07 Driver=(none)
       E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
       E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      
      Huawei use subclass and protocol to identify vendor specific
      functions, so adding a new vendor rule for this combination.
      
      The Pantech devices UML290 (106c:3718) and P4200 (106c:3721) use
      the same subclass to identify the QMI/wwan function.  Replace the
      existing device specific UML290 entries with generic vendor matching,
      adding support for the Pantech P4200.
      
      The ZTE MF683 has 6 vendor specific interfaces, all using
      ff/ff/ff for cls/sub/prot.  Adding a match on interface #5 which
      is a QMI/wwan interface.
      
      Cc: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
      Cc: Thomas Schäfer <tschaefer@t-online.de>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Shawn J. Goff <shawn7400@gmail.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42d94dcb
  18. 20 Sep, 2012 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200 · 9db273f4
      Bjørn Mork authored
      
      
      One of the modes of Huawei E367 has this QMI/wwan interface:
      
       I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=07 Driver=(none)
       E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
       E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      
      Huawei use subclass and protocol to identify vendor specific
      functions, so adding a new vendor rule for this combination.
      
      The Pantech devices UML290 (106c:3718) and P4200 (106c:3721) use
      the same subclass to identify the QMI/wwan function.  Replace the
      existing device specific UML290 entries with generic vendor matching,
      adding support for the Pantech P4200.
      
      The ZTE MF683 has 6 vendor specific interfaces, all using
      ff/ff/ff for cls/sub/prot.  Adding a match on interface #5 which
      is a QMI/wwan interface.
      
      Cc: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
      Cc: Thomas Schäfer <tschaefer@t-online.de>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Shawn J. Goff <shawn7400@gmail.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9db273f4
  19. 13 Sep, 2012 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: call subdriver with control intf only · 8624dd2a
      Bjørn Mork authored
      This fixes a hang on suspend due to calling wdm_suspend on
      the unregistered data interface. The hang should have been
      a NULL pointer reference had it not been for a logic error
      in the cdc_wdm code.
      
        commit 230718bd
      
       net: qmi_wwan: bind to both control and data interface
      
      changed qmi_wwan to use cdc_wdm as a subdriver for devices with
      a two-interface QMI/wwan function.  The commit failed to update
      qmi_wwan_suspend and qmi_wwan_resume, which were written to handle
      either a single combined interface function, or no subdriver at all.
      
      The result was that we called into the subdriver both when the
      control interface was suspended and when the data interface was
      suspended.  Calling the subdriver suspend function with an
      unregistered interface is not supported and will make the
      subdriver bug out.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8624dd2a
  20. 10 Sep, 2012 1 commit
  21. 07 Sep, 2012 2 commits
    • Bjørn Mork's avatar
      net: qmi_wwan: use a single bind function for all device types · bd877e48
      Bjørn Mork authored
      
      
      Refactoring the bind code lets us use a common driver_info struct
      for all supported devices, simplifying the code a bit.  The
      real advantage is that devices using the CDC ECM interface
      layout now also can be added dynamically using the new_id sysfs
      interface.  This simplifies testing of new devices.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd877e48
    • Bjørn Mork's avatar
      net: qmi_wwan: increase max QMI message size to 4096 · 3ee24037
      Bjørn Mork authored
      
      
      QMI requests exceeding 1500 bytes are possible and
      device firmware does not handle fragmented messages
      very well.  It is therefore necessary to increase
      the maximum message size from the current 512 bytes.
      
      The protocol message size limit is not documented
      in any publicly known source, but the out of tree
      driver from CodeAurora use 4 kB.  This is therefore
      chosen as the new arbitrary default until the real
      limit is known.
      
      This should allow any QMI message to be transmitted
      without fragmentation, fixing known issues with GPS
      assistance data upload.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ee24037
  22. 01 Sep, 2012 1 commit
  23. 31 Aug, 2012 1 commit
  24. 20 Aug, 2012 1 commit
  25. 14 Aug, 2012 3 commits
    • Bjørn Mork's avatar
      net: qmi_wwan: compress device_id list using macros · 5ea42963
      Bjørn Mork authored
      
      
      Take advantage of the matching macros to make the device id
      list easier to read and maintain.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ea42963
    • Bjørn Mork's avatar
      net: qmi_wwan: add Sierra Wireless devices · 9b469a60
      Bjørn Mork authored
      
      
      Add 6 new devices and one modified device, based on
      information from laptop vendor Windows drivers.
      
      Sony provides a driver with two new devices using
      a Gobi 2k+ layout (1199:68a5 and 1199:68a9).  The
      Sony driver also adds a non-standard QMI/net
      interface to the already supported 1199:9011
      Gobi device. We do not know whether this is an
      alternate interface number or an additional
      interface which might be present, but that doesn't
      really matter.
      
      Lenovo provides a driver supporting 4 new devices:
       - MC7770 (1199:901b) with standard Gobi 2k+ layout
       - MC7700 (0f3d:68a2) with layout similar to MC7710
       - MC7750 (114f:68a2) with layout similar to MC7710
       - EM7700 (1199:901c) with layout similar to MC7710
      
      Note regaring the three devices similar to MC7710:
      
      The Windows drivers only support interface #8 on these
      devices.  The MC7710 can support QMI/net functions on
      interface #19 and #20 as well, and this driver is
      verified to work on interface #19 (a firmware bug is
      suspected to prevent #20 from working).
      
      We do not enable these additional interfaces until they
      either show up in a Windows driver or are verified to
      work in some other way.  Therefore limiting the new
      devices to interface #8 for now.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b469a60
    • Bjørn Mork's avatar
      net: qmi_wwan: use fixed interface number matching · 03304bcb
      Bjørn Mork authored
      
      
      This driver support many composite USB devices where the
      interface class/subclass/protocol provides no information
      about the interface function. Interfaces with different
      functions may all use ff/ff/ff, like this example of
      a device with three serial interfaces and three QMI/wwan
      interfaces:
      
      T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=116 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=1199 ProdID=68a2 Rev= 0.06
      S:  Manufacturer=Sierra Wireless, Incorporated
      S:  Product=MC7710
      S:  SerialNumber=3581780xxxxxx
      C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
      E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#=19 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#=20 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      
      Instead of class/subclass/protocol the vendor use fixed
      interface numbers for each function, and the Windows
      drivers use these numbers to match driver and function.
      
      The driver has had its own interface number whitelisting
      code to simulate this functionality.  Replace this with
      generic interface number matching now that the USB subsystem
      support is there. This
       - removes the need for a driver_info structure per
         interface number,
       - avoids running the probe function for unsupported
         interfaces, and
       - simplifies the code.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03304bcb
  26. 18 Jul, 2012 2 commits
  27. 09 Jul, 2012 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: add ZTE MF60 · 6fecd35d
      Bjørn Mork authored
      
      
      Adding a device with limited QMI support. It does not support
      normal QMI_WDS commands for connection management. Instead,
      sending a QMI_CTL SET_INSTANCE_ID command is required to
      enable the network interface:
      
        01 0f 00 00 00 00 00 00  20 00 04 00 01 01 00 00
      
      A number of QMI_DMS and QMI_NAS commands are also supported
      for optional device management.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6fecd35d
  28. 28 Jun, 2012 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: fix Oops while disconnecting · d9b87068
      Bjørn Mork authored
      
      
      usbnet_disconnect() will set intfdata to NULL before calling
      the minidriver unbind function.  The cdc_wdm subdriver cannot
      know that it is disconnecting until the qmi_wwan unbind
      function has called its disconnect function.  This means that
      we must be able to support the cdc_wdm subdriver operating
      normally while usbnet_disconnect() is running, and in
      particular that intfdata may be NULL.
      
      The only place this matters is in qmi_wwan_cdc_wdm_manage_power
      which is called from cdc_wdm.  Simply testing for NULL
      intfdata there is sufficient to allow it to continue working
      at all times.
      
      Fixes this Oops where a cdc-wdm device was closed while the
      USB device was disconnecting, causing wdm_release to call
      qmi_wwan_cdc_wdm_manage_power after intfdata was set to
      NULL by usbnet_disconnect:
      
      [41819.087460] BUG: unable to handle kernel NULL pointer dereference at 00000080
      [41819.087815] IP: [<f8640458>] qmi_wwan_manage_power+0x68/0x90 [qmi_wwan]
      [41819.088028] *pdpt = 000000000314f001 *pde = 0000000000000000
      [41819.088028] Oops: 0002 [#1] SMP
      [41819.088028] Modules linked in: qmi_wwan option usb_wwan usbserial usbnet
      cdc_wdm nls_iso8859_1 nls_cp437 vfat fat usb_storage bnep rfcomm bluetooth
      parport_pc ppdev binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4
      nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables
      x_tables dm_crypt uvcvideo snd_hda_codec_realtek snd_hda_intel
      videobuf2_core snd_hda_codec joydev videodev videobuf2_vmalloc
      hid_multitouch snd_hwdep arc4 videobuf2_memops snd_pcm snd_seq_midi
      snd_rawmidi snd_seq_midi_event ath9k mac80211 snd_seq ath9k_common ath9k_hw
      ath snd_timer snd_seq_device sparse_keymap dm_multipath scsi_dh coretemp
      mac_hid snd soundcore cfg80211 snd_page_alloc psmouse serio_raw microcode
      lp parport dm_mirror dm_region_hash dm_log usbhid hid i915 drm_kms_helper
      drm r8169 i2c_algo_bit wmi video [last unloaded: qmi_wwan]
      [41819.088028]
      [41819.088028] Pid: 23292, comm: qmicli Not tainted 3.4.0-5-generic #11-Ubuntu GIGABYTE T1005/T1005
      [41819.088028] EIP: 0060:[<f8640458>] EFLAGS: 00010246 CPU: 1
      [41819.088028] EIP is at qmi_wwan_manage_power+0x68/0x90 [qmi_wwan]
      [41819.088028] EAX: 00000000 EBX: 00000000 ECX: 000000c3 EDX: 00000000
      [41819.088028] ESI: c3b27658 EDI: 00000000 EBP: c298bea4 ESP: c298be98
      [41819.088028]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [41819.088028] CR0: 8005003b CR2: 00000080 CR3: 3605e000 CR4: 000007f0
      [41819.088028] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [41819.088028] DR6: ffff0ff0 DR7: 00000400
      [41819.088028] Process qmicli (pid: 23292, ti=c298a000 task=f343b280 task.ti=c298a000)
      [41819.088028] Stack:
      [41819.088028]  00000000 c3b27658 e2a80d00 c298beb0 f864051a c3b27600 c298bec0 f9027099
      [41819.088028]  c2fd6000 00000008 c298bef0 c1147f96 00000001 00000000 00000000 f4e54790
      [41819.088028]  ecf43a00 ecf43a00 c2fd6008 c2fd6000 ebbd7600 ffffffb9 c298bf08 c1144474
      [41819.088028] Call Trace:
      [41819.088028]  [<f864051a>] qmi_wwan_cdc_wdm_manage_power+0x1a/0x20 [qmi_wwan]
      [41819.088028]  [<f9027099>] wdm_release+0x69/0x70 [cdc_wdm]
      [41819.088028]  [<c1147f96>] fput+0xe6/0x210
      [41819.088028]  [<c1144474>] filp_close+0x54/0x80
      [41819.088028]  [<c1046a65>] put_files_struct+0x75/0xc0
      [41819.088028]  [<c1046b56>] exit_files+0x46/0x60
      [41819.088028]  [<c1046f81>] do_exit+0x141/0x780
      [41819.088028]  [<c107248f>] ? wake_up_state+0xf/0x20
      [41819.088028]  [<c1053f48>] ? signal_wake_up+0x28/0x40
      [41819.088028]  [<c1054f3b>] ? zap_other_threads+0x6b/0x80
      [41819.088028]  [<c1047864>] do_group_exit+0x34/0xa0
      [41819.088028]  [<c10478e8>] sys_exit_group+0x18/0x20
      [41819.088028]  [<c15bb7df>] sysenter_do_call+0x12/0x28
      [41819.088028] Code: 04 83 e7 01 c1 e7 03 0f b6 42 18 83 e0 f7 09 f8 88 42
      18 8b 43 04 e8 48 9a dd c8 89 f0 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3 90
      <f0> ff 88 80 00 00 00 0f 94 c0 84 c0 75 b7 31 f6 8b 5d f4 89 f0
      [41819.088028] EIP: [<f8640458>] qmi_wwan_manage_power+0x68/0x90 [qmi_wwan] SS:ESP 0068:c298be98
      [41819.088028] CR2: 0000000000000080
      [41819.149492] ---[ end trace 0944479ff8257f55 ]---
      Reported-by: default avatarMarius Bjørnstad Kotsbak <marius.kotsbak@gmail.com>
      Cc: <stable@vger.kernel.org> # v3.4
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9b87068
  29. 26 Jun, 2012 1 commit
  30. 22 Jun, 2012 1 commit
    • Bjørn Mork's avatar
      net: qmi_wwan: fix Gobi device probing · b9f90eb2
      Bjørn Mork authored
      Ignoring interfaces with additional descriptors is not a reliable
      method for locating the correct interface on Gobi devices.  There
      is at least one device where this method fails:
      https://bbs.archlinux.org/viewtopic.php?id=143506
      
      
      
      The result is that the AT command port (interface #2) is hidden
      from qcserial, preventing traditional serial modem usage:
      
      [   15.562552] qmi_wwan 4-1.6:1.0: cdc-wdm0: USB WDM device
      [   15.562691] qmi_wwan 4-1.6:1.0: wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
      [   15.563383] qmi_wwan: probe of 4-1.6:1.1 failed with error -22
      [   15.564189] qmi_wwan 4-1.6:1.2: cdc-wdm1: USB WDM device
      [   15.564302] qmi_wwan 4-1.6:1.2: wwan1: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
      [   15.564328] qmi_wwan: probe of 4-1.6:1.3 failed with error -22
      [   15.569376] qcserial 4-1.6:1.1: Qualcomm USB modem converter detected
      [   15.569440] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB0
      [   15.570372] qcserial 4-1.6:1.3: Qualcomm USB modem converter detected
      [   15.570430] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB1
      
      Use static interface numbers taken from the interface map in
      qcserial for all Gobi devices instead:
      
      	Gobi 1K USB layout:
      	0: serial port (doesn't respond)
      	1: serial port (doesn't respond)
      	2: AT-capable modem port
      	3: QMI/net
      
      	Gobi 2K+ USB layout:
      	0: QMI/net
      	1: DM/DIAG (use libqcdm from ModemManager for communication)
      	2: AT-capable modem port
      	3: NMEA
      
      This should be more reliable over all, and will also prevent the
      noisy "probe failed" messages.  The whitelisting logic is expected
      to be replaced by direct interface number matching in 3.6.
      Reported-by: default avatarHeinrich Siebmanns (Harvey) <H.Siebmanns@t-online.de>
      Cc: <stable@vger.kernel.org> # v3.4: 00001880 USB: qmi_wwan: Make forced int 4 whitelist generic
      Cc: <stable@vger.kernel.org> # v3.4: f7142e6c
      
       USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
      Cc: <stable@vger.kernel.org> # v3.4
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9f90eb2
  31. 19 Jun, 2012 4 commits
    • Bjørn Mork's avatar
      net: qmi_wwan: use module_usb_driver macro · 677a3d60
      Bjørn Mork authored
      
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      677a3d60
    • Bjørn Mork's avatar
      net: qmi_wwan: shorten driver description · a40345b5
      Bjørn Mork authored
      
      
      The description is used in ethtool fixed length fields.  Make
      it shorter to avoid truncation.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a40345b5
    • Bjørn Mork's avatar
      net: qmi_wwan: bind to both control and data interface · 230718bd
      Bjørn Mork authored
      
      
      Always bind to control interface regardless of whether
      it is a shared interface or not.
      
      A QMI/wwan function is required to provide both a control
      interface (QMI) and a data interface (wwan).  All devices
      supported by this driver do so.  But the vendors may
      choose to use different USB descriptor layouts, and some
      vendors even allow the same device to present different
      layouts.
      
      Most of these devices use a USB descriptor layout with a
      single USB interface for both control and data.  But some
      split control and data into two interfaces, bound together
      by a CDC Union descriptor on the control interface. Before
      the cdc-wdm subdriver support was added, this split was
      used to let cdc-wdm drive the QMI control interface and
      qmi_wwan drive the wwna data interface.
      
      This split driver model has a number of issues:
       - qmi_wwan must match on the data interface descriptor,
         which often are indistiguishable from data interfaces
         belonging to other CDC (like) functions like ACM
       - supporting a single QMI/wwan function requires adding
         the device to two drivers
       - syncronizing the probes among a number of drivers, to
         ensure selecting the correct driver, is difficult unless
         all drivers match on the same interface
      
      This patch resolves these problems by using the same
      probing mechanism as cdc-ether for devices with a two-
      interface USB descriptor layout.  This makes the driver
      behave consistently, supporting both the control and data
      part of the QMI/wwan function, regardless of the USB
      descriptors.
      
      Cc: Thomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      230718bd
    • Bjørn Mork's avatar
      net: qmi_wwan: rearranging to prepare for code sharing · f47cd136
      Bjørn Mork authored
      
      
      Most of the subdriver registration code can be reused for devices
      with separate control and data interfaces.  Move the code a bit
      around to prepare for such reuse.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f47cd136