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

[Limonciello, Mario]

[Public]

> -----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-
> kernel@xxxxxxxxxxxxxxx
> 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
> >> devices.
> >>
> >> As both AMD and Intel have released new products with new XHCI
> controllers
> >> 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>
> >> Link:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.intel.com%2Fcontent%2Fdam%2Fwww%2Fpublic%2Fus%2Fen%2Fdocum
> ents%2Ftechnical-specifications%2Fextensible-host-controler-interface-usb-
> xhci.pdf&amp;data=05%7C01%7Cmario.limonciello%40amd.com%7Cb286e9c
> 63e9e4c3a1a3708daab8a9b23%7C3dd8961fe4884e608e11a82d994e183d%7C0
> %7C0%7C638010909687542135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&amp;sdata=CetIs1VuAqj8nNBoLnXaGncw6Sl4JcImYY67JpVxyjg%
> 3D&amp;reserved=0
> >> Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
> >
> > Reviewed-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
> 
> Thanks, added to queue

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

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.