Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp180603imw; Wed, 13 Jul 2022 22:31:00 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vkpBOXzt1gYIIUt/LNNIj570Vrr0VNY9L9SEQD03JaTdw/KxNngKqOfWliHkIBxdutV5Fq X-Received: by 2002:a17:90a:fc6:b0:1f0:47:ca71 with SMTP id 64-20020a17090a0fc600b001f00047ca71mr14115637pjz.98.1657776660725; Wed, 13 Jul 2022 22:31:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657776660; cv=none; d=google.com; s=arc-20160816; b=ItfWh1EExuW2DnG0QrXvEOQ97YYN5nXxW0XXXHaRQf/fMF78qix6c7bCfX8YHj9e40 huXailYEktruLHKzKuLi7IrxbQRzgRWPKLeZm4b8DL901qrj9dAu0LFIBG/L1X9KCZbq x87ewsBqnw3xelQvgkolHaLX1Pzp4YXpo6JAHzdiD4VEOoD27ESovYS54rKOoaQ4yjLh 6vcckMX8lrXWO3m48fRPzWJ7wyuX8Q5bGa3v4/veRYNgXbXGRHHyCGkNnYJRbsEQN6Tb FFNx5XxzRqvyxE9DccotBPzIAVwkOBBrQ1sVLAC3jIwEVWld57p1OH5dm9XZSRy2uV3u L8eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=gNfA8L8vp51U+1R8pxt1zVSdGTgaEz69hhzXIwnB4hI=; b=TFBKwo4oecMjSbU7GaVtd7Wc/OI/ccLe94P3n6L5NUvduzu8g5ac3wgGBmV/li7HCy mu0wzNge+gu7V/daktZZXpl68Yq14hS9Sj1BKacWb1g3cs7EHT9kfXBeg3pXnUrXgr72 KmGRLhcUHtZWu//W/ko303N3nKJ9YduzUrJH9/TiDlotEa4IGzX6cQhxYpb3/LuqmO8s ZrdaiH/jMVf+yQyLKWkYpaiOs9HGkL73bTDtmSpHdJkAv9clQ61LzDZdAWNwwfrkREP+ vxVwqrsRMbSownUxZ4lCAva3OYpe3ijExhRZDG39GvR10y99WJBFXcc9JJDfotIhbuH6 FmEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 19-20020a630413000000b003aa90e6d50bsi734573pge.45.2022.07.13.22.30.46; Wed, 13 Jul 2022 22:31:00 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234424AbiGNFCD (ORCPT + 99 others); Thu, 14 Jul 2022 01:02:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236010AbiGNE7q (ORCPT ); Thu, 14 Jul 2022 00:59:46 -0400 Received: from cavan.codon.org.uk (irc.codon.org.uk [IPv6:2a00:1098:84:22e::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 885841EC6C for ; Wed, 13 Jul 2022 21:56:18 -0700 (PDT) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 0558340A56; Thu, 14 Jul 2022 05:56:13 +0100 (BST) Date: Thu, 14 Jul 2022 05:56:13 +0100 From: Matthew Garrett To: Kai-Heng Feng Cc: Bjorn Helgaas , Manyi Li , bhelgaas@google.com, refactormyself@gmail.com, kw@linux.com, rajatja@google.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Vidya Sagar Subject: Re: [PATCH] PCI/ASPM: Should not report ASPM support to BIOS if FADT indicates ASPM is unsupported Message-ID: <20220714045613.GA8720@srcf.ucam.org> References: <20220713112612.6935-1-limanyi@uniontech.com> <20220713182852.GA841582@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,KHOP_HELO_FCRDNS,SPF_HELO_NEUTRAL, SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 14, 2022 at 11:20:26AM +0800, Kai-Heng Feng wrote: > According to commit 387d37577fdd ("PCI: Don't clear ASPM bits when the > FADT declares it's unsupported"), the bit means "just use the ASPM Yes, the assumption is that if the BIOS set up ASPM but FADT indicates it's unsupported, just trust that the BIOS did the right thing and don't interfere. It's been a long time, but when we were clearing the ASPM bits in response to this FADT setting, a bunch of machines suddenly started consuming a lot more power than when running Windows.