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

[Igor Paunovic <royalnet026@gmail.com>]

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