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

[Mathias Nyman]

On 11.10.2022 19.46, Limonciello, Mario wrote:
> [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?

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.

Thanks
-Mathias