Re: [PATCH v3] coresight: Fix scheduling while atomic in coresight_cpu_pm_notify()

[Leo Yan]

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@xxxxxxx>

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.