xHCI over-current causing pm loop

xHCI over-current causing pm loop

[Dominik Winecki]

Hello,

I've got an issue on my laptop (Dell XPS 9570 with an i7-7700HQ) that
I'm trying to fix. Multiple usb ports are reporting over-current, despite
nothing being plugged in:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 138a:0091 Validity Sensors, Inc. VFS7552 Touch Fingerprint Sensor
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Two kworkers running runtime pm are trying to suspend the usb 2 & 3 root hubs.
The xHCI driver will not suspend a hub with over-current triggered
(since e9fb08d617bf) so it fails, resumes the hub, and pm tries again.
This is taking two CPU cores, but it stops if a device of the same usb
version is plugged in, or if I set the power control policy to on.
Also, this is blocking system suspend, but that's expected behavior.

Reverting the e9fb08d617bf check fixes both issues for me, but that may cause
system halts in other systems. Making it a non-retriable suspend failure
stops the kworkers but then it will never suspend after an OC event.

Does it make sense to fix this in the USB driver? Or is this a PM issue?
I'd rather fix my over-current issue, but taking two cpus whenever xHCI has
a no-device over-current reading seems like a bug.

Thanks,
Dominik

Re: xHCI over-current causing pm loop

[Alan Stern]

On Sat, May 15, 2021 at 10:17:07PM -0400, Dominik Winecki wrote:
> Hello,
> 
> I've got an issue on my laptop (Dell XPS 9570 with an i7-7700HQ) that
> I'm trying to fix. Multiple usb ports are reporting over-current, despite
> nothing being plugged in:
> 
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 002: ID 138a:0091 Validity Sensors, Inc. VFS7552 Touch Fingerprint Sensor
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> Two kworkers running runtime pm are trying to suspend the usb 2 & 3 root hubs.
> The xHCI driver will not suspend a hub with over-current triggered
> (since e9fb08d617bf) so it fails, resumes the hub, and pm tries again.
> This is taking two CPU cores, but it stops if a device of the same usb
> version is plugged in, or if I set the power control policy to on.
> Also, this is blocking system suspend, but that's expected behavior.
> 
> Reverting the e9fb08d617bf check fixes both issues for me, but that may cause
> system halts in other systems. Making it a non-retriable suspend failure
> stops the kworkers but then it will never suspend after an OC event.
> 
> Does it make sense to fix this in the USB driver? Or is this a PM issue?
> I'd rather fix my over-current issue, but taking two cpus whenever xHCI has
> a no-device over-current reading seems like a bug.

As you mentioned, the real bug is in your hardware.  Why does it report 
an over-current condition when nothing is plugged into the port?

The only reasonable way I can think of to fix this would be to add a 
quirk telling the xhci-hcd driver that your hardware does not report 
over-current conditions reliably, so the reports should be ignored.

Alan Stern