Kconfig symbols must not include the CONFIG_ prefix. Remove the CONFIG_
prefix for default values to work.
The STM_PROTO_SYS_T config is selected by default when STM is enabled.
However, its description currently says "If you don't know what this is,
say N," which contradicts the default behavior. Update the description
to say "Y" to align with the default setting.
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>
---
Changes in v2:
- Updated STM_PROTO_BASIC description to align with default selection
(James).
- Link to v1: https://lore.kernel.org/r/20251217-fix_stm_kconfig-v1-1-531fb3674549@arm.com
---
drivers/hwtracing/stm/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig
index eda6b11d40a1f9ab49a1ec1e6faae8ee178c5ed3..8ab079785189052945521e9b0a93a0d458de37e0 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
@@ -38,7 +38,7 @@ config STM_PROTO_SYS_T
The receiving side must be able to decode this protocol in
addition to the MIPI STP, in order to extract the data.
- If you don't know what this is, say N.
+ If you don't know what this is, say Y.
config STM_DUMMY
tristate "Dummy STM driver"
---
base-commit: fcb70a56f4d81450114034b2c61f48ce7444a0e2
change-id: 20251216-fix_stm_kconfig-a72f40c7612c
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
This series is to fix and refactor CoreSight device registration and
unregistration, it can be divided into three small parts:
Patches 01-03: Three fixes for memory leak, device reference and mutex
protection.
Patches 04-05: Move connection cleanup operations into
coresight_remove_conns().
Patches 06-08: Refactor error handling in coresight_register().
This series is verified on Juno board with kmemleak detector.
For kmemleak verifying:
echo clear > /sys/kernel/debug/kmemleak
insmod coresight modules
rmmod coresight modules
echo scan > /sys/kernel/debug/kmemleak
The result shows no memory leak during a cycle of device registration
and unregistration.
---
Changes in v2:
- Refined the commit log in patch 06 (Suzuki).
- Unified to call coresight_unregister() for error handling (Suzuki).
- Refactor connection and sysfs group release.
- Link to v1: https://lore.kernel.org/linux-arm-kernel/20250512154108.23920-1-leo.yan@arm…
To: Suzuki K Poulose <suzuki.poulose(a)arm.com>
To: Mike Leach <mike.leach(a)linaro.org>
To: James Clark <james.clark(a)linaro.org>
To: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
To: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
To: Mathieu Poirier <mathieu.poirier(a)linaro.org>
To: Mao Jinlong <quic_jinlmao(a)quicinc.com>
Cc: coresight(a)lists.linaro.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
Leo Yan (8):
coresight: Fix memory leak in coresight_alloc_device_name()
coresight: Get parent device reference after sink ID map allocation
coresight: Protect unregistration with mutex
coresight: Refactor output connection sysfs link cleanup
coresight: Refactor sysfs connection group cleanup
coresight: Move sink validation into etm_perf_add_symlink_sink()
coresight: Do not mix success path with failure handling
coresight: Unify error handling in coresight_register()
drivers/hwtracing/coresight/coresight-core.c | 105 +++++++++++------------
drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +-
drivers/hwtracing/coresight/coresight-platform.c | 2 +-
drivers/hwtracing/coresight/coresight-priv.h | 3 +-
4 files changed, 56 insertions(+), 59 deletions(-)
---
base-commit: eebe8dbd8630f51cf70b1f68a440cd3d7f7a914d
change-id: 20260120-arm_coresight_refactor_dev_register-f16c069db41d
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
The first patch fixes an build failure issued caused by bitfield on the
stable kernel, the second patch is a minor polish to avoid including
redundant headers.
Verified for Arm64 perf building.
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
Leo Yan (2):
tools: Fix bitfield dependency failure
perf: Remove redundant kernel.h include
tools/include/linux/bitfield.h | 1 +
tools/perf/arch/arm64/util/header.c | 1 -
tools/perf/util/cs-etm.c | 1 -
3 files changed, 1 insertion(+), 2 deletions(-)
---
base-commit: 800af362d68945e589f73cda429d04bfe4287feb
change-id: 20260123-perf_fix_bitfield-h-084902f55c35
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
On 22/01/2026 02:08, Jie Gan wrote:
> Remove ctcu_get_active_port from CTCU module and add it to the core
> framework.
>
> The port number is crucial for the CTCU device to identify which ETR
> it serves. With the port number we can correctly get required parameters
> of the CTCU device in TMC module.
>
> Reviewed-by: Mike Leach <mike.leach(a)linaro.org>
> Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com>
> ---
> drivers/hwtracing/coresight/coresight-core.c | 24 +++++++++++++++++++++++
> drivers/hwtracing/coresight/coresight-ctcu-core.c | 19 +-----------------
> drivers/hwtracing/coresight/coresight-priv.h | 2 ++
> 3 files changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index c660cf8adb1c..0e8448784c62 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -585,6 +585,30 @@ struct coresight_device *coresight_get_sink(struct coresight_path *path)
> }
> EXPORT_SYMBOL_GPL(coresight_get_sink);
>
> +/**
> + * coresight_get_in_port: Find the input port number at @csdev where a @remote
> + * device is connected to.
This doesn't match the code ?
We are looking at the remote devices' in_connections ?
> + *
> + * @csdev: csdev of the device.
> + * @remote: csdev of the remote device which is connected to @csdev.
> + *
> + * Return: port number upon success or -EINVAL for fail.
> + */
> +int coresight_get_in_port(struct coresight_device *csdev,
> + struct coresight_device *remote)
> +{
> + struct coresight_platform_data *pdata = remote->pdata;
> + int i;
> +
> + for (i = 0; i < pdata->nr_inconns; ++i) {
> + if (pdata->in_conns[i]->src_dev == csdev)
> + return pdata->in_conns[i]->dest_port;
> + }
Suzuki
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>