Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp2162755iob; Thu, 5 May 2022 17:38:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyTAcfCHpq1i418nLZatdPx3WZw12wouVyfyUY9YtVNGqo6eg6Z9m0hb50e1b6VweCKfUFL X-Received: by 2002:a50:f14e:0:b0:427:efb9:1bbb with SMTP id z14-20020a50f14e000000b00427efb91bbbmr877897edl.322.1651797503566; Thu, 05 May 2022 17:38:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651797503; cv=none; d=google.com; s=arc-20160816; b=OD6OpGwKpiGOge4SpxgIVf2V062uyZSoreMLHz04oMEC/WssaLl1bOeE2qSO5HOrAv fN6XOPV8oKolLj6LJ7sWiwBGKRf+Gqq69ouBqfTqV9cHQ9doWkpirGfTpi+R41k9cQci ma/spqGVhtiUmrsBHgP6qhQ7oWBsaqDkUeQcqtfBtMo6WCf7APCyIMVmgH7ybUirMQwR r6OfPxMskF8aoW3bspRixmud3F4Amehh4KnvN4hESVHEatFnC18cwMgzb3GFAjBb7Eo7 PD+M89Dvs3If/EMsMOapoTg1qxpUs2hEW4v6e2yEFBXUYvV5aix11WlSNuQlHyRq6bKt 1Fnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:to:subject :cc; bh=qhb45gEx6zBO+e3oaGPZrcl60wQQVbulYDuRfj51b08=; b=F23WabdXiqUC3xDMR+0D0bsmLGjMlN3zbX4Vx8TmKyI+UdionddCCvYvQTyqWrESpQ fz+b4ZBytHnsDnvjOO3S7VNtK09QEiawTnMEHquHtXFHvPogRr07JTgwPTNDjAImLMRR fr4Qbb0XfKh7PWQJu4TOXiv2rehUVaigcS2jtQ7LB71fOZKFEs5p4yIS1b6z+Nff5/X0 XsbtVKqkhSAdA/lv7G//V8PJmXarGy7Lvkqr8Pp1Zy3FPTaJEN36H/r9LyL3F9jLr3YH w7ohrhH3GubkCVoJulfYyYLci+kgThRxFCkZVctofarVBs8mPjgK5bjCExzDU3wuBUIv S9gw== 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i8-20020a170906698800b006e8793c1c88si3611625ejr.238.2022.05.05.17.37.59; Thu, 05 May 2022 17:38:23 -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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354832AbiEEMk3 (ORCPT + 99 others); Thu, 5 May 2022 08:40:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244338AbiEEMkY (ORCPT ); Thu, 5 May 2022 08:40:24 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EDE0154FA0; Thu, 5 May 2022 05:36:44 -0700 (PDT) Received: from canpemm500009.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KvCqJ4wbJzQj6q; Thu, 5 May 2022 20:36:12 +0800 (CST) Received: from [10.67.102.169] (10.67.102.169) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 5 May 2022 20:36:42 +0800 CC: , , , , , , Subject: Re: [PATCH] PCI/ACPI: Always advertise ASPM support if CONFIG_PCIEASPM=y To: Bjorn Helgaas , Yicong Yang References: <20220503223857.GA414278@bhelgaas> From: Yicong Yang Message-ID: <38e81af3-e7fa-df0c-c3f7-14244dde5a21@huawei.com> Date: Thu, 5 May 2022 20:36:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20220503223857.GA414278@bhelgaas> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.102.169] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500009.china.huawei.com (7.192.105.203) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 2022/5/4 6:38, Bjorn Helgaas wrote: > On Mon, Apr 25, 2022 at 03:06:34PM +0800, Yicong Yang wrote: >> When we have CONFIG_PCIEASPM enabled it means OS can always support ASPM no >> matter user have disabled it through pcie_aspm=off or not. But currently we >> won't advertise ASPM support in _OSC negotiation if user disables it, which >> doesn't match the fact. This will also have side effects that other PCIe >> services like AER and hotplug will be disabled as ASPM support is required >> and we won't negotiate other services if ASPM support is absent. >> >> So this patch makes OS always advertising ASPM support if CONFIG_PCIEASPM=y. >> It intends no functional change to pcie_aspm=off as it will still mark >> aspm_disabled=1 and aspm_support_enabled=false, driver will check these >> status before configuring ASPM. >> >> Tested this patch with pcie_aspm=off: >> estuary:/$ dmesg | egrep -i "aspm|osc" >> [ 0.000000] PCIe ASPM is disabled >> [ 8.706961] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM >> ClockPM Segments MSI EDR HPX-Type3] >> [ 8.726032] acpi PNP0A08:00: _OSC: platform does not support [LTR] >> [ 8.742818] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME >> AER PCIeCapability DPC] >> estuary:/sys/module/pcie_aspm/parameters$ cat policy >> [default] performance powersave powersupersave >> estuary:/sys/module/pcie_aspm/parameters$ echo powersave > policy >> bash: echo: write error: Operation not permitted >> >> Cc: Rafael J. Wysocki >> Suggested-by: Bjorn Helgaas >> [https://lore.kernel.org/linux-pci/20220407154257.GA235990@bhelgaas/] >> Signed-off-by: Yicong Yang >> --- >> drivers/acpi/pci_root.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c >> index 6f9e75d14808..17e78582e633 100644 >> --- a/drivers/acpi/pci_root.c >> +++ b/drivers/acpi/pci_root.c >> @@ -393,7 +393,7 @@ static u32 calculate_support(void) >> support |= OSC_PCI_HPX_TYPE_3_SUPPORT; >> if (pci_ext_cfg_avail()) >> support |= OSC_PCI_EXT_CONFIG_SUPPORT; >> - if (pcie_aspm_support_enabled()) >> + if (IS_ENABLED(CONFIG_PCIEASPM)) > > Is there any way firmware could tell the difference between > "CONFIG_PCIEASPM not set" and "CONFIG_PCIEASPM=y and booted with > 'pcie_aspm=off'"? > > If not, why would we even check whether CONFIG_PCIEASPM is set? > If we announce ASPM support when CONFIG_PCIEASPM=n it'll work as well but negotiation and the log don't match the fact. We'll get misleading messages that ASPM is supported by OS by it cannot be enable as there's no driver. As mentioned by the PCIe Firmware Spec r3.3, "ASPM Optionality supported The operating system sets this bit to 1 if it properly recognizes and manages ASPM support on PCI Express components which report support for ASPM L1 only in the ASPM Support field within the Link Capabilities Register. Otherwise, the operating system sets this bit to 0" When CONFIG_PCIEASPM=n we have no aspm driver and apparently cannot support any ASPM features so we should set the bit to 0 to match the spec. >> support |= OSC_PCI_ASPM_SUPPORT | OSC_PCI_CLOCK_PM_SUPPORT; >> if (pci_msi_enabled()) >> support |= OSC_PCI_MSI_SUPPORT; >> -- >> 2.24.0 >> > . >