1. 26 1月, 2017 4 次提交
  2. 25 1月, 2017 2 次提交
  3. 21 1月, 2017 1 次提交
  4. 12 1月, 2017 1 次提交
  5. 11 1月, 2017 2 次提交
  6. 05 1月, 2017 1 次提交
  7. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  8. 25 12月, 2016 1 次提交
  9. 09 12月, 2016 2 次提交
  10. 06 12月, 2016 1 次提交
  11. 03 12月, 2016 2 次提交
    • D
      NET: usb: qmi_wwan: add support for Telit LE922A PID 0x1040 · 9bd813da
      Daniele Palmas 提交于
      This patch adds support for PID 0x1040 of Telit LE922A.
      
      The qmi adapter requires to have DTR set for proper working,
      so QMI_WWAN_QUIRK_DTR has been enabled.
      Signed-off-by: NDaniele Palmas <dnlplm@gmail.com>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9bd813da
    • K
      cdc_ether: Fix handling connection notification · d5c83d0d
      Kristian Evensen 提交于
      Commit bfe9b9d2 ("cdc_ether: Improve ZTE MF823/831/910 handling")
      introduced a work-around in usbnet_cdc_status() for devices that exported
      cdc carrier on twice on connect. Before the commit, this behavior caused
      the link state to be incorrect. It was assumed that all CDC Ethernet
      devices would either export this behavior, or send one off and then one on
      notification (which seems to be the default behavior).
      
      Unfortunately, it turns out multiple devices sends a connection
      notification multiple times per second (via an interrupt), even when
      connection state does not change. This has been observed with several
      different USB LAN dongles (at least), for example 13b1:0041 (Linksys).
      After bfe9b9d2, the link state has been set as down and then up for
      each notification. This has caused a flood of Netlink NEWLINK messages and
      syslog to be flooded with messages similar to:
      
      cdc_ether 2-1:2.0 eth1: kevent 12 may have been dropped
      
      This commit fixes the behavior by reverting usbnet_cdc_status() to how it
      was before bfe9b9d2. The work-around has been moved to a separate
      status-function which is only called when a known, affect device is
      detected.
      
      v1->v2:
      
      * Do not open-code netif_carrier_ok() (thanks Henning Schild).
      * Call netif_carrier_off() instead of usb_link_change(). This prevents
      calling schedule_work() twice without giving the work queue a chance to be
      processed (thanks Bjørn Mork).
      
      Fixes: bfe9b9d2 ("cdc_ether: Improve ZTE MF823/831/910 handling")
      Reported-by: NHenning Schild <henning.schild@siemens.com>
      Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5c83d0d
  12. 02 12月, 2016 1 次提交
  13. 19 11月, 2016 1 次提交
  14. 16 11月, 2016 2 次提交
  15. 14 11月, 2016 1 次提交
    • G
      r8152: Fix error path in open function · ca0a7531
      Guenter Roeck 提交于
      If usb_submit_urb() called from the open function fails, the following
      crash may be observed.
      
      r8152 8-1:1.0 eth0: intr_urb submit failed: -19
      ...
      r8152 8-1:1.0 eth0: v1.08.3
      Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b7b
      pgd = ffffffc0e7305000
      [6b6b6b6b6b6b6b7b] *pgd=0000000000000000, *pud=0000000000000000
      Internal error: Oops: 96000004 [#1] PREEMPT SMP
      ...
      PC is at notifier_chain_register+0x2c/0x58
      LR is at blocking_notifier_chain_register+0x54/0x70
      ...
      Call trace:
      [<ffffffc0002407f8>] notifier_chain_register+0x2c/0x58
      [<ffffffc000240bdc>] blocking_notifier_chain_register+0x54/0x70
      [<ffffffc00026991c>] register_pm_notifier+0x24/0x2c
      [<ffffffbffc183200>] rtl8152_open+0x3dc/0x3f8 [r8152]
      [<ffffffc000808000>] __dev_open+0xac/0x104
      [<ffffffc0008082f8>] __dev_change_flags+0xb0/0x148
      [<ffffffc0008083c4>] dev_change_flags+0x34/0x70
      [<ffffffc000818344>] do_setlink+0x2c8/0x888
      [<ffffffc0008199d4>] rtnl_newlink+0x328/0x644
      [<ffffffc000819e98>] rtnetlink_rcv_msg+0x1a8/0x1d4
      [<ffffffc0008373c8>] netlink_rcv_skb+0x68/0xd0
      [<ffffffc000817990>] rtnetlink_rcv+0x2c/0x3c
      [<ffffffc000836d1c>] netlink_unicast+0x16c/0x234
      [<ffffffc00083720c>] netlink_sendmsg+0x340/0x364
      [<ffffffc0007e85d0>] sock_sendmsg+0x48/0x60
      [<ffffffc0007e9c30>] SyS_sendto+0xe0/0x120
      [<ffffffc0007e9cb0>] SyS_send+0x40/0x4c
      [<ffffffc000203e34>] el0_svc_naked+0x24/0x28
      
      Clean up error handling to avoid registering the notifier if the open
      function is going to fail.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca0a7531
  16. 10 11月, 2016 1 次提交
  17. 03 11月, 2016 1 次提交
  18. 31 10月, 2016 1 次提交
    • M
      r8152: Fix broken RX checksums. · b9a321b4
      Mark Lord 提交于
      The r8152 driver has been broken since (approx) 3.16.xx
      when support was added for hardware RX checksums
      on newer chip versions.  Symptoms include random
      segfaults and silent data corruption over NFS.
      
      The hardware checksum logig does not work on the VER_02
      dongles I have here when used with a slow embedded system CPU.
      Google reveals others reporting similar issues on Raspberry Pi.
      
      So, disable hardware RX checksum support for VER_02, and fix
      an obvious coding error for IPV6 checksums in the same function.
      
      Because this bug results in silent data corruption,
      it is a good candidate for back-porting to -stable >= 3.16.xx.
      Signed-off-by: NMark Lord <mlord@pobox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9a321b4
  19. 28 10月, 2016 1 次提交
    • A
      kalmia: avoid potential uninitialized variable use · e30520c2
      Arnd Bergmann 提交于
      The kalmia_send_init_packet() returns zero or a negative return
      code, but gcc has no way of knowing that there cannot be a
      positive return code, so it determines that copying the ethernet
      address at the end of kalmia_bind() will access uninitialized
      data:
      
      drivers/net/usb/kalmia.c: In function ‘kalmia_bind’:
      arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)&ethernet_addr+4)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
         *((short *)to + 2) = *((short *)from + 2);
                            ^
      drivers/net/usb/kalmia.c:138:5: note: ‘*((void *)&ethernet_addr+4)’ was declared here
      
      This warning is harmless, but for consistency, we should make
      the check for the return code match what the driver does everywhere
      else and just progate it, which then gets rid of the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e30520c2
  20. 21 10月, 2016 1 次提交
    • J
      net: use core MTU range checking in USB NIC drivers · f77f0aee
      Jarod Wilson 提交于
      usbnet:
      - Remove stale new_mtu <= 0 check in usbnet.c
      - Set min_mtu = 0, max_mtu = 65535 (sub-drivers must set their own
        max_mtu and/or min_mtu as needed)
      
      r8152:
      - Set appropriate max_mtu for different variants (1500 or 9194)
      
      lan78xx:
      - Set max_mtu = 9000
      
      asix_driver:
      - max_mtu = 16384 for ax88178 variant
      
      ax88179:
      - max_mtu = 4088
      
      cdc_ncm:
      - max_mtu from hardware
      
      cdc-phonet:
      - min_mtu = 6, max_mtu = 65541
      
      sierra_net:
      - max_mtu = 1500, call usbnet_change_mtu directly
      - sierra_net_change_mtu checked for MTU > 1500, then called
        usbnet_change_mtu, but if we set max_mtu to let the network core handle
        the range check, then we can simply call usbnet_change_mtu directly
      
      smsc75xx:
      - max_mtu = 9000
      
      CC: netdev@vger.kernel.org
      CC: Woojung Huh <woojung.huh@microchip.com>
      CC: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
      CC: Hayes Wang <hayeswang@realtek.com>
      CC: Oliver Neukum <oneukum@suse.com>
      CC: Steve Glendinning <steve.glendinning@shawell.net>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f77f0aee
  21. 19 10月, 2016 1 次提交
  22. 15 10月, 2016 1 次提交
    • G
      net: asix: Avoid looping when the device does not respond · 610df1d2
      Guenter Roeck 提交于
      Check answers from USB stack and avoid re-sending the request
      multiple times if the device does not respond.
      
      This fixes the following problem, observed with a probably flaky adapter.
      
      [62108.732707] usb 1-3: new high-speed USB device number 5 using xhci_hcd
      [62108.914421] usb 1-3: New USB device found, idVendor=0b95, idProduct=7720
      [62108.914463] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      [62108.914476] usb 1-3: Product: AX88x72A
      [62108.914486] usb 1-3: Manufacturer: ASIX Elec. Corp.
      [62108.914495] usb 1-3: SerialNumber: 000001
      [62114.109109] asix 1-3:1.0 (unnamed net_device) (uninitialized):
      	Failed to write reg index 0x0000: -110
      [62114.109139] asix 1-3:1.0 (unnamed net_device) (uninitialized):
      	Failed to send software reset: ffffff92
      [62119.109048] asix 1-3:1.0 (unnamed net_device) (uninitialized):
      	Failed to write reg index 0x0000: -110
      ...
      
      Since the USB timeout is 5 seconds, and the operation is retried 30 times,
      this results in
      
      [62278.180353] INFO: task mtpd:1725 blocked for more than 120 seconds.
      [62278.180373]       Tainted: G        W      3.18.0-13298-g94ace9e #1
      [62278.180383] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      ...
      [62278.180957] kworker/2:0     D 0000000000000000     0  5744      2 0x00000000
      [62278.180978] Workqueue: usb_hub_wq hub_event
      [62278.181029]  ffff880177f833b8 0000000000000046 ffff88017fd00000 ffff88017b126d80
      [62278.181048]  ffff880177f83fd8 ffff880065a71b60 0000000000013340 ffff880065a71b60
      [62278.181065]  0000000000000286 0000000103b1c199 0000000000001388 0000000000000002
      [62278.181081] Call Trace:
      [62278.181092]  [<ffffffff8e0971fd>] ? console_conditional_schedule+0x2c/0x2c
      [62278.181105]  [<ffffffff8e094f7b>] schedule+0x69/0x6b
      [62278.181117]  [<ffffffff8e0972e0>] schedule_timeout+0xe3/0x11d
      [62278.181133]  [<ffffffff8daadb1b>] ? trace_timer_start+0x51/0x51
      [62278.181146]  [<ffffffff8e095a05>] do_wait_for_common+0x12f/0x16c
      [62278.181162]  [<ffffffff8da856a7>] ? wake_up_process+0x39/0x39
      [62278.181174]  [<ffffffff8e095aee>] wait_for_common+0x52/0x6d
      [62278.181187]  [<ffffffff8e095b3b>] wait_for_completion_timeout+0x13/0x15
      [62278.181201]  [<ffffffff8de676ce>] usb_start_wait_urb+0x93/0xf1
      [62278.181214]  [<ffffffff8de6780d>] usb_control_msg+0xe1/0x11d
      [62278.181230]  [<ffffffffc037d629>] usbnet_write_cmd+0x9c/0xc6 [usbnet]
      [62278.181286]  [<ffffffffc03af793>] asix_write_cmd+0x4e/0x7e [asix]
      [62278.181300]  [<ffffffffc03afb41>] asix_set_sw_mii+0x25/0x4e [asix]
      [62278.181314]  [<ffffffffc03b001d>] asix_mdio_read+0x51/0x109 [asix]
      ...
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      610df1d2
  23. 13 10月, 2016 2 次提交
    • B
      qmi_wwan: add support for Quectel EC21 and EC25 · 9a765881
      Bjørn Mork 提交于
      The Quectel EC21 and EC25 need the same "set DTR" request as devices
      based on the MDM9230 chipset, but has no USB3 support. Our best guess
      is that the "set DTR" functionality depends on chipset and/or
      baseband firmware generation. But USB3 is still an optional feature.
      
      Since we cannot enable this unconditionally for all older devices, and
      there doesn't appear to be anything we can use in the USB descriptors
      to identify these chips, we are forced to use a device specific quirk
      flag.
      Reported-and-tested-by: NSebastian Sjoholm <sebastian.sjoholm@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a765881
    • J
      net: deprecate eth_change_mtu, remove usage · a52ad514
      Jarod Wilson 提交于
      With centralized MTU checking, there's nothing productive done by
      eth_change_mtu that isn't already done in dev_set_mtu, so mark it as
      deprecated and remove all usage of it in the kernel. All callers have been
      audited for calls to alloc_etherdev* or ether_setup directly, which means
      they all have a valid dev->min_mtu and dev->max_mtu. Now eth_change_mtu
      prints out a netdev_warn about being deprecated, for the benefit of
      out-of-tree drivers that might be utilizing it.
      
      Of note, dvb_net.c actually had dev->mtu = 4096, while using
      eth_change_mtu, meaning that if you ever tried changing it's mtu, you
      couldn't set it above 1500 anymore. It's now getting dev->max_mtu also set
      to 4096 to remedy that.
      
      v2: fix up lantiq_etop, missed breakage due to drive not compiling on x86
      
      CC: netdev@vger.kernel.org
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a52ad514
  24. 12 10月, 2016 1 次提交
  25. 21 9月, 2016 5 次提交
  26. 08 9月, 2016 1 次提交
  27. 07 9月, 2016 1 次提交
    • B
      lan78xx: mark symbols static where possible · e0c79ff6
      Baoyou Xie 提交于
      We get a few warnings when building kernel with W=1:
      drivers/net/usb/lan78xx.c:1182:6: warning: no previous prototype for 'lan78xx_defer_kevent' [-Wmissing-prototypes]
      drivers/net/usb/lan78xx.c:1409:5: warning: no previous prototype for 'lan78xx_nway_reset' [-Wmissing-prototypes]
      drivers/net/usb/lan78xx.c:2000:5: warning: no previous prototype for 'lan78xx_set_mac_addr' [-Wmissing-prototypes]
      ....
      
      In fact, these functions are only used in the file in which they are
      declared and don't need a declaration, but can be made static.
      so this patch marks these functions with 'static'.
      Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0c79ff6