xHCI over-current causing pm loop
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
Quoted 17 lines · 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 hubTwo 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.
Quoted 7 lines
Reverting the
e9fb08d617bfcheck 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