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
