From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Philip Langdale <philipl@overt.org>, linux-usb@vger.kernel.org
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: xhci-pci: don't enable runtime PM for Alpine Ridge on Maximus VIII Impact
Date: Wed, 2 Jan 2019 13:23:51 +0200 [thread overview]
Message-ID: <f162d690-5d65-02b5-48f5-ed3da4842358@linux.intel.com> (raw)
On 30.12.2018 18:34, Philip Langdale wrote:
> This fixes a regression since: 2815ef7fe4d43072b9eda448d04fbc184f2aa513
>
> This motherboard is a strange beast, with an Alpine Ridge thunderbolt
> controller configured to only do USB with no actual thunderbolt
> capabilities (Apparently due to the wiring not being thunderbolt
> compliant).
>
> When runtime PM is enabled in this case, plugging in a USB device results
> in nothing being detected. Everything works fine when runtime PM is not
> enabled.
>
> Signed-off-by: Philip Langdale <philipl@overt.org>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=202095
> ---
> drivers/usb/host/xhci-pci.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index a9ec7051f286..147ae893f055 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -211,7 +211,9 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
> pdev->device == PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_C_4C_XHCI ||
> pdev->device == PCI_DEVICE_ID_INTEL_TITAN_RIDGE_2C_XHCI ||
> pdev->device == PCI_DEVICE_ID_INTEL_TITAN_RIDGE_4C_XHCI ||
> - pdev->device == PCI_DEVICE_ID_INTEL_TITAN_RIDGE_DD_XHCI))
> + pdev->device == PCI_DEVICE_ID_INTEL_TITAN_RIDGE_DD_XHCI) &&
> + pdev->subsystem_vendor != 0x2222 &&
> + pdev->subsystem_device != 0x1111)
> xhci->quirks |= XHCI_DEFAULT_PM_RUNTIME_ALLOW;
>
> if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
>
Before doing this there are a couple other possible reasons why this is not working.
Mika (cc) suspects it might be related to a PCI PM patch, can you try reverting it?:
0e157e5 PCI/PME: Implement runtime PM callbacks
Another possibility is that xHC is stopped (runtime suspended), but still in PCI D0 state,
which would prevent PME from waking it up.
can you check the D state of the Alpine Ridge xHCI controller when it doesn't react:
cat /sys/bus/pci/devices/<your Alpine Ridge xHCI PCI bus address>/firmware_node/power_state
Don't use lspci for checking D state, it might wake up the PCI devices.
-Mathias
next reply other threads:[~2019-01-02 11:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-02 11:23 Mathias Nyman [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-01-03 8:17 xhci-pci: don't enable runtime PM for Alpine Ridge on Maximus VIII Impact Mika Westerberg
2019-01-03 4:00 Philip Langdale
2018-12-30 16:34 Philip Langdale
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=f162d690-5d65-02b5-48f5-ed3da4842358@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=linux-usb@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=philipl@overt.org \
/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