Re: [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