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: Fri, 2 Feb 2024 10:00:33 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczy??ski <kw@...ux.com>, Rob Herring <robh@...nel.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	quic_krichai@...cinc.com, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 0/2] Enable D3 support for Qualcomm bridges

On Fri, Feb 02, 2024 at 12:24:16PM +0530, Manivannan Sadhasivam wrote:
> This series enables D3 support for PCI bridges found in Qcom SoCs. Currently,
> PCI core will enable D3 support for PCI bridges only when the following
> conditions are met:
> 
> 1. Platform is ACPI based
> 2. Thunderbolt controller is used
> 3. pcie_port_pm=force passed in cmdline
> 
> While options 1 and 2 do not apply to Qcom SoCs, option 3 will make the life
> harder for distro maintainers. Due to this, runtime PM is also not getting
> enabled for the bridges.
> 
> Ideally, D3 support should be enabled by default for the recent PCI bridges,
> but we do not have a sane way to detect them. So this series adds a new flag
> "bridge_d3_capable" to "struct pci_dev" which could be set by the bridge
> drivers for capable devices. This will allow the PCI core to enable D3
> support for the bridges during enumeration.

I think the right way to do this is to use the existing call to
platform_pci_bridge_d3() in pci_bridge_d3_possible().

Please amend platform_pci_bridge_d3() to call a new of_pci_bridge_d3()
function which determines whether D3 is supported by the platform.

E.g. of_pci_bridge_d3() could contain a whitelist of supported VID/DID
tuples.  Or it could be defined as a __weak function which always
returns false but can be overridden at link time by a function
defined somewhere in arch/arm/, arch/arm64/ or in some driver
whose Kconfig option is enabled in Qualcomm platforms.

Adding a bit to struct pci_dev essentially duplicates the existing
platform_pci_bridge_d3() functionality, which seems inelegant.
It increases the size of struct pci_dev even on platforms which
don't need it (e.g. ACPI).

Thanks,

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ