From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 267F7C54E76 for ; Thu, 16 Nov 2023 23:38:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229714AbjKPXiG (ORCPT ); Thu, 16 Nov 2023 18:38:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229533AbjKPXiG (ORCPT ); Thu, 16 Nov 2023 18:38:06 -0500 X-Greylist: delayed 607 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 16 Nov 2023 15:37:58 PST Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3929D8E; Thu, 16 Nov 2023 15:37:58 -0800 (PST) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 13F98406B6; Thu, 16 Nov 2023 23:27:48 +0000 (GMT) Date: Thu, 16 Nov 2023 23:27:48 +0000 From: Matthew Garrett To: Bjorn Helgaas Cc: "David E. Box" , Mika Westerberg , "Kenneth R. Crudup" , vidyas@nvidia.com, bhelgaas@google.com, kai.heng.feng@canonical.com, andrea.righi@canonical.com, vicamo.yang@canonical.com, Kuppuswamy Sathyanarayanan , "Rafael J. Wysocki" , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Ricky WU , Mario Limonciello , linux-pm@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Witt Subject: Re: My AlderLake Dell (XPS-9320) needs these patches to get full standby/low-power modes Message-ID: References: <70ec50bab17ec112641f01a122e389e71b470270.camel@linux.intel.com> <20231116231812.GA57394@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231116231812.GA57394@bhelgaas> Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Thu, Nov 16, 2023 at 05:18:12PM -0600, Bjorn Helgaas wrote: > I think this would be better as a quirk instead of a driver probe > method because I don't think ASPM really has anything to do with the > driver probe. We do most ASPM configuration at enumeration (before > driver probe), so now we have this exception that we delay it until > probe time if the policy is POLICY_POWERSAVE or > POLICY_POWER_SUPERSAVE. I think doing this as a quirk would probably work fine, but from an aesthetic point of view it feels awkward - this is knowledge that the drivers have, and so fundamentally placing that knowledge in the core PCI code feels like the wrong place to put it.