1. 23 1月, 2020 4 次提交
  2. 15 1月, 2020 1 次提交
  3. 23 11月, 2019 1 次提交
    • H
      r8152: avoid to call napi_disable twice · 5b1d9c17
      Hayes Wang 提交于
      Call napi_disable() twice would cause dead lock. There are three situations
      may result in the issue.
      
      1. rtl8152_pre_reset() and set_carrier() are run at the same time.
      2. Call rtl8152_set_tunable() after rtl8152_close().
      3. Call rtl8152_set_ringparam() after rtl8152_close().
      
      For #1, use the same solution as commit 84811412 ("r8152: Re-order
      napi_disable in rtl8152_close"). For #2 and #3, add checking the flag
      of IFF_UP and using napi_disable/napi_enable during mutex.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b1d9c17
  4. 21 11月, 2019 1 次提交
    • P
      r8152: Re-order napi_disable in rtl8152_close · 84811412
      Prashant Malani 提交于
      Both rtl_work_func_t() and rtl8152_close() call napi_disable().
      Since the two calls aren't protected by a lock, if the close
      function starts executing before the work function, we can get into a
      situation where the napi_disable() function is called twice in
      succession (first by rtl8152_close(), then by set_carrier()).
      
      In such a situation, the second call would loop indefinitely, since
      rtl8152_close() doesn't call napi_enable() to clear the NAPI_STATE_SCHED
      bit.
      
      The rtl8152_close() function in turn issues a
      cancel_delayed_work_sync(), and so it would wait indefinitely for the
      rtl_work_func_t() to complete. Since rtl8152_close() is called by a
      process holding rtnl_lock() which is requested by other processes, this
      eventually leads to a system deadlock and crash.
      
      Re-order the napi_disable() call to occur after the work function
      disabling and urb cancellation calls are issued.
      
      Change-Id: I6ef0b703fc214998a037a68f722f784e1d07815e
      Reported-by: http://crbug.com/1017928Signed-off-by: NPrashant Malani <pmalani@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84811412
  5. 06 11月, 2019 1 次提交
  6. 26 10月, 2019 1 次提交
    • H
      r8152: check the pointer rtl_fw->fw before using it · 8e484ebb
      Hayes Wang 提交于
      Fix the pointer rtl_fw->fw would be used before checking in
      rtl8152_apply_firmware() that causes the following kernel oops.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000002
      pgd = (ptrval)
      [00000002] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 131 Comm: kworker/0:2 Not tainted
      5.4.0-rc1-00539-g9370f2d0 #6788
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      Workqueue: events_long rtl_hw_phy_work_func_t
      PC is at rtl8152_apply_firmware+0x14/0x464
      LR is at r8153_hw_phy_cfg+0x24/0x17c
      pc : [<c064f4e4>]    lr : [<c064fa18>]    psr: a0000013
      sp : e75c9e60  ip : 60000013  fp : c11b7614
      r10: e883b91c  r9 : 00000000  r8 : fffffffe
      r7 : e883b640  r6 : fffffffe  r5 : fffffffe  r4 : e883b640
      r3 : 736cfe7c  r2 : 736cfe7c  r1 : 000052f8  r0 : e883b640
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 6640006a  DAC: 00000051
      Process kworker/0:2 (pid: 131, stack limit = 0x(ptrval))
      Stack: (0xe75c9e60 to 0xe75ca000)
      ...
      [<c064f4e4>] (rtl8152_apply_firmware) from [<c064fa18>]
      (r8153_hw_phy_cfg+0x24/0x17c)
      [<c064fa18>] (r8153_hw_phy_cfg) from [<c064e784>]
      (rtl_hw_phy_work_func_t+0x220/0x3e4)
      [<c064e784>] (rtl_hw_phy_work_func_t) from [<c0148a74>]
      (process_one_work+0x22c/0x7c8)
      [<c0148a74>] (process_one_work) from [<c0149054>] (worker_thread+0x44/0x520)
      [<c0149054>] (worker_thread) from [<c0150548>] (kthread+0x130/0x164)
      [<c0150548>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xe75c9fb0 to 0xe75c9ff8)
      ...
      
      Fixes: 9370f2d0 ("r8152: support request_firmware for RTL8153")
      Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e484ebb
  7. 23 10月, 2019 4 次提交
  8. 22 10月, 2019 1 次提交
  9. 17 10月, 2019 1 次提交
    • H
      r8152: support request_firmware for RTL8153 · 9370f2d0
      Hayes Wang 提交于
      This patch supports loading additional firmware file through
      request_firmware().
      
      A firmware file may include a header followed by several blocks
      which have different types of firmware. Currently, the supported
      types are RTL_FW_END, RTL_FW_PLA, and RTL_FW_USB.
      
      The firmware is used to fix some compatible or hardware issues. For
      example, the device couldn't be found after rebooting several times.
      
      The supported chips are
      	RTL_VER_04 (rtl8153a-2.fw)
      	RTL_VER_05 (rtl8153a-3.fw)
      	RTL_VER_06 (rtl8153a-4.fw)
      	RTL_VER_09 (rtl8153b-2.fw)
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Reviewed-by: NPrashant Malani <pmalani@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9370f2d0
  10. 05 10月, 2019 1 次提交
  11. 03 10月, 2019 1 次提交
  12. 02 10月, 2019 2 次提交
  13. 05 9月, 2019 2 次提交
  14. 29 8月, 2019 2 次提交
  15. 26 8月, 2019 1 次提交
  16. 24 8月, 2019 2 次提交
  17. 21 8月, 2019 1 次提交
  18. 20 8月, 2019 1 次提交
  19. 14 8月, 2019 5 次提交
  20. 03 8月, 2019 1 次提交
  21. 06 7月, 2019 1 次提交
  22. 04 7月, 2019 1 次提交
  23. 02 7月, 2019 1 次提交
  24. 19 6月, 2019 1 次提交
  25. 23 4月, 2019 1 次提交
  26. 07 4月, 2019 1 次提交