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 -- மணிவண்ணன் சதாசிவம்
