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

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

[Manivannan Sadhasivam via B4 Relay]

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

Best regards,
-- 
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

[PATCH 1/2] PCI/pwrctrl: Ensure that the remote endpoint node parent has the supply requirement

[Manivannan Sadhasivam via B4 Relay]

From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

If OF graph is used in the PCI device node, pwrctrl core currently creates
the pwrctrl device even if the remote endpoint doesn't have the power
supply requirements. Since the device doesn't have any power supply
requirements, there was no pwrctrl driver to probe, leading to PCI
controller driver probe deferral as it waits for all pwrctrl drivers to
probe before starting bus scan.

This issue happens with Qcom ath12k devices with WSI interface attached to
the Qcom IPQ platforms.

Fix this issue by checking for the existence of at least one power supply
property in the remote endpoint parent node. To consolidate all the checks,
create a new helper pci_pwrctrl_is_required() and move all the checks
there.

Fixes: 9db826206f9b ("PCI/pwrctrl: Create pwrctrl device if graph port is found")
Reported-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/pci/pwrctrl/core.c | 47 +++++++++++++++++++++++++++++++++-------------
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
index 6f7dea6746e0..8325858cc379 100644
--- a/drivers/pci/pwrctrl/core.c
+++ b/drivers/pci/pwrctrl/core.c
@@ -268,6 +268,39 @@ int pci_pwrctrl_power_on_devices(struct device *parent)
 }
 EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
 
+/*
+ * Check whether the pwrctrl device really needs to be created or not. The
+ * pwrctrl device will only be created if the node satisfies below requirements:
+ *
+ * 1. Presence of compatible property to match against the pwrctrl driver (AND)
+ * 2. At least one of the power supplies defined in the devicetree node of the
+ *    device (OR) in the remote endpoint parent node to indicate pwrctrl
+ *    requirement.
+ */
+static bool pci_pwrctrl_is_required(struct device_node *np)
+{
+	struct device_node *endpoint;
+
+	if (!of_property_present(np, "compatible"))
+		return false;
+
+	if (of_pci_supply_present(np))
+		return true;
+
+	if (of_graph_is_present(np)) {
+		for_each_endpoint_of_node(np, endpoint) {
+			struct device_node *remote __free(device_node) =
+				of_graph_get_remote_port_parent(endpoint);
+			if (remote) {
+				if (of_pci_supply_present(remote))
+					return true;
+			}
+		}
+	}
+
+	return false;
+}
+
 static int pci_pwrctrl_create_device(struct device_node *np,
 				     struct device *parent)
 {
@@ -287,19 +320,7 @@ static int pci_pwrctrl_create_device(struct device_node *np,
 		return 0;
 	}
 
-	/*
-	 * Sanity check to make sure that the node has the compatible property
-	 * to allow driver binding.
-	 */
-	if (!of_property_present(np, "compatible"))
-		return 0;
-
-	/*
-	 * Check whether the pwrctrl device really needs to be created or not.
-	 * This is decided based on at least one of the power supplies defined
-	 * in the devicetree node of the device or the graph property.
-	 */
-	if (!of_pci_supply_present(np) && !of_graph_is_present(np)) {
+	if (!pci_pwrctrl_is_required(np)) {
 		dev_dbg(parent, "Skipping OF node: %s\n", np->name);
 		return 0;
 	}

-- 
2.51.0

Re: [PATCH 1/2] PCI/pwrctrl: Ensure that the remote endpoint node parent has the supply requirement

[Bartosz Golaszewski]

On Tue, 17 Feb 2026 11:18:46 +0100, Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> If OF graph is used in the PCI device node, pwrctrl core currently creates
> the pwrctrl device even if the remote endpoint doesn't have the power
> supply requirements. Since the device doesn't have any power supply
> requirements, there was no pwrctrl driver to probe, leading to PCI
> controller driver probe deferral as it waits for all pwrctrl drivers to
> probe before starting bus scan.
>
> This issue happens with Qcom ath12k devices with WSI interface attached to
> the Qcom IPQ platforms.
>
> Fix this issue by checking for the existence of at least one power supply
> property in the remote endpoint parent node. To consolidate all the checks,
> create a new helper pci_pwrctrl_is_required() and move all the checks
> there.
>
> Fixes: 9db826206f9b ("PCI/pwrctrl: Create pwrctrl device if graph port is found")
> Reported-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---

Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH 1/2] PCI/pwrctrl: Ensure that the remote endpoint node parent has the supply requirement

[Krishna Chaitanya Chundru]

On 2/17/2026 3:48 PM, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> If OF graph is used in the PCI device node, pwrctrl core currently creates
> the pwrctrl device even if the remote endpoint doesn't have the power
> supply requirements. Since the device doesn't have any power supply
> requirements, there was no pwrctrl driver to probe, leading to PCI
> controller driver probe deferral as it waits for all pwrctrl drivers to
> probe before starting bus scan.
>
> This issue happens with Qcom ath12k devices with WSI interface attached to
> the Qcom IPQ platforms.
>
> Fix this issue by checking for the existence of at least one power supply
> property in the remote endpoint parent node. To consolidate all the checks,
> create a new helper pci_pwrctrl_is_required() and move all the checks
> there.
>
> Fixes: 9db826206f9b ("PCI/pwrctrl: Create pwrctrl device if graph port is found")
> Reported-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Krishna Chaitanya Chundru<krishna.chundru@oss.qualcomm.com>

- Krishna Chaitanya.
> ---
>   drivers/pci/pwrctrl/core.c | 47 +++++++++++++++++++++++++++++++++-------------
>   1 file changed, 34 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 6f7dea6746e0..8325858cc379 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c
> @@ -268,6 +268,39 @@ int pci_pwrctrl_power_on_devices(struct device *parent)
>   }
>   EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
>   
> +/*
> + * Check whether the pwrctrl device really needs to be created or not. The
> + * pwrctrl device will only be created if the node satisfies below requirements:
> + *
> + * 1. Presence of compatible property to match against the pwrctrl driver (AND)
> + * 2. At least one of the power supplies defined in the devicetree node of the
> + *    device (OR) in the remote endpoint parent node to indicate pwrctrl
> + *    requirement.
> + */
> +static bool pci_pwrctrl_is_required(struct device_node *np)
> +{
> +	struct device_node *endpoint;
> +
> +	if (!of_property_present(np, "compatible"))
> +		return false;
> +
> +	if (of_pci_supply_present(np))
> +		return true;
> +
> +	if (of_graph_is_present(np)) {
> +		for_each_endpoint_of_node(np, endpoint) {
> +			struct device_node *remote __free(device_node) =
> +				of_graph_get_remote_port_parent(endpoint);
> +			if (remote) {
> +				if (of_pci_supply_present(remote))
> +					return true;
> +			}
> +		}
> +	}
> +
> +	return false;
> +}
> +
>   static int pci_pwrctrl_create_device(struct device_node *np,
>   				     struct device *parent)
>   {
> @@ -287,19 +320,7 @@ static int pci_pwrctrl_create_device(struct device_node *np,
>   		return 0;
>   	}
>   
> -	/*
> -	 * Sanity check to make sure that the node has the compatible property
> -	 * to allow driver binding.
> -	 */
> -	if (!of_property_present(np, "compatible"))
> -		return 0;
> -
> -	/*
> -	 * Check whether the pwrctrl device really needs to be created or not.
> -	 * This is decided based on at least one of the power supplies defined
> -	 * in the devicetree node of the device or the graph property.
> -	 */
> -	if (!of_pci_supply_present(np) && !of_graph_is_present(np)) {
> +	if (!pci_pwrctrl_is_required(np)) {
>   		dev_dbg(parent, "Skipping OF node: %s\n", np->name);
>   		return 0;
>   	}
>

Re: [PATCH 1/2] PCI/pwrctrl: Ensure that the remote endpoint node parent has the supply requirement

[Raj Kumar Bhagat]

On 17-02-2026 15:48, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> If OF graph is used in the PCI device node, pwrctrl core currently creates
> the pwrctrl device even if the remote endpoint doesn't have the power
> supply requirements. Since the device doesn't have any power supply
> requirements, there was no pwrctrl driver to probe, leading to PCI
> controller driver probe deferral as it waits for all pwrctrl drivers to
> probe before starting bus scan.
> 
> This issue happens with Qcom ath12k devices with WSI interface attached to
> the Qcom IPQ platforms.
> 
> Fix this issue by checking for the existence of at least one power supply
> property in the remote endpoint parent node. To consolidate all the checks,
> create a new helper pci_pwrctrl_is_required() and move all the checks
> there.
> 
> Fixes: 9db826206f9b ("PCI/pwrctrl: Create pwrctrl device if graph port is found")
> Reported-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Verified it on QCOM IPQ9574 RDP433 with ath12k devices with WSI
interface attached.

Tested-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>

[PATCH 2/2] PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci"

[Manivannan Sadhasivam via B4 Relay]

From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

The PCI host bridge node can have non-PCI child nodes as well, like OPP
tables, USB controller node etc... So the pwrctrl core must check for the
presence of 'device_type' property with value of "pci" to ensure that the
pwrctrl device is only created for PCI device nodes.

Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices")
Reported-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Closes: https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/pci/pwrctrl/core.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
index 8325858cc379..7404d48427ce 100644
--- a/drivers/pci/pwrctrl/core.c
+++ b/drivers/pci/pwrctrl/core.c
@@ -272,8 +272,9 @@ EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
  * Check whether the pwrctrl device really needs to be created or not. The
  * pwrctrl device will only be created if the node satisfies below requirements:
  *
- * 1. Presence of compatible property to match against the pwrctrl driver (AND)
- * 2. At least one of the power supplies defined in the devicetree node of the
+ * 1. Presence of 'device_type = "pci"' property to identify PCI node (AND)
+ * 2. Presence of compatible property to match against the pwrctrl driver (AND)
+ * 3. At least one of the power supplies defined in the devicetree node of the
  *    device (OR) in the remote endpoint parent node to indicate pwrctrl
  *    requirement.
  */
@@ -281,6 +282,9 @@ static bool pci_pwrctrl_is_required(struct device_node *np)
 {
 	struct device_node *endpoint;
 
+	if (!of_node_is_type(np, "pci"))
+		return false;
+
 	if (!of_property_present(np, "compatible"))
 		return false;
 

-- 
2.51.0

Re: [PATCH 2/2] PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci"

[Krishna Chaitanya Chundru]

On 2/17/2026 3:48 PM, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> The PCI host bridge node can have non-PCI child nodes as well, like OPP
> tables, USB controller node etc... So the pwrctrl core must check for the
> presence of 'device_type' property with value of "pci" to ensure that the
> pwrctrl device is only created for PCI device nodes.
>
> Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices")
> Reported-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> Closes: https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Krishna Chaitanya Chundru<krishna.chundru@oss.qualcomm.com>

- Krishna Chaitanya.
> ---
>   drivers/pci/pwrctrl/core.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 8325858cc379..7404d48427ce 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c
> @@ -272,8 +272,9 @@ EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
>    * Check whether the pwrctrl device really needs to be created or not. The
>    * pwrctrl device will only be created if the node satisfies below requirements:
>    *
> - * 1. Presence of compatible property to match against the pwrctrl driver (AND)
> - * 2. At least one of the power supplies defined in the devicetree node of the
> + * 1. Presence of 'device_type = "pci"' property to identify PCI node (AND)
> + * 2. Presence of compatible property to match against the pwrctrl driver (AND)
> + * 3. At least one of the power supplies defined in the devicetree node of the
>    *    device (OR) in the remote endpoint parent node to indicate pwrctrl
>    *    requirement.
>    */
> @@ -281,6 +282,9 @@ static bool pci_pwrctrl_is_required(struct device_node *np)
>   {
>   	struct device_node *endpoint;
>   
> +	if (!of_node_is_type(np, "pci"))
> +		return false;
> +
>   	if (!of_property_present(np, "compatible"))
>   		return false;
>   
>

Re: [PATCH 2/2] PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci"

[Bartosz Golaszewski]

On Tue, 17 Feb 2026 11:18:47 +0100, Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> The PCI host bridge node can have non-PCI child nodes as well, like OPP
> tables, USB controller node etc... So the pwrctrl core must check for the
> presence of 'device_type' property with value of "pci" to ensure that the
> pwrctrl device is only created for PCI device nodes.
>
> Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices")
> Reported-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> Closes: https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---

Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH 2/2] PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci"

[Bjorn Andersson]

On Tue, Feb 17, 2026 at 03:48:47PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> The PCI host bridge node can have non-PCI child nodes as well, like OPP
> tables, USB controller node etc...

Yes, but the usb-controller in my case is a PCI child and should be
pwrctrl'ed. The entity that I don't want pcictrl to handle is the HUB
child on the USB bus.

> So the pwrctrl core must check for the
> presence of 'device_type' property with value of "pci" to ensure that the
> pwrctrl device is only created for PCI device nodes.
> 
> Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices")
> Reported-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> Closes: https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  drivers/pci/pwrctrl/core.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 8325858cc379..7404d48427ce 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c
> @@ -272,8 +272,9 @@ EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
>   * Check whether the pwrctrl device really needs to be created or not. The
>   * pwrctrl device will only be created if the node satisfies below requirements:
>   *
> - * 1. Presence of compatible property to match against the pwrctrl driver (AND)
> - * 2. At least one of the power supplies defined in the devicetree node of the
> + * 1. Presence of 'device_type = "pci"' property to identify PCI node (AND)
> + * 2. Presence of compatible property to match against the pwrctrl driver (AND)
> + * 3. At least one of the power supplies defined in the devicetree node of the
>   *    device (OR) in the remote endpoint parent node to indicate pwrctrl
>   *    requirement.
>   */
> @@ -281,6 +282,9 @@ static bool pci_pwrctrl_is_required(struct device_node *np)
>  {
>  	struct device_node *endpoint;
>  
> +	if (!of_node_is_type(np, "pci"))
> +		return false;

This "solves" my problem by no longer attempting to power on the
onboard_hub. But it also ensures that Neil's added μPD720201 power
controller doesn't power on.

This is based on the expectation that I shouldn't mark the PCI device
(the μPD720201) as device_type = "pci", right? (Doing so makes dtc barf,
but the μPD720201 is powered up, and functional).

If this is incorrect, can you please help me understand how the
usb-controller@0,0 node should look like in
https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com/

Regards,
Bjorn

> +
>  	if (!of_property_present(np, "compatible"))
>  		return false;
>  
> 
> -- 
> 2.51.0
> 
> 

Re: [PATCH 2/2] PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci"

[Manivannan Sadhasivam]

On Tue, Feb 17, 2026 at 12:09:56PM -0600, Bjorn Andersson wrote:
> On Tue, Feb 17, 2026 at 03:48:47PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > 
> > The PCI host bridge node can have non-PCI child nodes as well, like OPP
> > tables, USB controller node etc...
> 
> Yes, but the usb-controller in my case is a PCI child and should be
> pwrctrl'ed. The entity that I don't want pcictrl to handle is the HUB
> child on the USB bus.
> 

I was wrong here. More below...

> > So the pwrctrl core must check for the
> > presence of 'device_type' property with value of "pci" to ensure that the
> > pwrctrl device is only created for PCI device nodes.
> > 
> > Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices")
> > Reported-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> > Closes: https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >  drivers/pci/pwrctrl/core.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> > index 8325858cc379..7404d48427ce 100644
> > --- a/drivers/pci/pwrctrl/core.c
> > +++ b/drivers/pci/pwrctrl/core.c
> > @@ -272,8 +272,9 @@ EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
> >   * Check whether the pwrctrl device really needs to be created or not. The
> >   * pwrctrl device will only be created if the node satisfies below requirements:
> >   *
> > - * 1. Presence of compatible property to match against the pwrctrl driver (AND)
> > - * 2. At least one of the power supplies defined in the devicetree node of the
> > + * 1. Presence of 'device_type = "pci"' property to identify PCI node (AND)
> > + * 2. Presence of compatible property to match against the pwrctrl driver (AND)
> > + * 3. At least one of the power supplies defined in the devicetree node of the
> >   *    device (OR) in the remote endpoint parent node to indicate pwrctrl
> >   *    requirement.
> >   */
> > @@ -281,6 +282,9 @@ static bool pci_pwrctrl_is_required(struct device_node *np)
> >  {
> >  	struct device_node *endpoint;
> >  
> > +	if (!of_node_is_type(np, "pci"))
> > +		return false;
> 
> This "solves" my problem by no longer attempting to power on the
> onboard_hub. But it also ensures that Neil's added μPD720201 power
> controller doesn't power on.
> 
> This is based on the expectation that I shouldn't mark the PCI device
> (the μPD720201) as device_type = "pci", right? (Doing so makes dtc barf,
> but the μPD720201 is powered up, and functional).
> 

Ah, this property is applicable only to bridges, not endpoints. So dt checker
was right and I was wrong :(

> If this is incorrect, can you please help me understand how the
> usb-controller@0,0 node should look like in
> https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com/
> 

Will the below diff on top of this series help? It checks for the presence of
the 'pci' prefix in the device compatible, which should always exist for all
kind of PCI devices including the USB controller and will be absent for the
internal USB hub, which will have 'usb' prefix.

---
diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
index 7404d48427ce..7754baed67f2 100644
--- a/drivers/pci/pwrctrl/core.c
+++ b/drivers/pci/pwrctrl/core.c
@@ -272,20 +272,23 @@ EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
  * Check whether the pwrctrl device really needs to be created or not. The
  * pwrctrl device will only be created if the node satisfies below requirements:
  *
- * 1. Presence of 'device_type = "pci"' property to identify PCI node (AND)
- * 2. Presence of compatible property to match against the pwrctrl driver (AND)
- * 3. At least one of the power supplies defined in the devicetree node of the
+ * 1. Presence of compatible property with "pci" prefix to match against the
+ *    pwrctrl driver (AND)
+ * 2. At least one of the power supplies defined in the devicetree node of the
  *    device (OR) in the remote endpoint parent node to indicate pwrctrl
  *    requirement.
  */
 static bool pci_pwrctrl_is_required(struct device_node *np)
 {
        struct device_node *endpoint;
+       const char *compat;
+       int ret;
 
-       if (!of_node_is_type(np, "pci"))
+       ret = of_property_read_string(np, "compatible", &compat);
+       if (ret < 0)
                return false;
 
-       if (!of_property_present(np, "compatible"))
+       if (!strstarts(compat, "pci"))
                return false;
 
        if (of_pci_supply_present(np))

- Mani

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

Re: [PATCH 2/2] PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci"

[Bjorn Andersson]

On Wed, Feb 18, 2026 at 05:54:58PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Feb 17, 2026 at 12:09:56PM -0600, Bjorn Andersson wrote:
> > On Tue, Feb 17, 2026 at 03:48:47PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[..]
> > > @@ -281,6 +282,9 @@ static bool pci_pwrctrl_is_required(struct device_node *np)
> > >  {
> > >  	struct device_node *endpoint;
> > >  
> > > +	if (!of_node_is_type(np, "pci"))
> > > +		return false;
> > 
> > This "solves" my problem by no longer attempting to power on the
> > onboard_hub. But it also ensures that Neil's added μPD720201 power
> > controller doesn't power on.
> > 
> > This is based on the expectation that I shouldn't mark the PCI device
> > (the μPD720201) as device_type = "pci", right? (Doing so makes dtc barf,
> > but the μPD720201 is powered up, and functional).
> > 
> 
> Ah, this property is applicable only to bridges, not endpoints. So dt checker
> was right and I was wrong :(
> 

Thanks for confirming my understanding (about the property).

> > If this is incorrect, can you please help me understand how the
> > usb-controller@0,0 node should look like in
> > https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com/
> > 
> 
> Will the below diff on top of this series help? It checks for the presence of
> the 'pci' prefix in the device compatible, which should always exist for all
> kind of PCI devices including the USB controller and will be absent for the
> internal USB hub, which will have 'usb' prefix.
> 

It does look a bit crude, but it does resolve my issue. And I don't have
a much better suggestion at this time.

Regards,
Bjorn

> ---
> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 7404d48427ce..7754baed67f2 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c
> @@ -272,20 +272,23 @@ EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
>   * Check whether the pwrctrl device really needs to be created or not. The
>   * pwrctrl device will only be created if the node satisfies below requirements:
>   *
> - * 1. Presence of 'device_type = "pci"' property to identify PCI node (AND)
> - * 2. Presence of compatible property to match against the pwrctrl driver (AND)
> - * 3. At least one of the power supplies defined in the devicetree node of the
> + * 1. Presence of compatible property with "pci" prefix to match against the
> + *    pwrctrl driver (AND)
> + * 2. At least one of the power supplies defined in the devicetree node of the
>   *    device (OR) in the remote endpoint parent node to indicate pwrctrl
>   *    requirement.
>   */
>  static bool pci_pwrctrl_is_required(struct device_node *np)
>  {
>         struct device_node *endpoint;
> +       const char *compat;
> +       int ret;
>  
> -       if (!of_node_is_type(np, "pci"))
> +       ret = of_property_read_string(np, "compatible", &compat);
> +       if (ret < 0)
>                 return false;
>  
> -       if (!of_property_present(np, "compatible"))
> +       if (!strstarts(compat, "pci"))
>                 return false;
>  
>         if (of_pci_supply_present(np))
> 
> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்

Re: [PATCH 2/2] PCI/pwrctrl: Only create pwrctrl device if the device node is of type "pci"

[Manivannan Sadhasivam]

On Mon, Feb 23, 2026 at 08:25:43AM -0600, Bjorn Andersson wrote:
> On Wed, Feb 18, 2026 at 05:54:58PM +0530, Manivannan Sadhasivam wrote:
> > On Tue, Feb 17, 2026 at 12:09:56PM -0600, Bjorn Andersson wrote:
> > > On Tue, Feb 17, 2026 at 03:48:47PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> [..]
> > > > @@ -281,6 +282,9 @@ static bool pci_pwrctrl_is_required(struct device_node *np)
> > > >  {
> > > >  	struct device_node *endpoint;
> > > >  
> > > > +	if (!of_node_is_type(np, "pci"))
> > > > +		return false;
> > > 
> > > This "solves" my problem by no longer attempting to power on the
> > > onboard_hub. But it also ensures that Neil's added μPD720201 power
> > > controller doesn't power on.
> > > 
> > > This is based on the expectation that I shouldn't mark the PCI device
> > > (the μPD720201) as device_type = "pci", right? (Doing so makes dtc barf,
> > > but the μPD720201 is powered up, and functional).
> > > 
> > 
> > Ah, this property is applicable only to bridges, not endpoints. So dt checker
> > was right and I was wrong :(
> > 
> 
> Thanks for confirming my understanding (about the property).
> 
> > > If this is incorrect, can you please help me understand how the
> > > usb-controller@0,0 node should look like in
> > > https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com/
> > > 
> > 
> > Will the below diff on top of this series help? It checks for the presence of
> > the 'pci' prefix in the device compatible, which should always exist for all
> > kind of PCI devices including the USB controller and will be absent for the
> > internal USB hub, which will have 'usb' prefix.
> > 
> 
> It does look a bit crude, but it does resolve my issue. And I don't have
> a much better suggestion at this time.
> 

Thanks for confirming. I'll respin the patches with the changes.

- Mani

> Regards,
> Bjorn
> 
> > ---
> > diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> > index 7404d48427ce..7754baed67f2 100644
> > --- a/drivers/pci/pwrctrl/core.c
> > +++ b/drivers/pci/pwrctrl/core.c
> > @@ -272,20 +272,23 @@ EXPORT_SYMBOL_GPL(pci_pwrctrl_power_on_devices);
> >   * Check whether the pwrctrl device really needs to be created or not. The
> >   * pwrctrl device will only be created if the node satisfies below requirements:
> >   *
> > - * 1. Presence of 'device_type = "pci"' property to identify PCI node (AND)
> > - * 2. Presence of compatible property to match against the pwrctrl driver (AND)
> > - * 3. At least one of the power supplies defined in the devicetree node of the
> > + * 1. Presence of compatible property with "pci" prefix to match against the
> > + *    pwrctrl driver (AND)
> > + * 2. At least one of the power supplies defined in the devicetree node of the
> >   *    device (OR) in the remote endpoint parent node to indicate pwrctrl
> >   *    requirement.
> >   */
> >  static bool pci_pwrctrl_is_required(struct device_node *np)
> >  {
> >         struct device_node *endpoint;
> > +       const char *compat;
> > +       int ret;
> >  
> > -       if (!of_node_is_type(np, "pci"))
> > +       ret = of_property_read_string(np, "compatible", &compat);
> > +       if (ret < 0)
> >                 return false;
> >  
> > -       if (!of_property_present(np, "compatible"))
> > +       if (!strstarts(compat, "pci"))
> >                 return false;
> >  
> >         if (of_pci_supply_present(np))
> > 
> > - Mani
> > 
> > -- 
> > மணிவண்ணன் சதாசிவம்

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

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

[Bjorn Helgaas]

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?

Is there a functional regression from v6.19 to v7.0 that would justify
including these in v7.0?

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

[Manivannan Sadhasivam]

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.

- Mani

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

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

[Bjorn Helgaas]

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?

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@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.
> 

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

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