lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 3 May 2022 17:38:57 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Yicong Yang <yangyicong@...ilicon.com>
Cc:     bhelgaas@...gle.com, rafael@...nel.org, linux-pci@...r.kernel.org,
        linux-acpi@...r.kernel.org, lenb@...nel.org,
        linux-kernel@...r.kernel.org, linuxarm@...wei.com
Subject: Re: [PATCH] PCI/ACPI: Always advertise ASPM support if
 CONFIG_PCIEASPM=y

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

>  		support |= OSC_PCI_ASPM_SUPPORT | OSC_PCI_CLOCK_PM_SUPPORT;
>  	if (pci_msi_enabled())
>  		support |= OSC_PCI_MSI_SUPPORT;
> -- 
> 2.24.0
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ