[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v7l7n7bi.fsf@rasp.cworth.amperemail.amperecomputing.com>
Date: Wed, 24 Sep 2025 09:28:33 -0700
From: Carl Worth <carl@...amperecomputing.com>
To: Jie Gan <jie.gan@....qualcomm.com>, Suzuki K Poulose
<suzuki.poulose@....com>, Mike Leach <mike.leach@...aro.org>, James Clark
<james.clark@...aro.org>, Alexander Shishkin
<alexander.shishkin@...ux.intel.com>, Tingwei Zhang
<tingwei.zhang@....qualcomm.com>
Cc: coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to
the path
Jie Gan <jie.gan@....qualcomm.com> writes:
> On 9/23/2025 1:31 AM, Carl Worth wrote:
>> I'd still like to have the original command I used to trigger the bug in
>> the commit message. I really like having reproduction steps captured in
>> commit messages when I look back at commits in the future. So, that was:
>>
>> perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null
>
> Sure, I’ll include your commit message in the formal patch series, I
> think it's V3 since you have submitted two versions, if you're okay with
> me sending it out.
Yes. Please do. And thank you.
> The core idea behind coresight_path is that it can hold all the data
> potentially needed by any device along the path.
>
> For example with the path ETM->Link->ETR->CATU:
OK. That makes sense to me. The name of coresight_path definitely threw
me off, since I interpreted it as being a description of the path, not a
container for data to be consumed along the path.
-Carl
Powered by blists - more mailing lists