RK3576: rockchip-pm-domain fw_devlink device-link failures for nested power-domain nodes

RK3576: rockchip-pm-domain fw_devlink device-link failures for nested power-domain nodes

[Muhammed Subair]

|Hi Rockchip/kernel folks, I am bringing up an RK3576 board on a 7.1.x 
based kernel and I see the following early boot errors from 
fw_devlink/device-links: [ 0.260388] rockchip-pm-domain 
27380000.power-management:power-controller: Failed to create device link 
(0x180) with supplier soc for 
/soc/power-management@27380000/power-controller/power-domain@0/power-domain@1 
[ 0.262168] rockchip-pm-domain 
27380000.power-management:power-controller: Failed to create device link 
(0x180) with supplier soc for 
/soc/power-management@27380000/power-controller/power-domain@0/power-domain@1/power-domain@2 
... [ 0.285927] rockchip-pm-domain 
27380000.power-management:power-controller: Failed to create device link 
(0x180) with supplier soc for 
/soc/power-management@27380000/power-controller/power-domain@18/power-domain@17 
The board otherwise boots and the affected domains appear functional. 
PCIe/NVMe, HDMI, Ethernet, etc. are working. The RK3576 power-controller 
node has nested power-domain children. These child domain nodes contain 
properties such as `clocks` and `pm_qos`, similar to RK3588/RK3568, and 
`#power-domain-cells` is present as required by 
`rockchip,power-controller.yaml`. My current understanding is that the 
Rockchip PM domain driver consumes these child nodes internally and 
registers the provider from the top-level `power-controller` via 
`of_genpd_add_provider_onecell()`. However, fw_devlink recurses into the 
child fwnodes and tries to create proxy supplier links for dependencies 
such as `clocks`. Since the child power-domain nodes are not normal 
devices, this ends up as failed links from `rockchip-pm-domain` to 
supplier `soc`. Is this expected noise for nested Rockchip power-domain 
nodes, or is RK3576 missing a DT/driver annotation to prevent fw_devlink 
from trying to create device links for these internal child nodes? I 
compared with RK3588/RK3568 and did not find an obvious missing property 
in RK3576. I also do not want to use `fw_devlink=off`, since that hides 
the issue globally. Could you advise whether the right fix should be: 1. 
a DT change for RK3576 power-domain nodes, 2. a Rockchip PM-domain 
driver change to mark child fwnodes as internal/not devices for 
fw_devlink, or 3. an OF/fw_devlink change to avoid creating proxy links 
from generic power-domain child nodes? Thanks, Subair|

RK3576: rockchip-pm-domain fw_devlink device-link failures for nested power-domain nodes

[Muhammed Subair]

Hi Rockchip/kernel folks, 

I am bringing up an RK3576 board on a 7.1.x based kernel and I see the following early boot errors from

fw_devlink/device-links: [ 0.260388] rockchip-pm-domain
27380000.power-management:power-controller: Failed to create device link
(0x180) with supplier soc for
/soc/power-management@27380000/power-controller/power-domain@0/power-domain@1
[ 0.262168] rockchip-pm-domain
27380000.power-management:power-controller: Failed to create device link
(0x180) with supplier soc for
/soc/power-management@27380000/power-controller/power-domain@0/power-domain@1/power-domain@2
... [ 0.285927] rockchip-pm-domain
27380000.power-management:power-controller: Failed to create device link
(0x180) with supplier soc for
/soc/power-management@27380000/power-controller/power-domain@18/power-domain@17

The board otherwise boots and the affected domains appear functional. 
PCIe/NVMe, HDMI, Ethernet, etc. are working. The RK3576 power-controller node has nested power-domain children. 
These child domain nodes contain properties such as `clocks` and `pm_qos`, similar to RK3588/RK3568, and `#power-domain-cells` is present as required by `rockchip,power-controller.yaml`. 
My current understanding is that the Rockchip PM domain driver consumes these child nodes internally and registers the provider from the top-level `power-controller` via `of_genpd_add_provider_onecell()`.
However, fw_devlink recurses into the child fwnodes and tries to create proxy supplier links for dependencies such as `clocks`. 
Since the child power-domain nodes are not normal devices, this ends up as failed links from `rockchip-pm-domain` to supplier `soc`. 
Is this expected noise for nested Rockchip power-domain nodes, or is RK3576 missing a DT/driver annotation to prevent fw_devlink from trying to create device links for these internal child nodes? 
I compared with RK3588/RK3568 and did not find an obvious missing property in RK3576. I also do not want to use `fw_devlink=off`, 
since that hides the issue globally. Could you advise whether the right fix should be: 

1. a DT change for RK3576 power-domain nodes, 
2. a Rockchip PM-domain driver change to mark child fwnodes as internal/not devices for fw_devlink, or 
3. an OF/fw_devlink change to avoid creating proxy links from generic power-domain child nodes? 


Thanks, Subair

Re: RK3576: rockchip-pm-domain fw_devlink device-link failures for nested power-domain nodes

[support]

[-- Attachment #1.1: Type: text/plain, Size: 3569 bytes --]

Hi Subair,
We have encountered the same "Failed to create device link (0x180)" warnings across our Rockchip BSP development, not only on RK3576 but also on RK3588 and RK3568. This is not an RK3576-specific DTS issue.
As Sebastian Reichel explained in the accel: rocket NPU thread earlier this year [1], the root cause is a fundamental cyclic dependency in the Rockchip power-controller driver: the PM domain controller may depend on a regulator supplied via I2C, while the I2C controller itself sits in a power domain managed by the same controller. fw_devlink detects this cycle, gives up, and prints the warning.
For the specific pattern you are seeing ― where the failed supplier is "soc" rather than an I2C PMIC ― the mechanism is slightly different. The nested power-domain child nodes (power-domain@0/power-domain@1, etc.) are consumed internally by rockchip_pm_add_one_domain(), but fw_devlink treats them as potential devices. It sees their clocks references and attempts to create proxy device links. Since the child fwnodes have no associated struct device, the links fail and fall back to the parent ("soc").
Regarding your three options:
Option 2 (driver-level fix) is the most practical path. In rockchip_pm_domain_probe(), after parsing each child node via rockchip_pm_add_one_domain(), the driver could mark the child fwnode with FWNODE_FLAG_NOT_DEVICE. This tells fw_devlink to skip link creation for that node and walk up to the parent (power-controller) device instead. Something like:
for_each_available_child_of_node(np, np_child) {
    /* ... existing domain registration ... */
    fwnode_set_flag(&np_child->fwnode, FWNODE_FLAG_NOT_DEVICE);
}

This is targeted, does not affect other platforms, and requires no DT binding changes. The same approach could be applied recursively for nested sub-domains (power-domain@0/power-domain@1).
Option 1 (DT change) would be fragile ― the DT binding already correctly describes the power-domain topology, and adding a non-standard annotation property would be a workaround rather than a fix.
Option 3 (OF/fw_devlink core change) is the proper long-term fix but, as Sebastian noted, requires restructuring how the Rockchip power-controller driver registers its provider. This is unlikely to land in the near term.
In our production BSPs (RK3588/RK3568), we have been treating these warnings as cosmetic ― the affected domains function correctly because rockchip_pd_power() handles dependencies internally. However, on RK3576 with its deeper nesting of power-domain child nodes, the volume of warnings is noticeably larger.
We would be happy to test a patch for option 2 on RK3588, RK3568, and RK3576 hardware if someone picks it up.
[1] https://lists.freedesktop.org/archives/dri-devel/2026-June/573801.html
Best regards,

Owen



*************************************************************
Boardcon Embedded Design
Skype: Boardcon
Tel: +86-13537685878
Fax: 86-755-27571552
Email: support@armdesigner.com
Website: http://armdesigner.com
www.boardcon.com
*************************************************************
This message (and any attachments) may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee(s). Unless you are the intended addressee(s), any dissemination, distribution, copying or disclosure of such information is strictly prohibited. If you have received this message in error, please delete it from your system immediately and notify the sender. Thanks!

[-- Attachment #1.2: Type: text/html, Size: 12660 bytes --]

[-- Attachment #2: InsertPic_E166.jpg --]
[-- Type: image/jpeg, Size: 2573 bytes --]

Re: RK3576: rockchip-pm-domain fw_devlink device-link failures for nested power-domain nodes

[support]

[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]

Hi Subair,
We have encountered the same "Failed to create device link (0x180)" warnings across our Rockchip BSP development, not only on RK3576 but also on RK3588 and RK3568. This is not an RK3576-specific DTS issue.
As Sebastian Reichel explained in the accel: rocket NPU thread earlier this year [1], the root cause is a fundamental cyclic dependency in the Rockchip power-controller driver: the PM domain controller may depend on a regulator supplied via I2C, while the I2C controller itself sits in a power domain managed by the same controller. fw_devlink detects this cycle, gives up, and prints the warning.
For the specific pattern you are seeing ― where the failed supplier is "soc" rather than an I2C PMIC ― the mechanism is slightly different. The nested power-domain child nodes (power-domain@0/power-domain@1, etc.) are consumed internally by rockchip_pm_add_one_domain(), but fw_devlink treats them as potential devices. It sees their clocks references and attempts to create proxy device links. Since the child fwnodes have no associated struct device, the links fail and fall back to the parent ("soc").
Regarding your three options:
Option 2 (driver-level fix) is the most practical path. In rockchip_pm_domain_probe(), after parsing each child node via rockchip_pm_add_one_domain(), the driver could mark the child fwnode with FWNODE_FLAG_NOT_DEVICE. This tells fw_devlink to skip link creation for that node and walk up to the parent (power-controller) device instead. Something like:
for_each_available_child_of_node(np, np_child) {
    /* ... existing domain registration ... */
    fwnode_set_flag(&np_child->fwnode, FWNODE_FLAG_NOT_DEVICE);
}

This is targeted, does not affect other platforms, and requires no DT binding changes. The same approach could be applied recursively for nested sub-domains (power-domain@0/power-domain@1).
Option 1 (DT change) would be fragile ― the DT binding already correctly describes the power-domain topology, and adding a non-standard annotation property would be a workaround rather than a fix.
Option 3 (OF/fw_devlink core change) is the proper long-term fix but, as Sebastian noted, requires restructuring how the Rockchip power-controller driver registers its provider. This is unlikely to land in the near term.
In our production BSPs (RK3588/RK3568), we have been treating these warnings as cosmetic ― the affected domains function correctly because rockchip_pd_power() handles dependencies internally. However, on RK3576 with its deeper nesting of power-domain child nodes, the volume of warnings is noticeably larger.
We would be happy to test a patch for option 2 on RK3588, RK3568, and RK3576 hardware if someone picks it up.
[1] https://lists.freedesktop.org/archives/dri-devel/2026-June/573801.html
Best regards,

Owen

*************************************************************
Boardcon Embedded Design
Skype: Boardcon
Tel: +86-13537685878
Fax: 86-755-27571552
Email: support@armdesigner.com
Website: http://armdesigner.com
www.boardcon.com
*************************************************************


[-- Attachment #2: Type: text/html, Size: 11317 bytes --]

Re: RK3576: rockchip-pm-domain fw_devlink device-link failures for nested power-domain nodes

[support]

[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]

Hi Subair,
We have encountered the same "Failed to create device link (0x180)" warnings across our Rockchip BSP development, not only on RK3576 but also on RK3588 and RK3568. This is not an RK3576-specific DTS issue.
As Sebastian Reichel explained in the accel: rocket NPU thread earlier this year [1], the root cause is a fundamental cyclic dependency in the Rockchip power-controller driver: the PM domain controller may depend on a regulator supplied via I2C, while the I2C controller itself sits in a power domain managed by the same controller. fw_devlink detects this cycle, gives up, and prints the warning.
For the specific pattern you are seeing ― where the failed supplier is "soc" rather than an I2C PMIC ― the mechanism is slightly different. The nested power-domain child nodes (power-domain@0/power-domain@1, etc.) are consumed internally by rockchip_pm_add_one_domain(), but fw_devlink treats them as potential devices. It sees their clocks references and attempts to create proxy device links. Since the child fwnodes have no associated struct device, the links fail and fall back to the parent ("soc").
Regarding your three options:
Option 2 (driver-level fix) is the most practical path. In rockchip_pm_domain_probe(), after parsing each child node via rockchip_pm_add_one_domain(), the driver could mark the child fwnode with FWNODE_FLAG_NOT_DEVICE. This tells fw_devlink to skip link creation for that node and walk up to the parent (power-controller) device instead. Something like:
for_each_available_child_of_node(np, np_child) {
    /* ... existing domain registration ... */
    fwnode_set_flag(&np_child->fwnode, FWNODE_FLAG_NOT_DEVICE);
}

This is targeted, does not affect other platforms, and requires no DT binding changes. The same approach could be applied recursively for nested sub-domains (power-domain@0/power-domain@1).
Option 1 (DT change) would be fragile ― the DT binding already correctly describes the power-domain topology, and adding a non-standard annotation property would be a workaround rather than a fix.
Option 3 (OF/fw_devlink core change) is the proper long-term fix but, as Sebastian noted, requires restructuring how the Rockchip power-controller driver registers its provider. This is unlikely to land in the near term.
In our production BSPs (RK3588/RK3568), we have been treating these warnings as cosmetic ― the affected domains function correctly because rockchip_pd_power() handles dependencies internally. However, on RK3576 with its deeper nesting of power-domain child nodes, the volume of warnings is noticeably larger.
We would be happy to test a patch for option 2 on RK3588, RK3568, and RK3576 hardware if someone picks it up.
[1] https://lists.freedesktop.org/archives/dri-devel/2026-June/573801.html
Best regards,

Owen

Boardcon Embedded Design

[-- Attachment #2: Type: text/html, Size: 8612 bytes --]