linux-kernel - Re: [PATCH v3] PCI: Add D3 support for PCI bridges in DT 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20240227173705.GA241732@bhelgaas>
Date: Tue, 27 Feb 2024 11:37:05 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
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>, Lukas Wunner <lukas@...ner.de>,
	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 v3] PCI: Add D3 support for PCI bridges in DT based
 platforms

On Tue, Feb 27, 2024 at 10:38:40PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Feb 27, 2024 at 10:25:35AM -0600, Bjorn Helgaas wrote:
> 
> [...]
> 
> > > Ok, I got the issue. TBH, I added the device tree property based on
> > > the existing quirks for the ACPI devices. But none of the DT based
> > > platforms I'm aware of (even the legacy Qcom MSM8996 chipset
> > > released in early 2016) doesn't have any issue with D3hot. But I'm
> > > just nervous to assume it is the case for all the DT based platforms
> > > in the wild.
> > > 
> > > But to proceed further, what is your preference? Should we ammend
> > > the DT property to make it explicit that the propery only focuses on
> > > the D3hot capability of the bridge and it works as per the spec
> > > (PMCSR) or bite the bullet and enable D3hot for all the non-ACPI
> > > platforms?
> > > 
> > > We can add quirks for the bridges later on if we happen to receive
> > > any bug report.
> > 
> > I would assume all devices support D3hot via PMCSR per spec.  We can
> > add quirks if we discover something that doesn't.
> 
> When you say "all devices", are you referring to bridges in DT
> platforms or the bridges across all platforms?

This patch is only concerned with DT, so that's what I'm commenting on
here.  I don't know how to untangle the question of ACPI systems.

This patch affects platform_pci_bridge_d3(), so just based on the
"platform" in the function name, I would expect it to be concerned
with the D3cold case and whether the platform supports controlling
main power.

It looks like this patch says "we can put devices in D3cold if DT has
'supports-d3'".  But I don't know how to make sense of that because
that requires (a) platform hardware to control main power and (b)
software that knows how to use that hardware.  Wouldn't this require a
little more DT description, like "regulator X controls main power for
this bridge"?  And then an OS would only be able to actually use
D3cold if it knows how to *operate* the regulator, and it doesn't seem
like DT could answer that.

> > If we add annotations that "this device works correctly", we're
> > digging a hole for ourselves because it's impossible to remove those
> > annotations and they complicate all future maintenance.
> > 
> > Bjorn
> 
> -- 
> மணிவண்ணன் சதாசிவம்