Re: [PATCH 0/2] Enable D3 support for Qualcomm bridges

[Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>]

On Fri, Feb 02, 2024 at 08:33:26PM +0100, Lukas Wunner wrote:
> On Fri, Feb 02, 2024 at 03:30:41PM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Feb 02, 2024 at 10:00:33AM +0100, Lukas Wunner wrote:
> > > Please amend platform_pci_bridge_d3() to call a new of_pci_bridge_d3()
> > > function which determines whether D3 is supported by the platform.
> > > 
> > > E.g. of_pci_bridge_d3() could contain a whitelist of supported VID/DID
> > > tuples.  Or it could be defined as a __weak function which always
> > > returns false but can be overridden at link time by a function
> > > defined somewhere in arch/arm/, arch/arm64/ or in some driver
> > > whose Kconfig option is enabled in Qualcomm platforms.
> > 
> > Hmm. If we go with a DT based solution, then introducing a new property like
> > "d3-support" in the PCI bridge node would be the right approach. But then, it
> > also requires defining the PCI bridge node in all the DTs. But that should be
> > fine since it will help us to support WAKE# (per bridge) in the future.
> 
> I'm not sure whether a "d3-support" property would be acceptable.
> My understanding is that capabilities which can be auto-sensed by
> the driver (or the PCI core in this case), e.g. by looking at the
> PCI IDs or compatible string, should not be described in the DT.
> 

We cannot whitelist platforms in DT. DT should describe the hardware and its
capabilities. In this case, the "supports-d3" property as I proposed [1] tells
the OS that this bridge is capable of supporting D3.

Blacklisting/whitelisting belongs to the OS. We can however, whitelist the
bridges in PCI core. But that has the downside of not being useful to other OSes
supporting DT. Hence, a DT property that describes the hardware capability
makes sense to me.

- Mani

[1] https://github.com/devicetree-org/dt-schema/pull/127

-- 
மணிவண்ணன் சதாசிவம்