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

Jie Gan
2026-04-17T08:58:55Z

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
>