CoreSight May 2026

coresight@lists.linaro.org

6 participants
51 discussions

[PATCH v6 0/8] perf cs-etm: Support thread stack and callchain

by Leo Yan

This series adds thread-stack and synthesized callchain support for Arm CoreSight, which comes from older series [1] but heavily rewritten. CS ETM previously kept last-branch state in a per-trace-queue buffer. That effectively makes the state per CPU, while the call/return history belongs to a thread. This series moves branch tracking to the common thread-stack code. The series records CoreSight branches with thread_stack__event(), uses thread_stack__br_sample() for last branch entries, flushes thread stacks after decoder resets. A decoder reset between AUX trace buffers is treated as a global trace discontinuity, so all thread stacks are flushed, so avoids carrying stale call/return history across a trace discontinuity. One limitation remains for instructions emulated by the kernel. In that case the exception return address may not match the return address stored in the thread stack, because after exception return can be one instruction ahead. The stack can still recover when a later return matches an upper caller. Given emulated instructions are not the common target for performance callchain analysis. Supporting this would require extending the common thread-stack path to accept both the real target address and an adjusted address for stack matching, so this series leaves that extra complexity out. The series has been tested on Orion6 board: perf test 150 -vvv 150: Check Arm CoreSight synthesized callchain: --- start --- test child forked, pid 13528 Test callchain push: PASS Test callchain pop: PASS ---- end(0) ---- 150: Check Arm CoreSight synthesized callchain : Ok perf script --itrace=g16i10il64 callchain_test 17468 [005] 1031003.229943: 10 instructions: aaaac32507c4 main+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test) ffff90bd225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6) ffff90bd233c call_init+0x9c (inlined) ffff90bd233c __libc_start_main_impl+0x9c (inlined) aaaac3250670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 17468 [005] 1031003.229943: 10 instructions: aaaac3250774 do_svc+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac3250798 print+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac32507b0 foo+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac32507c8 main+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) ffff90bd225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6) ffff90bd233c call_init+0x9c (inlined) ffff90bd233c __libc_start_main_impl+0x9c (inlined) aaaac3250670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test) callchain_test 17468 [005] 1031003.229944: 10 instructions: ffff800080010c20 vectors+0x420 ([kernel.kallsyms]) aaaac3250784 do_svc+0x1c (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac3250798 print+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac32507b0 foo+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) aaaac32507c8 main+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test) ffff90bd225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6) ffff90bd233c call_init+0x9c (inlined) ffff90bd233c __libc_start_main_impl+0x9c (inlined) aaaac3250670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test) Note, the test fails on Juno board which is caused by many discontinuity packets (mainly caused by NO_SYNC elem). This is likely caused by the FIFO overflow on the path. [1] https://lore.kernel.org/linux-arm-kernel/20200220052701.7754-1-leo.yan@lina… Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- Leo Yan (8): perf cs-etm: Decode ETE exception packets perf cs-etm: Refactor instruction size handling perf cs-etm: Use thread-stack for last branch entries perf cs-etm: Flush thread stacks after decoder reset perf cs-etm: Support call indentation perf cs-etm: Filter synthesized branch samples perf cs-etm: Synthesize callchains for instruction samples perf test: Add Arm CoreSight callchain test .../tests/shell/test_arm_coresight_callchain.sh | 235 ++++++++++++++++ tools/perf/util/cs-etm.c | 309 ++++++++++++--------- 2 files changed, 408 insertions(+), 136 deletions(-) --- base-commit: bd2a5be1fe731bc7548205dd148db75f1d588da2 change-id: 20260521-b4-arm_cs_callchain_support_v1-2c2a70719bcc Best regards, -- Leo Yan <leo.yan(a)arm.com>

5 hours, 29 minutes

Re: [PATCH v7 09/13] coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable

by Leo Yan

On Tue, May 19, 2026 at 04:48:08PM +0100, Yeoreum Yun wrote: > In the perf enable path, there are missing cases where > cscfg_csdev_disable_active_config() is not called: > > - Branch broadcast is selected but not supported by the hardware > - etm4_enable_hw() fails > > This can lead to a leak of config_desc->active_cnt. > Fix this by properly calling cscfg_csdev_disable_active_config() > in these error paths. > > Fixes: 810ac401db1f ("coresight: etm4x: Add complex configuration handlers to etmv4") > Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> > --- > .../hwtracing/coresight/coresight-etm4x-core.c | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index f0a9f2ef4b27..0889937811cb 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -899,6 +899,8 @@ static int etm4_parse_event_config(struct coresight_device *csdev, > * Missing BB support could cause silent decode errors > * so fail to open if it's not supported. > */ > + if (cfg_hash) > + cscfg_csdev_disable_active_config(csdev); > ret = -EINVAL; > goto out; > } else { > @@ -915,6 +917,7 @@ static int etm4_enable_perf(struct coresight_device *csdev, > struct coresight_path *path) > { > struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); > + struct perf_event_attr *attr = &event->attr; > int ret; > > if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id())) > @@ -926,7 +929,7 @@ static int etm4_enable_perf(struct coresight_device *csdev, > /* Configure the tracer based on the session's specifics */ > ret = etm4_parse_event_config(csdev, event); > if (ret) > - goto out; > + goto err; > > drvdata->trcid = path->trace_id; > > @@ -935,16 +938,19 @@ static int etm4_enable_perf(struct coresight_device *csdev, > > /* And enable it */ > ret = etm4_enable_hw(drvdata); > - > -out: > - /* Failed to start tracer; roll back to DISABLED mode */ > if (ret) { > - coresight_set_mode(csdev, CS_MODE_DISABLED); > - return ret; > + if (ATTR_CFG_GET_FLD(attr, configid)) > + cscfg_csdev_disable_active_config(csdev); > + goto err; > } > > csdev->path = path; > return 0; > + > +err: > + /* Failed to start tracer; roll back to DISABLED mode */ > + coresight_set_mode(csdev, CS_MODE_DISABLED); > + return ret; > } Seems to me, it is not readable if spread error handling into both child and parent functions. I would like we can stick to use the same function for resource allocation and rollback for failures. How about below change (I did not verify it yet): diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 0889937811cb..8347efb2069b 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -794,8 +794,7 @@ static int etm4_parse_event_config(struct coresight_device *csdev, .ATTR_CFG_FLD_timestamp_CFG = U64_MAX, }; struct perf_event_attr *attr = &event->attr; - unsigned long cfg_hash; - int preset, cc_threshold; + int cc_threshold; u8 ts_level; /* Clear configuration from previous run */ @@ -882,16 +881,6 @@ static int etm4_parse_event_config(struct coresight_device *csdev, /* bit[12], Return stack enable bit */ config->cfg |= TRCCONFIGR_RS; - /* - * Set any selected configuration and preset. A zero configid means no - * configuration active, preset = 0 means no preset selected. - */ - cfg_hash = ATTR_CFG_GET_FLD(attr, configid); - if (cfg_hash) { - preset = ATTR_CFG_GET_FLD(attr, preset); - ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset); - } - /* branch broadcast - enable if selected and supported */ if (ATTR_CFG_GET_FLD(attr, branch_broadcast)) { if (!caps->trcbb) { @@ -899,8 +888,6 @@ static int etm4_parse_event_config(struct coresight_device *csdev, * Missing BB support could cause silent decode errors * so fail to open if it's not supported. */ - if (cfg_hash) - cscfg_csdev_disable_active_config(csdev); ret = -EINVAL; goto out; } else { @@ -918,7 +905,8 @@ static int etm4_enable_perf(struct coresight_device *csdev, { struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent); struct perf_event_attr *attr = &event->attr; - int ret; + unsigned long cfg_hash; + int preset, ret; if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id())) return -EINVAL; @@ -931,6 +919,18 @@ static int etm4_enable_perf(struct coresight_device *csdev, if (ret) goto err; + /* + * Set any selected configuration and preset. A zero configid means no + * configuration active, preset = 0 means no preset selected. + */ + cfg_hash = ATTR_CFG_GET_FLD(attr, configid); + if (cfg_hash) { + preset = ATTR_CFG_GET_FLD(attr, preset); + ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset); + if (ret) + goto err; + } + drvdata->trcid = path->trace_id; /* Populate pause state */ @@ -938,15 +938,15 @@ static int etm4_enable_perf(struct coresight_device *csdev, /* And enable it */ ret = etm4_enable_hw(drvdata); - if (ret) { - if (ATTR_CFG_GET_FLD(attr, configid)) - cscfg_csdev_disable_active_config(csdev); - goto err; - } + if (ret) + goto err_enable_hw; csdev->path = path; return 0; +err_enable_hw: + if (cfg_hash) + cscfg_csdev_disable_active_config(csdev); err: /* Failed to start tracer; roll back to DISABLED mode */ coresight_set_mode(csdev, CS_MODE_DISABLED);

3 days, 3 hours

Re: [PATCH v7 08/13] coresight: etm4x: fix inconsistencies with sysfs configuration

by Leo Yan

On Thu, May 28, 2026 at 03:26:57PM +0100, Yeoreum Yun wrote: [...] > > > @@ -47,7 +47,7 @@ static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata, > > > struct cscfg_regval_csdev *reg_csdev, u32 offset) > > > { > > > int err = -EINVAL, idx; > > > - struct etmv4_config *drvcfg = &drvdata->config; > > > + struct etmv4_config *drvcfg = &drvdata->active_config; > > > > Wouldn't it make more sense to keep using drvdata->config for cfgfs? > > This would avoid cfgfs updating the active configuration while a session > > is enabled. > > > > My understanding is after refactoring cfgfs, we will never expose > > active_config or config anymore so this should not an issue. Before > > that, maybe we just keep to use config so can avoid mess. > > I don't think so. since the cfgfs's config is updated right before > enable and in this patchset, It's applied after "take the mode". > > If we do it into drvdta->config, then contention would be increased > with the access of sysfs and that nullifies almost this patch purpose > and because of we use "one config" this makes a corruption with perf > and sysfs. Here have two different contention: the contention between sysfs and cfgfs, and the contention between cfgfs and a runtime config (active config). My suggestion is to avoid the later contention, which is the main idea in this series that avoid the runtime config is modified in the middle of a session. That said, I have no strong opinion. > > > static void etm4_enable_sysfs_smp_call(void *info) > > > { > > > struct etm4_enable_arg *arg = info; > > > + struct etmv4_drvdata *drvdata; > > > struct coresight_device *csdev; > > > + unsigned long cfg_hash; > > > + int preset; > > > > > > if (WARN_ON(!arg)) > > > return; > > > > > > - csdev = arg->drvdata->csdev; > > > + drvdata = arg->drvdata; > > > + csdev = drvdata->csdev; > > > if (!coresight_take_mode(csdev, CS_MODE_SYSFS)) { > > > /* Someone is already using the tracer */ > > > arg->rc = -EBUSY; > > > return; > > > } > > > > > > - arg->rc = etm4_enable_hw(arg->drvdata); > > > + /* enable any config activated by configfs */ > > > + cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset); > > > > > > - /* The tracer didn't start */ > > > + drvdata->active_config = arg->config; > > > > Can move this down to just before drvdata->trcid assignment so cscfg > > operations can be put together? > > No. Copy the arg->config must be before cscfg_csdev_enable_active_config(). > If that's after, it overrides the "preset" and this is different from > the former behavior. Please copy config first, then do cscfg stuffs. > > > + arg->rc = etm4_enable_hw(drvdata); > > > if (arg->rc) { > > > - coresight_set_mode(csdev, CS_MODE_DISABLED); > > > - return; > > > + cscfg_csdev_disable_active_config(csdev); > > > + goto err; > > > > Add a new goto tag (like err_enable_hw) for the disable_active_config > > rollback? > > This is only place where cscfg_csdev_disable_active_config(). > Why do we need to goto for cleanup where there is no duplication? It is about to use a central place for handling errors. > > > @@ -1449,7 +1458,7 @@ static void etm4_init_arch_data(void *info) > > > > > > /* EXLEVEL_S, bits[19:16] Secure state instruction tracing */ > > > caps->s_ex_level = FIELD_GET(TRCIDR3_EXLEVEL_S_MASK, etmidr3); > > > - drvdata->config.s_ex_level = caps->s_ex_level; > > > + config->s_ex_level = caps->s_ex_level; > > > > config->s_ex_level is redundant and not really a configuration item. > > We should use caps->s_ex_level instead of config->s_ex_level wherever > > it is used. > > Agree, but this includes it should change the omse function > declations to pass "caps" argument: > - etm4_set_comparator_filter() > - etm4_set_start_stop_filter() > > If that's okay, I'll respin with it. This is fine for me. Thanks, Leo

3 days, 4 hours

Re: [PATCH v9 4/4] coresight: cti: expose banked sysfs registers for Qualcomm extended CTI

by Leo Yan

On Thu, May 21, 2026 at 08:16:30PM +0800, Yingchao Deng wrote: [...] > @@ -515,18 +543,36 @@ static struct attribute *coresight_cti_regs_attrs[] = { > &dev_attr_appclear.attr, > &dev_attr_apppulse.attr, > coresight_cti_reg(triginstatus, CTITRIGINSTATUS), > + coresight_cti_reg_index(triginstatus1, CTITRIGINSTATUS, 1), > + coresight_cti_reg_index(triginstatus2, CTITRIGINSTATUS, 2), > + coresight_cti_reg_index(triginstatus3, CTITRIGINSTATUS, 3), For this patch: Reviewed-by: Leo Yan <leo.yan(a)arm.com> AI tool reminds to update Documentation/ABI/testing/sysfs-bus-coresight-devices-cti, you might need to add description with a new patch: What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus[1-3] Date: May 2026 KernelVersion: 7.2 Contact: coresight(a)lists.linaro.org Description: (Read) read current status of QCOM extended output trigger signals. And please add document for other new sysfs knobs. Thanks, Leo

6 days, 5 hours

[PATCH 0/2] perf cs-etm: Queue context packets for frontend

by James Clark

Fix thread tracking when decoding Coresight trace and add a new test for it. Unfortunately the test has to be added as a separate binary like the other existing Coresight workloads which needs a bit of makefile boilerplate. Ideally it would be a builtin Perf test workload, but Perf has a lot of dependencies and generates a lot of trace when starting up which makes tracing tests very slow because all that has to be decoded. Hopefully I can find a generic way to enable Perf events at the beginning of the workload and then I can migrate everything from tools/perf/tests/shell/coresight to Perf test workloads, but that will have to be done as a separate change. Signed-off-by: James Clark <james.clark(a)linaro.org> --- James Clark (1): perf test cs-etm: Test thread attribution Leo Yan (1): perf cs-etm: Queue context packets for frontend tools/perf/tests/shell/coresight/Makefile | 1 + .../shell/coresight/context_switch_loop/.gitignore | 1 + .../shell/coresight/context_switch_loop/Makefile | 29 ++++ .../context_switch_loop/context_switch_loop.c | 83 ++++++++++ .../tests/shell/coresight/context_switch_thread.sh | 48 ++++++ tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 +- tools/perf/util/cs-etm.c | 181 +++++++++++++-------- tools/perf/util/cs-etm.h | 5 +- 8 files changed, 295 insertions(+), 71 deletions(-) --- base-commit: 09d355618f7ccc27ffc7fc668b2e232872962079 change-id: 20260515-james-cs-context-tracking-fix-754998bae7ed Best regards, -- James Clark <james.clark(a)linaro.org>

6 days, 5 hours

Re: [PATCH v9 2/4] coresight: cti: use __reg_addr() helper for register access

by Leo Yan

On Thu, May 21, 2026 at 08:16:28PM +0800, Yingchao Deng wrote: [...] > +static void __iomem *__reg_addr(struct cti_drvdata *drvdata, u32 off, > + u32 index) > +{ > + return drvdata->base + off + sizeof(u32) * index; > +} > + > +#define reg_addr(drvdata, off) __reg_addr((drvdata), (off), 0) > +#define reg_index_addr(drvdata, off, i) __reg_addr((drvdata), (off), (i)) > -u32 cti_read_single_reg(struct cti_drvdata *drvdata, int offset) > +u32 cti_read_single_reg(struct cti_drvdata *drvdata, u32 off, u32 index) > { > - int val; > + u32 val; > > CS_UNLOCK(drvdata->base); > - val = readl_relaxed(drvdata->base + offset); > + val = readl_relaxed(reg_index_addr(drvdata, off, index)); > CS_LOCK(drvdata->base); > > return val; > } > > -void cti_write_single_reg(struct cti_drvdata *drvdata, int offset, u32 value) > +void cti_write_single_reg(struct cti_drvdata *drvdata, u32 off, u32 index, > + u32 value) > { > CS_UNLOCK(drvdata->base); > - writel_relaxed(value, drvdata->base + offset); > + writel_relaxed(value, reg_index_addr(drvdata, off, index)); > CS_LOCK(drvdata->base); > } I prefer to move the register helpers into coresight-cti.h and add two additional helpers: cti_read_single_reg_index() and cti_write_single_reg_index(). I also found circular dependency between coresight-cti.h and qcom-cti.h. Since qcom-cti.h only contains register definitions and a small inline function for register conversion, we can simply fold it into coresight-cti.h and dismiss the circular dependency. Based on this idea, I played around with the code a bit (see the snippet below). Would you be okay with applying this approach to patches 02/03? If have any questions, please let me know. ---8<--- --- a/drivers/hwtracing/coresight/coresight-cti.h +++ b/drivers/hwtracing/coresight/coresight-cti.h @@ -60,6 +60,31 @@ struct fwnode_handle; */ #define CTIINOUTEN_MAX 128 +/* QCOM CTI extension */ +#define QCOM_ARCHITECT 0x477 + +#define QCOM_CTIINTACK 0x020 +#define QCOM_CTIAPPSET 0x004 +#define QCOM_CTIAPPCLEAR 0x008 +#define QCOM_CTIAPPPULSE 0x00C +#define QCOM_CTIINEN 0x400 +#define QCOM_CTIOUTEN 0x800 +#define QCOM_CTITRIGINSTATUS 0x040 +#define QCOM_CTITRIGOUTSTATUS 0x060 +#define QCOM_CTICHINSTATUS 0x080 +#define QCOM_CTICHOUTSTATUS 0x084 +#define QCOM_CTIGATE 0x088 +#define QCOM_ASICCTL 0x08C +/* Integration test registers */ +#define QCOM_ITCHINACK 0xE70 +#define QCOM_ITTRIGINACK 0xE80 +#define QCOM_ITCHOUT 0xE74 +#define QCOM_ITTRIGOUT 0xEA0 +#define QCOM_ITCHOUTACK 0xE78 +#define QCOM_ITTRIGOUTACK 0xEC0 +#define QCOM_ITCHIN 0xE7C +#define QCOM_ITTRIGIN 0xEE0 + /** * Group of related trigger signals * @@ -222,9 +247,8 @@ int cti_enable(struct coresight_device *csdev, enum cs_mode mode, 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, u32 off, u32 index, - u32 value); -u32 cti_read_single_reg(struct cti_drvdata *drvdata, u32 off, u32 index); int cti_channel_trig_op(struct device *dev, enum cti_chan_op op, enum cti_trig_dir direction, u32 channel_idx, u32 trigger_idx); @@ -237,6 +261,78 @@ struct coresight_platform_data * coresight_cti_get_platform_data(struct device *dev); const char *cti_plat_get_node_name(struct fwnode_handle *fwnode); +static inline u32 cti_qcom_reg_off(u32 offset) +{ + switch (offset) { + case CTIINTACK: return QCOM_CTIINTACK; + case CTIAPPSET: return QCOM_CTIAPPSET; + case CTIAPPCLEAR: return QCOM_CTIAPPCLEAR; + case CTIAPPPULSE: return QCOM_CTIAPPPULSE; + case CTIINEN: return QCOM_CTIINEN; + case CTIOUTEN: return QCOM_CTIOUTEN; + case CTITRIGINSTATUS: return QCOM_CTITRIGINSTATUS; + case CTITRIGOUTSTATUS: return QCOM_CTITRIGOUTSTATUS; + case CTICHINSTATUS: return QCOM_CTICHINSTATUS; + case CTICHOUTSTATUS: return QCOM_CTICHOUTSTATUS; + case CTIGATE: return QCOM_CTIGATE; + case ASICCTL: return QCOM_ASICCTL; + case ITCHINACK: return QCOM_ITCHINACK; + case ITTRIGINACK: return QCOM_ITTRIGINACK; + case ITCHOUT: return QCOM_ITCHOUT; + case ITTRIGOUT: return QCOM_ITTRIGOUT; + case ITCHOUTACK: return QCOM_ITCHOUTACK; + case ITTRIGOUTACK: return QCOM_ITTRIGOUTACK; + case ITCHIN: return QCOM_ITCHIN; + case ITTRIGIN: return QCOM_ITTRIGIN; + + default: + return offset; + } +} + +static inline void __iomem *__reg_addr(struct cti_drvdata *drvdata, + u32 off, u32 index) +{ + if (unlikely(drvdata->is_qcom_cti)) + off = cti_qcom_reg_off(off); + + return drvdata->base + off + index * sizeof(u32); +} + +#define reg_addr(drvdata, off) __reg_addr((drvdata), (off), 0) +#define reg_index_addr(drvdata, off, i) __reg_addr((drvdata), (off), (i)) + +static inline u32 cti_read_single_reg_index(struct cti_drvdata *drvdata, + u32 off, u32 index) +{ + u32 val; + + CS_UNLOCK(drvdata->base); + val = readl_relaxed(reg_index_addr(drvdata, off, index)); + CS_LOCK(drvdata->base); + + return val; +} + +static inline u32 cti_read_single_reg(struct cti_drvdata *drvdata, u32 off) +{ + return cti_read_single_reg_index(drvdata, off, 0); +} + +static inline void cti_write_single_reg_index(struct cti_drvdata *drvdata, + u32 off, u32 index, u32 value) +{ + CS_UNLOCK(drvdata->base); + writel_relaxed(value, reg_index_addr(drvdata, off, index)); + CS_LOCK(drvdata->base); +} + +static inline void cti_write_single_reg(struct cti_drvdata *drvdata, + u32 off, u32 value) +{ + cti_write_single_reg_index(drvdata, off, 0, value); +} + /* Check if a cti device is enabled */ static inline bool cti_is_active(struct cti_config *cfg) {

6 days, 5 hours

Re: [PATCH v3 0/3] Enable CTCU and ETR devices for multiple QCOM platforms

by Suzuki K Poulose

On 29/05/2026 11:26, Jie Gan wrote: > > > On 2/27/2026 6:10 PM, Suzuki K Poulose wrote: >> Hello, >> >> >> On 04/02/2026 02:22, Jie Gan wrote: >>> The DT‑binding patch adds platform‑specific compatibles for the >>> CTCU device, and the following Qualcomm platforms are included: >>> Kaanapali >>> Pakala(sm8750) >>> Hamoa(x1e80100) >>> Glymur >> >> Given this is predominantly DTS changes, and there is very low chances >> of a conflict with the binding yaml change, I would recommend this to go >> via soc or the qcom platform tree. >> >> For the series: >> >> Acked-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> > > Hi Suzuki, > > May I ask is there a chance this patch series could go through the > CoreSight tree? Like I said, it is mostly Qcom platform changes. So, I would leave it to the appropriate channel Suzuki > > Thanks a lot. > Jie > >> >> >>> >>> Since the base Coresight DT patches for the Kaanapali and Glymur >>> platforms have not yet been applied, I created DT patches only >>> for the Pakala and Hamoa platforms. I will submit the Kaanapali >>> and Glymur patches once their corresponding base Coresight DT patches >>> are merged. >>> >>> The Hamoa‑related patches were posted in a separate email, and I >>> have included them in the current patch series. >>> >>> Link to the previous Hamoa patch series: >>> https://lore.kernel.org/all/20251106-enable-etr-and-ctcu-for-hamoa- >>> v2-0-cdb3a18753aa(a)oss.qualcomm.com/ >>> >>> Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> >>> --- >>> Changes in v3: >>> - change back to the numeric compatible from hamoa to x1e80100. >>> - Link to v2: https://lore.kernel.org/r/20260203-enable-ctcu-and-etr- >>> v2-0-aacc7bd7eccb(a)oss.qualcomm.com >>> >>> Changes in v2: >>> - change back to the numeric compatible from pakala to sm8750. >>> - Link to v1: https://lore.kernel.org/r/20260203-enable-ctcu-and-etr- >>> v1-0-a5371a2ec2b8(a)oss.qualcomm.com >>> >>> --- >>> Jie Gan (3): >>> dt-binding: document QCOM platforms for CTCU device >>> arm64: dts: qcom: hamoa: enable ETR and CTCU devices >>> arm64: dts: qcom: sm8750: enable ETR and CTCU devices >>> >>> .../bindings/arm/qcom,coresight-ctcu.yaml | 4 + >>> arch/arm64/boot/dts/qcom/hamoa.dtsi | 160 ++++++++++ >>> + +++++++- >>> arch/arm64/boot/dts/qcom/sm8750.dtsi | 177 ++++++++++ >>> + ++++++++++ >>> 3 files changed, 340 insertions(+), 1 deletion(-) >>> --- >>> base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d >>> change-id: 20260203-enable-ctcu-and-etr-31f9e9d1088d >>> >>> Best regards, >> >

6 days, 9 hours

Re: [PATCH] coresight: platform: defer connection counter increment until alloc succeeds

by Suzuki K Poulose

On Mon, 11 May 2026 12:19:18 +0800, Jie Gan wrote: > coresight_add_out_conn() increments nr_outconns before calling > devm_krealloc_array() and again before devm_kmalloc(). If either > allocation fails, the counter is already bumped while the corresponding > array entry is NULL or uninitialized garbage. > > coresight_add_in_conn() has the same problem with nr_inconns and > devm_krealloc_array(). > > [...] Applied, thanks! [1/1] coresight: platform: defer connection counter increment until alloc succeeds https://git.kernel.org/coresight/c/1563ae33dc4f Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

6 days, 10 hours

Re: [PATCH] coresight: etb10: restore atomic_t for shared reading state

by Suzuki K Poulose

On Fri, 29 May 2026 00:52:01 +0800, Runyu Xiao wrote: > The etb10 miscdevice uses drvdata->reading as a shared exclusivity gate > for userspace buffer access. etb_open() claims that gate with > local_cmpxchg(), and etb_release() clears it with local_set(). > > That gate is shared per-device state rather than CPU-local state. A > running system can reach it whenever /dev/<etb> is opened, closed, and > reopened by different tasks while the device remains registered, so the > same drvdata->reading variable may be claimed on one CPU and later > cleared on another. > > [...] Applied, thanks! [1/1] coresight: etb10: restore atomic_t for shared reading state https://git.kernel.org/coresight/c/fa09f08ede3d Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

6 days, 11 hours

Re: [PATCH] coresight: etb10: restore atomic_t for shared reading state

by James Clark

On 28/05/2026 5:52 pm, Runyu Xiao wrote: > The etb10 miscdevice uses drvdata->reading as a shared exclusivity gate > for userspace buffer access. etb_open() claims that gate with > local_cmpxchg(), and etb_release() clears it with local_set(). > > That gate is shared per-device state rather than CPU-local state. A > running system can reach it whenever /dev/<etb> is opened, closed, and > reopened by different tasks while the device remains registered, so the > same drvdata->reading variable may be claimed on one CPU and later > cleared on another. > > This code used to use atomic_t for the same gate, but commit > 27b10da8fff2 ("coresight: etb10: moving to local atomic operations") > changed it to local_t even though the access pattern remained cross-task > and cross-CPU. Restore atomic_t together with atomic_cmpxchg() and > atomic_set() so the exclusivity gate again uses a primitive intended > for shared state. > > The issue was found on Linux v6.18.21 by our static analysis tool while > scanning surviving local_t-on-shared-state sites, and then manually > reviewed against the live etb10 file-op path. > > It was runtime-validated with a reproducible QEMU no-device KCSAN PoC > that kept the same report-local contract: > > 1. use one shared struct etb_drvdata carrier and its > drvdata->reading gate; > 2. call etb_open() and etb_release() sequentially on that gate to > confirm the original claim/clear path; > 3. bind the open side to CPU0 and the release side to CPU1 for the > same gate to show cross-CPU ownership; > 4. run bound workers that repeatedly race etb_open() and > etb_release() on the same gate until KCSAN reports a target hit. > > The harness recorded: > > L1 passed open=1 release=1 > reading_after_open=1 reading_after_release=0 > L2 passed open_cpu=0 release_cpu=1 > cross_cpu_release=1 reading_after=0 open_ret=0 > > Representative KCSAN excerpt from the no-device validation run: > > BUG: KCSAN: data-race in etb_open.constprop.0.isra.0 [vuln_msv] > > write to 0xffffffffc0003810 of 4 bytes by task 216 on cpu 1: > etb_open.constprop.0.isra.0+0x38/0x80 [vuln_msv] > l3_worker_thread_fn+0x4f/0xf0 [vuln_msv] > kthread+0x17e/0x1c0 > ret_from_fork+0x22/0x30 > > read to 0xffffffffc0003810 of 4 bytes by task 215 on cpu 0: > etb_open.constprop.0.isra.0+0x18/0x80 [vuln_msv] > l3_worker_thread_fn+0x4f/0xf0 [vuln_msv] > kthread+0x17e/0x1c0 > ret_from_fork+0x22/0x30 > > value changed: 0x00000000 -> 0x00000001 > > Reported by Kernel Concurrency Sanitizer on: > CPU: 0 PID: 215 Comm: etb10_l3_a Tainted: G O 6.1.66 #2 > > This no-device harness is not a real ETB10 hardware end-to-end run, but > it preserves the same shared drvdata->reading gate and the same > etb_open()/etb_release() claim/clear contract. No real ETB10 hardware > was available for runtime testing. > > Build-tested with: > make olddefconfig > make -j"$(nproc)" drivers/hwtracing/coresight/coresight-etb10.o > > Fixes: 27b10da8fff2 ("coresight: etb10: moving to local atomic operations") > Cc: stable(a)vger.kernel.org > Signed-off-by: Runyu Xiao <runyu.xiao(a)seu.edu.cn> > --- > drivers/hwtracing/coresight/coresight-etb10.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c > index 35db1b6093d1..98269ea6f7ae 100644 > --- a/drivers/hwtracing/coresight/coresight-etb10.c > +++ b/drivers/hwtracing/coresight/coresight-etb10.c > @@ -85,7 +85,7 @@ struct etb_drvdata { > struct coresight_device *csdev; > struct miscdevice miscdev; > raw_spinlock_t spinlock; > - local_t reading; > + atomic_t reading; > pid_t pid; > u8 *buf; > u32 buffer_depth; > @@ -603,7 +603,7 @@ static int etb_open(struct inode *inode, struct file *file) > struct etb_drvdata *drvdata = container_of(file->private_data, > struct etb_drvdata, miscdev); > > - if (local_cmpxchg(&drvdata->reading, 0, 1)) > + if (atomic_cmpxchg(&drvdata->reading, 0, 1)) > return -EBUSY; > > dev_dbg(&drvdata->csdev->dev, "%s: successfully opened\n", __func__); > @@ -641,7 +641,7 @@ static int etb_release(struct inode *inode, struct file *file) > { > struct etb_drvdata *drvdata = container_of(file->private_data, > struct etb_drvdata, miscdev); > - local_set(&drvdata->reading, 0); > + atomic_set(&drvdata->reading, 0); > > dev_dbg(&drvdata->csdev->dev, "%s: released\n", __func__); > return 0; Reviewed-by: James Clark <james.clark(a)linaro.org> Semi-related to this change, etb_read() doesn't have any lock when reading drvdata->buffer_dept or drvdata->buf. It locks in etb_dump(), but then unlocks before actually calling copy_to_user(). Seems like concurrent calls to etb_read() might end up with corrupt data, although I'm not sure if that would ever happen in practice because it only allows one open file handle.

6 days, 11 hours

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight May 2026