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|



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[Igor Paunovic]

Hi Subair,

Your diagnosis is right, and the answer to your first question is: this
is not RK3576 missing anything. RK3588 does the same thing.

From my Orange Pi 5 Plus on mainline 7.2.0-rc7, one line per boot:

  [    2.215019] rockchip-pm-domain fd8d8000.power-management:power-controller:
      Failed to create device link (0x180) with supplier spi2.0 for
      /power-management@fd8d8000/power-controller/power-domain@12

Same driver, same 0x180, same nested-child path, different SoC. And the
trigger on my board is a different property than yours: power-domain@12
and power-domain@8 here carry `domain-supply`, so the supplier resolves
to the SPI-attached PMIC regulator rather than to `soc` via `clocks`.
Two different properties on two different SoCs producing the same
message is a fairly strong sign the cause is structural rather than a
per-SoC DT omission. So I would drop your option 1.

On the flags, for whoever picks this up: 0x180 is
DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_INFERRED, i.e.
FW_DEVLINK_FLAGS_PERMISSIVE in drivers/base/core.c, and that value is
taken on the branch where the fwnode declaring the dependency is not the
device's own fwnode:

	if (con->fwnode == link->consumer)
		flags = fw_devlink_get_flags(link->flags);
	else
		flags = FW_DEVLINK_FLAGS_PERMISSIVE;

which is exactly the nested-child case you describe. Worth noting that
DL_FLAG_CYCLE is a separate bit, so a cycle-tagged link would print
0x380.

More usefully: this has already been explained on-list. Sebastian
Reichel answered the same message class for RK3588 on 12 June 2026,
replying to Diederik de Haas's reports on nanopc-t6-lts, nanopc-t6-plus
and Rock 5B (identical 0x180, power-domain@8 and @12, suppliers 2-0042
and spi2.0):

  https://lore.kernel.org/all/aixze8zFboY3huSf@venus/

His explanation is a cyclic dependency arising because all domains are
provided by a single power-controller device: to probe the regulator you
need the bus controller, which needs its power domain, which needs the
power-controller, which needs the regulator. I would read that message
before going further, and I would not treat this as cosmetic. He is
explicit that it is "neither super bad, nor completely harmless",
because the kernel ends up missing dependency information and pays for
it in extra -EPROBE_DEFER rounds. He also says fixing it properly needs
substantial restructuring of the Rockchip power-controller driver, which
is a rather bigger answer than any of your three options.

One last thing, and I mean it helpfully: I think you have mailed the
wrong people. Your To: list is get_maintainer.pl output for
drivers/gpu/drm/rockchip, which is why five DRM maintainers were on a
power-domain question while the people who own it were not. For the
subsystems you are actually asking about:

  drivers/pmdomain/rockchip/  ->  Ulf Hansson, linux-pm@vger.kernel.org
  drivers/of/ (fw_devlink)    ->  Saravana Kannan,
                                  devicetree@vger.kernel.org

I have added linux-pm and Ulf here, and dropped the DRM maintainers and
dri-devel since the topic is not DRM. If you follow up, consider adding
Saravana and devicetree as well, and run scripts/get_maintainer.pl
against the files you are asking about rather than reusing a recipient
list from another thread. That is most likely why this went five days
without an answer.

Regards,
Igor

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip