2269256_zh-CN

是

linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx

linux6.12+imx8mp内核启动时报告：
[ 0.057737] /soc@0: 固定了与 /soc@0/bus@30000000/efuse@30350000/unique-id@8 的依赖循环
[ 0.058809] /soc@0/bus@32c00000/lcd-controller@32fc6000：修正了与 /soc@0/bus@32c00000/hdmi@32fd8000 的依赖循环
[ 0.058972] /soc@0/bus@32c00000/hdmi@32fd8000：修正了与 /soc@0/bus@32c00000/lcd-controller@32fc6000 的依赖循环
[ 0.059239] /soc@0/interrupt-controller@38800000: 修正了与 /soc@0/interrupt-controller@38800000 的依赖循环
[ 0.061960] /soc@0/bus@30000000/pinctrl@30330000: 修复了与 /soc@0/bus@30000000/pinctrl@30330000/miscgrp 的依赖循环
[ 0.061986] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /soc@0/bus@30000000/pinctrl@30330000/hoggrp
[ 0.062566] imx8mp-pinctrl 30330000.pinctrl：initialized IMX pinctrl driver
[ 0.063301] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000
[ 0.064431] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000
[ 0.065497] /soc@0/bus@30000000/clock-controller@30380000: 修正了与 /soc@0/interrupt-controller@38800000 的依赖循环
[ 0.074336] /soc@0/bus@32c00000/lcd-controller@32fc6000：修正了与 /soc@0/bus@32c00000/hdmi@32fd8000 的依赖循环
[ 0.074446] /soc@0/bus@32c00000/hdmi@32fd8000：修复了 /soc@0/bus@32c00000/lcd-controller@32fc6000 的依赖循环
[ 0.076363] /soc@0/bus@32c00000/lcd-controller@32fc6000：修正了与 /soc@0/bus@32c00000/hdmi@32fd8000 的依赖循环
[ 0.076855] /soc@0/bus@32c00000/lcd-controller@32fc6000：修正了与 /soc@0/bus@32c00000/hdmi@32fd8000 的依赖循环
[ 0.076990] /soc@0/bus@32c00000/hdmi@32fd8000：修正了与 /soc@0/bus@32c00000/lcd-controller@32fc6000 的依赖循环

原因是什么？需要处理吗？

Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx

Hi @machangbao

这是正常的，不用处理。

Best Regards,
Zhiming

Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx

Hi @machangbao

这是内核上游引入得补丁，具体commit信息是：

driver core: fw_devlink: Stop trying to optimize cycle detection logic

commit bac3b10b78e54b7da3cede397258f75a2180609b upstream.

In attempting to optimize fw_devlink runtime, I introduced numerous cycle
detection bugs by foregoing cycle detection logic under specific
conditions. Each fix has further narrowed the conditions for optimization.

It's time to give up on these optimization attempts and just run the cycle
detection logic every time fw_devlink tries to create a device link.

The specific bug report that triggered this fix involved a supplier fwnode
that never gets a device created for it. Instead, the supplier fwnode is
represented by the device that corresponds to an ancestor fwnode.

In this case, fw_devlink didn't do any cycle detection because the cycle
detection logic is only run when a device link is created between the
devices that correspond to the actual consumer and supplier fwnodes.

With this change, fw_devlink will run cycle detection logic even when
creating SYNC_STATE_ONLY proxy device links from a device that is an
ancestor of a consumer fwnode.

6.12上面的fw_devlink框架相比以前更健壮，Fixed dependency cycle(s) with表示 fw_devlink 检测到环，并通过调整链接策略（例如降级某些 link 类型或不创建某些 link）来解决问题。这不是错误，而是信息提示，说明系统在启动时处理了潜在的死锁风险。

driver core: fw_devlink: Make cycle detection more robust

fw_devlink could only detect a single and simple cycle because it relied
mainly on device link cycle detection code that only checked for cycles
between devices. The expectation was that the firmware wouldn't have
complicated cycles and multiple cycles between devices. That expectation
has been proven to be wrong.

For example, fw_devlink could handle:

+-+ +-+
|A+------> |B+
+-+ +++
^ |
| |
+----------+

But it couldn't handle even something as "simple" as:

+---------------------+
| |
v |
+-+ +-+ +++
|A+------> |B+------> |C|
+-+ +++ +-+
^ |
| |
+----------+

But firmware has even more complicated cycles like:

+---------------------+
| |
v |
+-+ +---+ +++
+--+A+------>| B +-----> |C|<--+
| +-+ ++--+ +++ |
| ^ | ^ | |
| | | | | |
| +---------+ +---------+ |
| |
+------------------------------+

And this is without including parent child dependencies or nodes in the
cycle that are just firmware nodes that'll never have a struct device
created for them.

The proper way to treat these devices it to not force any probe ordering
between them, while still enforce dependencies between node in the
cycles (A, B and C) and their consumers.

So this patch goes all out and just deals with all types of cycles. It
does this by:

1. Following dependencies across device links, parent-child and fwnode
links.
2. When it find cycles, it mark the device links and fwnode links as
such instead of just deleting them or making the indistinguishable
from proxy SYNC_STATE_ONLY device links.

This way, when new nodes get added, we can immediately find and mark any
new cycles whether the new node is a device or firmware node.

Best Regards,
Zhiming