From: "Loïc Yhuel" <loic.yhuel@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: No SuperSpeedPlus on ASM2142
Date: Tue, 24 Sep 2019 17:50:21 +0200 [thread overview]
Message-ID: <CANMwUkioh3QoYfWiTO7z9Pi54z=_+a=H01sHFL2HaJYut5RLuw@mail.gmail.com> (raw)
In-Reply-To: <36d828f1-eb5d-a75e-fe0d-0b95c35b527c@linux.intel.com>
Le mar. 24 sept. 2019 à 09:55, Mathias Nyman
<mathias.nyman@linux.intel.com> a écrit :
> Just fyi, turns out initial xHCI 1.1 spec was a bit unclear about SBRN
> and minor revision numbers, later xHCI specs clarify them better.
> A few USB 3.1 capable xHCI hosts were based on that spec, not just the ASM2142.
> They have SBRN set to 30h and minor revision 0x1.
> I'll send a patch to detect those correctly.
>
> But it won't fix your inconsistency with PortSpeed bits in PORTSC register.
Do you know anything I could try do debug the problem if it happens again ?
>
> >
> > Btw, I found another problem on resuming the system after a suspend :
> > [ 137.029272] pcieport 0000:00:01.1: PME: Spurious native interrupt!
> > ...
> > [ 137.129618] xhci_hcd 0000:08:00.0: WARN: xHC restore state timeout
> > [ 137.129624] xhci_hcd 0000:08:00.0: PCI post-resume error -110!
> > [ 137.129625] xhci_hcd 0000:08:00.0: HC died; cleaning up
> > [ 137.129633] PM: dpm_run_callback(): pci_pm_resume+0x0/0x90 returns -110
> > [ 137.129636] PM: Device 0000:08:00.0 failed to resume async: error -110
> > Then a "echo 1 > remove, then "echo 1 > ../rescan" on sysfs got it back.
> > This is a completely different issue, but at least, I can reproduce
> > this one reliably.
> >
>
> Looks like the xHCI PCI controller wasn't fully powered up to D0 state yet
> when xhci_resume was called. Looks similar to what is discussed in thread:
>
> https://marc.info/?l=linux-usb&m=156681068319529&w=2
In the runtime suspend case, on this laptop the xhci is stuck in D3,
where in my case it stays in D0.
I tried https://lore.kernel.org/linux-pci/20190821124519.71594-1-mika.westerberg@linux.intel.com/,
but it doesn't help.
On my machine, the PCIe "port" is supposed to support 8GT/s (but the
controller is on the motherboard,
so there is no official specification about how the internal
peripherals are linked), the device too,
but it's always in 5GT/s mode (in Windows too), so perhaps it changes
the delays.
next prev parent reply other threads:[~2019-09-24 15:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 2:41 No SuperSpeedPlus on ASM2142 Loïc Yhuel
2019-09-16 12:59 ` Mathias Nyman
2019-09-16 15:19 ` Loïc Yhuel
2019-09-16 20:53 ` Loïc Yhuel
2019-09-24 7:57 ` Mathias Nyman
2019-09-24 15:50 ` Loïc Yhuel [this message]
2019-10-07 23:37 ` ASM2142 issues Loïc Yhuel
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='CANMwUkioh3QoYfWiTO7z9Pi54z=_+a=H01sHFL2HaJYut5RLuw@mail.gmail.com' \
--to=loic.yhuel@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.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;
as well as URLs for NNTP newsgroup(s).