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

[support <support@armdesigner.com>]

[-- 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 --]