From: Bjorn Helgaas <helgaas@kernel.org>
To: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Will Deacon" <will@kernel.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, jonathanh@nvidia.com,
bjorn.andersson@oss.qualcomm.com
Subject: Re: [PATCH v5 1/5] PCI: host-common: Add helper to determine host bridge D3cold eligibility
Date: Wed, 20 May 2026 15:27:55 -0500 [thread overview]
Message-ID: <20260520202755.GA120626@bhelgaas> (raw)
In-Reply-To: <20260519223901.GA20376@bhelgaas>
On Tue, May 19, 2026 at 05:39:01PM -0500, Bjorn Helgaas wrote:
> On Wed, Apr 29, 2026 at 12:12:23PM +0530, Krishna Chaitanya Chundru wrote:
> > Add a common helper, pci_host_common_d3cold_possible(), to determine
> > whether PCIe devices under host bridge can safely transition to D3cold.
> ...
> > +static int __pci_host_common_d3cold_possible(struct pci_dev *pdev, void *userdata)
> > +{
> > + u32 *flags = userdata;
> > + int type;
> > +
> > + /* Ignore conventional PCI devices */
> > + if (!pci_is_pcie(pdev))
> > + return 0;
> > +
> > + type = pci_pcie_type(pdev);
> > + if (type != PCI_EXP_TYPE_ENDPOINT &&
> > + type != PCI_EXP_TYPE_LEG_END &&
> > + type != PCI_EXP_TYPE_RC_END)
> > + return 0;
>
> From https://sashiko.dev/#/patchset/20260429-d3cold-v5-0-89e9735b9df6%40oss.qualcomm.com:
>
> If the topology contains an active conventional PCI device or an
> intermediate PCIe switch in PCI_D0, returning 0 here allows
> pci_walk_bus() to continue without clearing the
> PCI_HOST_D3COLD_ALLOWED flag.
>
> Does this create a situation where the host bridge might
> aggressively power off the link, dropping power to these active
> components?
>
> I guess this is intentional, since you have comment about ignoring
> conventional PCI devices. But this does seem like a potential
> problem. Why should we ignore switches here? And I think it's still
> fairly common to have a PCIe-to-PCI bridge leading to a conventional
> PCI device, and I don't know why we should ignore them.
>
> The commit log consistently refers to "PCIe" devices and endpoints, so
> maybe there's some reason that I'm missing.
>
> There are other sashiko comments on this series that I think should
> also be looked at.
This series is all in pci/next, so you and Mani can decide on whether
any sashiko comments need to be addressed.
Even if there's no code change, I think it'd be nice to have a brief
comment here about why conventional PCI and switches are ignored.
next prev parent reply other threads:[~2026-05-20 20:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 6:42 [PATCH v5 0/5] PCI: qcom: Add D3cold support Krishna Chaitanya Chundru
2026-04-29 6:42 ` [PATCH v5 1/5] PCI: host-common: Add helper to determine host bridge D3cold eligibility Krishna Chaitanya Chundru
2026-05-19 22:39 ` Bjorn Helgaas
2026-05-20 20:27 ` Bjorn Helgaas [this message]
2026-05-21 15:09 ` Manivannan Sadhasivam
2026-04-29 6:42 ` [PATCH v5 2/5] PCI: qcom: Add .get_ltssm() helper Krishna Chaitanya Chundru
2026-04-29 6:42 ` [PATCH v5 3/5] PCI: qcom: Power down PHY via PARF_PHY_CTRL before disabling rails/clocks Krishna Chaitanya Chundru
2026-04-29 6:42 ` [PATCH v5 4/5] PCI: dwc: Use common D3cold eligibility helper in suspend path Krishna Chaitanya Chundru
2026-05-13 13:20 ` Manivannan Sadhasivam
2026-05-20 0:01 ` Bjorn Helgaas
2026-05-22 22:48 ` Bjorn Helgaas
2026-04-29 6:42 ` [PATCH v5 5/5] PCI: qcom: Add D3cold support Krishna Chaitanya Chundru
2026-06-29 21:16 ` Steev Klimaszewski
2026-06-30 6:31 ` Krishna Chaitanya Chundru
2026-06-30 7:30 ` Manivannan Sadhasivam
2026-05-03 20:30 ` Steev Klimaszewski
2026-05-04 3:37 ` Krishna Chaitanya Chundru
2026-05-04 4:14 ` Steev Klimaszewski
2026-05-04 7:06 ` Krishna Chaitanya Chundru
2026-05-04 14:16 ` Steev Klimaszewski
2026-05-13 15:00 ` Manivannan Sadhasivam
2026-05-13 14:54 ` [PATCH v5 0/5] " 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=20260520202755.GA120626@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=will@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.