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

[Jie Gan <jie.gan@oss.qualcomm.com>]

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)

Thanks,
Jie