1. 18 7月, 2016 1 次提交
  2. 16 6月, 2016 3 次提交
  3. 01 6月, 2016 1 次提交
  4. 24 5月, 2016 1 次提交
  5. 21 5月, 2016 2 次提交
  6. 20 5月, 2016 2 次提交
  7. 18 5月, 2016 1 次提交
    • J
      asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions · cd9e2e5d
      John Stultz 提交于
      In testing with HiKey, we found that since
      commit 3f30b158 ("asix: On RX avoid creating bad Ethernet
      frames"),
      we're seeing lots of noise during network transfers:
      
      [  239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x54ebb5ec, offset 4
      [  239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xcdffe7a2, offset 4
      [  239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x1d36f59d, offset 4
      [  239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xaef3c1e9, offset 4
      [  239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x2881912, offset 4
      [  239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x5638f7e2, offset 4
      
      And network throughput ends up being pretty bursty and slow with
      a overall throughput of at best ~30kB/s (where as previously we
      got 1.1MB/s with the slower USB1.1 "full speed" host).
      
      We found the issue also was reproducible on a x86_64 system,
      using a "high-speed" USB2.0 port but the throughput did not
      measurably drop (possibly due to the scp transfer being cpu
      bound on my slow test hardware).
      
      After lots of debugging, I found the check added in the
      problematic commit seems to be calculating the offset
      incorrectly.
      
      In the normal case, in the main loop of the function, we do:
      (where offset is zero, or set to "offset += (copy_length + 1) &
      0xfffe" in the previous loop)
          rx->header = get_unaligned_le32(skb->data +
                                          offset);
          offset += sizeof(u32);
      
      But the problematic patch calculates:
          offset = ((rx->remaining + 1) & 0xfffe) + sizeof(u32);
          rx->header = get_unaligned_le32(skb->data + offset);
      
      Adding some debug logic to check those offset calculation used
      to find rx->header, the one in problematic code is always too
      large by sizeof(u32).
      
      Thus, this patch removes the incorrect " + sizeof(u32)" addition
      in the problematic calculation, and resolves the issue.
      
      Cc: Dean Jenkins <Dean_Jenkins@mentor.com>
      Cc: "David B. Robins" <linux@davidrobins.net>
      Cc: Mark Craske <Mark_Craske@mentor.com>
      Cc: Emil Goode <emilgoode@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: YongQin Liu <yongqin.liu@linaro.org>
      Cc: Guodong Xu <guodong.xu@linaro.org>
      Cc: Ivan Vecera <ivecera@redhat.com>
      Cc: linux-usb@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: stable <stable@vger.kernel.org> #4.4+
      Reported-by: NYongqin Liu <yongqin.liu@linaro.org>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd9e2e5d
  8. 05 5月, 2016 3 次提交
  9. 04 5月, 2016 2 次提交
  10. 02 5月, 2016 1 次提交
    • A
      net/smscx5xx: use the device tree for mac address · c489565b
      Arnd Bergmann 提交于
      This takes the MAC address for smsc75xx/smsc95xx USB network devices
      from a the device tree. This is required to get a usable persistent
      address on the popular beagleboard, whose hardware designers
      accidentally forgot that an ethernet device really requires an a
      MAC address to be functional.
      
      The Raspberry Pi also ships smsc9514 without a serial EEPROM, stores
      the MAC address in ROM accessible via VC4 firmware.
      
      The smsc75xx and smsc95xx drivers are just two copies of the
      same code, so better fix both.
      
      [lkundrak@v3.sk: updated to use of_get_property() as per suggestion from
      Arnd, reworded the message and comments a bit]
      Tested-by: NLubomir Rintel <lkundrak@v3.sk>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c489565b
  11. 01 5月, 2016 1 次提交
  12. 29 4月, 2016 4 次提交
  13. 15 4月, 2016 1 次提交
    • B
      cdc_mbim: apply "NDP to end" quirk to all Huawei devices · c5b5343c
      Bjørn Mork 提交于
      We now have a positive report of another Huawei device needing
      this quirk: The ME906s-158 (12d1:15c1).  This is an m.2 form
      factor modem with no obvious relationship to the E3372 (12d1:157d)
      we already have a quirk entry for.  This is reason enough to
      believe the quirk might be necessary for any number of current
      and future Huawei devices.
      
      Applying the quirk to all Huawei devices, since it is crucial
      to any device affected by the firmware bug, while the impact
      on non-affected devices is negligible.
      
      The quirk can if necessary be disabled per-device by writing
      N to /sys/class/net/<iface>/cdc_ncm/ndp_to_end
      Reported-by: NAndreas Fett <andreas.fett@secunet.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5b5343c
  14. 01 4月, 2016 1 次提交
  15. 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
  16. 28 3月, 2016 1 次提交
  17. 21 3月, 2016 1 次提交
    • D
      Revert "lan78xx: add ndo_get_stats64" · 1c191307
      David S. Miller 提交于
      This reverts commit a59f8c5b.
      
      There are several bugs in this new code, for example:
      
      1) Uses sleeping locks in get_stats64, which is not allowed,
         as the operation can be invoked in an atomic context.
      
      2) Uses PM fields without CONFIG_PM or similar guards.
      
      3) Does not synchronize HW stats when the device runtime
         suspends.
      
      Therefore this is being reverted until a correct version
      is implemented.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c191307
  18. 19 3月, 2016 2 次提交
  19. 18 3月, 2016 1 次提交
  20. 08 3月, 2016 3 次提交
  21. 07 3月, 2016 1 次提交
  22. 04 3月, 2016 1 次提交
  23. 01 3月, 2016 3 次提交
  24. 24 2月, 2016 1 次提交
  25. 19 2月, 2016 1 次提交
    • A
      USB: cdc_subset: only build when one driver is enabled · f3bb2376
      Arnd Bergmann 提交于
      This avoids a harmless randconfig warning I get when USB_NET_CDC_SUBSET
      is enabled, but all of the more specific drivers are not:
      
      drivers/net/usb/cdc_subset.c:241:2: #warning You need to configure some hardware for this driver
      
      The current behavior is clearly intentional, giving a warning when
      a user picks a configuration that won't do anything good. The only
      reason for even addressing this is that I'm getting close to
      eliminating all 'randconfig' warnings on ARM, and this came up
      a couple of times.
      
      My workaround is to not even build the module when none of the
      configurations are enable.
      
      Alternatively we could simply remove the #warning (nothing wrong
      for compile-testing), turn it into a runtime warning, or
      change the Kconfig options into a menu to hide CONFIG_USB_NET_CDC_SUBSET.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3bb2376