1. 05 9月, 2019 2 次提交
  2. 29 8月, 2019 2 次提交
  3. 26 8月, 2019 1 次提交
  4. 24 8月, 2019 2 次提交
  5. 21 8月, 2019 1 次提交
  6. 20 8月, 2019 1 次提交
  7. 14 8月, 2019 5 次提交
  8. 03 8月, 2019 1 次提交
  9. 06 7月, 2019 1 次提交
  10. 04 7月, 2019 1 次提交
  11. 02 7月, 2019 1 次提交
  12. 19 6月, 2019 1 次提交
  13. 23 4月, 2019 1 次提交
  14. 07 4月, 2019 2 次提交
  15. 23 2月, 2019 1 次提交
  16. 19 2月, 2019 1 次提交
  17. 15 12月, 2018 1 次提交
  18. 30 9月, 2018 1 次提交
  19. 21 8月, 2018 1 次提交
  20. 12 8月, 2018 1 次提交
  21. 30 6月, 2018 1 次提交
  22. 26 6月, 2018 1 次提交
    • J
      r8152: napi hangup fix after disconnect · 0ee1f473
      Jiri Slaby 提交于
      When unplugging an r8152 adapter while the interface is UP, the NIC
      becomes unusable.  usb->disconnect (aka rtl8152_disconnect) deletes
      napi. Then, rtl8152_disconnect calls unregister_netdev and that invokes
      netdev->ndo_stop (aka rtl8152_close). rtl8152_close tries to
      napi_disable, but the napi is already deleted by disconnect above. So
      the first while loop in napi_disable never finishes. This results in
      complete deadlock of the network layer as there is rtnl_mutex held by
      unregister_netdev.
      
      So avoid the call to napi_disable in rtl8152_close when the device is
      already gone.
      
      The other calls to usb_kill_urb, cancel_delayed_work_sync,
      netif_stop_queue etc. seem to be fine. The urb and netdev is not
      destroyed yet.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: linux-usb@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ee1f473
  23. 22 6月, 2018 1 次提交
  24. 27 2月, 2018 1 次提交
  25. 03 2月, 2018 2 次提交
  26. 18 1月, 2018 1 次提交
  27. 24 10月, 2017 1 次提交
  28. 02 10月, 2017 1 次提交
  29. 09 8月, 2017 1 次提交
  30. 21 6月, 2017 1 次提交
  31. 16 6月, 2017 1 次提交
    • H
      r8152: move calling delay_autosuspend function · bd882982
      hayeswang 提交于
      Move calling delay_autosuspend() in rtl8152_runtime_suspend(). Calling
      delay_autosuspend() as late as possible.
      
      The original flows are
         1. check if the driver/device is busy now.
         2. set wake events.
         3. enter runtime suspend.
      
      If the wake event occurs between (1) and (2), the device may miss it. Besides,
      to avoid the runtime resume occurs after runtime suspend immediately, move the
      checking to the end of rtl8152_runtime_suspend().
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd882982