linux-kernel - Re: [PATCH v12 0/7] Coresight: Add Coresight TMC Control Unit driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7680489-db7c-49d5-88ff-29e99a49f624@quicinc.com>
Date: Wed, 19 Feb 2025 08:59:29 +0800
From: Jie Gan <quic_jiegan@...cinc.com>
To: James Clark <james.clark@...aro.org>,
        Suzuki K Poulose
	<suzuki.poulose@....com>
CC: Tingwei Zhang <quic_tingweiz@...cinc.com>,
        Jinlong Mao
	<quic_jinlmao@...cinc.com>, <coresight@...ts.linaro.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        Mike Leach
	<mike.leach@...aro.org>,
        Alexander Shishkin
	<alexander.shishkin@...ux.intel.com>,
        Maxime Coquelin
	<mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>
Subject: Re: [PATCH v12 0/7] Coresight: Add Coresight TMC Control Unit driver



On 2/18/2025 6:05 PM, James Clark wrote:
> 
> 
> On 17/02/2025 9:30 am, Jie Gan wrote:
>> From: Jie Gan <jie.gan@....qualcomm.com>
>>
>> The Coresight TMC Control Unit(CTCU) device hosts miscellaneous 
>> configuration
>> registers to control various features related to TMC ETR device.
>>
>> The CTCU device works as a helper device physically connected to the 
>> TMC ETR device.
>> ---------------------------------------------------------
>>               |ETR0|             |ETR1|
>>                . \                 / .
>>                .  \               /  .
>>                .   \             /   .
>>                .    \           /    .
>> ---------------------------------------------------
>> ETR0ATID0-ETR0ATID3     CTCU    ETR1ATID0-ETR1ATID3
>> ---------------------------------------------------
>> Each ETR has four ATID registers with 128 bits long in total.
>> e.g. ETR0ATID0-ETR0ATID3 registers are used by ETR0 device.
>>
>> Based on the trace id which is programed in CTCU ATID register of
>> specific ETR, trace data with that trace id can get into ETR's buffer
>> while other trace data gets ignored. The number of CTCU ATID registers
>> depends on the number of defined TMC ETR devices. For example, two TMC
>> ETR devices need eight ATID registers. ETR0 with ETR0ATID0-ETR0ATID3
>> and ETR1 with ETR1ATID0-ETRATID3.
>>
>> The significant challenge in enabling the data filter function is how
>> to collect the trace ID of the source device. The introduction of
>> trace_id callback function addresses this challenge. The callback 
>> function
>> collects trace ID of the device and return it back. The trace ID will be
>> stored in the structure called coresight_path and transmitted to helper
>> and sink devices.
>>
>> The coresight_path structure is created to address how to transmit
>> parameters needs by coresight_enable_path/coresight_disbale_path
>> functions.
>>
>> Here is the definition of the struct coresight_path:
>> /**
>>   * struct coresight_path - data needed by enable/disable path
>>   * @path:               path from source to sink.
>>   * @trace_id:           trace_id of the whole path.
>>   */
>> struct coresight_path {
>>          struct list_head                *path;
>>          u8                              trace_id;
>> };
>>
>> The atid_offset mentioned before is the offset to ATID register in CTCU
>> device.
>>
>> Enabling the source device will configure one bit in the ATID register 
>> based
>> on its trace ID.
>> Disabling the source devices will reset the bit in the AITD register
>> based on its trace ID.
>>
>> Useage:
>> Enable:
>> STM device with trace ID 5 and ETR0 is activated.
>> Bitmap before the enablement:
>> ETR0ATID0:
>> 31..................543210
>> ==========================
>> 0000000000000000000000...0
>> ==========================
>>
>> Bitmap after the enablement:
>> 31..................543210
>> ==========================
>> 0000000000000...0000100000
>> ==========================
>>
>> The bit 5 of the ETR0ATID0 register is configured to 1 when enabling the
>> STM device.
>>
>> Disable:
>> STM device with trace ID 5 and ETR0 is activated.
>> Bitmap before the disablement:
>> ETR0ATID0:
>> 31................6543210
>> =========================
>> 000000000010111...0100000
>> =========================
>>
>> Bitmap after the disablement
>> ETR0ATID0:
>> 31................6543210
>> =========================
>> 000000000010111...0000000
>> =========================
>>
>> The bit 5 of the ETR0ATID0 register is reset to 0 when disabling the STM
>> device.
>>
>> Sincere thanks to James Clark for providing an excellent idea to handle
>> the trace_id of the path.
>>
>> Changes in V12:
>> 1. Update the method for allocating trace_id for perf mode.
>> Link to V11 - https://lore.kernel.org/linux-arm- 
>> msm/20250214024021.249655-1-quic_jiegan@...cinc.com/
>>
> 
> I tested the latest change, looks good to me.
> 
Hi James,

Thanks for testing.

Jie