linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yicong Yang <yangyicong@huawei.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
	Yicong Yang <yangyicong@hisilicon.com>
Cc: <bhelgaas@google.com>, <rafael@kernel.org>,
	<linux-pci@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
	<lenb@kernel.org>, <linux-kernel@vger.kernel.org>,
	<linuxarm@huawei.com>
Subject: Re: [PATCH] PCI/ACPI: Always advertise ASPM support if CONFIG_PCIEASPM=y
Date: Thu, 5 May 2022 20:36:42 +0800	[thread overview]
Message-ID: <38e81af3-e7fa-df0c-c3f7-14244dde5a21@huawei.com> (raw)
In-Reply-To: <20220503223857.GA414278@bhelgaas>

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 <rafael@kernel.org>
>> Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
>> [https://lore.kernel.org/linux-pci/20220407154257.GA235990@bhelgaas/]
>> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
>> ---
>>  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
>>
> .
> 

  reply	other threads:[~2022-05-05 12:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25  7:06 [PATCH] PCI/ACPI: Always advertise ASPM support if CONFIG_PCIEASPM=y Yicong Yang
2022-05-03 22:38 ` Bjorn Helgaas
2022-05-05 12:36   ` Yicong Yang [this message]
2022-05-05 18:41     ` Bjorn Helgaas
2022-05-09 12:20       ` Yicong Yang
2022-06-25 19:01         ` Bjorn Helgaas
2022-06-27 12:35           ` Yicong Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38e81af3-e7fa-df0c-c3f7-14244dde5a21@huawei.com \
    --to=yangyicong@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=rafael@kernel.org \
    --cc=yangyicong@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).