Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7df4a91d-6829-5ebf-18ca-c0783c03f443@linux.intel.com>
Date:   Wed, 12 Oct 2022 11:34:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.11.0
Content-Language: en-US
To:     "Limonciello, Mario" <Mario.Limonciello@amd.com>,
        Mika Westerberg <mika.westerberg@linux.intel.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-usb@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20221010160022.647-1-mario.limonciello@amd.com>
 <Y0T68lC6bUY7dg7D@black.fi.intel.com>
 <7c08c4c8-562d-553f-e513-c925080300a7@linux.intel.com>
 <MN0PR12MB6101ECEA1CCED9B65667031DE2239@MN0PR12MB6101.namprd12.prod.outlook.com>
From:   Mathias Nyman <mathias.nyman@linux.intel.com>
Subject: Re: [PATCH v3] xhci-pci: Set runtime PM as default policy on all xHC
 1.2 or later devices
In-Reply-To: <MN0PR12MB6101ECEA1CCED9B65667031DE2239@MN0PR12MB6101.namprd12.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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