[PATCH] of: property: Create devlink between PCI Host bridge and Root Port suppliers

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---
 drivers/of/property.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 50d95d512bf5..10d041ea61f7 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c

@@ -1561,6 +1561,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
 /**
  * of_link_property - Create device links to suppliers listed in a property
  * @con_np: The consumer device tree node which contains the property
+ * @parent_np: Optional parent device tree node requiring child's supplies
  * @prop_name: Name of property to be parsed
  *
  * This function checks if the property @prop_name that is present in the

@@ -1577,7 +1578,8 @@ static const struct supplier_bindings of_supplier_bindings[] = {
  * device tree nodes even when attempts to create a link to one or more
  * suppliers fail.
  */
-static int of_link_property(struct device_node *con_np, const char *prop_name)
+static int of_link_property(struct device_node *con_np, struct device_node *parent_np,
+			    const char *prop_name)
 {
 	struct device_node *phandle;
 	const struct supplier_bindings *s = of_supplier_bindings;

@@ -1598,6 +1600,10 @@ static int of_link_property(struct device_node *con_np, const char *prop_name)
 			matched = true;
 			i++;
 			of_link_to_phandle(con_dev_np, phandle, s->fwlink_flags);
+
+			/* Link the child's supplies to parent if needed */
+			if (parent_np)
+				of_link_to_phandle(parent_np, phandle, s->fwlink_flags);
 			of_node_put(phandle);
 		}
 		s++;

@@ -1632,7 +1638,21 @@ static int of_fwnode_add_links(struct fwnode_handle *fwnode)
 		return -EINVAL;
 
 	for_each_property_of_node(con_np, p)
-		of_link_property(con_np, p->name);
+		of_link_property(con_np, NULL, p->name);
+
+	/*
+	 * Supplies for the PCI host bridges are typically present in the Root
+	 * Port nodes. So parse the Root Port supplies and link them to Host
+	 * bridges (identified by the presence of "linux,pci-domain" property).
+	 */
+	if (of_property_present(con_np, "linux,pci-domain")) {
+		for_each_available_child_of_node_scoped(con_np, child) {
+			if (of_node_is_type(child, "pci")) {
+				for_each_property_of_node(child, p)
+					of_link_property(child, con_np, p->name);
+			}
+		}
+	}
 
 	return 0;
 }

-- 
2.51.0

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---

[...]

This is not 'required' in bindings and device_type="pci" doesn't uniquely
identify root complexes (as can be seen below).. but I suppose this is the
best delimiter we've got

Perhaps it could be made 'required'?

Konrad

On 2/5/26 9:50 AM, Konrad Dybcio wrote:

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

quoted

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---

[...]

This is not 'required' in bindings and device_type="pci" doesn't uniquely
identify root complexes (as can be seen below).. but I suppose this is the
best delimiter we've got

Perhaps it could be made 'required'?

I cut out the line where it said:

if (of_property_present(con_np, "linux,pci-domain")) {

Konrad

Konrad

quoted

+		for_each_available_child_of_node_scoped(con_np, child) {
+			if (of_node_is_type(child, "pci")) {
+				for_each_property_of_node(child, p)
+					of_link_property(child, con_np, p->name);
+			}
+		}
+	}
 
 	return 0;
 }

On Thu, Feb 05, 2026 at 09:50:20AM +0100, Konrad Dybcio wrote:

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

quoted

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---

[...]

This is not 'required' in bindings and device_type="pci" doesn't uniquely
identify root complexes (as can be seen below).. but I suppose this is the
best delimiter we've got

Yeah. There is no way to uniquely identify the Host bridges in DT. So I had to
settle for this.

Maybe I can check for 'device_type', but that will create devlink between switch
port supplies and Root Ports.

Perhaps it could be made 'required'?

Nah. Linux will generate domain numbers on its own. Also, this is a Linux
specific property, so we cannot make it mandatory in dtschema.

- Mani

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

On Thu, Feb 5, 2026 at 1:01 AM Manivannan Sadhasivam
[off-list ref] wrote:

On Thu, Feb 05, 2026 at 09:50:20AM +0100, Konrad Dybcio wrote:

quoted

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

quoted

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---

100% NACK to this patch. You are touching a core part of the
fw_devlink code to fix it for one specific case. This is not the place
to special case for a property or a framework.

Please fix it on the PCI framework level please. Couple of options:
1. Revert the original patch causing the issue. The patch was from
Qualcomm and they didn't test it on their own devices?

2. PCI does this weird thing of setting the of_node of two different
devices to the same of_node. Now that you have this new node, I think
fixing that behavior to use different of_nodes for the two devices
might be a solution that might work here. I forget the technical terms
used in the PCI framework, but I think one was a the bus device and
the other was the root node.

3. Just create device links if you know you have a weird case of
dependency that fw_devlink doesn't pick up? It's generally more
painful to get fw_devlink to ignore what it thinks is a dependency,
but thankfully that's not the case here.

Please continue cc'ing me in future patches trying to address this.
I'm happy to give guidance if you get stuck.

-Saravana

quoted

[...]

This is not 'required' in bindings and device_type="pci" doesn't uniquely
identify root complexes (as can be seen below).. but I suppose this is the
best delimiter we've got

Yeah. There is no way to uniquely identify the Host bridges in DT. So I had to
settle for this.

Maybe I can check for 'device_type', but that will create devlink between switch
port supplies and Root Ports.

quoted

Perhaps it could be made 'required'?

Nah. Linux will generate domain numbers on its own. Also, this is a Linux
specific property, so we cannot make it mandatory in dtschema.

- Mani

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

On Sat, Feb 07, 2026 at 05:27:21PM -0800, Saravana Kannan wrote:

On Thu, Feb 5, 2026 at 1:01 AM Manivannan Sadhasivam
[off-list ref] wrote:

quoted

On Thu, Feb 05, 2026 at 09:50:20AM +0100, Konrad Dybcio wrote:

quoted

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

quoted

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---

100% NACK to this patch. You are touching a core part of the
fw_devlink code to fix it for one specific case. This is not the place
to special case for a property or a framework.

Please fix it on the PCI framework level please. Couple of options:
1. Revert the original patch causing the issue. The patch was from
Qualcomm and they didn't test it on their own devices?

No, this is not the case. Even though the change is applicable to Qcom, the
design is generic. Let me explain a bit more:

The PCIe Root Complex (aka PCIe controller) IP integrates two components:

1. Host bridge (1 per controller)
2. Root Port (1 or more per controller)

Historically, a single PCIe controller devicetree node represented these two
components as most of the ARM platforms had only one Root Port per controller.
But then we started seeing platforms with multiple Root Ports [1]. So this
created fragmentation w.r.t bindings and controller drivers. So Rob suggested to
move the Root Port specific properties (PHY, PERST#, WAKE#) to Root Port node
even if the platform has a single Root Port per controller. This move aimed at
easing the pain when the IP design moves to multi-Root Port design in the
future. So this is how Qcom moved. Now we mandate all PCIe controller drivers to
split port properties to Root Port node.

But the problem here is, the Root Port properties are not controlled by the Root
Port driver (drivers/pci/pcie/portdrv.c), but by the controller driver itself.
Because, most of the controller drivers need to enable the port properties
before they can program their own CSRs. Since the properties are moved to the
Root Port node, the controller drivers are parsing the properties themselves and
controlling the resources. This works fine from controller driver PoV, but
fwdevlink is broken since the suppliers (PHY...) are now associated with the
Root Port node instead of the controller node. So the fwdevlink cannot associate
suppliers with controller node and allows the driver to probe but only to defer
multiple times. This is not a big concern as of now, but Bjorn started noticing
1000s of such deferrals which increased boot time on Qcom's new Glymur platform.

2. PCI does this weird thing of setting the of_node of two different
devices to the same of_node. Now that you have this new node, I think
fixing that behavior to use different of_nodes for the two devices
might be a solution that might work here. I forget the technical terms
used in the PCI framework, but I think one was a the bus device and
the other was the root node.

I believe you are referring to controller device (platform) and Root bus device:

mani@work:~/pci$ ls -l /sys/devices/platform/soc@0/1c08000.pci/of_node
lrwxrwxrwx 1 root root 0 Feb  8 20:31 /sys/devices/platform/soc@0/1c08000.pci/of_node -> ../../../../firmware/devicetree/base/soc@0/pci@1c08000
mani@work:~/pci$ ls -l /sys/devices/platform/soc@0/1c08000.pci/pci0004:00/pci_bus/0004:00/of_node
lrwxrwxrwx 1 root root 0 Feb  8 20:41 /sys/devices/platform/soc@0/1c08000.pci/pci0004:00/pci_bus/0004:00/of_node -> ../../../../../../../firmware/devicetree/base/soc@0/pci@1c08000

Technically, Root bus origates from the host bridge device and connects to the
Root Port device. So we cannot bind it to Root Port node that we are discussing
here and binding to the controller node would be the correct option.

3. Just create device links if you know you have a weird case of
dependency that fw_devlink doesn't pick up? It's generally more
painful to get fw_devlink to ignore what it thinks is a dependency,
but thankfully that's not the case here.

I would love to solve it in the PCI layer itself if there is a way. But I don't
know how. The PCI framework becomes operational only when the controller driver
probes and registers with the framework. But we need to create devlink even
before the controller driver probes.

We do have the PCI class which gets registered during postcore_initcall(), FYI.

Please continue cc'ing me in future patches trying to address this.
I'm happy to give guidance if you get stuck.

Sure, thanks for the review. Even I'm not super happy with plumbing PCI
specific code in the core DT layer, but I'm not sure of doing it elsewhere. Any
suggestions from you would be greatly appreciated!

- Mani

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

On Sun, Feb 08, 2026 at 08:51:33PM +0530, Manivannan Sadhasivam wrote:

On Sat, Feb 07, 2026 at 05:27:21PM -0800, Saravana Kannan wrote:

quoted

On Thu, Feb 5, 2026 at 1:01 AM Manivannan Sadhasivam
[off-list ref] wrote:

quoted

On Thu, Feb 05, 2026 at 09:50:20AM +0100, Konrad Dybcio wrote:

quoted

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

[..]

quoted

3. Just create device links if you know you have a weird case of
dependency that fw_devlink doesn't pick up? It's generally more
painful to get fw_devlink to ignore what it thinks is a dependency,
but thankfully that's not the case here.

I would love to solve it in the PCI layer itself if there is a way. But I don't
know how. The PCI framework becomes operational only when the controller driver
probes and registers with the framework. But we need to create devlink even
before the controller driver probes.

The devlinks are just an optimization, so worst case you should be able
to create the link on the first probe attempt to avoid further probe
deferrals until the dependencies are in place?

Just like we could have done for all those other provider types that
of_link_property() handles.

We do have the PCI class which gets registered during postcore_initcall(), FYI.

quoted

Please continue cc'ing me in future patches trying to address this.
I'm happy to give guidance if you get stuck.

Sure, thanks for the review. Even I'm not super happy with plumbing PCI
specific code in the core DT layer, but I'm not sure of doing it elsewhere. Any
suggestions from you would be greatly appreciated!

I don't understand your concern, Saravana, of_link_property() is all
about tangling subsystem-specific details into the of-core.

Regards,
Bjorn

- Mani

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

On 2/8/26 2:27 AM, Saravana Kannan wrote:

On Thu, Feb 5, 2026 at 1:01 AM Manivannan Sadhasivam
[off-list ref] wrote:

quoted

On Thu, Feb 05, 2026 at 09:50:20AM +0100, Konrad Dybcio wrote:

quoted

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

quoted

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---

100% NACK to this patch. You are touching a core part of the
fw_devlink code to fix it for one specific case. This is not the place
to special case for a property or a framework.

I think the issue runs deeper. There are multiple cases where an
OF node has children which represents sub-blocks of a hw block, and
those may house e.g. a phy reference within. I'm not sure the code can
handle this today.

Konrad

On Mon, Feb 9, 2026 at 4:38 AM Konrad Dybcio
[off-list ref] wrote:

On 2/8/26 2:27 AM, Saravana Kannan wrote:

quoted

On Thu, Feb 5, 2026 at 1:01 AM Manivannan Sadhasivam
[off-list ref] wrote:

quoted

On Thu, Feb 05, 2026 at 09:50:20AM +0100, Konrad Dybcio wrote:

quoted

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

quoted

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---

100% NACK to this patch. You are touching a core part of the
fw_devlink code to fix it for one specific case. This is not the place
to special case for a property or a framework.

Save NACKs for people that aren't listening and you are done
explaining your objections.

I think the issue runs deeper. There are multiple cases where an
OF node has children which represents sub-blocks of a hw block, and
those may house e.g. a phy reference within. I'm not sure the code can
handle this today.

Other cases would probably be for very specific bindings, so they
really have to be located with the code for that binding. It wouldn't
scale in the DT code. I'm not all that against this case (PCI handling
is already somewhat mixed in), but if it has to be solved anyways
there's not much reason to handle a subsystem specific case in the DT
code either.

Rob

On Thu, Feb 5, 2026 at 3:01 AM Manivannan Sadhasivam
[off-list ref] wrote:

On Thu, Feb 05, 2026 at 09:50:20AM +0100, Konrad Dybcio wrote:

quoted

On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:

quoted

In the recent times, devicetree started to represent the PCI Host bridge
supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
the Host bridge drivers still need to control these supplies as a part of
their controller initialization/deinitialization sequence.

So the Host bridge drivers end up parsing the Root Port supplies in their
probe() and controlled them. A downside to this approach is that the
devlink dependency between the suppliers and Host bridge is completely
broken. Due to this, the driver core probes the Host bridge drivers even if
the suppliers are not ready, causing probe deferrals and setup teardowns in
probe().

These probe deferrals sometime happen over 1000 times (as reported in Qcom
Glymur platform) leading to a waste of CPU resources and increase in boot
time. So to fix these unnecessary deferrals, create devlink between the
Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
allow the driver core to probe the Host bridge drivers only when all Root
Port suppliers are available.

Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Manivannan Sadhasivam <redacted>
---

[...]

This is not 'required' in bindings and device_type="pci" doesn't uniquely
identify root complexes (as can be seen below).. but I suppose this is the
best delimiter we've got

Yeah. There is no way to uniquely identify the Host bridges in DT. So I had to
settle for this.

Maybe I can check for 'device_type', but that will create devlink between switch
port supplies and Root Ports.

You can also check the parent is not PCI to exclude that case.

Rob