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]
Message-ID: <Z9xXAYA4KS5BabhE@google.com>
Date: Thu, 20 Mar 2025 10:57:21 -0700
From: Brian Norris <briannorris@...omium.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Bjorn Helgaas <helgaas@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>, Len Brown <lenb@...nel.org>,
	Hsin-Yi Wang <hsinyi@...omium.org>, linux-kernel@...r.kernel.org,
	mika.westerberg@...ux.intel.com, linux-acpi@...r.kernel.org,
	linux-pci@...r.kernel.org, lukas@...ner.de
Subject: Re: [PATCH v5] PCI: Allow PCI bridges to go to D3Hot on all
 Devicetree based platforms

Hi Rafael, Manivannan,

On Thu, Mar 13, 2025 at 10:51:13AM +0530, Manivannan Sadhasivam wrote:
> On Wed, Mar 05, 2025 at 02:41:26PM +0100, Rafael J. Wysocki wrote:
> > There were hardware issues related to PM on x86 platforms predating
> > the introduction of Connected Standby in Windows.  For instance,
> > programming a port into D3hot by writing to its PMCSR might cause the
> > PCIe link behind it to go down and the only way to revive it was to
> > power cycle the Root Complex.  And similar.
> > 
> > Also, PM has never really worked correctly on PCI (non-PCIe) bridges
> > and there is this case where the platform firmware handles hotplug and
> > doesn't want the OS to get in the way (the bridge->is_hotplug_bridge
> > && !pciehp_is_native(bridge) check in pci_bridge_d3_possible()).
> > 
> > The DMI check at the end of pci_bridge_d3_possible() is really
> > something to the effect of "there is no particular reason to prevent
> > this bridge from going into D3, but try to avoid platforms where it
> > may not work".
> > 
> 
> Thanks for sharing the background. This could go in the commit message IMO.

Yes, thanks Rafael. This adds a bit more than the guesswork I've done so
far.

> > Basically, as far as I'm concerned, this check can be changed into
> > something like
> > 
> > if (!IS_ENABLED(CONFIG_X86) || dmi_get_bios_year() >= 2015)
> >         return true;

I suppose if this harms any non-x86 BIOS systems, we can just add to
bridge_d3_blacklist[]. This works for me too.

> > which also requires updating the comment above it accordingly.
> > 
> > This would have been better than the check added by the $subject patch IMV.
> 
> Looks good to me. Brian, could you please respin incorporating the comments?

Sure, will send shortly.

Brian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ