CoreSight

coresight@lists.linaro.org

5 participants
2730 discussions

Re: [PATCH] coresight/etm4: fix missing disable active config

by Leo Yan

On Thu, Nov 12, 2026 at 09:54:06PM +0800, Shuai Xue wrote: > From: Yeoreum Yun <yeoreum.yun(a)arm.com> > > commit 895b12b7d7b8c651f73f57a1ea040d35aa7048cb upstream. > > When etm4 device is disabled via sysfs, it should disable its active > count. > > Fixes: 7ebd0ec6cf94 ("coresight: configfs: Allow configfs to activate configuration") > Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> > Reviewed-by: Leo Yan <leo.yan(a)arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> > [ shuai: kept spin_lock()/spin_unlock() in etm4_disable_sysfs(); 6.6.y does not have the raw spinlock conversion ] > Signed-off-by: Shuai Xue <xueshuai(a)linux.alibaba.com> > --- > Note for stable maintainers: this is patch 1/3 of LKML series > 20250514161951.3427590. Its siblings are already in 6.6.y: 2/3 > (53b9e2659719) as 1cd09aaf47a5 and 3/3 (408c97c4a5e0) as > b3b4efa2e623, but this one was only ever picked into 6.15.y > (c7f2b00d5e17e) because it does not apply cleanly to 6.6.y without the > raw spinlock conversion. Without it, each sysfs enable/disable cycle > leaks one config_desc->active_cnt reference and the module reference > taken on the config load owner, so the configuration module can never > be unloaded. Makes sense for me. This backport should be applied on both 6.6.y and 6.12.y.

1 day, 19 hours

Re: [PATCH v7 0/5] Fix traceNoC probe issue on multiple QCOM platforms

by Leo Yan

On Tue, Nov 10, 2026 at 09:46:43AM -0600, Rob Herring wrote: > On Tue, Nov 10, 2026 at 09:21:13AM +0800, Jie Gan wrote: > > The CoreSight TNOC (Trace Network-On-Chip) binding so far only allowed the > > two-string AMBA form "qcom,coresight-tnoc", "arm,primecell". That form > > forces the device onto the AMBA bus, where the driver must read the > > peripheral ID from the device registers during probe. On several QCOM > > platforms this AMBA peripheral-ID probing fails, so the traceNoC device > > never probes and its trace path is unavailable. > > But it works fine on some platforms? We have a property to override the > peripheral-ID which would solve your issue. That would be much simpler > and avoid the ABI break on any of the working platforms. Looking back at the earlier discussion [1], Jie in v2 already proposed "arm,primecell-periphid". Questions about AMBA IDs and ATID handling got mixed together. The series later moved towards platform-device probing, then became current shape. Hope we make the right decision on arm,primecell-periphid this time. Anyway, I'd like to apologise to Jie for all the back and forth. Thanks, Leo [1] https://lore.kernel.org/linux-arm-kernel/9432df20-08bf-4134-b4b9-e6b5d618af…

2 days, 13 hours

[PATCH v2 00/23] coresight: trbe: Refactor buffer and IRQ handling

by Leo Yan

This series follows the earlier TRBE buffer refactoring posting [1]. The work is now split into two parts. This first part contains fixes and refactoring in preparation for wrap and trigger mode support. Support for those modes will be sent separately. The patches are grouped as follows for easier review: Patches 1-5: Minor fixes Add register definitions, fix the watermark range check, and improve erratum checks and perf handle validation. Patches 6-11: Enable/disable lifecycle fixes Clean up session setup, status clearing and IRQ handle ownership. Patches 12-17: Refine status classification Decode stop reasons, report truncation on errors and improve trace-size accounting. Patches 18-23: Improve IRQ and overflow handling Keep the handle in per-CPU data, stabilize status reads, and improve AUX restarts and trace-gap reporting. A race also remains between TRBE interrupt handling and AUX pause/resume from a sampling NMI. This should be resolved as part of the state machine refactoring in the CoreSight AUX sampling series [2]. [1] https://lore.kernel.org/linux-arm-kernel/20251201-trbe_buffer_refactor_v1-1… [2] https://lore.kernel.org/linux-arm-kernel/20260915-arm_cs_support_aux_sample… Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- Leo Yan (23): arm64/sysreg: Define TRBSR_EL1.EC event classes coresight: trbe: Make watermark range check overflow safe in __trbe_normal_offset() coresight: trbe: Use helpers for checking errata coresight: trbe: Check the buffer association before IRQ validation coresight: trbe: Validate perf handle before using sink data coresight: trbe: Drop redundant disable from enable path coresight: trbe: Publish the session after successful enable coresight: trbe: Clear stale external abort status coresight: trbe: Clear TRBSR status at stop sites coresight: trbe: Drop redundant disables coresight: trbe: Assign the perf handle in enable and disable coresight: trbe: Decode TRBSR status codes coresight: trbe: Simplify wrap status handling coresight: trbe: Treat access not allowed stops as fatal coresight: trbe: Report truncated trace on buffer update errors coresight: trbe: Always classify TRBSR when updating buffer coresight: trbe: Calculate trace size across buffer wrap coresight: trbe: Keep the perf handle in per-CPU data coresight: trbe: Reload the AUX buffer on overflow restart coresight: trbe: Add fault action argument to trbe_handle_overflow() coresight: trbe: Read TRBSR after prohibiting and flushing trace coresight: trbe: Restart trace source for stopped buffers coresight: trbe: Report trace gaps with PARTIAL instead of COLLISION arch/arm64/include/asm/sysreg.h | 6 + arch/arm64/tools/sysreg | 8 +- drivers/hwtracing/coresight/coresight-trbe.c | 481 ++++++++++++++++++--------- drivers/hwtracing/coresight/coresight-trbe.h | 8 - 4 files changed, 345 insertions(+), 158 deletions(-) --- base-commit: 343cfcbb3ecfdb80aa576a428cfa3b65ad783842 change-id: 20261016-trbe_enable_disable_irq_handle_refactor-0a3450f03473 Best regards, -- Leo Yan <leo.yan(a)arm.com>

2 days, 16 hours

Re: [PATCH v7 0/5] Fix traceNoC probe issue on multiple QCOM platforms

by Suzuki K Poulose

On 10/11/2026 15:46, Rob Herring wrote: > On Tue, Nov 10, 2026 at 09:21:13AM +0800, Jie Gan wrote: >> The CoreSight TNOC (Trace Network-On-Chip) binding so far only allowed the >> two-string AMBA form "qcom,coresight-tnoc", "arm,primecell". That form >> forces the device onto the AMBA bus, where the driver must read the >> peripheral ID from the device registers during probe. On several QCOM >> platforms this AMBA peripheral-ID probing fails, so the traceNoC device >> never probes and its trace path is unavailable. > > But it works fine on some platforms? We have a property to override the > peripheral-ID which would solve your issue. That would be much simpler > and avoid the ABI break on any of the working platforms. That is true ! Sorry, I didn't think of the quirk. > > But this is already applied and it's not any platform I use, so I don't > really care. I am happy to revert these changes and let the DTS be fixed. Cheers Suzuki > > Rob

2 days, 19 hours

RE: [PATCH v2 1/4] coresight: syscfg: Fail to enable a configuration not loaded on the device

by Mike Leach

3 days, 19 hours

RE: [PATCH v2 3/4] coresight: etm4x: Report the external outputs the PMU counts

by Mike Leach

Hi, > -----Original Message----- > From: Amir Ayupov <aaupov(a)fb.com> > Sent: Tuesday, October 13, 2026 12:05 AM > To: James Clark <james.clark(a)linaro.org>; Leo Yan <Leo.Yan(a)arm.com>; > Suzuki Poulose <Suzuki.Poulose(a)arm.com>; Mike Leach > <Mike.Leach(a)arm.com>; Alexander Shishkin > <alexander.shishkin(a)linux.intel.com> > Cc: Jonathan Corbet <corbet(a)lwn.net>; Randy Dunlap > <rdunlap(a)infradead.org>; Shuah Khan <skhan(a)linuxfoundation.org>; > coresight(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org; linux- > doc(a)vger.kernel.org; linux-kernel(a)vger.kernel.org > Subject: [PATCH v2 3/4] coresight: etm4x: Report the external outputs the > PMU counts > > Some CPUs count the trace unit's external outputs as the PMU common > events TRCEXTOUT0-3 (0x4010-0x4013), which lets a configuration drive a > PMU event from trace unit events. Other CPUs, Neoverse N1 for example, > have no such events, and a feature relying on them would silently do > nothing there. > > Detect at probe, on the trace unit's CPU, which outputs the PMU counts: > the trace unit has an external output for each of its events > (TRCIDR0.NUMEVENT), and from PMUv3p1, PMCEID0_EL0[63:32] reports > which of > the common events 0x4000-0x401f are implemented. Per the ETE > specification, an implemented TRCEXTOUTn event counts external output n; > only whether that output is also an external input is IMPLEMENTATION > DEFINED. > > Add a capability match flag for each output, > CS_CFG_MATCH_CAP_PMU_EXTOUT(n), set it on ETMs whose PMU counts > that > output, and show it in the feature's configfs 'matches' attribute. With > capabilities matched separately from the device class, a feature that > requires one only loads on those ETMs. > The ability of the PMU to count extout events is a feature of the PMU, not a feature of the ETM/ETE. The capability to use extout in a configuration should be predicated solely on the correctly interpreted values of TRCIDR0 and TRCIDR4 - the number of available extout events. There does not have to be a valid pmu counter for a configuration using extout to work correctly - indeed the extout connections are often implementation defined and sometimes connected via coresight CTI. If we have a use case that requires extout to trigger PMUs, then clearly we have both trace software and PMU software that must be initialised and run. It seems more relevant to me that the PMU software should check that it can count the extout when it is run, especially given the PMU command line detailed in the next patch is in part " -e armv8_pmuv3_0/trcextout1,aux-action=pause,period=1000," - specifically identifying extout1 as a parameter > Assisted-by: Devmate:Opus-5.5 > Signed-off-by: Amir Ayupov <aaupov(a)fb.com> > --- > .../hwtracing/coresight/coresight-config.h | 4 +++ > .../hwtracing/coresight/coresight-etm4x-cfg.c | 5 ++- > .../coresight/coresight-etm4x-core.c | 32 +++++++++++++++++++ > drivers/hwtracing/coresight/coresight-etm4x.h | 3 ++ > .../coresight/coresight-syscfg-configfs.c | 7 ++++ > 5 files changed, 50 insertions(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-config.h > b/drivers/hwtracing/coresight/coresight-config.h > index af6ef96b9ae01..10e95f5ecc8d9 100644 > --- a/drivers/hwtracing/coresight/coresight-config.h > +++ b/drivers/hwtracing/coresight/coresight-config.h > @@ -35,6 +35,10 @@ > * a device that matches one of its classes and has all of its capabilities. > */ > #define CS_CFG_MATCH_CAP_MASK 0x0000ff00 > +/* trace unit external output n is countable by the PMU as TRCEXTOUTn */ > +#define CS_CFG_MATCH_CAP_PMU_EXTOUT_SHIFT 8 > +#define CS_CFG_MATCH_CAP_PMU_EXTOUT_NR 4 /* > TRCEXTOUT0-3 */ > +#define CS_CFG_MATCH_CAP_PMU_EXTOUT(n) > BIT(CS_CFG_MATCH_CAP_PMU_EXTOUT_SHIFT + (n)) > > /* flags defining device instance matching - used in config match desc data. */ > #define CS_CFG_MATCH_INST_ANY 0x80000000 /* any instance > of a class */ > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > index e1a59b4345052..09a7a6b86968c 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c > @@ -174,9 +174,12 @@ static int etm4_cfg_load_feature(struct > coresight_device *csdev, > > int etm4_cscfg_register(struct coresight_device *csdev) > { > + struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev- > >dev.parent); > struct cscfg_csdev_feat_ops ops; > + u32 match_flags = CS_CFG_ETM4_MATCH_FLAGS; > > ops.load_feat = &etm4_cfg_load_feature; > + match_flags |= (u32)drvdata->pmu_extout << > CS_CFG_MATCH_CAP_PMU_EXTOUT_SHIFT; > > - return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, > &ops); > + return cscfg_register_csdev(csdev, match_flags, &ops); > } > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c > b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 2247ad55d4442..1e78774025d13 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -30,6 +30,7 @@ > #include <linux/uaccess.h> > #include <linux/perf_event.h> > #include <linux/perf/arm_pmu.h> > +#include <linux/perf/arm_pmuv3.h> > #include <linux/platform_device.h> > #include <linux/pm_runtime.h> > #include <linux/property.h> > @@ -1368,6 +1369,35 @@ static void etm4_fixup_wrong_ccitmin(struct > etmv4_drvdata *drvdata) > } > } > > +/* > + * Find the external outputs of this trace unit that the PMU counts as the > + * common events TRCEXTOUT0-3. The trace unit has an external output for > each > + * of its events, and PMCEID0_EL0[63:32] reports the common events > + * 0x4000-0x401f from PMUv3p1. > + * > + * Must run on the CPU that owns the trace unit. > + */ > +static u8 etm4_pmu_extout(struct etmv4_drvdata *drvdata) > +{ > + int pmuver = read_pmuver(); > + u64 pmceid; > + u8 extout = 0; > + int n; > + > + if (!pmuv3_implemented(pmuver) || pmuver < > ID_AA64DFR0_EL1_PMUVer_V3P1) > + return 0; > + > + pmceid = read_pmceid0() >> 32; > + /* nr_event is TRCIDR0.NUMEVENT, the number of events minus one > */ Not necessarily - this value depends on the ETM version. > + for (n = 0; n <= drvdata->nr_event; n++) { > + if (pmceid & > BIT_ULL(ARMV8_PMUV3_PERFCTR_TRCEXTOUT0 + n - > + > ARMV8_PMUV3_EXT_COMMON_EVENT_BASE)) > + extout |= BIT(n); > + } > + > + return extout; > +} > + > static void etm4_init_arch_data(void *info) > { > u32 etmidr0; > @@ -1522,6 +1552,8 @@ static void etm4_init_arch_data(void *info) > /* NUMCNTR, bits[30:28] number of counters available for tracing */ > drvdata->nr_cntr = FIELD_GET(TRCIDR5_NUMCNTR_MASK, etmidr5); > > + drvdata->pmu_extout = etm4_pmu_extout(drvdata); > + > coresight_clear_self_claim_tag_unlocked(csa); > etm4_cs_lock(drvdata, csa); > cpu_detect_trace_filtering(drvdata); > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h > b/drivers/hwtracing/coresight/coresight-etm4x.h > index df9e0748d71ec..11d95a4518b88 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x.h > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h > @@ -979,6 +979,8 @@ struct etmv4_save_state { > * @nrseqstate: The number of sequencer states that are implemented. > * @nr_seq_ctrls: The number of sequence state transition control registers. > * @nr_event: Indicates how many events the trace unit support. > + * @pmu_extout: Bitmap of the external outputs n that the PMU counts > as > + * TRCEXTOUTn. > * @nr_resource:The number of resource selection pairs available for tracing. > * @nr_ss_cmp: Number of single-shot comparator controls that are > available. > * @trcid: value of the current ID for this component. > @@ -1045,6 +1047,7 @@ struct etmv4_drvdata { > u8 nrseqstate; > u8 nr_seq_ctrls; > u8 nr_event; > + u8 pmu_extout; PMU connection to extout a feature of PMU not the etm. We don't want to add every single extout connection use-case into the ETM driver. Wouldn't scale well. Regards Mike. > u8 nr_resource; > u8 nr_ss_cmp; > u8 trcid; > diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.c > b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c > index 2b40e556be872..7893d40f2e9ea 100644 > --- a/drivers/hwtracing/coresight/coresight-syscfg-configfs.c > +++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c > @@ -243,6 +243,7 @@ static ssize_t cscfg_feat_matches_show(struct > config_item *item, char *page) > struct > cscfg_fs_feature, group); > u32 match_flags = fs_feat->feat_desc->match_flags; > int used = 0; > + int n; > > if (match_flags & CS_CFG_MATCH_CLASS_SRC_ALL) > used = scnprintf(page, PAGE_SIZE, "SRC_ALL "); > @@ -250,6 +251,12 @@ static ssize_t cscfg_feat_matches_show(struct > config_item *item, char *page) > if (match_flags & CS_CFG_MATCH_CLASS_SRC_ETM4) > used += scnprintf(page + used, PAGE_SIZE - used, > "SRC_ETMV4 "); > > + for (n = 0; n < CS_CFG_MATCH_CAP_PMU_EXTOUT_NR; n++) { > + if (match_flags & CS_CFG_MATCH_CAP_PMU_EXTOUT(n)) > + used += scnprintf(page + used, PAGE_SIZE - used, > + "PMU_EXTOUT%d ", n); > + } > + > used += scnprintf(page + used, PAGE_SIZE - used, "\n"); > return used; > } > -- > 2.52.0

3 days, 19 hours

Re: [PATCH v7 0/5] Fix traceNoC probe issue on multiple QCOM platforms

by Suzuki K Poulose

On Tue, 10 Nov 2026 09:21:13 +0800, Jie Gan wrote: > The CoreSight TNOC (Trace Network-On-Chip) binding so far only allowed the > two-string AMBA form "qcom,coresight-tnoc", "arm,primecell". That form > forces the device onto the AMBA bus, where the driver must read the > peripheral ID from the device registers during probe. On several QCOM > platforms this AMBA peripheral-ID probing fails, so the traceNoC device > never probes and its trace path is unavailable. > > [...] Applied, thanks! [1/5] dt-bindings: arm: coresight-tnoc: Bind on platform bus instead of AMBA https://git.kernel.org/coresight/c/76e192f4d40a [2/5] coresight: tnoc: Bind Aggregator TNOC on the platform bus https://git.kernel.org/coresight/c/4d443f2e0956 [3/5] arm64: dts: qcom: kaanapali: bind traceNoC on the platform bus https://git.kernel.org/coresight/c/50e7796ab751 [4/5] arm64: dts: qcom: sm8750: bind traceNoC on the platform bus https://git.kernel.org/coresight/c/f599d281541e [5/5] arm64: dts: qcom: glymur: use Aggregator TNOC compatible https://git.kernel.org/coresight/c/1352ce9c99bd Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

3 days, 22 hours

Re: [PATCH] coresight: fix resource leaks on path build failure

by James Clark

On 09/11/2026 01:24, Jie Gan wrote: > > > On 5/13/2026 9:32 AM, Jie Gan wrote: >> Two related leaks when _coresight_build_path() encounters an error after >> coresight_grab_device() has already incremented the pm_runtime, module, >> and device references for a node: >> >> 1. In _coresight_build_path(), if kzalloc_obj() for the path node fails >> after coresight_grab_device() succeeds, coresight_drop_device() was >> never called, permanently leaking all three references. >> >> 2. In coresight_build_path(), on failure the partial path was freed with >> kfree(path) instead of coresight_release_path(path). kfree() only >> frees the coresight_path struct itself; it does not iterate path_list >> to call coresight_drop_device() and kfree() for each coresight_node >> already added by deeper recursive calls, leaking both the pm_runtime, >> module, and device references and the node memory for every element >> on the partial path. >> >> Fix both by adding coresight_drop_device() in the OOM unwind of >> _coresight_build_path(), and replacing kfree(path) with >> coresight_release_path(path) in coresight_build_path(). >> >> Fixes: 32b0707a4182 ("coresight: Add try_get_module() in >> coresight_grab_device()") >> Fixes: b3e94405941e ("coresight: associating path with session rather >> than tracer") >> Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > > Gentle ping. > >> --- >> drivers/hwtracing/coresight/coresight-core.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/ >> hwtracing/coresight/coresight-core.c >> index 46f247f73cf6..c1354ea8e11d 100644 >> --- a/drivers/hwtracing/coresight/coresight-core.c >> +++ b/drivers/hwtracing/coresight/coresight-core.c >> @@ -825,8 +825,10 @@ static int _coresight_build_path(struct >> coresight_device *csdev, >> return ret; >> node = kzalloc_obj(struct coresight_node); >> - if (!node) >> + if (!node) { >> + coresight_drop_device(csdev); >> return -ENOMEM; >> + } >> node->csdev = csdev; >> list_add(&node->link, &path->path_list); >> @@ -851,7 +853,7 @@ struct coresight_path *coresight_build_path(struct >> coresight_device *source, >> rc = _coresight_build_path(source, source, sink, path); >> if (rc) { >> - kfree(path); >> + coresight_release_path(path); @Suzuki, there's a conflict here. This will need to be coresight_release_path_locked() if we also take "coresight: etm-perf: Serialize AUX topology access" from my Sashiko fixes. >> return ERR_PTR(rc); >> } >> >> --- >> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83 >> change-id: 20260513-fix-memory-leak-issue-034b4a45265e >> >> Best regards, >

4 days, 22 hours

Re: [PATCH] [v2] coresight: funnel: inport schedule by priority can not take work

by Suzuki K Poulose

On Tue, 27 Oct 2026 23:14:56 +0800, Chao Xu wrote: > The CoreSight SoC-600 TRM, section 10.11.2, PRIORITYCONTROL, a funnel > rejects priority register writes whenever any port is enabled. The > current sequence therefore prevent the configured priorities from > taking effect. Write the priority register before enabling the > first port. > > > [...] Applied, thanks! [1/1] coresight: funnel: inport schedule by priority can not take work https://git.kernel.org/coresight/c/533e91f192eb Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

4 days, 23 hours

Re: [PATCH v3 0/2] fix clock refcount imbalance for all Coresight platform drivers

by Suzuki K Poulose

On Fri, 10 Jul 2026 09:14:46 +0800, Jie Gan wrote: > Found a clock imbalance issue when remove the CTCU module. > > coresight_get_enable_clocks() enables the programming clock and the > optional AT clock through devm_clk_get_optional_enabled(), which also > registers a devm action to call clk_disable_unprepare() when the driver > detaches. > > [...] Applied, thanks! [1/2] coresight: Fix clock refcount imbalance on platform remove https://git.kernel.org/coresight/c/c2d0f71617f4 [2/2] coresight: tnoc: Fix clock refcount imbalance on platform remove https://git.kernel.org/coresight/c/69285a3b57db Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

4 days, 23 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight