Re: [PATCH v4 3/9] coresight: etm4x: fix leaked trace id

[Leo Yan <leo.yan@arm.com>]

On Wed, Apr 15, 2026 at 09:01:09AM +0100, Yeoreum Yun wrote:

[...]

> > > What I am thinking is as SoCs continue to grow more complex with an
> > > increasing number of subsystems, trace IDs may be exhausted in the near
> > > future. (that's why we have dynamic trace ID allocation/release).
> >
> > Thanks for the input.
> >
> > I am wandering if we can use "dev->devt" as the trace ID.  A device's
> > major/minor number is unique in kernel and dev_t is defined as u32:
> >
> >   typedef u32 __kernel_dev_t;
> >
> > And we can consolidate this for both SYSFS and PERF modes.
> >
> 
> When I see the CORESIGHT_TRACE_ID_MAX:
> 
>  /* architecturally we have 128 IDs some of which are reserved */
>   #define CORESIGHT_TRACE_IDS_MAX 128
> 
> I think this came from the hardware restriction for number of TRACE_IDs.
> In this case, clamping the device_id to trace_id seems more complex and
> reduce some performance perspective.

Sigh, my stupid.  Please ignore my previous comment, let us first fix
ID leak issue.

Given Jie's comment on the use-out issue, it is valid for me especially
if a system have many dummy tracers.  We can defer to refactor it
later (e.g., use separate ranges for hardware and dummy tracers).

thanks for correction!