CoreSight

coresight@lists.linaro.org

5 participants
2762 discussions

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

by Leo Yan

On Mon, Jun 01, 2026 at 10:08:55AM +0800, Yingchao Deng (Consultant) wrote: [...] > I noticed that among the new sysfs knobs in this series, the > integration test registers (ittrigin[1-3], ittrigout[1-3], > ittrigoutack[1-3], ittriginack[1-3]) have no existing documentation > for their base (index-0) counterparts, which were added long before > this series. Ah, thanks for pointing out the missed piece! > Two options for patch 5/5: > > (a) Document only the knobs whose base versions are already > documented (triginstatus[1-3] and trigoutstatus[1-3]). > > (b) Document everything in patch 5/5 — both the new indexed > variants and the previously missing base IT register entries. Please use option (b). Could you fold the code piece below into patch 5? Note, we cannot merge ittrigin and ittrigin[1-3] into a single entry because they were introduced in different kernel versions. @Mike, if any chance you could give a review on this? ---8<--- --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti @@ -134,6 +134,60 @@ KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) read current status of output trigger signals. +What: /sys/bus/coresight/devices/<cti-name>/regs/itctrl +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (RW) Control integration mode. + +What: /sys/bus/coresight/devices/<cti-name>/regs/itchin +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (Read) Read the values of the CTCHIN inputs. + +What: /sys/bus/coresight/devices/<cti-name>/regs/itchinack +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (Write) Write the value of the CTCHINACK input. + +What: /sys/bus/coresight/devices/<cti-name>/regs/ittrigin +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (Read) Read the values of the CTTRIGIN inputs. + +What: /sys/bus/coresight/devices/<cti-name>/regs/ittriginack +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (Write) Write the value of the CTTRIGINACK input. + +What: /sys/bus/coresight/devices/<cti-name>/regs/itchout +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (RW) Read or write the value of the CTCHOUT outputs. + +What: /sys/bus/coresight/devices/<cti-name>/regs/itchoutack +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (Read) Read the value of the CTCHOUTACK input. + +What: /sys/bus/coresight/devices/<cti-name>/regs/ittrigout +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (RW) Read or write the value of the CTTRIGOUT outputs. + +What: /sys/bus/coresight/devices/<cti-name>/regs/ittrigoutack +Date: March 2020 +KernelVersion 5.7 +Contact: coresight(a)lists.linaro.org +Description: (Read) Read the value of the CTTRIGOUTACK input. + What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach Date: March 2020 KernelVersion: 5.7

4 days, 9 hours

Re: [PATCH v7 02/13] coresight: etm4x: fix underflow for nrseqstate

by Suzuki K Poulose

On 19/05/2026 16:48, Yeoreum Yun wrote: > TCRSEQEVR<n> is implemented only when TCRIDR5.NUMSEQSTATE is 0b100, > in which case n ranges from 0 to 2; otherwise, TCRIDR5.NUMSEQSTATE is 0b000. > > Therefore, drvdata->nrseqstate should be checked before entering the loop. for (i = 0; i < drvdata->nrseqstate - 1; i++) Wouldn't that check cover the case ? (provided i is signed int ?) Suzuki > > Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] > Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver") > Reviewed-by: Leo Yan <leo.yan(a)arm.com> > Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> > --- > .../hwtracing/coresight/coresight-etm4x-core.c | 18 ++++++++++-------- > .../coresight/coresight-etm4x-sysfs.c | 2 ++ > 2 files changed, 12 insertions(+), 8 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 1e3b0344dc00..94b9385e964a 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -542,9 +542,11 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > etm4x_relaxed_write32(csa, config->vissctlr, TRCVISSCTLR); > if (drvdata->nr_pe_cmp) > etm4x_relaxed_write32(csa, config->vipcssctlr, TRCVIPCSSCTLR); > - for (i = 0; i < drvdata->nrseqstate - 1; i++) > - etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i)); > + > if (drvdata->nrseqstate) { > + for (i = 0; i < drvdata->nrseqstate - 1; i++) > + etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i)); > + > etm4x_relaxed_write32(csa, config->seq_rst, TRCSEQRSTEVR); > etm4x_relaxed_write32(csa, config->seq_state, TRCSEQSTR); > } > @@ -1896,10 +1898,10 @@ static int etm4_cpu_save(struct coresight_device *csdev) > if (drvdata->nr_pe_cmp) > state->trcvipcssctlr = etm4x_read32(csa, TRCVIPCSSCTLR); > > - for (i = 0; i < drvdata->nrseqstate - 1; i++) > - state->trcseqevr[i] = etm4x_read32(csa, TRCSEQEVRn(i)); > - > if (drvdata->nrseqstate) { > + for (i = 0; i < drvdata->nrseqstate - 1; i++) > + state->trcseqevr[i] = etm4x_read32(csa, TRCSEQEVRn(i)); > + > state->trcseqrstevr = etm4x_read32(csa, TRCSEQRSTEVR); > state->trcseqstr = etm4x_read32(csa, TRCSEQSTR); > } > @@ -2009,10 +2011,10 @@ static void etm4_cpu_restore(struct coresight_device *csdev) > if (drvdata->nr_pe_cmp) > etm4x_relaxed_write32(csa, state->trcvipcssctlr, TRCVIPCSSCTLR); > > - for (i = 0; i < drvdata->nrseqstate - 1; i++) > - etm4x_relaxed_write32(csa, state->trcseqevr[i], TRCSEQEVRn(i)); > - > if (drvdata->nrseqstate) { > + for (i = 0; i < drvdata->nrseqstate - 1; i++) > + etm4x_relaxed_write32(csa, state->trcseqevr[i], TRCSEQEVRn(i)); > + > etm4x_relaxed_write32(csa, state->trcseqrstevr, TRCSEQRSTEVR); > etm4x_relaxed_write32(csa, state->trcseqstr, TRCSEQSTR); > } > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > index e9eeea6240d5..0e1ad175aa1e 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > @@ -1395,6 +1395,8 @@ static ssize_t seq_idx_store(struct device *dev, > struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent); > struct etmv4_config *config = &drvdata->config; > > + if (!drvdata->nrseqstate) > + return -ENOTSUPP; > if (kstrtoul(buf, 16, &val)) > return -EINVAL; > if (val >= drvdata->nrseqstate - 1)

4 days, 10 hours

Re: [PATCH v7 02/13] coresight: etm4x: fix underflow for nrseqstate

by Suzuki K Poulose

On 19/05/2026 16:48, Yeoreum Yun wrote: > TCRSEQEVR<n> is implemented only when TCRIDR5.NUMSEQSTATE is 0b100, > in which case n ranges from 0 to 2; otherwise, TCRIDR5.NUMSEQSTATE is 0b000. > > Therefore, drvdata->nrseqstate should be checked before entering the loop. s/TCR/TRC/g ^^^ and every other patch in the series. Seem like you have been playing with the MMU code ;-) > > Link: https://developer.arm.com/documentation/ihi0064/latest/ [0] > Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver") > Reviewed-by: Leo Yan <leo.yan(a)arm.com> > Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> > --- > .../hwtracing/coresight/coresight-etm4x-core.c | 18 ++++++++++-------- > .../coresight/coresight-etm4x-sysfs.c | 2 ++ > 2 files changed, 12 insertions(+), 8 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 1e3b0344dc00..94b9385e964a 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -542,9 +542,11 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > etm4x_relaxed_write32(csa, config->vissctlr, TRCVISSCTLR); > if (drvdata->nr_pe_cmp) > etm4x_relaxed_write32(csa, config->vipcssctlr, TRCVIPCSSCTLR); > - for (i = 0; i < drvdata->nrseqstate - 1; i++) > - etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i)); > + > if (drvdata->nrseqstate) { > + for (i = 0; i < drvdata->nrseqstate - 1; i++) > + etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i)); Looking at this again, I think we are contemplating two different values from a single variable (blame the architecture). Instead, we should: 1. Disconnect number of TRCSEQEVRn from drvdata->nrseqstate, and add nr_seq_ctrls to drvdata and initialise this at probe. for (i = 0; i < drvdata->nr_seq_ctrls; i++) Suzuki > + > etm4x_relaxed_write32(csa, config->seq_rst, TRCSEQRSTEVR); > etm4x_relaxed_write32(csa, config->seq_state, TRCSEQSTR); > } > @@ -1896,10 +1898,10 @@ static int etm4_cpu_save(struct coresight_device *csdev) > if (drvdata->nr_pe_cmp) > state->trcvipcssctlr = etm4x_read32(csa, TRCVIPCSSCTLR); > > - for (i = 0; i < drvdata->nrseqstate - 1; i++) > - state->trcseqevr[i] = etm4x_read32(csa, TRCSEQEVRn(i)); > - > if (drvdata->nrseqstate) { > + for (i = 0; i < drvdata->nrseqstate - 1; i++) > + state->trcseqevr[i] = etm4x_read32(csa, TRCSEQEVRn(i)); > + > state->trcseqrstevr = etm4x_read32(csa, TRCSEQRSTEVR); > state->trcseqstr = etm4x_read32(csa, TRCSEQSTR); > } > @@ -2009,10 +2011,10 @@ static void etm4_cpu_restore(struct coresight_device *csdev) > if (drvdata->nr_pe_cmp) > etm4x_relaxed_write32(csa, state->trcvipcssctlr, TRCVIPCSSCTLR); > > - for (i = 0; i < drvdata->nrseqstate - 1; i++) > - etm4x_relaxed_write32(csa, state->trcseqevr[i], TRCSEQEVRn(i)); > - > if (drvdata->nrseqstate) { > + for (i = 0; i < drvdata->nrseqstate - 1; i++) > + etm4x_relaxed_write32(csa, state->trcseqevr[i], TRCSEQEVRn(i)); > + > etm4x_relaxed_write32(csa, state->trcseqrstevr, TRCSEQRSTEVR); > etm4x_relaxed_write32(csa, state->trcseqstr, TRCSEQSTR); > } > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > index e9eeea6240d5..0e1ad175aa1e 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c > @@ -1395,6 +1395,8 @@ static ssize_t seq_idx_store(struct device *dev, > struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent); > struct etmv4_config *config = &drvdata->config; > > + if (!drvdata->nrseqstate) > + return -ENOTSUPP; > if (kstrtoul(buf, 16, &val)) > return -EINVAL; > if (val >= drvdata->nrseqstate - 1)

4 days, 10 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

1 week

[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>

1 week

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) {

1 week

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, >> >

1 week

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>

1 week

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>

1 week

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.

1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight