| Message ID | f4d5eae4-738f-2504-1254-68c8a04140fe@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
| Series | r8169: series with smaller improvements | expand |
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index a3df61d81..c7a89d2a8 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -6787,9 +6787,8 @@ static void __rtl8169_resume(struct net_device *dev) rtl_lock_work(tp); napi_enable(&tp->napi); set_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags); + rtl_reset_work(tp); rtl_unlock_work(tp); - - rtl_schedule_task(tp, RTL_FLAG_TASK_RESET_PENDING); } static int rtl8169_resume(struct device *device)
Triggering an asynchronous reset is problematic for the following reasons, therefore reset the chip synchronously. - The reset routine resets registers and parameters behind our back what may collide with code executed after triggering the reset. - __rtl8169_resume() is called as part of pm_runtime_get_sync() and callers expect that the chip is fully resumed afterwards. In context of this driver triggering an asynchonous reset should be considered an emergency procedure. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> --- drivers/net/ethernet/realtek/r8169.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)