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
