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

Jie Gan jie.gan at oss.qualcomm.com
Fri Apr 17 01:51:13 PDT 2026



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 
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




More information about the linux-arm-kernel mailing list