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

[Suzuki K Poulose]

On 15/04/2026 09:45, Jie Gan wrote:
> On 4/15/2026 4:32 PM, Leo Yan wrote:
> > 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!
>
> Just share some info:
>
> With my memory, The ARM AMBA ATB Protocol Specification defined a 7-bit 
> width field for the trace ID, that's where the 128 comes from. (in each 
> frame, we also have 7-bit field for containing the trace ID)

That is true and some IDs in the range (0-128) are reserved. So we
actually have less than 128. We need the dynamic allocation, preferrably
isolated to a "pool" for the relevant session to make the full use of
the space.

Suzuki

> Thanks,
> Jie