CoreSight

coresight@lists.linaro.org

7 participants
2678 discussions

Re: [PATCH v5 2/3] coresight: Reorder coresight_device_release to match coresight_register

by Mike Leach

On Thu, 25 Sept 2025 at 16:04, Sean Anderson <sean.anderson(a)linux.dev> wrote: > > To make it easier to determine where to add new release actions, reorder > the actions in coresight_device_release to be the reverse of > coresight_register. > > Signed-off-by: Sean Anderson <sean.anderson(a)linux.dev> > --- > > Changes in v5: > - New > > drivers/hwtracing/coresight/coresight-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index 022c8384b98d..305b1773cfbe 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -1046,8 +1046,8 @@ static void coresight_device_release(struct device *dev) > { > struct coresight_device *csdev = to_coresight_device(dev); > > - fwnode_handle_put(csdev->dev.fwnode); > free_percpu(csdev->perf_sink_id_map.cpu_map); > + fwnode_handle_put(csdev->dev.fwnode); > kfree(csdev); > } > > -- > 2.35.1.1320.gc452695387.dirty > Reviewed-by: Mike Leach <mike.leach(a)linaro.org> -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

1 year

Re: [PATCH v5 1/3] coresight: Fix fwnode leak in coresight_register error path

by Mike Leach

On Thu, 25 Sept 2025 at 16:04, Sean Anderson <sean.anderson(a)linux.dev> wrote: > > If registering the CPU map fails, we need to put the fwnode. free_percpu > works when called with a NULL pointer, so just use > coresight_device_release. > > Fixes: 5ad628a76176 ("coresight: Use per-sink trace ID maps for Perf sessions") > Signed-off-by: Sean Anderson <sean.anderson(a)linux.dev> > --- > > (no changes since v4) > > Changes in v4: > - New > > drivers/hwtracing/coresight/coresight-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index fa758cc21827..022c8384b98d 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -1352,7 +1352,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc) > raw_spin_lock_init(&csdev->perf_sink_id_map.lock); > csdev->perf_sink_id_map.cpu_map = alloc_percpu(atomic_t); > if (!csdev->perf_sink_id_map.cpu_map) { > - kfree(csdev); > + coresight_device_release(&csdev->dev); > ret = -ENOMEM; > goto err_out; > } > -- > 2.35.1.1320.gc452695387.dirty > Reviewed-by: Mike Leach <mike.leach(a)linaro.org> -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

1 year

Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path

by Mike Leach

Hi, On Tue, 23 Sept 2025 at 02:49, Jie Gan <jie.gan(a)oss.qualcomm.com> wrote: > > > > On 9/23/2025 1:31 AM, Carl Worth wrote: > > Jie Gan <jie.gan(a)oss.qualcomm.com> writes: > >> From: Carl Worth <carl(a)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

1 year

Re: [PATCH v5 3/3] coresight: Fix possible deadlock in coresight_panic_cb

by Leo Yan

On Thu, Sep 25, 2025 at 11:03:42AM -0400, Sean Anderson wrote: > Panics can occur at any time, so taking locks may cause a deadlock (such > as if the panicking CPU held the lock). coresight_panic_cb uses > bus_for_each_dev, but that calls bus_to_subsys which takes > bus_kset->list_lock. > > Instead of registering a single panic notifier and iterating over > coresight devices, register a panic notifier for each coresight device > that requires it (letting the atomic notifier list handle iteration). > atomic_notifier_chain_unregister will just return -ENOENT if a notifier > block isn't on the list, so it's safe to call when we haven't registered > a notifier. > > Fixes: 46006ceb5d02 ("coresight: core: Add provision for panic callbacks") > Signed-off-by: Sean Anderson <sean.anderson(a)linux.dev> Reviewed-by: Leo Yan <leo.yan(a)arm.com>

1 year

Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path

by Carl Worth

Jie Gan <jie.gan(a)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

1 year, 1 month

Re: [UPDATED] [GIT PULL] coresight: Updates for Linux v6.18

by Suzuki K Poulose

On 24/09/2025 12:06, Greg KH wrote: > On Wed, Sep 24, 2025 at 09:22:42AM +0100, Suzuki K Poulose wrote: >> Hi Greg >> >> Please find the updated pull request to fix the invalid commit reference in >> the fixes tag, in the original pull request [0] >> >> Apologies for the inconvenience. >> >> [0] https://lkml.kernel.org/r/20250922125907.2268152-1-suzuki.poulose@arm.com >> >> Kindly pull, >> >> Suzuki >> >> --- >> >> The following changes since commit 1b237f190eb3d36f52dffe07a40b5eb210280e00: >> >> Linux 6.17-rc3 (2025-08-24 12:04:12 -0400) >> >> are available in the Git repository at: >> >> git//git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.18-v2 > > That is not a valid "url" to pull from, how did you create this? Dang! I did use the git request-pull, but have to manually replace the "ssh" URL with git:// :-( and I messed up. > > I've added the missing ':', but you might want to check your scripts to > verify you aren't doing something odd. Will take care of it, thanks. Suzuki

1 year, 1 month

[UPDATED] [GIT PULL] coresight: Updates for Linux v6.18

by Suzuki K Poulose

Hi Greg Please find the updated pull request to fix the invalid commit reference in the fixes tag, in the original pull request [0] Apologies for the inconvenience. [0] https://lkml.kernel.org/r/20250922125907.2268152-1-suzuki.poulose@arm.com Kindly pull, Suzuki --- The following changes since commit 1b237f190eb3d36f52dffe07a40b5eb210280e00: Linux 6.17-rc3 (2025-08-24 12:04:12 -0400) are available in the Git repository at: git//git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.18-v2 for you to fetch changes up to 01f96b812526a2c8dcd5c0e510dda37e09ec8bcd: coresight: Add label sysfs node support (2025-09-23 14:14:13 +0100) ---------------------------------------------------------------- coresight: Updates for Linux v6.18, take 2 This is an updated drop for v6.18, fixing the invalid commit reference in the original tag. CoreSight selfhosted tracing subsystem updates targeting Linux v6.18, includes: - Clean up and consolidate clocks handling - Support for exposing labels via sysfs for better device identification - Add Qualcomm Trace Network On Chip driver support - Miscellaneous fixes Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> ---------------------------------------------------------------- Dan Carpenter (1): coresight: tnoc: Fix a NULL vs IS_ERR() bug in probe James Clark (2): coresight: trbe: Add ISB after TRBLIMITR write coresight: Fix missing include for FIELD_GET Jie Gan (1): coresight: tpda: fix the logic to setup the element size Leo Yan (13): coresight: stm: Remove redundant NULL checks coresight: perf: Use %px for printing pointers coresight: tmc: Support atclk coresight: catu: Support atclk coresight: etm4x: Support atclk coresight: Appropriately disable programming clocks coresight: Appropriately disable trace bus clocks coresight: Avoid enable programming clock duplicately coresight: Consolidate clock enabling coresight: Refactor driver data allocation coresight: Make clock sequence consistent coresight: Refactor runtime PM coresight: trbe: Return NULL pointer for allocation failures Lin Yujun (1): coresight: Fix incorrect handling for return value of devm_kzalloc Mao Jinlong (2): dt-bindings: arm: Add label in the coresight components coresight: Add label sysfs node support Rob Herring (Arm) (1): hwtracing: coresight: Use of_reserved_mem_region_to_resource() for "memory-region" Yeoreum Yun (1): coresight: fix indentation error in cscfg_remove_owned_csdev_configs() Yuanfang Zhang (5): coresight: Only register perf symlink for sinks with alloc_buffer dt-bindings: arm: Add device Trace Network On Chip definition coresight: add coresight Trace Network On Chip driver coresight-etm4x: Conditionally access register TRCEXTINSELR coresight: tnoc: add new AMBA ID to support Trace Noc V2 .../ABI/testing/sysfs-bus-coresight-devices-cti | 6 + .../sysfs-bus-coresight-devices-dummy-source | 6 + .../ABI/testing/sysfs-bus-coresight-devices-etb10 | 6 + .../ABI/testing/sysfs-bus-coresight-devices-etm3x | 6 + .../ABI/testing/sysfs-bus-coresight-devices-etm4x | 6 + .../ABI/testing/sysfs-bus-coresight-devices-funnel | 6 + .../ABI/testing/sysfs-bus-coresight-devices-stm | 6 + .../ABI/testing/sysfs-bus-coresight-devices-tmc | 6 + .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 6 + .../ABI/testing/sysfs-bus-coresight-devices-trbe | 6 + .../devicetree/bindings/arm/arm,coresight-cti.yaml | 4 + .../bindings/arm/arm,coresight-dummy-sink.yaml | 4 + .../bindings/arm/arm,coresight-dummy-source.yaml | 4 + .../bindings/arm/arm,coresight-dynamic-funnel.yaml | 4 + .../arm/arm,coresight-dynamic-replicator.yaml | 4 + .../bindings/arm/arm,coresight-etb10.yaml | 4 + .../devicetree/bindings/arm/arm,coresight-etm.yaml | 4 + .../bindings/arm/arm,coresight-static-funnel.yaml | 4 + .../arm/arm,coresight-static-replicator.yaml | 4 + .../devicetree/bindings/arm/arm,coresight-tmc.yaml | 4 + .../bindings/arm/arm,coresight-tpiu.yaml | 4 + .../bindings/arm/qcom,coresight-ctcu.yaml | 4 + .../bindings/arm/qcom,coresight-remote-etm.yaml | 4 + .../bindings/arm/qcom,coresight-tnoc.yaml | 113 ++++++++++ .../bindings/arm/qcom,coresight-tpda.yaml | 4 + .../bindings/arm/qcom,coresight-tpdm.yaml | 4 + drivers/hwtracing/coresight/Kconfig | 12 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-catu.c | 53 +++-- drivers/hwtracing/coresight/coresight-catu.h | 1 + drivers/hwtracing/coresight/coresight-core.c | 54 ++++- drivers/hwtracing/coresight/coresight-cpu-debug.c | 41 ++-- drivers/hwtracing/coresight/coresight-ctcu-core.c | 24 +- drivers/hwtracing/coresight/coresight-etb10.c | 18 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 4 +- drivers/hwtracing/coresight/coresight-etm3x-core.c | 17 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 44 ++-- .../hwtracing/coresight/coresight-etm4x-sysfs.c | 1 + drivers/hwtracing/coresight/coresight-etm4x.h | 6 +- drivers/hwtracing/coresight/coresight-funnel.c | 66 ++---- drivers/hwtracing/coresight/coresight-replicator.c | 63 ++---- drivers/hwtracing/coresight/coresight-stm.c | 42 ++-- drivers/hwtracing/coresight/coresight-syscfg.c | 2 +- drivers/hwtracing/coresight/coresight-sysfs.c | 71 +++++- drivers/hwtracing/coresight/coresight-tmc-core.c | 70 +++--- drivers/hwtracing/coresight/coresight-tmc.h | 2 + drivers/hwtracing/coresight/coresight-tnoc.c | 246 +++++++++++++++++++++ drivers/hwtracing/coresight/coresight-tpda.c | 3 + drivers/hwtracing/coresight/coresight-tpiu.c | 36 ++- drivers/hwtracing/coresight/coresight-trbe.c | 9 +- drivers/hwtracing/coresight/ultrasoc-smb.h | 1 + include/linux/coresight.h | 31 +-- 52 files changed, 827 insertions(+), 324 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml create mode 100644 drivers/hwtracing/coresight/coresight-tnoc.c

1 year, 1 month

Re: [PATCH RFC 3/3] coresight: change the sink_ops to accept coresight_path

by Carl Worth

Jie Gan <jie.gan(a)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(a)oss.qualcomm.com> Tested-by: Carl Worth <carl(a)os.amperecomputing.com> Reviewed-by: Carl Worth <carl(a)os.amperecomputing.com> -Carl

1 year, 1 month

Re: [PATCH RFC 2/3] coresight: change helper_ops to accept coresight_path

by Carl Worth

Jie Gan <jie.gan(a)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(a)oss.qualcomm.com> Tested-by: Carl Worth <carl(a)os.amperecomputing.com> Reviewed-by: Carl Worth <carl(a)os.amperecomputing.com> -Carl

1 year, 1 month

Re: [PATCH RFC 1/3] coresight: tmc: add the handle of the event to the path

by Carl Worth

Jie Gan <jie.gan(a)oss.qualcomm.com> writes: > From: Carl Worth <carl(a)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

1 year, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight