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

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 11.10.2022 19.46, Limonciello, Mario wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Mathias Nyman <mathias.nyman@linux.intel.com>
>> Sent: Tuesday, October 11, 2022 08:16
>> To: Mika Westerberg <mika.westerberg@linux.intel.com>; Limonciello,
>> Mario <Mario.Limonciello@amd.com>
>> Cc: Mathias Nyman <mathias.nyman@intel.com>; Mehta, Sanju
>> <Sanju.Mehta@amd.com>; Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org>; linux-usb@vger.kernel.org; linux-
>> kernel@vger.kernel.org
>> 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@linux.intel.com>
>>>> 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@amd.com>
>>>
>>> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>>
>> 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