Remove the disabled device that blocks probing of the connected
replicator, as the replicator driver validates all connected
devices during probe.

kernel log:
[   18.540971] platform 6046000.replicator: deferred probe pending: (reason unknown)

Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/talos.dtsi | 41 -------------------------------------
 1 file changed, 41 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index e0282a5f9a6a..1e2cfd040fe5 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -2263,14 +2263,6 @@ replicator0_out0: endpoint {
 						remote-endpoint = <&tmc_etr_in>;
 					};
 				};
-
-				port@1 {
-					reg = <1>;
-
-					replicator0_out1: endpoint {
-						remote-endpoint = <&replicator1_in>;
-					};
-				};
 			};
 		};
 
@@ -2317,31 +2309,6 @@ tmc_etr_in: endpoint {
 			};
 		};
 
-		replicator@604a000 {
-			compatible = "arm,coresight-dynamic-replicator", "arm,primecell";
-			reg = <0x0 0x0604a000 0x0 0x1000>;
-
-			clocks = <&aoss_qmp>;
-			clock-names = "apb_pclk";
-			status = "disabled";
-
-			in-ports {
-				port {
-					replicator1_in: endpoint {
-						remote-endpoint = <&replicator0_out1>;
-					};
-				};
-			};
-
-			out-ports {
-				port {
-					replicator1_out: endpoint {
-						remote-endpoint = <&funnel_swao_in6>;
-					};
-				};
-			};
-		};
-
 		cti@683b000 {
 			compatible = "arm,coresight-cti", "arm,primecell";
 			reg = <0x0 0x0683b000 0x0 0x1000>;
@@ -2763,14 +2730,6 @@ in-ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				port@6 {
-					reg = <6>;
-
-					funnel_swao_in6: endpoint {
-						remote-endpoint = <&replicator1_out>;
-					};
-				};
-
 				port@7 {
 					reg = <7>;
 

---
base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
change-id: 20260316-clean-up-failed-devices-188fc328b5d2

Best regards,
-- 
Jie Gan <jie.gan@oss.qualcomm.com>

On 16/03/2026 06:31, Jie Gan wrote:
> Remove the disabled device that blocks probing of the connected
> replicator, as the replicator driver validates all connected
> devices during probe.
> 
> kernel log:
> [   18.540971] platform 6046000.replicator: deferred probe pending: (reason unknown)

No, that's not a reason to remove a device. The device is there, right?
So fix Linux drivers if they cannot handle it properly.

Best regards,
Krzysztof

On 3/16/2026 3:14 PM, Krzysztof Kozlowski wrote:
> On 16/03/2026 06:31, Jie Gan wrote:
>> Remove the disabled device that blocks probing of the connected
>> replicator, as the replicator driver validates all connected
>> devices during probe.
>>
>> kernel log:
>> [   18.540971] platform 6046000.replicator: deferred probe pending: (reason unknown)
> 
> No, that's not a reason to remove a device. The device is there, right?
> So fix Linux drivers if they cannot handle it properly.

CoreSight devices build a path from source to sink and defer probing if 
any device in the path is unavailable so the deferred‑probe behavior is 
expected.

We could add logic to fix it in driver but it's much easier to address 
it in DT because we are knowing the device is disabled/Failed in DT.

It's my fault I didnt remove this disabled replicator device in previous 
fix.

Thanks,
Jie

> 
> Best regards,
> Krzysztof

On 16/03/2026 10:33, Jie Gan wrote:
> 
> 
> On 3/16/2026 3:14 PM, Krzysztof Kozlowski wrote:
>> On 16/03/2026 06:31, Jie Gan wrote:
>>> Remove the disabled device that blocks probing of the connected
>>> replicator, as the replicator driver validates all connected
>>> devices during probe.
>>>
>>> kernel log:
>>> [   18.540971] platform 6046000.replicator: deferred probe pending: (reason unknown)
>>
>> No, that's not a reason to remove a device. The device is there, right?
>> So fix Linux drivers if they cannot handle it properly.
> 
> CoreSight devices build a path from source to sink and defer probing if 
> any device in the path is unavailable so the deferred‑probe behavior is 
> expected.
> 
> We could add logic to fix it in driver but it's much easier to address 
> it in DT because we are knowing the device is disabled/Failed in DT.

Nope. You got comment already. DTS represents the hardware, not your
current Linux driver status.

> 
> It's my fault I didnt remove this disabled replicator device in previous 
> fix.
> 



Best regards,
Krzysztof

On 3/16/2026 6:15 PM, Krzysztof Kozlowski wrote:
> On 16/03/2026 10:33, Jie Gan wrote:
>>
>>
>> On 3/16/2026 3:14 PM, Krzysztof Kozlowski wrote:
>>> On 16/03/2026 06:31, Jie Gan wrote:
>>>> Remove the disabled device that blocks probing of the connected
>>>> replicator, as the replicator driver validates all connected
>>>> devices during probe.
>>>>
>>>> kernel log:
>>>> [   18.540971] platform 6046000.replicator: deferred probe pending: (reason unknown)
>>>
>>> No, that's not a reason to remove a device. The device is there, right?
>>> So fix Linux drivers if they cannot handle it properly.
>>
>> CoreSight devices build a path from source to sink and defer probing if
>> any device in the path is unavailable so the deferred‑probe behavior is
>> expected.
>>
>> We could add logic to fix it in driver but it's much easier to address
>> it in DT because we are knowing the device is disabled/Failed in DT.
> 
> Nope. You got comment already. DTS represents the hardware, not your
> current Linux driver status.
> 

Thanks for the patience to explain it, I have submitted a driver patch 
to address it.

Thanks,
Jie

>>
>> It's my fault I didnt remove this disabled replicator device in previous
>> fix.
>>
> 
> 
> 
> Best regards,
> Krzysztof