1. 02 7月, 2013 5 次提交
  2. 29 6月, 2013 2 次提交
  3. 20 6月, 2013 1 次提交
  4. 11 6月, 2013 1 次提交
    • B
      qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820 · c2020be3
      Bjørn Mork 提交于
      Another QMI speaking Qualcomm based device, which should be
      driven by qmi_wwan, while cdc_ether should ignore it.
      
      Like on other Huawei devices, the wwan function can appear
      either as a single vendor specific interface or as a CDC ECM
      class function using separate control and data interfaces.
      The ECM control interface protocol is 0xff, likely in an
      attempt to indicate that vendor specific management is
      required.
      
      In addition to the near standard CDC class, Huawei also add
      vendor specific AT management commands to their firmwares.
      This is probably an attempt to support non-Windows systems
      using standard class drivers.  Unfortunately, this part of
      the firmware is often buggy.  Linux is much better off using
      whatever native vendor specific management protocol the
      device offers, and Windows uses, whenever possible. This
      means QMI in the case of Qualcomm based devices.
      
      The E1820 has been verified to work fine with QMI.
      
      Matching on interface number is necessary to distiguish the
      wwan function from serial functions in the single interface
      mode, as both function types will have class/subclass/function
      set to ff/ff/ff.
      
      The control interface number does not change in CDC ECM mode,
      so the interface number matching rule is sufficient to handle
      both modes.  The cdc_ether blacklist entry is only relevant in
      CDC ECM mode, but using a similar interface number based rule
      helps document this as a transfer from one driver to another.
      
      Other Huawei 02/06/ff devices are left with the cdc_ether driver
      because we do not know whether they are based on Qualcomm chips.
      The Huawei specific AT command management is known to be somewhat
      hardware independent, and their usage of these class codes may
      also be independent of the modem hardware.
      Reported-by: NGraham Inggs <graham.inggs@uct.ac.za>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2020be3
  5. 29 5月, 2013 1 次提交
  6. 23 5月, 2013 1 次提交
  7. 21 5月, 2013 1 次提交
  8. 18 5月, 2013 2 次提交
  9. 16 5月, 2013 1 次提交
  10. 09 5月, 2013 3 次提交
  11. 07 5月, 2013 1 次提交
  12. 04 5月, 2013 3 次提交
  13. 30 4月, 2013 3 次提交
  14. 20 4月, 2013 5 次提交
    • B
      net: qmi_wwan: prevent duplicate mac address on link (firmware bug workaround) · cc6ba5fd
      Bjørn Mork 提交于
      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: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc6ba5fd
    • B
      net: qmi_wwan: fixup destination address (firmware bug workaround) · 6483bdc9
      Bjørn Mork 提交于
      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: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6483bdc9
    • B
      net: qmi_wwan: fixup missing ethernet header (firmware bug workaround) · 6ff509af
      Bjørn Mork 提交于
      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: NDan Williams <dcbw@redhat.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ff509af
    • P
      net: vlan: add protocol argument to packet tagging functions · 86a9bad3
      Patrick McHardy 提交于
      Add a protocol argument to the VLAN packet tagging functions. In case of HW
      tagging, we need that protocol available in the ndo_start_xmit functions,
      so it is stored in a new field in the skb. The new field fits into a hole
      (on 64 bit) and doesn't increase the sks's size.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86a9bad3
    • P
      net: vlan: rename NETIF_F_HW_VLAN_* feature flags to NETIF_F_HW_VLAN_CTAG_* · f646968f
      Patrick McHardy 提交于
      Rename the hardware VLAN acceleration features to include "CTAG" to indicate
      that they only support CTAGs. Follow up patches will introduce 802.1ad
      server provider tagging (STAGs) and require the distinction for hardware not
      supporting acclerating both.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f646968f
  15. 18 4月, 2013 1 次提交
  16. 17 4月, 2013 1 次提交
  17. 12 4月, 2013 8 次提交