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
