mbox series

[0/2] r8152: Fix a couple of PM problems

Message ID 20210714170022.8162-1-tiwai@suse.de
Headers show
Series r8152: Fix a couple of PM problems | expand

Message

Takashi Iwai July 14, 2021, 5 p.m. UTC 
Hi,

it seems that r8152 driver suffers from the deadlock at both runtime
and system PM.  Formerly, it was seen more often at hibernation
resume, but now it's triggered more frequently, as reported in SUSE
Bugzilla:
  https://bugzilla.suse.com/show_bug.cgi?id=1186194

While debugging the problem, I stumbled on a few obvious bugs and here
is the results with two patches for addressing the resume problem.

***

However, the story doesn't end here, unfortunately, and those patches
don't seem sufficing.  The rest major problem is that the driver calls
napi_disable() and napi_enable() in the PM suspend callbacks.  This
makes the system stalling at (runtime-)suspend.  If we drop
napi_disable() and napi_enable() calls in the PM suspend callbacks, it
starts working (that was the result in Bugzilla comment 13):
  https://bugzilla.suse.com/show_bug.cgi?id=1186194#c13

So, my patches aren't enough and we still need to investigate
further.  It'd be appreciated if anyone can give a fix or a hint for
more debugging.  The usage of napi_disable() at PM callbacks is unique
in this driver and looks rather suspicious to me; but I'm no expert in
this area so I might be wrong...


Thanks!

Takashi

===

Takashi Iwai (2):
  r8152: Fix potential PM refcount imbalance
  r8152: Fix a deadlock by doubly PM resume

 drivers/net/usb/r8152.c | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

Comments

Hayes Wang July 15, 2021, 4:36 a.m. UTC | #1 
> Subject: Re: [PATCH 0/2] r8152: Fix a couple of PM problems

[...]
> 

> Here is the summary with links:

>   - [1/2] r8152: Fix potential PM refcount imbalance

>     https://git.kernel.org/netdev/net/c/9c23aa51477a

>   - [2/2] r8152: Fix a deadlock by doubly PM resume

>     https://git.kernel.org/netdev/net/c/776ac63a986d


I think set_ethernet_addr() shouldn't be called at reset-resume.
The MAC address should be restored to the current one, not the
default value. Someone may change the MAC address before suspending.
And the MAC address would become the default value after reset-resume,
if set_ethernet_addr() is called.

Best Regards,
Hayes