Hi CoreSight maintainers,
I'm working on adding CoreSight support for RISC-V platform and encountering dependency cycle warnings during boot when defining the device tree topology with bidirectional port references.
## Problem Description
When I define the CoreSight topology in device tree with remote-endpoint properties in both out-ports and in-ports (as shown in some examples), the kernel reports dependency cycle warnings:
... [ 2.092243] /soc/funnel@d9042000: Fixed dependency cycle(s) with /soc/etf@d9043000 [ 2.099843] /soc/funnel@d9042000: Fixed dependency cycle(s) with /soc/etf@d9043000 [ 2.107359] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/funnel@d9042000 [ 2.114899] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/etr@d9044000 [ 2.122234] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/etr@d9044000 [ 2.129492] /soc/etr@d9044000: Fixed dependency cycle(s) with /soc/etf@d9043000
## Current Device Tree Structure
encoder0: encoder@d9002000 { compatible = "riscv,trace-encoder"; reg = <0x0 0xd9002000 0x0 0x1000>; cpus = <&cpu_0>; out-ports { port { cluster0_encoder0_out_port: endpoint { remote-endpoint = <&cluster0_bridge0_in_port>; }; }; }; };
bridge0: bridge@d9003000 { compatible = "riscv,trace-atbbridge"; reg = <0x0 0xd9003000 0x0 0x1000>; cpus = <&cpu_0>; out-ports { port { cluster0_bridge0_out_port: endpoint { remote-endpoint = <&cluster0_funnel_in_port0>; }; }; }; in-ports { port { cluster0_bridge0_in_port: endpoint { remote-endpoint = <&cluster0_encoder0_out_port>; }; }; }; };
.................
cluster0_funnel: funnel@d9000000 { compatible = "riscv,trace-funnel"; reg = <0x0 0xd9000000 0x0 0x1000>; cpus = <&cpu_0>, <&cpu_1>, <&cpu_2>, <&cpu_3>; out-ports { port { cluster0_funnel_out_port: endpoint { remote-endpoint = <&main_funnel_in_port0>; }; }; }; in-ports { #address-cells = <1>; #size-cells = <0>;
port@0 { reg = <0>; cluster0_funnel_in_port0: endpoint { remote-endpoint = <&cluster0_bridge0_out_port>; }; };
port@1 { reg = <1>; cluster0_funnel_in_port1: endpoint { remote-endpoint = <&cluster0_bridge1_out_port>; }; };
port@2 { reg = <2>; cluster0_funnel_in_port2: endpoint { remote-endpoint = <&cluster0_bridge2_out_port>; }; };
port@3 { reg = <3>; cluster0_funnel_in_port3: endpoint { remote-endpoint = <&cluster0_bridge3_out_port>; }; };
}; };
main_funnel: funnel@d9042000 { compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; reg = <0x0 0xd9042000 0x0 0x1000>; clocks = <&dummy_clk>; clock-names = "apb_pclk"; out-ports { port { main_funnel_out_port: endpoint { remote-endpoint = <&etf_in_port>; }; }; }; in-ports { #address-cells = <1>; #size-cells = <0>;
port@0 { reg = <0>; main_funnel_in_port0: endpoint { remote-endpoint = <&cluster0_funnel_out_port>; }; };
port@1 { reg = <1>; main_funnel_in_port1: endpoint { remote-endpoint = <&cluster1_funnel_out_port>; }; };
port@2 { reg = <2>; main_funnel_in_port2: endpoint { remote-endpoint = <&cluster2_funnel_out_port>; }; };
port@3 { reg = <3>; main_funnel_in_port3: endpoint { remote-endpoint = <&cluster3_funnel_out_port>; }; }; }; };
etf: etf@d9043000 { compatible = "arm,coresight-tmc", "arm,primecell"; reg = <0x0 0xd9043000 0x0 0x1000>; clocks = <&dummy_clk>; clock-names = "apb_pclk"; out-ports { port { etf_out_port: endpoint { remote-endpoint = <&etr_in_port>; }; }; }; in-ports { port { etf_in_port: endpoint { remote-endpoint = <&main_funnel_out_port>; }; }; }; };
etr: etr@d9044000 { compatible = "arm,coresight-tmc", "arm,primecell"; reg = <0x0 0xd9044000 0x0 0x1000>; clocks = <&dummy_clk>; clock-names = "apb_pclk"; arm,scatter-gather; in-ports { port { etr_in_port: endpoint { remote-endpoint = <&etf_out_port>; }; }; }; };
## Questions
The kernel's fw_devlink mechanism detects and "fixes" these cycles, but can I avoid them in the device tree definition?
The system works correctly despite the warnings, but I'd like to understand the proper way to define the topology to avoid these messages.
Thank you for your guidance!
liangzhen@linux.spacemit.com
Hi,
On Wed, Feb 04, 2026 at 04:14:48PM +0800, Coresight ML wrote:
[ 2.092243] /soc/funnel@d9042000: Fixed dependency cycle(s) with /soc/etf@d9043000 [ 2.099843] /soc/funnel@d9042000: Fixed dependency cycle(s) with /soc/etf@d9043000 [ 2.107359] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/funnel@d9042000 [ 2.114899] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/etr@d9044000 [ 2.122234] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/etr@d9044000 [ 2.129492] /soc/etr@d9044000: Fixed dependency cycle(s) with /soc/etf@d9043000
[...]
## Questions
The kernel's fw_devlink mechanism detects and "fixes" these cycles, but can I avoid them in the device tree definition?
The system works correctly despite the warnings, but I'd like to understand the proper way to define the topology to avoid these messages.
Thank you for your guidance!
I roughly went through the kernel code:
pr_info("%pfwf: Fixed dependency cycle(s) with %pfwf\n", link->consumer, sup_handle);
This is not a warning but a info for fwnode link cycle. I checked my Juno board which has the similiar logs.
So I concluded the "Fixed dependency cycle(s)" logs are expected for CoreSight DT binding.
Thanks, Leo