Re: [PATCH v3] PCI: Add D3 support for PCI bridges in DT based platforms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux