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] [day] [month] [year] [list]

Message-ID: <20240305175107.GA539676@bhelgaas>
Date: Tue, 5 Mar 2024 11:51:07 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Lukas Wunner <lukas@...ner.de>, 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 v3] PCI: Add D3 support for PCI bridges in DT based
 platforms

On Tue, Mar 05, 2024 at 09:55:37PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Feb 22, 2024 at 10:40:52AM +0100, Lukas Wunner wrote:
> > On Wed, Feb 21, 2024 at 12:20:00PM -0600, Bjorn Helgaas wrote:
> > >   1) D3hot doesn't work per spec.  This sounds like a hardware
> > >      defect in the device that should be a quirk based on
> > >      Vendor/Device ID, not something in DT.  I don't actually know if
> > >      this is common, although there are several existing quirks that
> > >      mention issues with D3.
> > 
> > My recollection is that putting Root Ports into D3hot on older x86
> > systems would raise MCEs, which is why pci_bridge_d3_possible() only
> > allows D3hot in cases which are known to work (e.g. Thunderbolt
> > controllers, machines with a recent BIOS).  It was a conservative
> > policy chosen to avoid regressions.
> 
> So pci_bridge_d3_possible() is only checking for D3hot capability?
> If so, I'd rename it to pci_bridge_d3hot_possible() and also
> 'bridge_d3' to 'bridge_d3hot' to make it explicit.

Every device is required to support D3hot (and D3cold), so I think
"d3_possible" and "d3hot_possible" are not very descriptive since they
should always be *possible*.

pci_bridge_d3_possible() seems to be more about whether hotplug and
power management events work in D3hot and maybe some firmware
coordination and validation concerns.

> Since the default value of 'd3cold_allowed' is true, I believe the
> code expects all devices to support D0 and D3cold. Please correct me
> if I'm wrong.

D3cold means "no main power", so every device "supports" that
situation.  The only time 'd3cold_allowed' can be false is when a user
has set it to false via sysfs, so I think it only reflects an
administrative policy choice.

I think the important question for the code is whether software can
remove and restore main power and maybe something about what hotplug
events or PME can be reported, and I have a really hard time following
that decision path.

Bjorn