1. 01 9月, 2015 1 次提交
  2. 18 8月, 2015 1 次提交
  3. 21 7月, 2015 2 次提交
  4. 04 3月, 2015 1 次提交
  5. 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
  6. 17 11月, 2014 1 次提交
  7. 18 7月, 2014 1 次提交
  8. 08 7月, 2014 1 次提交
  9. 07 6月, 2014 1 次提交
  10. 03 6月, 2014 2 次提交
  11. 02 6月, 2014 1 次提交
  12. 28 4月, 2014 7 次提交
  13. 01 4月, 2014 1 次提交
  14. 18 2月, 2014 1 次提交
    • E
      usbnet: remove generic hard_header_len check · eb85569f
      Emil Goode 提交于
      This patch removes a generic hard_header_len check from the usbnet
      module that is causing dropped packages under certain circumstances
      for devices that send rx packets that cross urb boundaries.
      
      One example is the AX88772B which occasionally send rx packets that
      cross urb boundaries where the remaining partial packet is sent with
      no hardware header. When the buffer with a partial packet is of less
      number of octets than the value of hard_header_len the buffer is
      discarded by the usbnet module.
      
      With AX88772B this can be reproduced by using ping with a packet
      size between 1965-1976.
      
      The bug has been reported here:
      
      https://bugzilla.kernel.org/show_bug.cgi?id=29082
      
      This patch introduces the following changes:
      - Removes the generic hard_header_len check in the rx_complete
        function in the usbnet module.
      - Introduces a ETH_HLEN check for skbs that are not cloned from
        within a rx_fixup callback.
      - For safety a hard_header_len check is added to each rx_fixup
        callback function that could be affected by this change.
        These extra checks could possibly be removed by someone
        who has the hardware to test.
      - Removes a call to dev_kfree_skb_any() and instead utilizes the
        dev->done list to queue skbs for cleanup.
      
      The changes place full responsibility on the rx_fixup callback
      functions that clone skbs to only pass valid skbs to the
      usbnet_skb_return function.
      Signed-off-by: NEmil Goode <emilgoode@gmail.com>
      Reported-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eb85569f
  15. 14 2月, 2014 1 次提交
  16. 10 2月, 2014 1 次提交
  17. 05 2月, 2014 1 次提交
  18. 05 11月, 2013 2 次提交
  19. 18 10月, 2013 1 次提交
  20. 01 10月, 2013 3 次提交
  21. 12 9月, 2013 1 次提交
    • B
      net: qmi_wwan: add new Qualcomm devices · 0470667c
      Bjørn Mork 提交于
      Adding the device list from the Windows driver description files
      included with a new Qualcomm MDM9615 based device, "Alcatel-sbell
      ASB TL131 TDD LTE", from China Mobile.  This device is tested
      and verified to work.  The others are assumed to work based on
      using the same Windows driver.
      
      Many of these devices support multiple QMI/wwan ports, requiring
      multiple interface matching entries.  All devices are composite,
      providing a mix of one or more serial, storage or Android Debug
      Brigde functions in addition to the wwan function.
      
      This device list included an update of one previously known device,
      which was incorrectly assumed to have a Gobi 2K layout.  This is
      corrected.
      Reported-by: N王康 <scateu@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0470667c
  22. 04 9月, 2013 1 次提交
    • J
      drivers/net: Convert uses of compare_ether_addr to ether_addr_equal · 7367d0b5
      Joe Perches 提交于
      Use the new bool function ether_addr_equal to add
      some clarity and reduce the likelihood for misuse
      of compare_ether_addr for sorting.
      
      Done via cocci script: (and a little typing)
      
      $ cat compare_ether_addr.cocci
      @@
      expression a,b;
      @@
      -	!compare_ether_addr(a, b)
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	compare_ether_addr(a, b)
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) == 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) != 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) == 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) != 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!!ether_addr_equal(a, b)
      +	ether_addr_equal(a, b)
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7367d0b5
  23. 02 7月, 2013 4 次提交
  24. 24 6月, 2013 1 次提交
  25. 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
  26. 23 5月, 2013 1 次提交