All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof Wilczy??ski <kw@linux.com>,
	Rob Herring <robh@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	quic_krichai@quicinc.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 0/2] Enable D3 support for Qualcomm bridges
Date: Fri, 2 Feb 2024 20:33:26 +0100	[thread overview]
Message-ID: <20240202193326.GA29000@wunner.de> (raw)
In-Reply-To: <20240202100041.GB8020@thinkpad>

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.

My point was really that this should be determined by
platform_pci_bridge_d3(), that's what the function is for,
instead of inventing a new mechanism.  Exactly how the capability
is detected by of_pci_bridge_d3() is up to DT schema maintainers.

A DT property does have the advantage of better maintainability,
unlike a whitelist which may need to constantly be extended.

Thanks,

Lukas

  reply	other threads:[~2024-02-02 19:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02  6:54 [PATCH 0/2] Enable D3 support for Qualcomm bridges Manivannan Sadhasivam
2024-02-02  6:54 ` [PATCH 1/2] PCI: Add a flag to enable D3 support for PCI bridges Manivannan Sadhasivam
2024-02-02  6:54 ` [PATCH 2/2] PCI: qcom: Enable D3 support for the recent " Manivannan Sadhasivam
2024-02-02  9:00 ` [PATCH 0/2] Enable D3 support for Qualcomm bridges Lukas Wunner
2024-02-02 10:00   ` Manivannan Sadhasivam
2024-02-02 19:33     ` Lukas Wunner [this message]
2024-02-03  4:55       ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240202193326.GA29000@wunner.de \
    --to=lukas@wunner.de \
    --cc=andersson@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=quic_krichai@quicinc.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.