On Fri, Jul 17, 2026 at 12:41:54AM +0300, Mohamed Ayman wrote:

[...]

static struct coresight_path *coresight_cpu_get_active_path(enum cs_mode mode) { struct coresight_device *source;

• bool is_active = false;

• struct coresight_path *path = NULL;

• source = coresight_get_percpu_source_ref(smp_processor_id());
• if (!source)

• return NULL;
  

• if (coresight_get_mode(source) & mode)

• is_active = true;
  

• guard(raw_spinlock_irqsave)(&coresight_dev_lock);

• coresight_put_percpu_source_ref(source);

• source = per_cpu(csdev_source, smp_processor_id());
• if (source && (coresight_get_mode(source) & mode))

• path = source->path;
  

• /*

• * It is expected to run in atomic context or with the CPU lock held for
  

• * sysfs mode, so it cannot be preempted to disable the path. Here
  

• * returns the active path pointer without concern that its state may
  

• * change. Since the build path has taken a reference on the component,
  

• * the path can be safely used by the caller.
  

• */
  

Please keep the comment, as it helps explain why the path pointer can be returned and safely used by the caller.

• return is_active ? source->path : NULL;

• return path;

With above update:

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

Just a thought: we could view this in two stages.

1) The first stage is building the CoreSight path, where we need to ensure the involved modules remain bound while the path is being established.

2) Once the path has been built and the device mode is enabled, we enter the runtime stage. From that point on, observing the device mode as enabled guarantees that the associated data structures can be accessed safely.

I would leave this to maintainers for a call in case any concerns on lifetime management.