[PATCH] coresight: platform: check the availability of the endpoint before parse

[PATCH] coresight: platform: check the availability of the endpoint before parse

[Jie Gan]

Check endpoint availability before parsing it. If parsing a connected
endpoint fails, the probe is deferred until the endpoint becomes
available, or eventually fails. In some legacy cases, a replicator
has two output ports where one is disabled and the other is available.
The replicator probe always fails because the disabled endpoint never
becomes available for parsing. In addition, there is no need to defer
probing a device that is connected to a disabled device, which improves
probe performance.

Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
 drivers/hwtracing/coresight/coresight-platform.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
index 0ca3bd762454..e337b6e2bf32 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -220,6 +220,8 @@ static int of_coresight_parse_endpoint(struct device *dev,
 		rparent = of_coresight_get_port_parent(rep);
 		if (!rparent)
 			break;
+		if (!of_device_is_available(rparent))
+			break;
 		if (of_graph_parse_endpoint(rep, &rendpoint))
 			break;
 

---
base-commit: b5d083a3ed1e2798396d5e491432e887da8d4a06
change-id: 20260320-add-availability-check-4cb2ee6e520b

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

Re: [PATCH] coresight: platform: check the availability of the endpoint before parse

[Leo Yan]

On Fri, Mar 20, 2026 at 03:31:12PM +0800, Jie Gan wrote:
> Check endpoint availability before parsing it. If parsing a connected
> endpoint fails, the probe is deferred until the endpoint becomes
> available, or eventually fails.

I want to clarify a bit the failure flow.

Does this mean coresight_find_device_by_fwnode() returns NULL when the
remote device is not found, resulting in -EPROBE_DEFER, but the probe
never waits for the remote device to become available?

> In some legacy cases, a replicator
> has two output ports where one is disabled and the other is available.
> The replicator probe always fails because the disabled endpoint never
> becomes available for parsing. In addition, there is no need to defer
> probing a device that is connected to a disabled device, which improves
> probe performance.
> 
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
>  drivers/hwtracing/coresight/coresight-platform.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
> index 0ca3bd762454..e337b6e2bf32 100644
> --- a/drivers/hwtracing/coresight/coresight-platform.c
> +++ b/drivers/hwtracing/coresight/coresight-platform.c
> @@ -220,6 +220,8 @@ static int of_coresight_parse_endpoint(struct device *dev,
>  		rparent = of_coresight_get_port_parent(rep);
>  		if (!rparent)
>  			break;
> +		if (!of_device_is_available(rparent))
> +			break;
>  		if (of_graph_parse_endpoint(rep, &rendpoint))
>  			break;
>  
> 
> ---
> base-commit: b5d083a3ed1e2798396d5e491432e887da8d4a06
> change-id: 20260320-add-availability-check-4cb2ee6e520b
> 
> Best regards,
> -- 
> Jie Gan <jie.gan@oss.qualcomm.com>
> 

Re: [PATCH] coresight: platform: check the availability of the endpoint before parse

[Jie Gan]

Hi Leo,

On 3/20/2026 4:25 PM, Leo Yan wrote:
> On Fri, Mar 20, 2026 at 03:31:12PM +0800, Jie Gan wrote:
>> Check endpoint availability before parsing it. If parsing a connected
>> endpoint fails, the probe is deferred until the endpoint becomes
>> available, or eventually fails.
> 
> I want to clarify a bit the failure flow.
> 
> Does this mean coresight_find_device_by_fwnode() returns NULL when the
> remote device is not found, resulting in -EPROBE_DEFER, but the probe
> never waits for the remote device to become available?

It's about the coresight_find_device_by_fwnode() returns NULL, resulting 
in -EPROBE_DEFER. So the probe process will re-start after several 
seconds, but always failed because we have a "disabled" device node in 
DT(we can see this device in DT, but it never becomes available). It's 
ok if the device only has one remote device, but has issue with more 
than one remote devices.

Consider below situation:

       device0
    |          |
   device1  device2(status = "disabled")

The probe of device0 succeeds only when device1 and device2 are 
available at probe time. But I think it's ok to probe the device0 only 
with device1 available.

Thanks,
Jie

> 
>> In some legacy cases, a replicator
>> has two output ports where one is disabled and the other is available.
>> The replicator probe always fails because the disabled endpoint never
>> becomes available for parsing. In addition, there is no need to defer
>> probing a device that is connected to a disabled device, which improves
>> probe performance.
>>
>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> ---
>>   drivers/hwtracing/coresight/coresight-platform.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
>> index 0ca3bd762454..e337b6e2bf32 100644
>> --- a/drivers/hwtracing/coresight/coresight-platform.c
>> +++ b/drivers/hwtracing/coresight/coresight-platform.c
>> @@ -220,6 +220,8 @@ static int of_coresight_parse_endpoint(struct device *dev,
>>   		rparent = of_coresight_get_port_parent(rep);
>>   		if (!rparent)
>>   			break;
>> +		if (!of_device_is_available(rparent))
>> +			break;
>>   		if (of_graph_parse_endpoint(rep, &rendpoint))
>>   			break;
>>   
>>
>> ---
>> base-commit: b5d083a3ed1e2798396d5e491432e887da8d4a06
>> change-id: 20260320-add-availability-check-4cb2ee6e520b
>>
>> Best regards,
>> -- 
>> Jie Gan <jie.gan@oss.qualcomm.com>
>>

Re: [PATCH] coresight: platform: check the availability of the endpoint before parse

[Leo Yan]

Hi Jie,

On Fri, Mar 20, 2026 at 04:44:54PM +0800, Jie Gan wrote:

[...]

> It's about the coresight_find_device_by_fwnode() returns NULL, resulting in
> -EPROBE_DEFER. So the probe process will re-start after several seconds, but
> always failed because we have a "disabled" device node in DT(we can see this
> device in DT, but it never becomes available). It's ok if the device only
> has one remote device, but has issue with more than one remote devices.
> 
> Consider below situation:
> 
>       device0
>    |          |
>   device1  device2(status = "disabled")
> 
> The probe of device0 succeeds only when device1 and device2 are available at
> probe time. But I think it's ok to probe the device0 only with device1
> available.

Thanks a lot for details.  We might need to report warning or error if
all remote endpoints fail (e.g., device1/device2 both are disabled),
this is a rare case so would be low priority.

For this patch:

Reviewed-by: Leo Yan <leo.yan@arm.com>