linux-kernel - Re: [PATCH v4 0/4] PCI: Allow D3Hot for PCI bridges in Devicetree based platforms

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sat, 11 May 2024 12:45:32 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Bjorn Helgaas <bhelgaas@...gle.com>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org, lukas@...ner.de,
	mika.westerberg@...ux.intel.com, Bjorn Helgaas <helgaas@...nel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Len Brown <lenb@...nel.org>
Subject: Re: [PATCH v4 0/4] PCI: Allow D3Hot for PCI bridges in Devicetree
 based platforms

On Tue, Mar 26, 2024 at 04:18:16PM +0530, Manivannan Sadhasivam wrote:
> Hi,
> 
> This series allows D3Hot for PCI bridges in Devicetree based platforms.
> Even though most of the bridges in Devicetree platforms support D3Hot, PCI
> core will allow D3Hot only when one of 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 most of the DT based platforms,
> option 3 will make the life harder for distro maintainers.
> 
> Initially, I tried to fix this issue by using a Devicetree property [1], but
> that was rejected by Bjorn and it was concluded that D3Hot should be allowed by
> default for all the Devicetree based platforms.
> 
> During the review of v3 series, Bjorn noted several shortcomings of the
> pci_bridge_d3_possible() API [2] and I tried to address them in this series as
> well.
> 
> But please note that the patches 2 and 3 needs closer review from ACPI and x86
> folks since I've splitted the D3Hot and D3Cold handling based on my little
> understanding of the code.
> 
> Testing
> =======
> 
> This series is tested on SM8450 based development board on top of [3].
> 

Bjorn, a gently ping on this series.

- Mani

> - Mani
> 
> [1] https://lore.kernel.org/linux-pci/20240214-pcie-qcom-bridge-v3-1-3a713bbc1fd7@linaro.org/
> [2] https://lore.kernel.org/linux-pci/20240305175107.GA539676@bhelgaas/
> [3] https://lore.kernel.org/linux-arm-msm/20240321-pcie-qcom-bridge-dts-v2-0-1eb790c53e43@linaro.org/
> 
> Changes in v4:
> - Added pci_bridge_d3_possible() rework based on comments from Bjorn
> - Got rid of the DT property and allowed D3Hot by default on all DT platforms
> 
> Changes in v3:
> - Fixed kdoc, used of_property_present() and dev_of_node() (Lukas)
> - Link to v2: https://lore.kernel.org/r/20240214-pcie-qcom-bridge-v2-1-9dd6dbb1b817@linaro.org
> 
> Changes in v2:
> - Switched to DT based approach as suggested by Lukas.
> - Link to v1: https://lore.kernel.org/r/20240202-pcie-qcom-bridge-v1-0-46d7789836c0@linaro.org
> 
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> ---
> Manivannan Sadhasivam (4):
>       PCI/portdrv: Make use of pci_dev::bridge_d3 for checking the D3 possibility
>       PCI: Rename pci_bridge_d3_possible() to pci_bridge_d3_allowed()
>       PCI: Decouple D3Hot and D3Cold handling for bridges
>       PCI: Allow PCI bridges to go to D3Hot on all Devicetree based platforms
> 
>  drivers/pci/bus.c          |  2 +-
>  drivers/pci/pci-acpi.c     |  9 ++---
>  drivers/pci/pci-sysfs.c    |  2 +-
>  drivers/pci/pci.c          | 90 ++++++++++++++++++++++++++++++++--------------
>  drivers/pci/pci.h          | 12 ++++---
>  drivers/pci/pcie/portdrv.c | 16 ++++-----
>  drivers/pci/remove.c       |  2 +-
>  include/linux/pci.h        |  3 +-
>  8 files changed, 89 insertions(+), 47 deletions(-)
> ---
> base-commit: 705c1da8fa4816fb0159b5602fef1df5946a3ee2
> change-id: 20240320-pci-bridge-d3-092e2beac438
> 
> Best regards,
> -- 
> Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> 

-- 
மணிவண்ணன் சதாசிவம்