Fix a regression caused by an incorrect assumption about auxtrace
indices. Then add a test that would have caught it.
---
Changes in v2:
- Fix cover letter and subject
- Link to v1: https://lore.kernel.org/r/20260119-james-perf-coresight-cpu-map-segfault-v1…
---
James Clark (2):
perf cs-etm: Fix decoding for sparse CPU maps
perf cs-etm: Test sparse CPU maps
tools/perf/tests/shell/test_arm_coresight.sh | 54 ++++++++++++++++++++++++++++
tools/perf/util/cs-etm.c | 3 +-
2 files changed, 56 insertions(+), 1 deletion(-)
---
base-commit: 571d29baa07e83e637075239f379f91353c24ec9
change-id: 20260115-james-perf-coresight-cpu-map-segfault-e250af5aa778
Best regards,
--
James Clark <james.clark(a)linaro.org>
Kconfig symbols must not include the CONFIG_ prefix. Remove the CONFIG_
prefix for default values to work.
Fixes: a02509f301c6 ("stm class: Factor out default framing protocol")
Fixes: d69d5e83110f ("stm class: Add MIPI SyS-T protocol support")
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
drivers/hwtracing/stm/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig
index eda6b11d40a1f9ab49a1ec1e6faae8ee178c5ed3..cd7f0b0f3fbebc74775d8835187e49e5bd21d646 100644
--- a/drivers/hwtracing/stm/Kconfig
+++ b/drivers/hwtracing/stm/Kconfig
@@ -13,7 +13,7 @@ if STM
config STM_PROTO_BASIC
tristate "Basic STM framing protocol driver"
- default CONFIG_STM
+ default STM
help
This is a simple framing protocol for sending data over STM
devices. This was the protocol that the STM framework used
@@ -28,7 +28,7 @@ config STM_PROTO_BASIC
config STM_PROTO_SYS_T
tristate "MIPI SyS-T STM framing protocol driver"
- default CONFIG_STM
+ default STM
help
This is an implementation of MIPI SyS-T protocol to be used
over the STP transport. In addition to the data payload, it
---
base-commit: 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb
change-id: 20251216-fix_stm_kconfig-a72f40c7612c
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
On Mon, Jan 19, 2026 at 02:11:43PM +0200, Adrian Hunter wrote:
[...]
> >> 0 0 0x200 [0x90]: PERF_RECORD_ID_INDEX nr: 4
> >> ... id: 771 idx: 0 cpu: 2 tid: -1
> >> ... id: 772 idx: 1 cpu: 3 tid: -1
> >> ... id: 773 idx: 0 cpu: 2 tid: -1
> >> ... id: 774 idx: 1 cpu: 3 tid: -1
> >
> > Seems to me that this patch works around the issue by using the CPU ID
> > instead, but event->auxtrace.idx is broken.
> >
> > Should we store the correct index in event->auxtrace.idx (e.g., in the
> > __perf_event__synthesize_id_index()) ?
>
> The idx value represents a perf events ring buffer. Events on the same
> CPU can share the same ring buffer. But in the case of per-thread
> recording, different threads have different ring buffers and therefore
> different idx values.
>
> So I don't think the idx value is wrong. It is just not the same thing
> as CPU number.
Thanks a lot for the explanation, this makes sense to me.
Leo
This patch series adds support for the Qualcomm CoreSight Interconnect TNOC
(Trace Network On Chip) block, which acts as a CoreSight graph link forwarding
trace data from subsystems to the Aggregator TNOC. Unlike the Aggregator TNOC,
this block does not support aggregation or ATID assignment.
Signed-off-by: Yuanfang Zhang <yuanfang.zhang(a)oss.qualcomm.com>
---
Changes in v5:
- Add the missing review-by tag for patch 3.
- Link to v4: https://lore.kernel.org/r/20250831-itnoc-v4-0-f0fb0ef822a5@oss.qualcomm.com
Changes in v4:
- Fix unintended blank line removals in trace_noc_enable_hw.
- Link to v3: https://lore.kernel.org/r/20250828-itnoc-v3-0-f1b55dea7a27@oss.qualcomm.com
Changes in v3:
- Add detail for changes in V2.
- Remove '#address-cells' and '#size-cells' properties from in-ports field.
- Fix comment indentation for packet description.
- Link to v2: https://lore.kernel.org/r/20250819-itnoc-v2-0-2d0e6be44e2f@oss.qualcomm.com
Changes in v2:
- Removed the trailing '|' after the description in qcom,coresight-itnoc.yaml.
- Dropped the 'select' section from the YAML file.
- Updated node name to use a more generic naming convention.
- Removed the 'items' property from the compatible field.
- Deleted the description for the reg property.
- Dropped clock-names and adjusted the order of clock-names and clocks.
- Moved additionalProperties to follow the $ref of out-ports.
- Change "atid" type from u32 to int, set it as "-EOPNOTSUPP" for non-AMBA device.
- Link to v1: https://lore.kernel.org/r/20250815-itnoc-v1-0-62c8e4f7ad32@oss.qualcomm.com
---
Yuanfang Zhang (3):
dt-bindings: arm: qcom: Add Coresight Interconnect TNOC
coresight-tnoc: add platform driver to support Interconnect TNOC
coresight-tnoc: Add runtime PM support for Interconnect TNOC
.../bindings/arm/qcom,coresight-itnoc.yaml | 90 ++++++++++++++
drivers/hwtracing/coresight/coresight-tnoc.c | 136 +++++++++++++++++++--
2 files changed, 215 insertions(+), 11 deletions(-)
---
base-commit: 2b52cf338d39d684a1c6af298e8204902c026aca
change-id: 20250815-itnoc-460273d1b80c
Best regards,
--
Yuanfang Zhang <yuanfang.zhang(a)oss.qualcomm.com>
On Thu, 08 Jan 2026 16:24:27 +0100, Antonio Borneo wrote:
> When changes [1] and [2] have been applied to the driver etm4x, the
> same modifications have been also collapsed in [3] and applied in
> one shot to the driver etm3x.
> While doing this, the driver etm3x has not been aligned to etm4x on
> the use of non cpuslocked version of cpuhp callback setup APIs.
>
> The current code triggers two run-time warnings when the kernel is
> compiled with CONFIG_PROVE_LOCKING=y.
>
> [...]
Applied, thanks!
[1/1] coresight: etm3x: Fix cpulocked warning on cpuhp
https://git.kernel.org/coresight/c/1feb0377b9b8
Best regards,
--
Suzuki K Poulose <suzuki.poulose(a)arm.com>
---
James Clark (2):
perf cs-etm: Fix decoding for sparse CPU maps
perf cs-etm: Test sparse CPU maps
tools/perf/tests/shell/test_arm_coresight.sh | 54 ++++++++++++++++++++++++++++
tools/perf/util/cs-etm.c | 3 +-
2 files changed, 56 insertions(+), 1 deletion(-)
---
base-commit: 571d29baa07e83e637075239f379f91353c24ec9
change-id: 20260115-james-perf-coresight-cpu-map-segfault-e250af5aa778
Best regards,
--
James Clark <james.clark(a)linaro.org>
The specific config field that an event format attribute is in is
consistently hard coded, even though the API is supposed to be that the
driver publishes the config field name. To stop this pattern from being
copy pasted and causing problems in the future, replace them all with
calls to a new helper that returns the value that a user set.
This reveals some issues in evsel__set_config_if_unset(). It doesn't
work with sparse bitfields, which are an unused but documented feature.
And it also only writes to the attr.config field. To fix it we need to
start tracking user changes for all config fields and then use existing
helper functions that support sparse bitfields. Some other refactoring
was also required and a test was added.
---
Changes in v4:
- Constify some function args (Ian)
- Move some evsel__* functions to evsel.c and make some pmu.c functions
public to support this (Ian)
- Drop pmu arg where it can be fetched from evsel->pmu (Ian)
- Link to v3: https://lore.kernel.org/r/20251212-james-perf-config-bits-v3-0-aa36a4846776…
Changes in v3:
- Fix uninitialized variable warning on GCC
- Fix leak of evlist in test
- Confirm no type punning issues with ubsan (Ian)
- Link to v2: https://lore.kernel.org/r/20251208-james-perf-config-bits-v2-0-4ac0281993b0…
Changes in v2:
- Remove macros in get_config_chgs() and some other refactoring.
- Support sparse bitfields in evsel__set_config_if_unset().
- Always track user changes instead of only when
'pmu->perf_event_attr_init_default' is set.
- Add a test.
- Don't bail out in cs-etm.c if any format fields are missing (Leo).
- Rename 'guess' to 'synth' (Mike).
- Link to v1: https://lore.kernel.org/r/20251201-james-perf-config-bits-v1-0-22ecbbf8007c…
---
James Clark (14):
perf parse-events: Refactor get_config_terms() to remove macros
perf evsel: Refactor evsel__set_config_if_unset() arguments
perf evsel: Move evsel__* functions to evsel.c
perf evsel: Support sparse fields in evsel__set_config_if_unset()
perf parse-events: Track all user changed config bits
perf evsel: apply evsel__set_config_if_unset() to all config fields
perf evsel: Add a helper to get the value of a config field
perf parse-events: Always track user config changes
perf tests: Test evsel__set_config_if_unset() and config change tracking
perf cs-etm: Make a helper to find the Coresight evsel
perf cs-etm: Don't use hard coded config bits when setting up ETMCR
perf cs-etm: Don't use hard coded config bits when setting up TRCCONFIGR
perf cs-etm: Don't hard code config attribute when configuring the event
perf arm-spe: Don't hard code config attribute
tools/perf/arch/arm/util/cs-etm.c | 201 +++++++++++++++-------------
tools/perf/arch/arm64/util/arm-spe.c | 17 +--
tools/perf/arch/x86/util/intel-pt.c | 3 +-
tools/perf/tests/pmu.c | 91 +++++++++++++
tools/perf/util/evsel.c | 112 +++++++++++++++-
tools/perf/util/evsel.h | 6 +-
tools/perf/util/evsel_config.h | 7 +-
tools/perf/util/parse-events.c | 248 ++++++++++++++++++++---------------
tools/perf/util/pmu.c | 95 ++++----------
tools/perf/util/pmu.h | 34 ++++-
10 files changed, 529 insertions(+), 285 deletions(-)
---
base-commit: cbd41c6d4c26c161a2b0e70ad411d3885ff13507
change-id: 20251112-james-perf-config-bits-bee7106f0f00
Best regards,
--
James Clark <james.clark(a)linaro.org>
The specific config field that an event format attribute is in is
consistently hard coded, even though the API is supposed to be that the
driver publishes the config field name. To stop this pattern from being
copy pasted and causing problems in the future, replace them all with
calls to a new helper that returns the value that a user set.
This reveals some issues in evsel__set_config_if_unset(). It doesn't
work with sparse bitfields, which are an unused but documented feature.
And it also only writes to the attr.config field. To fix it we need to
start tracking user changes for all config fields and then use existing
helper functions that support sparse bitfields. Some other refactoring
was also required and a test was added.
---
Changes in v5:
- Use bitfields wherever possible instead of converting to a u64. This
is more consistent with the existing format helper functions and
fixes a build error on i386 where unsigned long is 32 bits.
- Link to v4: https://lore.kernel.org/r/20251222-james-perf-config-bits-v4-0-0608438186fc…
Changes in v4:
- Constify some function args (Ian)
- Move some evsel__* functions to evsel.c and make some pmu.c functions
public to support this (Ian)
- Drop pmu arg where it can be fetched from evsel->pmu (Ian)
- Link to v3: https://lore.kernel.org/r/20251212-james-perf-config-bits-v3-0-aa36a4846776…
Changes in v3:
- Fix uninitialized variable warning on GCC
- Fix leak of evlist in test
- Confirm no type punning issues with ubsan (Ian)
- Link to v2: https://lore.kernel.org/r/20251208-james-perf-config-bits-v2-0-4ac0281993b0…
Changes in v2:
- Remove macros in get_config_chgs() and some other refactoring.
- Support sparse bitfields in evsel__set_config_if_unset().
- Always track user changes instead of only when
'pmu->perf_event_attr_init_default' is set.
- Add a test.
- Don't bail out in cs-etm.c if any format fields are missing (Leo).
- Rename 'guess' to 'synth' (Mike).
- Link to v1: https://lore.kernel.org/r/20251201-james-perf-config-bits-v1-0-22ecbbf8007c…
---
James Clark (14):
perf parse-events: Refactor get_config_terms() to remove macros
perf evsel: Refactor evsel__set_config_if_unset() arguments
perf evsel: Move evsel__* functions to evsel.c
perf evsel: Support sparse fields in evsel__set_config_if_unset()
perf parse-events: Track all user changed config bits
perf evsel: apply evsel__set_config_if_unset() to all config fields
perf evsel: Add a helper to get the value of a config field
perf parse-events: Always track user config changes
perf tests: Test evsel__set_config_if_unset() and config change tracking
perf cs-etm: Make a helper to find the Coresight evsel
perf cs-etm: Don't use hard coded config bits when setting up ETMCR
perf cs-etm: Don't use hard coded config bits when setting up TRCCONFIGR
perf cs-etm: Don't hard code config attribute when configuring the event
perf arm-spe: Don't hard code config attribute
tools/perf/arch/arm/util/cs-etm.c | 201 +++++++++++++++-------------
tools/perf/arch/arm64/util/arm-spe.c | 17 +--
tools/perf/arch/x86/util/intel-pt.c | 3 +-
tools/perf/tests/pmu.c | 91 +++++++++++++
tools/perf/util/evsel.c | 120 ++++++++++++++++-
tools/perf/util/evsel.h | 6 +-
tools/perf/util/evsel_config.h | 7 +-
tools/perf/util/parse-events.c | 248 ++++++++++++++++++++---------------
tools/perf/util/pmu.c | 95 ++++----------
tools/perf/util/pmu.h | 34 ++++-
10 files changed, 537 insertions(+), 285 deletions(-)
---
base-commit: 54a23bff770961e024e2c61cd1f46888190c3e79
change-id: 20251112-james-perf-config-bits-bee7106f0f00
Best regards,
--
James Clark <james.clark(a)linaro.org>
On Tue, Jan 13, 2026 at 12:58:16PM -0800, Ian Rogers wrote:
> > perf arm-spe: Don't hard code config attribute
>
> Reviewed-by: Ian Rogers <irogers(a)google.com>
>
> Most patches already have my tag, sending this for the remainder.
Thanks, will add to the ones missing it.
- Arnaldo
On Tue, Dec 16, 2025 at 01:00:32PM -0800, Ian Rogers wrote:
> On Fri, Dec 12, 2025 at 7:32 AM James Clark <james.clark(a)linaro.org> wrote:
> >
> > The specific config field that an event format attribute is in is
> > consistently hard coded, even though the API is supposed to be that the
> > driver publishes the config field name. To stop this pattern from being
> > copy pasted and causing problems in the future, replace them all with
> > calls to a new helper that returns the value that a user set.
> >
> > This reveals some issues in evsel__set_config_if_unset(). It doesn't
> > work with sparse bitfields, which are an unused but documented feature.
> > And it also only writes to the attr.config field. To fix it we need to
> > start tracking user changes for all config fields and then use existing
> > helper functions that support sparse bitfields. Some other refactoring
> > was also required and a test was added.
> >
> > Signed-off-by: James Clark <james.clark(a)linaro.org>
>
> Outside of some nits, for the series:
> Reviewed-by: Ian Rogers <irogers(a)google.com>
Are you ok with v4?
- Arnaldo