David Miller <da...@davemloft.net> :
> 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.
[...]
> 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.
Actually I do not see why the asynchronous reset would be a problem.
Aforementioned places that use pm_runtime_get_sync() are rtl_{open/close}
1. I understand that rtl_open needs to reach synchronously something like
a D0 state but it does not need anything else, whence the current no-op
in the driver runtime suspend/resume handlers (that I should have
remembered btw).
2. rtl_close() needs the same D0 state to perform the hw counters update
but it should neither need nor care about rtl_reset_work. rtl_close
even disables itself the deferred work queue right after the hw counter
update.
If it's also worth making the code more palatable, more explicit symmetry
between rtl8169_net_suspend and __rtl8169_resume would be welcome.
--
Ueimor
