Re: [PATCH v3] xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices

From: Mathias Nyman
Date: Wed Oct 12 2022 - 04:33:12 EST

On 11.10.2022 19.46, Limonciello, Mario wrote:

-----Original Message-----
From: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
Sent: Tuesday, October 11, 2022 08:16
To: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>; Limonciello,
Mario <Mario.Limonciello@xxxxxxx>
Cc: Mathias Nyman <mathias.nyman@xxxxxxxxx>; Mehta, Sanju
<Sanju.Mehta@xxxxxxx>; Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx; linux-
Subject: Re: [PATCH v3] xhci-pci: Set runtime PM as default policy on all xHC
1.2 or later devices

On 11.10.2022 8.11, Mika Westerberg wrote:
On Mon, Oct 10, 2022 at 11:00:21AM -0500, Mario Limonciello wrote:
For optimal power consumption of USB4 routers the XHCI PCIe endpoint
used for tunneling must be in D3. Historically this is accomplished
by a long list of PCIe IDs that correspond to these endpoints because
the xhci_hcd driver will not default to allowing runtime PM for all

As both AMD and Intel have released new products with new XHCI
this list continues to grow. In reviewing the XHCI specification v1.2 on
page 607 there is already a requirement that the PCI power management
states D3hot and D3cold must be supported.

In the quirk list, use this to indicate that runtime PM should be allowed
on XHCI controllers. The following controllers are known to be xHC 1.2 and
dropped explicitly:
* AMD Yellow Carp
* Intel Alder Lake
* Intel Meteor Lake
* Intel Raptor Lake

Suggested-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>

Reviewed-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>

Thanks, added to queue

For my own clarity - is this something you'll still take to 6.1, or are you meaning
6.2 queue at this point?

Was planning on sending it to usb-next after 6.1-rc1 is out, so ending up in 6.2
But if there's some benefit in having this already in 6.1 then I don't object that either.

This thread originated from enabling Pink Sardine. Wherever it lands after it's
baked for $long_enough I would like to bring it back to stable eventually too.
If you think it's too risky for stable later on, can we do separate set of commits
that adds and then removes the IDs for pink sardine that can go to stable? This
would at least mirror more closely what has been done historically for the other
USB4 products.

I think we can add this to stable. It's fine for Intel xHCI 1.2 hosts.