From: Heiner Kallweit <hkallwe...@gmail.com> Date: Mon, 21 May 2018 19:01:19 +0200
> The driver uses pm_runtime_get_sync() in few places and relies on the > device being fully runtime-resumed after this call. So far however > the runtime resume callback triggers an asynchronous reset. > Avoid this and perform the reset synchronously. > > Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> > --- > drivers/net/ethernet/realtek/r8169.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 75dfac024..1eb4f625a 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c > @@ -7327,9 +7327,9 @@ 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); > + if (netif_running(dev)) > + rtl_reset_work(tp); > rtl_unlock_work(tp); > - > - rtl_schedule_task(tp, RTL_FLAG_TASK_RESET_PENDING); > } > Given what we know about ->ndo_open() and the checks by the callers of __rtl8169_resume(), the netif_running() test seems superfluous or wrong. Either way you need to resolve this somehow.
