Re: [PATCH 0/2] PCI/pwrctrl: A couple of fixes

[Manivannan Sadhasivam]

On Tue, Feb 17, 2026 at 11:03:29AM -0600, Bjorn Helgaas wrote:
> 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@xxxxxxxxxxxxxxxx>
> > > > ---
> > > > 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.
> 

Actually, issue fixed by patch 2 is discovered by an upcoming support, but the
issue is there already in theory. That's why I wanted to merge it for 7.0.

> 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?
> 

'OF graph' is the terminology that is used to refer devicetree graph properties:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/graph.yaml

For modeling the M.2 connectors, we used OF graph. The connector node is linked
to the PCI RP node with the help of 'remote-endpoint' graph property as below:

&pcie6_port0 {
	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;

	port {
		pcie6a_port0_ep: endpoint {
			remote-endpoint = <&m2_pcie_ep>;
		};
	};
};

And in the pwrctrl core driver, we assumed that the existence of the 'port' and
'remote-endpoint' properties mean we have a link to the M.2 connector. But
apparently, there are a few platforms like IPQ9574 which has ath12k devices with
WSI interface which also use graph properties:

            wifi@0 {
                compatible = "pci17cb,1109";
                reg = <0x0 0x0 0x0 0x0 0x0>;

                qcom,calibration-variant = "RDP433_1";

                ports {
                    #address-cells = <1>;
                    #size-cells = <0>;

                    port@0 {
                        reg = <0>;

                        wifi1_wsi_tx: endpoint {
                            remote-endpoint = <&wifi2_wsi_rx>;
                        };
                    };

                    port@1 {
                        reg = <1>;

                        wifi1_wsi_rx: endpoint {
                            remote-endpoint = <&wifi3_wsi_tx>;
                        };
                    };
                };


And here, the graph properties are used to link WSI interfaces of one or more
ath12k endpoints together. But they don't need pwrctrl here. So our existing
assumption was wrong and that's what being fixed in patch 1.

> 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?

Exactly.

- Mani

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