From: Bjorn Helgaas <helgaas@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: manivannan.sadhasivam@oss.qualcomm.com,
Bartosz Golaszewski <brgl@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>,
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Subject: Re: [PATCH 0/2] PCI/pwrctrl: A couple of fixes
Date: Tue, 17 Feb 2026 11:03:29 -0600 [thread overview]
Message-ID: <20260217170329.GA3381022@bhelgaas> (raw)
In-Reply-To: <sq6wub733a7lwmwpjsxp6cxnl3zchzn632b6ni342f4g63rlz3@poxbx7d5vc4y>
On Tue, Feb 17, 2026 at 09:54:43PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Feb 17, 2026 at 10:06:08AM -0600, Bjorn Helgaas wrote:
> > On Tue, Feb 17, 2026 at 03:48:45PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > Hi,
> > >
> > > This series fixes a couple of issues introduced in the recent pwrctrl rework
> > > for v7.0. Both issues are due to some incorrect assumptions on deciding when to
> > > create pwrctrl devices. First issue is due to assuming that all OF graph nodes
> > > require pwrctrl and another one is due to assuming that all PCI child nodes are
> > > PCI devices.
> > >
> > > Both issues are fixed by changing the pwrctrl device creation logic in
> > > pwrctrl/core.
> > >
> > > Testing
> > > =======
> > >
> > > This series is tested on Lenovo Thinkpad T14s.
> > >
> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > ---
> > > Manivannan Sadhasivam (2):
> > > PCI/pwrctrl: Ensure that the remote endpoint node parent has the supply requirement
> > > PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci"
> > >
> > > drivers/pci/pwrctrl/core.c | 51 ++++++++++++++++++++++++++++++++++------------
> > > 1 file changed, 38 insertions(+), 13 deletions(-)
> > > ---
> > > base-commit: 1c2b4a4c2bcb950f182eeeb33d94b565607608cf
> > > change-id: 20260217-pwrctrl-fixes-7-0-b90eb30bbfe7
> >
> > Are these v7.0 material? I assume the pwrctrl changes merged for v7.0
> > were tested but maybe not on this platform or this DT structure?
> >
>
> Yes!
>
> > Is there a functional regression from v6.19 to v7.0 that would justify
> > including these in v7.0?
>
> Atleast patch 1 is a fix for the regression on IPQ platform, but patch 2 is
> required for an upcoming support.
Upcoming support sounds like v7.1 material.
Re patch 1, I'm not really up on the OF graph situation (git grep "OF
graph" in the kernel tree finds several mentions but no pointers,
other than "bindings/graph.txt", which doesn't exist), so I don't know
how to recognize the DT that leads to the problem. I guess we must
need a PCI endpoint node that contains an OF graph element but no
power supply property? Maybe an example would help?
And I guess the problem is that the PCI controller driver probe is
deferred indefinitely, waiting for a pwrctrl driver that doesn't
exist, so no PCI devices are ever found?
next prev parent reply other threads:[~2026-02-17 17:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 10:18 Manivannan Sadhasivam via B4 Relay
2026-02-17 10:18 ` [PATCH 1/2] PCI/pwrctrl: Ensure that the remote endpoint node parent has the supply requirement Manivannan Sadhasivam via B4 Relay
2026-02-17 11:15 ` Bartosz Golaszewski
2026-02-17 11:17 ` Krishna Chaitanya Chundru
2026-02-17 12:45 ` Raj Kumar Bhagat
2026-02-17 10:18 ` [PATCH 2/2] PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci" Manivannan Sadhasivam via B4 Relay
2026-02-17 11:18 ` Krishna Chaitanya Chundru
2026-02-17 12:14 ` Bartosz Golaszewski
2026-02-17 18:09 ` Bjorn Andersson
2026-02-18 12:24 ` Manivannan Sadhasivam
2026-02-23 14:25 ` Bjorn Andersson
2026-02-23 14:31 ` Manivannan Sadhasivam
2026-02-17 16:06 ` [PATCH 0/2] PCI/pwrctrl: A couple of fixes Bjorn Helgaas
2026-02-17 16:24 ` Manivannan Sadhasivam
2026-02-17 17:03 ` Bjorn Helgaas [this message]
2026-02-18 11:54 ` 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=20260217170329.GA3381022@bhelgaas \
--to=helgaas@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=bhelgaas@google.com \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mani@kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--cc=raj.bhagat@oss.qualcomm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®