[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7f0baef9-9070-b8a7-e3a2-52faec4eeb54@gmail.com>
Date: Sat, 19 Jan 2019 21:50:32 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: David Miller <davem@...emloft.net>,
Realtek linux nic maintainers <nic_swsd@...ltek.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: [PATCH net-next 6/8] r8169: reset chip synchronously in
__rtl8169_resume
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 asynchronous reset should be
considered an emergency procedure.
Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 48b5d7051..82042449d 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)
--
2.20.1
Powered by blists - more mailing lists