public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Dominik Winecki <dominikwinecki@gmail.com>,
	Mathias Nyman <mathias.nyman@intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: xHCI over-current causing pm loop
Date: Mon, 17 May 2021 10:03:39 -0400	[thread overview]
Message-ID: <20210517140339.GD1083813@rowland.harvard.edu> (raw)
In-Reply-To: <YKCAoxmr+7bVo63X@hyperion>

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

      reply	other threads:[~2021-05-17 14:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16  2:17 xHCI over-current causing pm loop Dominik Winecki
2021-05-17 14:03 ` Alan Stern [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210517140339.GD1083813@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=dominikwinecki@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox