[regression] USB power management failure to suspend / high CPU usage

[Ivan Mironov <mironov.ivan@gmail.com>]

On Wed, 2019-02-20 at 19:28 +0200, Mathias Nyman wrote:
> On 14.2.2019 20.04, Eric Blau wrote:
> > On Thu, Feb 14, 2019 at 9:56 AM Mathias Nyman
> > <mathias.nyman@linux.intel.com> wrote:
> > > > Thanks for looking into this, Mathias. Now that you point this out, on
> > > > older kernels where suspend and resume works, I noticed the following
> > > > log messages emitted when resuming from suspend:
> > > > 
> > > > Feb 06 18:58:05 eric-macbookpro kernel: usb usb2-port3: Cannot enable.
> > > > Maybe the USB cable is bad?
> > > 
> > > Attached a testpatch that should react to ports stuck in polling state,
> > > and warm reset them.
> > > 
> > > It doesn't limit the numbers of reset tries, or allow system suspend with ports
> > > stuck in polling state, but I'd like to know how the MacBook reacts to it
> > > 
> > > Can you test it with debugging enabled?
> > 
> > Hi Mathias,
> > 
> > Thanks for the patch. I tested it against 4.20.8 and got a couple
> > successful suspends but on the third attempt I got the same failure
> > again. I noticed after the first suspend/resume, the card reader
> > showed as "Link:Compliance" but on later attempts it showed stuck in
> > Polling again.
> > 
> > I've attached the logs with debugging enabled.
> > 
> 
> Thanks, logs show that several resets won't recover the card reader.
> 
> I'm taking a different approach, USB3 ports in polling state should
> automatically move to connected/enabled. So instead of preventing
> suspend if a port is found in polling I'll let it try to finish link
> training for some time, and then just continue with suspend if it fails.
> 
> Patch attached.
> 
> This won't fix the broken card reader, but should allow your MacBook to suspend.
> After this we can start looking at fixing the card reader, Ivan Miranov sent some
> proposal for this.
> 
> -Mathias

Hi Mathias,

I applied your patch on top of v5.0-rc8 and tested it on my laptop.

It fixes the suspend problem from the kernel side, but there is another
one: starting with the second suspend, XHCI controller wakes up the
system just after few seconds after suspending. Laptop keeps looping
through suspend/resume while lid is closed.

Such behaviour is quite stable: I was able to reproduce this three
times with reboots in between. Corresponding dmesg and traces are here
(from one run only):
https://github.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/tree/master/test-22

After disabling ACPI wake up on XHC1 (echo XHC1 >/proc/acpi/wakeup),
everything works as expected: suspend/resume works fine multiple times,
card reader remains missing after the first suspend/resume.