* [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-22 7:31 [PATCH RFC 0/3] coresight: replace the void pointer with coresight_path pointer Jie Gan
@ 2025-09-22 7:31 ` Jie Gan
2025-09-22 8:29 ` Leo Yan
2025-09-22 17:31 ` Carl Worth
2025-09-22 7:31 ` [PATCH RFC 2/3] coresight: change helper_ops to accept coresight_path Jie Gan
` (2 subsequent siblings)
3 siblings, 2 replies; 20+ messages in thread
From: Jie Gan @ 2025-09-22 7:31 UTC (permalink / raw)
To: Carl Worth, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Jie Gan, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
From: Carl Worth <carl@os.amperecomputing.com>
The handle is essential for retrieving the AUX_EVENT of each CPU and is
required in perf mode. It has been added to the coresight_path so that
dependent devices can access it from the path when needed.
Fixes: 080ee83cc361 ("Coresight: Change functions to accept the coresight_path")
Signed-off-by: Carl Worth <carl@os.amperecomputing.com>
Co-developed-by: Jie Gan <jie.gan@oss.qualcomm.com>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-etm-perf.c | 1 +
drivers/hwtracing/coresight/coresight-tmc-etr.c | 3 ++-
include/linux/coresight.h | 10 ++++++----
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f677c08233ba..5c256af6e54a 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -520,6 +520,7 @@ static void etm_event_start(struct perf_event *event, int flags)
goto out;
path = etm_event_cpu_path(event_data, cpu);
+ path->handle = handle;
/* We need a sink, no need to continue without one */
sink = coresight_get_sink(path);
if (WARN_ON_ONCE(!sink))
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index b07fcdb3fe1a..1040f73f0537 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1327,7 +1327,8 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
struct etr_buf *tmc_etr_get_buffer(struct coresight_device *csdev,
enum cs_mode mode, void *data)
{
- struct perf_output_handle *handle = data;
+ struct coresight_path *path = data;
+ struct perf_output_handle *handle = path->handle;
struct etr_perf_buffer *etr_perf;
switch (mode) {
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 6de59ce8ef8c..4591121ae1d4 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -332,12 +332,14 @@ static struct coresight_dev_list (var) = { \
/**
* struct coresight_path - data needed by enable/disable path
- * @path_list: path from source to sink.
- * @trace_id: trace_id of the whole path.
+ * @path_list: path from source to sink.
+ * @trace_id: trace_id of the whole path.
+ * struct perf_output_handle: handle of the aux_event.
*/
struct coresight_path {
- struct list_head path_list;
- u8 trace_id;
+ struct list_head path_list;
+ u8 trace_id;
+ struct perf_output_handle *handle;
};
enum cs_mode {
--
2.34.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-22 7:31 ` [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path Jie Gan
@ 2025-09-22 8:29 ` Leo Yan
2025-09-22 9:19 ` Jie Gan
2025-09-22 17:31 ` Carl Worth
1 sibling, 1 reply; 20+ messages in thread
From: Leo Yan @ 2025-09-22 8:29 UTC (permalink / raw)
To: Jie Gan
Cc: Carl Worth, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
On Mon, Sep 22, 2025 at 03:31:39PM +0800, Jie Gan wrote:
> From: Carl Worth <carl@os.amperecomputing.com>
>
> The handle is essential for retrieving the AUX_EVENT of each CPU and is
> required in perf mode. It has been added to the coresight_path so that
> dependent devices can access it from the path when needed.
>
> Fixes: 080ee83cc361 ("Coresight: Change functions to accept the coresight_path")
> Signed-off-by: Carl Worth <carl@os.amperecomputing.com>
> Co-developed-by: Jie Gan <jie.gan@oss.qualcomm.com>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm-perf.c | 1 +
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 3 ++-
> include/linux/coresight.h | 10 ++++++----
> 3 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index f677c08233ba..5c256af6e54a 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -520,6 +520,7 @@ static void etm_event_start(struct perf_event *event, int flags)
> goto out;
>
> path = etm_event_cpu_path(event_data, cpu);
> + path->handle = handle;
> /* We need a sink, no need to continue without one */
> sink = coresight_get_sink(path);
> if (WARN_ON_ONCE(!sink))
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index b07fcdb3fe1a..1040f73f0537 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1327,7 +1327,8 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
> struct etr_buf *tmc_etr_get_buffer(struct coresight_device *csdev,
> enum cs_mode mode, void *data)
> {
> - struct perf_output_handle *handle = data;
> + struct coresight_path *path = data;
> + struct perf_output_handle *handle = path->handle;
> struct etr_perf_buffer *etr_perf;
>
> switch (mode) {
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index 6de59ce8ef8c..4591121ae1d4 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -332,12 +332,14 @@ static struct coresight_dev_list (var) = { \
>
> /**
> * struct coresight_path - data needed by enable/disable path
> - * @path_list: path from source to sink.
> - * @trace_id: trace_id of the whole path.
> + * @path_list: path from source to sink.
> + * @trace_id: trace_id of the whole path.
> + * struct perf_output_handle: handle of the aux_event.
s/struct perf_output_handle/@handle/
Otherwise, LGTM:
Reviewed-by: Leo Yan <leo.yan@arm.com>
> */
> struct coresight_path {
> - struct list_head path_list;
> - u8 trace_id;
> + struct list_head path_list;
> + u8 trace_id;
> + struct perf_output_handle *handle;
> };
>
> enum cs_mode {
>
> --
> 2.34.1
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-22 8:29 ` Leo Yan
@ 2025-09-22 9:19 ` Jie Gan
0 siblings, 0 replies; 20+ messages in thread
From: Jie Gan @ 2025-09-22 9:19 UTC (permalink / raw)
To: Leo Yan
Cc: Carl Worth, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
On 9/22/2025 4:29 PM, Leo Yan wrote:
> On Mon, Sep 22, 2025 at 03:31:39PM +0800, Jie Gan wrote:
>> From: Carl Worth <carl@os.amperecomputing.com>
>>
>> The handle is essential for retrieving the AUX_EVENT of each CPU and is
>> required in perf mode. It has been added to the coresight_path so that
>> dependent devices can access it from the path when needed.
>>
>> Fixes: 080ee83cc361 ("Coresight: Change functions to accept the coresight_path")
>> Signed-off-by: Carl Worth <carl@os.amperecomputing.com>
>> Co-developed-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-etm-perf.c | 1 +
>> drivers/hwtracing/coresight/coresight-tmc-etr.c | 3 ++-
>> include/linux/coresight.h | 10 ++++++----
>> 3 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> index f677c08233ba..5c256af6e54a 100644
>> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
>> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> @@ -520,6 +520,7 @@ static void etm_event_start(struct perf_event *event, int flags)
>> goto out;
>>
>> path = etm_event_cpu_path(event_data, cpu);
>> + path->handle = handle;
>> /* We need a sink, no need to continue without one */
>> sink = coresight_get_sink(path);
>> if (WARN_ON_ONCE(!sink))
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> index b07fcdb3fe1a..1040f73f0537 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> @@ -1327,7 +1327,8 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
>> struct etr_buf *tmc_etr_get_buffer(struct coresight_device *csdev,
>> enum cs_mode mode, void *data)
>> {
>> - struct perf_output_handle *handle = data;
>> + struct coresight_path *path = data;
>> + struct perf_output_handle *handle = path->handle;
>> struct etr_perf_buffer *etr_perf;
>>
>> switch (mode) {
>> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>> index 6de59ce8ef8c..4591121ae1d4 100644
>> --- a/include/linux/coresight.h
>> +++ b/include/linux/coresight.h
>> @@ -332,12 +332,14 @@ static struct coresight_dev_list (var) = { \
>>
>> /**
>> * struct coresight_path - data needed by enable/disable path
>> - * @path_list: path from source to sink.
>> - * @trace_id: trace_id of the whole path.
>> + * @path_list: path from source to sink.
>> + * @trace_id: trace_id of the whole path.
>> + * struct perf_output_handle: handle of the aux_event.
>
> s/struct perf_output_handle/@handle/
Hi Leo,
Thanks for pointing out. I actually missed this error during the code
review...
Jie
>
> Otherwise, LGTM:
>
> Reviewed-by: Leo Yan <leo.yan@arm.com>
>
>> */
>> struct coresight_path {
>> - struct list_head path_list;
>> - u8 trace_id;
>> + struct list_head path_list;
>> + u8 trace_id;
>> + struct perf_output_handle *handle;
>> };
>>
>> enum cs_mode {
>>
>> --
>> 2.34.1
>>
>>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-22 7:31 ` [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path Jie Gan
2025-09-22 8:29 ` Leo Yan
@ 2025-09-22 17:31 ` Carl Worth
2025-09-23 1:49 ` Jie Gan
1 sibling, 1 reply; 20+ messages in thread
From: Carl Worth @ 2025-09-22 17:31 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Jie Gan, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
Jie Gan <jie.gan@oss.qualcomm.com> writes:
> From: Carl Worth <carl@os.amperecomputing.com>
>
> The handle is essential for retrieving the AUX_EVENT of each CPU and is
> required in perf mode. It has been added to the coresight_path so that
> dependent devices can access it from the path when needed.
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
> /**
> * struct coresight_path - data needed by enable/disable path
> - * @path_list: path from source to sink.
> - * @trace_id: trace_id of the whole path.
> + * @path_list: path from source to sink.
> + * @trace_id: trace_id of the whole path.
> + * struct perf_output_handle: handle of the aux_event.
> */
Fixing to "@handle" was mentioned in another comment already.
Something about the above still feels a little off to me. It feels like
we're throwing new data into a structure just because it happens to be
conveniently at hand for the code paths we're needing, and not because
it really _belongs_ there.
Or, maybe it's the right place for it, and the cause of my concern is
that "path" is an overly-narrow name in struct coresight_path?
But if a renaming of this structure would improve the code, I'd also be
fine with that happening in a subsequent commit, so I won't try to hold
up the current series based on that.
-Carl
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-22 17:31 ` Carl Worth
@ 2025-09-23 1:49 ` Jie Gan
2025-09-24 10:21 ` Mike Leach
2025-09-24 16:28 ` Carl Worth
0 siblings, 2 replies; 20+ messages in thread
From: Jie Gan @ 2025-09-23 1:49 UTC (permalink / raw)
To: Carl Worth, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
On 9/23/2025 1:31 AM, Carl Worth wrote:
> Jie Gan <jie.gan@oss.qualcomm.com> writes:
>> From: Carl Worth <carl@os.amperecomputing.com>
>>
>> The handle is essential for retrieving the AUX_EVENT of each CPU and is
>> required in perf mode. It has been added to the coresight_path so that
>> dependent devices can access it from the path when needed.
>
> 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.
>> /**
>> * struct coresight_path - data needed by enable/disable path
>> - * @path_list: path from source to sink.
>> - * @trace_id: trace_id of the whole path.
>> + * @path_list: path from source to sink.
>> + * @trace_id: trace_id of the whole path.
>> + * struct perf_output_handle: handle of the aux_event.
>> */
>
> Fixing to "@handle" was mentioned in another comment already.
>
> Something about the above still feels a little off to me. It feels like
> we're throwing new data into a structure just because it happens to be
> conveniently at hand for the code paths we're needing, and not because
> it really _belongs_ there.
>
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:
All the mentioned devices operate by forming a path, for which the
system constructs a coresight_path. This 'path' is then passed to each
device along the route, allowing any device to directly access the
required data from coresight_path instead of receiving it as a separate
argument.
Imagine a device that requires more than two or three arguments, and you
want to pass them through coresight_enable_path or similar functions...
For certain coresight_path instances, we may not need the handle or
other parameters. Since these values are initialized, it's acceptable to
leave them as NULL or 0.
> Or, maybe it's the right place for it, and the cause of my concern is
> that "path" is an overly-narrow name in struct coresight_path?
>
It defines the direction of data flow—serving as the path for trace data.
Thanks,
Jie
> But if a renaming of this structure would improve the code, I'd also be
> fine with that happening in a subsequent commit, so I won't try to hold
> up the current series based on that.
>
> -Carl
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-23 1:49 ` Jie Gan
@ 2025-09-24 10:21 ` Mike Leach
2025-09-24 16:42 ` Suzuki K Poulose
2025-09-24 16:28 ` Carl Worth
1 sibling, 1 reply; 20+ messages in thread
From: Mike Leach @ 2025-09-24 10:21 UTC (permalink / raw)
To: Jie Gan
Cc: Carl Worth, Suzuki K Poulose, James Clark, Alexander Shishkin,
Tingwei Zhang, coresight, linux-arm-kernel, linux-kernel
Hi,
On Tue, 23 Sept 2025 at 02:49, Jie Gan <jie.gan@oss.qualcomm.com> wrote:
>
>
>
> On 9/23/2025 1:31 AM, Carl Worth wrote:
> > Jie Gan <jie.gan@oss.qualcomm.com> writes:
> >> From: Carl Worth <carl@os.amperecomputing.com>
> >>
> >> The handle is essential for retrieving the AUX_EVENT of each CPU and is
> >> required in perf mode. It has been added to the coresight_path so that
> >> dependent devices can access it from the path when needed.
> >
> > 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.
>
> >> /**
> >> * struct coresight_path - data needed by enable/disable path
> >> - * @path_list: path from source to sink.
> >> - * @trace_id: trace_id of the whole path.
> >> + * @path_list: path from source to sink.
> >> + * @trace_id: trace_id of the whole path.
> >> + * struct perf_output_handle: handle of the aux_event.
> >> */
> >
> > Fixing to "@handle" was mentioned in another comment already.
> >
> > Something about the above still feels a little off to me. It feels like
> > we're throwing new data into a structure just because it happens to be
> > conveniently at hand for the code paths we're needing, and not because
> > it really _belongs_ there.
> >
>
This data is perf specific - not path generic; so I agree that this
structure should go elsewhere.
I would suggest in the csdev (coresight_device) structure itself. We
already have some sink specific data in here e.g. perf_sink_id_map.
This could then be set/clear in the functions coresight-etm-perf.c
file, where there is a significant amount of code dealing with the
perf handle and ensuring it is valid and in scope.
This can then be set only when appropriate - for source / sink devices
and only when in perf mode, and avoid the need to pass the handle
around as API call parameters.
Regards
Mike.
> 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:
>
> All the mentioned devices operate by forming a path, for which the
> system constructs a coresight_path. This 'path' is then passed to each
> device along the route, allowing any device to directly access the
> required data from coresight_path instead of receiving it as a separate
> argument.
>
> Imagine a device that requires more than two or three arguments, and you
> want to pass them through coresight_enable_path or similar functions...
>
> For certain coresight_path instances, we may not need the handle or
> other parameters. Since these values are initialized, it's acceptable to
> leave them as NULL or 0.
>
>
> > Or, maybe it's the right place for it, and the cause of my concern is
> > that "path" is an overly-narrow name in struct coresight_path?
> >
>
> It defines the direction of data flow—serving as the path for trace data.
>
> Thanks,
> Jie
>
> > But if a renaming of this structure would improve the code, I'd also be
> > fine with that happening in a subsequent commit, so I won't try to hold
> > up the current series based on that.
> >
> > -Carl
>
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-24 10:21 ` Mike Leach
@ 2025-09-24 16:42 ` Suzuki K Poulose
2025-09-25 10:10 ` James Clark
0 siblings, 1 reply; 20+ messages in thread
From: Suzuki K Poulose @ 2025-09-24 16:42 UTC (permalink / raw)
To: Mike Leach, Jie Gan
Cc: Carl Worth, James Clark, Alexander Shishkin, Tingwei Zhang,
coresight, linux-arm-kernel, linux-kernel
On 24/09/2025 11:21, Mike Leach wrote:
> Hi,
>
> On Tue, 23 Sept 2025 at 02:49, Jie Gan <jie.gan@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 9/23/2025 1:31 AM, Carl Worth wrote:
>>> Jie Gan <jie.gan@oss.qualcomm.com> writes:
>>>> From: Carl Worth <carl@os.amperecomputing.com>
>>>>
>>>> The handle is essential for retrieving the AUX_EVENT of each CPU and is
>>>> required in perf mode. It has been added to the coresight_path so that
>>>> dependent devices can access it from the path when needed.
>>>
>>> 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.
>>
>>>> /**
>>>> * struct coresight_path - data needed by enable/disable path
>>>> - * @path_list: path from source to sink.
>>>> - * @trace_id: trace_id of the whole path.
>>>> + * @path_list: path from source to sink.
>>>> + * @trace_id: trace_id of the whole path.
>>>> + * struct perf_output_handle: handle of the aux_event.
>>>> */
>>>
>>> Fixing to "@handle" was mentioned in another comment already.
>>>
>>> Something about the above still feels a little off to me. It feels like
>>> we're throwing new data into a structure just because it happens to be
>>> conveniently at hand for the code paths we're needing, and not because
>>> it really _belongs_ there.
>>>
>>
> This data is perf specific - not path generic; so I agree that this
> structure should go elsewhere.
>
> I would suggest in the csdev (coresight_device) structure itself. We
> already have some sink specific data in here e.g. perf_sink_id_map.
>
> This could then be set/clear in the functions coresight-etm-perf.c
> file, where there is a significant amount of code dealing with the
> perf handle and ensuring it is valid and in scope.
>
> This can then be set only when appropriate - for source / sink devices
> and only when in perf mode, and avoid the need to pass the handle
> around as API call parameters.
I think this data is specific to the session we are enabling the
device(s) in. e.g., we keep the trace-id in the path.
So, I don't mind having this in the path structure.
Instead of modifying csdev with additional locking from "etm-perf"
it is always cleaner to handle this in the path.
Suzuki
>
> Regards
>
> Mike.
>
>
>
>
>> 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:
>>
>> All the mentioned devices operate by forming a path, for which the
>> system constructs a coresight_path. This 'path' is then passed to each
>> device along the route, allowing any device to directly access the
>> required data from coresight_path instead of receiving it as a separate
>> argument.
>>
>> Imagine a device that requires more than two or three arguments, and you
>> want to pass them through coresight_enable_path or similar functions...
>>
>> For certain coresight_path instances, we may not need the handle or
>> other parameters. Since these values are initialized, it's acceptable to
>> leave them as NULL or 0.
>>
>>
>>> Or, maybe it's the right place for it, and the cause of my concern is
>>> that "path" is an overly-narrow name in struct coresight_path?
>>>
>>
>> It defines the direction of data flow—serving as the path for trace data.
>>
>> Thanks,
>> Jie
>>
>>> But if a renaming of this structure would improve the code, I'd also be
>>> fine with that happening in a subsequent commit, so I won't try to hold
>>> up the current series based on that.
>>>
>>> -Carl
>>
>
>
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-24 16:42 ` Suzuki K Poulose
@ 2025-09-25 10:10 ` James Clark
2025-09-25 16:01 ` Leo Yan
2025-09-25 16:04 ` Leo Yan
0 siblings, 2 replies; 20+ messages in thread
From: James Clark @ 2025-09-25 10:10 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, Jie Gan, Leo Yan
Cc: Carl Worth, Alexander Shishkin, Tingwei Zhang, coresight,
linux-arm-kernel, linux-kernel
On 24/09/2025 5:42 pm, Suzuki K Poulose wrote:
> On 24/09/2025 11:21, Mike Leach wrote:
>> Hi,
>>
>> On Tue, 23 Sept 2025 at 02:49, Jie Gan <jie.gan@oss.qualcomm.com> wrote:
>>>
>>>
>>>
>>> On 9/23/2025 1:31 AM, Carl Worth wrote:
>>>> Jie Gan <jie.gan@oss.qualcomm.com> writes:
>>>>> From: Carl Worth <carl@os.amperecomputing.com>
>>>>>
>>>>> The handle is essential for retrieving the AUX_EVENT of each CPU
>>>>> and is
>>>>> required in perf mode. It has been added to the coresight_path so that
>>>>> dependent devices can access it from the path when needed.
>>>>
>>>> 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.
>>>
>>>>> /**
>>>>> * struct coresight_path - data needed by enable/disable path
>>>>> - * @path_list: path from source to sink.
>>>>> - * @trace_id: trace_id of the whole path.
>>>>> + * @path_list: path from source to sink.
>>>>> + * @trace_id: trace_id of the whole path.
>>>>> + * struct perf_output_handle: handle of the aux_event.
>>>>> */
>>>>
>>>> Fixing to "@handle" was mentioned in another comment already.
>>>>
>>>> Something about the above still feels a little off to me. It feels like
>>>> we're throwing new data into a structure just because it happens to be
>>>> conveniently at hand for the code paths we're needing, and not because
>>>> it really _belongs_ there.
>>>>
>>>
>> This data is perf specific - not path generic; so I agree that this
>> structure should go elsewhere.
>>
>> I would suggest in the csdev (coresight_device) structure itself. We
>> already have some sink specific data in here e.g. perf_sink_id_map.
>>
>> This could then be set/clear in the functions coresight-etm-perf.c
>> file, where there is a significant amount of code dealing with the
>> perf handle and ensuring it is valid and in scope.
>>
>> This can then be set only when appropriate - for source / sink devices
>> and only when in perf mode, and avoid the need to pass the handle
>> around as API call parameters.
>
> I think this data is specific to the session we are enabling the
> device(s) in. e.g., we keep the trace-id in the path.
> So, I don't mind having this in the path structure.
> Instead of modifying csdev with additional locking from "etm-perf"
> it is always cleaner to handle this in the path.
>
>
> Suzuki
>
>
Yeah, and perf_sink_id_map only "needs" to be in the csdev because it
controls sharing IDs between multiple paths which can't be accomplished
by storing it in the path.
This one is just a pointer to the perf handle which really does belong
to the session rather than the device. This makes it more of a path
thing than a csdev thing. Maybe we can rename path to be more like
"session", which also happens to contain a path. But I think path is
fine for now.
However in this case handle is per-cpu data that is only accessed on the
same cpu in tmc_etr_get_buffer(). Assigning it in etm_event_start() just
copies the same per-cpu variable into a non per-cpu place that
eventually gets accessed on the same cpu anyway.
If we exported it then it can be used directly without worrying where to
store it:
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 17afa0f4cdee..4c33f442c80b 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -42,12 +42,8 @@ static bool etm_perf_up;
* the ETM. Thus the event_data for the session must be part of the
ETM context
* to make sure we can disable the trace path.
*/
-struct etm_ctxt {
- struct perf_output_handle handle;
- struct etm_event_data *event_data;
-};
-
-static DEFINE_PER_CPU(struct etm_ctxt, etm_ctxt);
+DEFINE_PER_CPU(struct etm_ctxt, etm_ctxt);
+EXPORT_SYMBOL_GPL(etm_ctxt);
static DEFINE_PER_CPU(struct coresight_device *, csdev_src);
/*
diff --git a/drivers/hwtracing/coresight/coresight-priv.h
b/drivers/hwtracing/coresight/coresight-priv.h
index fd896ac07942..b834e8bef2a5 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -14,6 +14,7 @@
extern struct mutex coresight_mutex;
extern const struct device_type coresight_dev_type[];
+DECLARE_PER_CPU(struct etm_ctxt, etm_ctxt);
/*
* Coresight management registers (0xf00-0xfcc)
@@ -49,6 +50,11 @@ extern const struct device_type coresight_dev_type[];
#define ETM_MODE_EXCL_HOST BIT(32)
#define ETM_MODE_EXCL_GUEST BIT(33)
+struct etm_ctxt {
+ struct perf_output_handle handle;
+ struct etm_event_data *event_data;
+};
+
struct cs_pair_attribute {
struct device_attribute attr;
u32 lo_off;
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c
b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index bf08f6117a7f..7026994b02b3 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1328,8 +1328,9 @@ struct etr_buf *tmc_etr_get_buffer(struct
coresight_device *csdev,
enum cs_mode mode,
struct coresight_path *path)
{
- struct perf_output_handle *handle = path->handle;
struct etr_perf_buffer *etr_perf;
+ struct etm_ctxt *ctxt = this_cpu_ptr(&etm_ctxt);
+ struct perf_output_handle *handle = &ctxt->handle;
switch (mode) {
case CS_MODE_SYSFS:
>>
>> Regards
>>
>> Mike.
>>
>>
>>
>>
>>> 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:
>>>
>>> All the mentioned devices operate by forming a path, for which the
>>> system constructs a coresight_path. This 'path' is then passed to each
>>> device along the route, allowing any device to directly access the
>>> required data from coresight_path instead of receiving it as a separate
>>> argument.
>>>
>>> Imagine a device that requires more than two or three arguments, and you
>>> want to pass them through coresight_enable_path or similar functions...
>>>
>>> For certain coresight_path instances, we may not need the handle or
>>> other parameters. Since these values are initialized, it's acceptable to
>>> leave them as NULL or 0.
>>>
>>>
>>>> Or, maybe it's the right place for it, and the cause of my concern is
>>>> that "path" is an overly-narrow name in struct coresight_path?
>>>>
>>>
>>> It defines the direction of data flow—serving as the path for trace
>>> data.
>>>
>>> Thanks,
>>> Jie
>>>
>>>> But if a renaming of this structure would improve the code, I'd also be
>>>> fine with that happening in a subsequent commit, so I won't try to hold
>>>> up the current series based on that.
>>>>
>>>> -Carl
>>>
>>
>>
>> --
>> Mike Leach
>> Principal Engineer, ARM Ltd.
>> Manchester Design Centre. UK
>
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-25 10:10 ` James Clark
@ 2025-09-25 16:01 ` Leo Yan
2025-09-25 16:04 ` Leo Yan
1 sibling, 0 replies; 20+ messages in thread
From: Leo Yan @ 2025-09-25 16:01 UTC (permalink / raw)
To: James Clark
Cc: Suzuki K Poulose, Mike Leach, Jie Gan, Carl Worth,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
On Thu, Sep 25, 2025 at 11:10:51AM +0100, James Clark wrote:
[...]
In short, I prefer to store perf handle in coresight path, as Jie has
done in this series.
I will give details below, sorry for a long replying.
[...]
> This one is just a pointer to the perf handle which really does belong to
> the session rather than the device. This makes it more of a path thing than
> a csdev thing. Maybe we can rename path to be more like "session", which
> also happens to contain a path. But I think path is fine for now.
Yes, renaming 'coresight_path' (to like 'coresight_runtime_ctx') better
reflects the structure’s purpose.
The point is we can take chance to separate runtime parameters from
device and driver instances.
- 'coresight_path': runtime parameters for an active session
- 'coresight_device': a device instance registered on the bus
- driver data: after probe, the driver maintains driver-specific
attributes (e.g., the ETMv4 driver keeps mode and filters in struct
etmv4_drvdata)
These structures have different lifetimes. For example, coresight_path
is valid only during a session; otherwise, it should be cleared.
From a lifecycle perspective, storing the perf handle in coresight_path
makes sense, since both are valid only for the duration of a session
(the perf handle isn't used in sysfs mode, in which case we can simply
leave it unset).
Furthermore, the perf handle is not just a handle; it lets us easily
retrieve private event data (see perf_get_aux()).
> However in this case handle is per-cpu data that is only accessed on the
> same cpu in tmc_etr_get_buffer(). Assigning it in etm_event_start() just
> copies the same per-cpu variable into a non per-cpu place that eventually
> gets accessed on the same cpu anyway.
>
> If we exported it then it can be used directly without worrying where to
> store it:
We need to be careful for exporting data structures across modules, as
it makes them harder to manage.
In fact, we already share 'etm_event_data' for ETR driver for the same
purpose, and seems to me, it is redendant to export another structure
'etm_ctxt' to just make it convenient for obtaining a buffer config
pointer.
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c
> b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 17afa0f4cdee..4c33f442c80b 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -42,12 +42,8 @@ static bool etm_perf_up;
> * the ETM. Thus the event_data for the session must be part of the ETM
> context
> * to make sure we can disable the trace path.
> */
> -struct etm_ctxt {
> - struct perf_output_handle handle;
> - struct etm_event_data *event_data;
> -};
> -
> -static DEFINE_PER_CPU(struct etm_ctxt, etm_ctxt);
> +DEFINE_PER_CPU(struct etm_ctxt, etm_ctxt);
> +EXPORT_SYMBOL_GPL(etm_ctxt);
I'd suggest a different approach: drop the etm_ctxt structure and
instead define a per-CPU pointer to etm_event_data:
static DEFINE_PER_CPU(struct etm_event_data *, etm_ev_ctx);
As mentioned above, if perf handle is maintained in coresight_path, we
can easily retrieve the etm_event_data via the perf handle.
A more aggressive refactoring would remove etm_ctxt from
coresight-etm-perf.c entirely, relying on the perf event to manage
private context data. For now, we keep it only to validate whether
ETM is enabled (see multiple place to validate ctxt->event_data).
Thanks,
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-25 10:10 ` James Clark
2025-09-25 16:01 ` Leo Yan
@ 2025-09-25 16:04 ` Leo Yan
2025-09-26 10:05 ` Mike Leach
1 sibling, 1 reply; 20+ messages in thread
From: Leo Yan @ 2025-09-25 16:04 UTC (permalink / raw)
To: James Clark
Cc: Suzuki K Poulose, Mike Leach, Jie Gan, Carl Worth,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
On Thu, Sep 25, 2025 at 11:10:51AM +0100, James Clark wrote:
> > > I would suggest in the csdev (coresight_device) structure itself. We
> > > already have some sink specific data in here e.g. perf_sink_id_map.
[...]
> > I think this data is specific to the session we are enabling the
> > device(s) in. e.g., we keep the trace-id in the path.
> > So, I don't mind having this in the path structure.
> > Instead of modifying csdev with additional locking from "etm-perf"
> > it is always cleaner to handle this in the path.
>
> Yeah, and perf_sink_id_map only "needs" to be in the csdev because it
> controls sharing IDs between multiple paths which can't be accomplished by
> storing it in the path.
This is a bit off-topic: do we really need to maintain an id_map in
every sink device, or could we simply use a global id_map?
I might miss some info; anyway, consolidating trace IDs is a low
priority for me and not critical to this thread. But this might be
benefit for later refactoring.
Thanks,
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-25 16:04 ` Leo Yan
@ 2025-09-26 10:05 ` Mike Leach
0 siblings, 0 replies; 20+ messages in thread
From: Mike Leach @ 2025-09-26 10:05 UTC (permalink / raw)
To: Leo Yan
Cc: James Clark, Suzuki K Poulose, Jie Gan, Carl Worth,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
On Thu, 25 Sept 2025 at 17:04, Leo Yan <leo.yan@arm.com> wrote:
>
> On Thu, Sep 25, 2025 at 11:10:51AM +0100, James Clark wrote:
>
> > > > I would suggest in the csdev (coresight_device) structure itself. We
> > > > already have some sink specific data in here e.g. perf_sink_id_map.
>
> [...]
>
> > > I think this data is specific to the session we are enabling the
> > > device(s) in. e.g., we keep the trace-id in the path.
> > > So, I don't mind having this in the path structure.
> > > Instead of modifying csdev with additional locking from "etm-perf"
> > > it is always cleaner to handle this in the path.
> >
> > Yeah, and perf_sink_id_map only "needs" to be in the csdev because it
> > controls sharing IDs between multiple paths which can't be accomplished by
> > storing it in the path.
>
> This is a bit off-topic: do we really need to maintain an id_map in
> every sink device, or could we simply use a global id_map?
>
> I might miss some info; anyway, consolidating trace IDs is a low
> priority for me and not critical to this thread. But this might be
> benefit for later refactoring.
>
> Thanks,
> Leo
There is a limit to the number of IDs that can be used - using ID map
per sink means that IDs can be re-used in different sinks.
This was added to overcome this problem in large multi-core systems
where there are more PEs than Available IDs.
Mike
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path
2025-09-23 1:49 ` Jie Gan
2025-09-24 10:21 ` Mike Leach
@ 2025-09-24 16:28 ` Carl Worth
1 sibling, 0 replies; 20+ messages in thread
From: Carl Worth @ 2025-09-24 16:28 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
Jie Gan <jie.gan@oss.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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH RFC 2/3] coresight: change helper_ops to accept coresight_path
2025-09-22 7:31 [PATCH RFC 0/3] coresight: replace the void pointer with coresight_path pointer Jie Gan
2025-09-22 7:31 ` [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path Jie Gan
@ 2025-09-22 7:31 ` Jie Gan
2025-09-22 8:34 ` Leo Yan
2025-09-22 17:33 ` Carl Worth
2025-09-22 7:31 ` [PATCH RFC 3/3] coresight: change the sink_ops " Jie Gan
2025-09-22 17:26 ` [PATCH RFC 0/3] coresight: replace the void pointer with coresight_path pointer Carl Worth
3 siblings, 2 replies; 20+ messages in thread
From: Jie Gan @ 2025-09-22 7:31 UTC (permalink / raw)
To: Carl Worth, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Jie Gan, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
Update the helper_enable and helper_disable functions to accept
coresight_path instead of a generic void *data, as coresight_path
encapsulates all the necessary data required by devices along the path.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-catu.c | 10 +++++-----
drivers/hwtracing/coresight/coresight-core.c | 20 ++++++++++++--------
drivers/hwtracing/coresight/coresight-ctcu-core.c | 9 +++------
drivers/hwtracing/coresight/coresight-cti-core.c | 5 +++--
drivers/hwtracing/coresight/coresight-cti.h | 5 +++--
drivers/hwtracing/coresight/coresight-tmc-etr.c | 4 ++--
drivers/hwtracing/coresight/coresight-tmc.h | 3 ++-
include/linux/coresight.h | 5 +++--
8 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
index a3ccb7034ae1..69b36bae97ab 100644
--- a/drivers/hwtracing/coresight/coresight-catu.c
+++ b/drivers/hwtracing/coresight/coresight-catu.c
@@ -397,7 +397,7 @@ static int catu_wait_for_ready(struct catu_drvdata *drvdata)
}
static int catu_enable_hw(struct catu_drvdata *drvdata, enum cs_mode cs_mode,
- void *data)
+ struct coresight_path *path)
{
int rc;
u32 control, mode;
@@ -425,7 +425,7 @@ static int catu_enable_hw(struct catu_drvdata *drvdata, enum cs_mode cs_mode,
etrdev = coresight_find_input_type(
csdev->pdata, CORESIGHT_DEV_TYPE_SINK, etr_subtype);
if (etrdev) {
- etr_buf = tmc_etr_get_buffer(etrdev, cs_mode, data);
+ etr_buf = tmc_etr_get_buffer(etrdev, cs_mode, path);
if (IS_ERR(etr_buf))
return PTR_ERR(etr_buf);
}
@@ -455,7 +455,7 @@ static int catu_enable_hw(struct catu_drvdata *drvdata, enum cs_mode cs_mode,
}
static int catu_enable(struct coresight_device *csdev, enum cs_mode mode,
- void *data)
+ struct coresight_path *path)
{
int rc = 0;
struct catu_drvdata *catu_drvdata = csdev_to_catu_drvdata(csdev);
@@ -463,7 +463,7 @@ static int catu_enable(struct coresight_device *csdev, enum cs_mode mode,
guard(raw_spinlock_irqsave)(&catu_drvdata->spinlock);
if (csdev->refcnt == 0) {
CS_UNLOCK(catu_drvdata->base);
- rc = catu_enable_hw(catu_drvdata, mode, data);
+ rc = catu_enable_hw(catu_drvdata, mode, path);
CS_LOCK(catu_drvdata->base);
}
if (!rc)
@@ -488,7 +488,7 @@ static int catu_disable_hw(struct catu_drvdata *drvdata)
return rc;
}
-static int catu_disable(struct coresight_device *csdev, void *__unused)
+static int catu_disable(struct coresight_device *csdev, struct coresight_path *path)
{
int rc = 0;
struct catu_drvdata *catu_drvdata = csdev_to_catu_drvdata(csdev);
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 3267192f0c1c..f44ec9e5b692 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -355,17 +355,20 @@ static bool coresight_is_helper(struct coresight_device *csdev)
}
static int coresight_enable_helper(struct coresight_device *csdev,
- enum cs_mode mode, void *data)
+ enum cs_mode mode,
+ struct coresight_path *path)
{
- return helper_ops(csdev)->enable(csdev, mode, data);
+ return helper_ops(csdev)->enable(csdev, mode, path);
}
-static void coresight_disable_helper(struct coresight_device *csdev, void *data)
+static void coresight_disable_helper(struct coresight_device *csdev,
+ struct coresight_path *path)
{
- helper_ops(csdev)->disable(csdev, data);
+ helper_ops(csdev)->disable(csdev, path);
}
-static void coresight_disable_helpers(struct coresight_device *csdev, void *data)
+static void coresight_disable_helpers(struct coresight_device *csdev,
+ struct coresight_path *path)
{
int i;
struct coresight_device *helper;
@@ -373,7 +376,7 @@ static void coresight_disable_helpers(struct coresight_device *csdev, void *data
for (i = 0; i < csdev->pdata->nr_outconns; ++i) {
helper = csdev->pdata->out_conns[i]->dest_dev;
if (helper && coresight_is_helper(helper))
- coresight_disable_helper(helper, data);
+ coresight_disable_helper(helper, path);
}
}
@@ -479,7 +482,8 @@ void coresight_disable_path(struct coresight_path *path)
EXPORT_SYMBOL_GPL(coresight_disable_path);
static int coresight_enable_helpers(struct coresight_device *csdev,
- enum cs_mode mode, void *data)
+ enum cs_mode mode,
+ struct coresight_path *path)
{
int i, ret = 0;
struct coresight_device *helper;
@@ -489,7 +493,7 @@ static int coresight_enable_helpers(struct coresight_device *csdev,
if (!helper || !coresight_is_helper(helper))
continue;
- ret = coresight_enable_helper(helper, mode, data);
+ ret = coresight_enable_helper(helper, mode, path);
if (ret)
return ret;
}
diff --git a/drivers/hwtracing/coresight/coresight-ctcu-core.c b/drivers/hwtracing/coresight/coresight-ctcu-core.c
index c586495e9a08..abed15eb72b4 100644
--- a/drivers/hwtracing/coresight/coresight-ctcu-core.c
+++ b/drivers/hwtracing/coresight/coresight-ctcu-core.c
@@ -156,17 +156,14 @@ static int ctcu_set_etr_traceid(struct coresight_device *csdev, struct coresight
return __ctcu_set_etr_traceid(csdev, traceid, port_num, enable);
}
-static int ctcu_enable(struct coresight_device *csdev, enum cs_mode mode, void *data)
+static int ctcu_enable(struct coresight_device *csdev, enum cs_mode mode,
+ struct coresight_path *path)
{
- struct coresight_path *path = (struct coresight_path *)data;
-
return ctcu_set_etr_traceid(csdev, path, true);
}
-static int ctcu_disable(struct coresight_device *csdev, void *data)
+static int ctcu_disable(struct coresight_device *csdev, struct coresight_path *path)
{
- struct coresight_path *path = (struct coresight_path *)data;
-
return ctcu_set_etr_traceid(csdev, path, false);
}
diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
index 8fb30dd73fd2..bfbc365bb2ef 100644
--- a/drivers/hwtracing/coresight/coresight-cti-core.c
+++ b/drivers/hwtracing/coresight/coresight-cti-core.c
@@ -799,14 +799,15 @@ static void cti_pm_release(struct cti_drvdata *drvdata)
}
/** cti ect operations **/
-int cti_enable(struct coresight_device *csdev, enum cs_mode mode, void *data)
+int cti_enable(struct coresight_device *csdev, enum cs_mode mode,
+ struct coresight_path *path)
{
struct cti_drvdata *drvdata = csdev_to_cti_drvdata(csdev);
return cti_enable_hw(drvdata);
}
-int cti_disable(struct coresight_device *csdev, void *data)
+int cti_disable(struct coresight_device *csdev, struct coresight_path *path)
{
struct cti_drvdata *drvdata = csdev_to_cti_drvdata(csdev);
diff --git a/drivers/hwtracing/coresight/coresight-cti.h b/drivers/hwtracing/coresight/coresight-cti.h
index 8362a47c939c..4f89091ee93f 100644
--- a/drivers/hwtracing/coresight/coresight-cti.h
+++ b/drivers/hwtracing/coresight/coresight-cti.h
@@ -216,8 +216,9 @@ int cti_add_connection_entry(struct device *dev, struct cti_drvdata *drvdata,
const char *assoc_dev_name);
struct cti_trig_con *cti_allocate_trig_con(struct device *dev, int in_sigs,
int out_sigs);
-int cti_enable(struct coresight_device *csdev, enum cs_mode mode, void *data);
-int cti_disable(struct coresight_device *csdev, void *data);
+int cti_enable(struct coresight_device *csdev, enum cs_mode mode,
+ struct coresight_path *path);
+int cti_disable(struct coresight_device *csdev, struct coresight_path *path);
void cti_write_all_hw_regs(struct cti_drvdata *drvdata);
void cti_write_intack(struct device *dev, u32 ackval);
void cti_write_single_reg(struct cti_drvdata *drvdata, int offset, u32 value);
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 1040f73f0537..b9bdbc745433 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1325,9 +1325,9 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
}
struct etr_buf *tmc_etr_get_buffer(struct coresight_device *csdev,
- enum cs_mode mode, void *data)
+ enum cs_mode mode,
+ struct coresight_path *path)
{
- struct coresight_path *path = data;
struct perf_output_handle *handle = path->handle;
struct etr_perf_buffer *etr_perf;
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index cbb4ba439158..95473d131032 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -442,7 +442,8 @@ struct coresight_device *tmc_etr_get_catu_device(struct tmc_drvdata *drvdata);
void tmc_etr_set_catu_ops(const struct etr_buf_operations *catu);
void tmc_etr_remove_catu_ops(void);
struct etr_buf *tmc_etr_get_buffer(struct coresight_device *csdev,
- enum cs_mode mode, void *data);
+ enum cs_mode mode,
+ struct coresight_path *path);
extern const struct attribute_group coresight_etr_group;
#endif
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 4591121ae1d4..a54241ae9aa1 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -424,8 +424,9 @@ struct coresight_ops_source {
*/
struct coresight_ops_helper {
int (*enable)(struct coresight_device *csdev, enum cs_mode mode,
- void *data);
- int (*disable)(struct coresight_device *csdev, void *data);
+ struct coresight_path *path);
+ int (*disable)(struct coresight_device *csdev,
+ struct coresight_path *path);
};
--
2.34.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH RFC 2/3] coresight: change helper_ops to accept coresight_path
2025-09-22 7:31 ` [PATCH RFC 2/3] coresight: change helper_ops to accept coresight_path Jie Gan
@ 2025-09-22 8:34 ` Leo Yan
2025-09-22 17:33 ` Carl Worth
1 sibling, 0 replies; 20+ messages in thread
From: Leo Yan @ 2025-09-22 8:34 UTC (permalink / raw)
To: Jie Gan
Cc: Carl Worth, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
On Mon, Sep 22, 2025 at 03:31:40PM +0800, Jie Gan wrote:
> Update the helper_enable and helper_disable functions to accept
> coresight_path instead of a generic void *data, as coresight_path
> encapsulates all the necessary data required by devices along the path.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 2/3] coresight: change helper_ops to accept coresight_path
2025-09-22 7:31 ` [PATCH RFC 2/3] coresight: change helper_ops to accept coresight_path Jie Gan
2025-09-22 8:34 ` Leo Yan
@ 2025-09-22 17:33 ` Carl Worth
1 sibling, 0 replies; 20+ messages in thread
From: Carl Worth @ 2025-09-22 17:33 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Jie Gan, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
Jie Gan <jie.gan@oss.qualcomm.com> writes:
> Update the helper_enable and helper_disable functions to accept
> coresight_path instead of a generic void *data, as coresight_path
> encapsulates all the necessary data required by devices along the path.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Tested-by: Carl Worth <carl@os.amperecomputing.com>
Reviewed-by: Carl Worth <carl@os.amperecomputing.com>
-Carl
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH RFC 3/3] coresight: change the sink_ops to accept coresight_path
2025-09-22 7:31 [PATCH RFC 0/3] coresight: replace the void pointer with coresight_path pointer Jie Gan
2025-09-22 7:31 ` [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path Jie Gan
2025-09-22 7:31 ` [PATCH RFC 2/3] coresight: change helper_ops to accept coresight_path Jie Gan
@ 2025-09-22 7:31 ` Jie Gan
2025-09-22 8:46 ` Leo Yan
2025-09-22 17:34 ` Carl Worth
2025-09-22 17:26 ` [PATCH RFC 0/3] coresight: replace the void pointer with coresight_path pointer Carl Worth
3 siblings, 2 replies; 20+ messages in thread
From: Jie Gan @ 2025-09-22 7:31 UTC (permalink / raw)
To: Carl Worth, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Jie Gan, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
Update the sink_enable functions to accept coresight_path instead of
a generic void *data, as coresight_path encapsulates all the necessary
data required by devices along the path.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 10 +++++-----
drivers/hwtracing/coresight/coresight-dummy.c | 2 +-
drivers/hwtracing/coresight/coresight-etb10.c | 8 ++++----
drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
drivers/hwtracing/coresight/coresight-priv.h | 3 +--
drivers/hwtracing/coresight/coresight-sysfs.c | 2 +-
drivers/hwtracing/coresight/coresight-tmc-etf.c | 10 ++++++----
drivers/hwtracing/coresight/coresight-tmc-etr.c | 10 ++++++----
drivers/hwtracing/coresight/coresight-tpiu.c | 2 +-
drivers/hwtracing/coresight/coresight-trbe.c | 4 ++--
drivers/hwtracing/coresight/ultrasoc-smb.c | 9 +++++----
include/linux/coresight.h | 2 +-
12 files changed, 34 insertions(+), 30 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index f44ec9e5b692..c660cf8adb1c 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -300,9 +300,10 @@ void coresight_add_helper(struct coresight_device *csdev,
EXPORT_SYMBOL_GPL(coresight_add_helper);
static int coresight_enable_sink(struct coresight_device *csdev,
- enum cs_mode mode, void *data)
+ enum cs_mode mode,
+ struct coresight_path *path)
{
- return sink_ops(csdev)->enable(csdev, mode, data);
+ return sink_ops(csdev)->enable(csdev, mode, path);
}
static void coresight_disable_sink(struct coresight_device *csdev)
@@ -501,8 +502,7 @@ static int coresight_enable_helpers(struct coresight_device *csdev,
return 0;
}
-int coresight_enable_path(struct coresight_path *path, enum cs_mode mode,
- void *sink_data)
+int coresight_enable_path(struct coresight_path *path, enum cs_mode mode)
{
int ret = 0;
u32 type;
@@ -532,7 +532,7 @@ int coresight_enable_path(struct coresight_path *path, enum cs_mode mode,
switch (type) {
case CORESIGHT_DEV_TYPE_SINK:
- ret = coresight_enable_sink(csdev, mode, sink_data);
+ ret = coresight_enable_sink(csdev, mode, path);
/*
* Sink is the first component turned on. If we
* failed to enable the sink, there are no components
diff --git a/drivers/hwtracing/coresight/coresight-dummy.c b/drivers/hwtracing/coresight/coresight-dummy.c
index aaa92b5081e3..14322c99e29d 100644
--- a/drivers/hwtracing/coresight/coresight-dummy.c
+++ b/drivers/hwtracing/coresight/coresight-dummy.c
@@ -52,7 +52,7 @@ static int dummy_source_trace_id(struct coresight_device *csdev, __maybe_unused
}
static int dummy_sink_enable(struct coresight_device *csdev, enum cs_mode mode,
- void *data)
+ struct coresight_path *path)
{
dev_dbg(csdev->dev.parent, "Dummy sink enabled\n");
diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 35db1b6093d1..6657602d8f2e 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -167,13 +167,13 @@ static int etb_enable_sysfs(struct coresight_device *csdev)
return ret;
}
-static int etb_enable_perf(struct coresight_device *csdev, void *data)
+static int etb_enable_perf(struct coresight_device *csdev, struct coresight_path *path)
{
int ret = 0;
pid_t pid;
unsigned long flags;
struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
- struct perf_output_handle *handle = data;
+ struct perf_output_handle *handle = path->handle;
struct cs_buffers *buf = etm_perf_sink_config(handle);
raw_spin_lock_irqsave(&drvdata->spinlock, flags);
@@ -224,7 +224,7 @@ static int etb_enable_perf(struct coresight_device *csdev, void *data)
}
static int etb_enable(struct coresight_device *csdev, enum cs_mode mode,
- void *data)
+ struct coresight_path *path)
{
int ret;
@@ -233,7 +233,7 @@ static int etb_enable(struct coresight_device *csdev, enum cs_mode mode,
ret = etb_enable_sysfs(csdev);
break;
case CS_MODE_PERF:
- ret = etb_enable_perf(csdev, data);
+ ret = etb_enable_perf(csdev, path);
break;
default:
ret = -EINVAL;
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 5c256af6e54a..17afa0f4cdee 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -527,7 +527,7 @@ static void etm_event_start(struct perf_event *event, int flags)
goto fail_end_stop;
/* Nothing will happen without a path */
- if (coresight_enable_path(path, CS_MODE_PERF, handle))
+ if (coresight_enable_path(path, CS_MODE_PERF))
goto fail_end_stop;
/* Finally enable the tracer */
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 33e22b1ba043..fd896ac07942 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -135,8 +135,7 @@ static inline void CS_UNLOCK(void __iomem *addr)
}
void coresight_disable_path(struct coresight_path *path);
-int coresight_enable_path(struct coresight_path *path, enum cs_mode mode,
- void *sink_data);
+int coresight_enable_path(struct coresight_path *path, enum cs_mode mode);
struct coresight_device *coresight_get_sink(struct coresight_path *path);
struct coresight_device *coresight_get_sink_by_id(u32 id);
struct coresight_device *
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index 5e52324aa9ac..d2a6ed8bcc74 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -215,7 +215,7 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
if (!IS_VALID_CS_TRACE_ID(path->trace_id))
goto err_path;
- ret = coresight_enable_path(path, CS_MODE_SYSFS, NULL);
+ ret = coresight_enable_path(path, CS_MODE_SYSFS);
if (ret)
goto err_path;
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 0f45ab5e5249..8882b1c4cdc0 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -246,13 +246,14 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev)
return ret;
}
-static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, void *data)
+static int tmc_enable_etf_sink_perf(struct coresight_device *csdev,
+ struct coresight_path *path)
{
int ret = 0;
pid_t pid;
unsigned long flags;
struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
- struct perf_output_handle *handle = data;
+ struct perf_output_handle *handle = path->handle;
struct cs_buffers *buf = etm_perf_sink_config(handle);
raw_spin_lock_irqsave(&drvdata->spinlock, flags);
@@ -304,7 +305,8 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, void *data)
}
static int tmc_enable_etf_sink(struct coresight_device *csdev,
- enum cs_mode mode, void *data)
+ enum cs_mode mode,
+ struct coresight_path *path)
{
int ret;
@@ -313,7 +315,7 @@ static int tmc_enable_etf_sink(struct coresight_device *csdev,
ret = tmc_enable_etf_sink_sysfs(csdev);
break;
case CS_MODE_PERF:
- ret = tmc_enable_etf_sink_perf(csdev, data);
+ ret = tmc_enable_etf_sink_perf(csdev, path);
break;
/* We shouldn't be here */
default:
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index b9bdbc745433..bf08f6117a7f 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1726,13 +1726,14 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
return size;
}
-static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
+static int tmc_enable_etr_sink_perf(struct coresight_device *csdev,
+ struct coresight_path *path)
{
int rc = 0;
pid_t pid;
unsigned long flags;
struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
- struct perf_output_handle *handle = data;
+ struct perf_output_handle *handle = path->handle;
struct etr_perf_buffer *etr_perf = etm_perf_sink_config(handle);
raw_spin_lock_irqsave(&drvdata->spinlock, flags);
@@ -1780,13 +1781,14 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
}
static int tmc_enable_etr_sink(struct coresight_device *csdev,
- enum cs_mode mode, void *data)
+ enum cs_mode mode,
+ struct coresight_path *path)
{
switch (mode) {
case CS_MODE_SYSFS:
return tmc_enable_etr_sink_sysfs(csdev);
case CS_MODE_PERF:
- return tmc_enable_etr_sink_perf(csdev, data);
+ return tmc_enable_etr_sink_perf(csdev, path);
default:
return -EINVAL;
}
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 9463afdbda8a..aaa44bc521c3 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -75,7 +75,7 @@ static void tpiu_enable_hw(struct csdev_access *csa)
}
static int tpiu_enable(struct coresight_device *csdev, enum cs_mode mode,
- void *__unused)
+ struct coresight_path *path)
{
struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
index 43643d2c5bdd..293715b4ff0e 100644
--- a/drivers/hwtracing/coresight/coresight-trbe.c
+++ b/drivers/hwtracing/coresight/coresight-trbe.c
@@ -1013,11 +1013,11 @@ static int __arm_trbe_enable(struct trbe_buf *buf,
}
static int arm_trbe_enable(struct coresight_device *csdev, enum cs_mode mode,
- void *data)
+ struct coresight_path *path)
{
struct trbe_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
struct trbe_cpudata *cpudata = dev_get_drvdata(&csdev->dev);
- struct perf_output_handle *handle = data;
+ struct perf_output_handle *handle = path->handle;
struct trbe_buf *buf = etm_perf_sink_config(handle);
WARN_ON(cpudata->cpu != smp_processor_id());
diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.c b/drivers/hwtracing/coresight/ultrasoc-smb.c
index 26cfc939e5bd..8f7922a5e534 100644
--- a/drivers/hwtracing/coresight/ultrasoc-smb.c
+++ b/drivers/hwtracing/coresight/ultrasoc-smb.c
@@ -213,10 +213,11 @@ static void smb_enable_sysfs(struct coresight_device *csdev)
coresight_set_mode(csdev, CS_MODE_SYSFS);
}
-static int smb_enable_perf(struct coresight_device *csdev, void *data)
+static int smb_enable_perf(struct coresight_device *csdev,
+ struct coresight_path *path)
{
struct smb_drv_data *drvdata = dev_get_drvdata(csdev->dev.parent);
- struct perf_output_handle *handle = data;
+ struct perf_output_handle *handle = path->handle;
struct cs_buffers *buf = etm_perf_sink_config(handle);
pid_t pid;
@@ -240,7 +241,7 @@ static int smb_enable_perf(struct coresight_device *csdev, void *data)
}
static int smb_enable(struct coresight_device *csdev, enum cs_mode mode,
- void *data)
+ struct coresight_path *path)
{
struct smb_drv_data *drvdata = dev_get_drvdata(csdev->dev.parent);
int ret = 0;
@@ -261,7 +262,7 @@ static int smb_enable(struct coresight_device *csdev, enum cs_mode mode,
smb_enable_sysfs(csdev);
break;
case CS_MODE_PERF:
- ret = smb_enable_perf(csdev, data);
+ ret = smb_enable_perf(csdev, path);
break;
default:
ret = -EINVAL;
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index a54241ae9aa1..fc7004081caa 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -367,7 +367,7 @@ enum cs_mode {
*/
struct coresight_ops_sink {
int (*enable)(struct coresight_device *csdev, enum cs_mode mode,
- void *data);
+ struct coresight_path *path);
int (*disable)(struct coresight_device *csdev);
void *(*alloc_buffer)(struct coresight_device *csdev,
struct perf_event *event, void **pages,
--
2.34.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH RFC 3/3] coresight: change the sink_ops to accept coresight_path
2025-09-22 7:31 ` [PATCH RFC 3/3] coresight: change the sink_ops " Jie Gan
@ 2025-09-22 8:46 ` Leo Yan
2025-09-22 17:34 ` Carl Worth
1 sibling, 0 replies; 20+ messages in thread
From: Leo Yan @ 2025-09-22 8:46 UTC (permalink / raw)
To: Jie Gan
Cc: Carl Worth, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
On Mon, Sep 22, 2025 at 03:31:41PM +0800, Jie Gan wrote:
> Update the sink_enable functions to accept coresight_path instead of
> a generic void *data, as coresight_path encapsulates all the necessary
> data required by devices along the path.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Good refactoring for me, thanks!
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 3/3] coresight: change the sink_ops to accept coresight_path
2025-09-22 7:31 ` [PATCH RFC 3/3] coresight: change the sink_ops " Jie Gan
2025-09-22 8:46 ` Leo Yan
@ 2025-09-22 17:34 ` Carl Worth
1 sibling, 0 replies; 20+ messages in thread
From: Carl Worth @ 2025-09-22 17:34 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Jie Gan, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
Jie Gan <jie.gan@oss.qualcomm.com> writes:
> Update the sink_enable functions to accept coresight_path instead of
> a generic void *data, as coresight_path encapsulates all the necessary
> data required by devices along the path.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Tested-by: Carl Worth <carl@os.amperecomputing.com>
Reviewed-by: Carl Worth <carl@os.amperecomputing.com>
-Carl
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH RFC 0/3] coresight: replace the void pointer with coresight_path pointer
2025-09-22 7:31 [PATCH RFC 0/3] coresight: replace the void pointer with coresight_path pointer Jie Gan
` (2 preceding siblings ...)
2025-09-22 7:31 ` [PATCH RFC 3/3] coresight: change the sink_ops " Jie Gan
@ 2025-09-22 17:26 ` Carl Worth
3 siblings, 0 replies; 20+ messages in thread
From: Carl Worth @ 2025-09-22 17:26 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Jie Gan, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel
Jie Gan <jie.gan@oss.qualcomm.com> writes:
> I think it's better to explain my ideas with codes, so I directly created the
> patch series for sharing my solution. Please let me know if it's
> offend you.
Thanks, Jie! I'm not offended at all. My primary goal is the improvement
of our shared code base, and this is helpful for that. And I agree with
you that code can bring a lot of clarity to the discussion.
I've tested the series and it works and fixes the bug. I'll comment
specifically on each patch separately.
-Carl
^ permalink raw reply [flat|nested] 20+ messages in thread