2269256_en-US

[#1]

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

linux6.12+imx8mp内核启动时报告：
[ 0.057737] /soc@0: Fixed dependency cycle(s) with /soc@0/bus@30000000/efuse@30350000/unique-id@8
[ 0.058809] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000
[ 0.058972] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000
[ 0.059239] /soc@0/interrupt-controller@38800000: Fixed dependency cycle(s) with /soc@0/interrupt-controller@38800000
[ 0.061960] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /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: Fixed dependency cycle(s) with /soc@0/interrupt-controller@38800000
[ 0.074336] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000
[ 0.074446] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000
[ 0.076363] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000
[ 0.076855] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000
[ 0.076990] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000

原因是什么？需要处理吗

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

Hi @machangbao

This is normal, no need to deal with it.

Best Regards,
Zhiming

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

Hi @machangbao

This is the patch that was introduced upstream of the kernel, the commit message is:

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.

The fw_devlink framework on top of 6.12 is more robust than before, and Fixed dependency cycle(s) with indicates that fw_devlink detected the ring and solved the problem by adjusting the linking policy (e.g., downgrading certain link types or not creating certain links). This is not an error, but an informational note that the system handles potential deadlock risks at boot time.

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