[PATCH v5 06/12] coresight: etm4x: fix leaked trace id

[Jie Gan]

On 4/17/2026 4:51 PM, Jie Gan wrote:
> 
> 
> On 4/17/2026 4:41 PM, Leo Yan wrote:
>> Hi Jie,
>>
> 
> Hi Leo,
> 
>> On Fri, Apr 17, 2026 at 09:01:17AM +0800, Jie Gan wrote:
>>
>> [...]
>>
>>> ... we still need support static trace ID allocation in parallel for
>>> the dummy sources and we should not break this logic in future refactor.
>>
>> Just confirm what is the reason you need to use static trace ID for the
>> dummy sources?
>>
>> I am wandering if we could use dev->devt as trace ID for dummy
>> devices.  Since the device's MAJOR number is non-zero and occupies the
>> upper bits (see MINORBITS), it is naturally separated from the hardware
>> trace ID range.  If so, we even don't need to bother ID alloc/release.
>>
> 
> The data frame is generated by the dummy source(static TPDM, or some 

I shouldnt take TPDM as example here, TPDM is a special source device 
and it's trace data will be re-constructed in it's connected TPDA device 
with TPDA's trace ID.

We have some other dummy sources designed for the CDSP/ADSP/MODEM 
subsystems... which cannot be directly accessed by the kernel.

Thanks,
Jie

> other static devices, connected to a funnel or replicator, or TPDA 
> device) automatically(contained pre-assigned trace ID) and the data 
> trace is enabled by default. What we should do for the dummy source is 
> enabling its connected port in driver for outputting the trace data to 
> the connected device(funnel/TPDA/replicator etc...).
> 
> For this scenario, we cannot dynamic allocate trace ID for the dummy 
> source device. Because it's pre-assigned during the hardware design.
> 
> Thanks,
> Jie
> 
>> Thanks,
>> Leo
>