CoreSight February 2026

coresight@lists.linaro.org

13 participants
47 discussions

[PATCH v3 0/8] coresight: Fix device registration and unregistration

by Leo Yan

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 v3: - Updated patch 01 to use coesight core layer for device index list (Suzuki). - Link to v2: https://lore.kernel.org/r/20260126-arm_coresight_refactor_dev_register-v2-0… 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)arm.com> 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-catu.c | 4 +- drivers/hwtracing/coresight/coresight-core.c | 230 +++++++++++++-------- drivers/hwtracing/coresight/coresight-ctcu-core.c | 4 +- drivers/hwtracing/coresight/coresight-cti-core.c | 19 +- drivers/hwtracing/coresight/coresight-dummy.c | 7 +- drivers/hwtracing/coresight/coresight-etb10.c | 4 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +- drivers/hwtracing/coresight/coresight-funnel.c | 4 +- drivers/hwtracing/coresight/coresight-platform.c | 2 +- drivers/hwtracing/coresight/coresight-priv.h | 3 +- drivers/hwtracing/coresight/coresight-replicator.c | 4 +- drivers/hwtracing/coresight/coresight-stm.c | 4 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 12 +- drivers/hwtracing/coresight/coresight-tnoc.c | 4 +- drivers/hwtracing/coresight/coresight-tpda.c | 4 +- drivers/hwtracing/coresight/coresight-tpdm.c | 4 +- drivers/hwtracing/coresight/coresight-tpiu.c | 4 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 4 +- include/linux/coresight.h | 14 +- 19 files changed, 175 insertions(+), 161 deletions(-) --- base-commit: eebe8dbd8630f51cf70b1f68a440cd3d7f7a914d change-id: 20260120-arm_coresight_refactor_dev_register-f16c069db41d Best regards, -- Leo Yan <leo.yan(a)arm.com>

1 week, 5 days

[issue] coresight: Device tree dependency cycle warnings with bidirectional port references

by 梁镇

Hi CoreSight maintainers, I'm working on adding CoreSight support for RISC-V platform and encountering dependency cycle warnings during boot when defining the device tree topology with bidirectional port references. ## Problem Description When I define the CoreSight topology in device tree with remote-endpoint properties in both out-ports and in-ports (as shown in some examples), the kernel reports dependency cycle warnings: ... [ 2.092243] /soc/funnel@d9042000: Fixed dependency cycle(s) with /soc/etf@d9043000 [ 2.099843] /soc/funnel@d9042000: Fixed dependency cycle(s) with /soc/etf@d9043000 [ 2.107359] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/funnel@d9042000 [ 2.114899] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/etr@d9044000 [ 2.122234] /soc/etf@d9043000: Fixed dependency cycle(s) with /soc/etr@d9044000 [ 2.129492] /soc/etr@d9044000: Fixed dependency cycle(s) with /soc/etf@d9043000 ## Current Device Tree Structure encoder0: encoder@d9002000 { compatible = "riscv,trace-encoder"; reg = <0x0 0xd9002000 0x0 0x1000>; cpus = <&cpu_0>; out-ports { port { cluster0_encoder0_out_port: endpoint { remote-endpoint = <&cluster0_bridge0_in_port>; }; }; }; }; bridge0: bridge@d9003000 { compatible = "riscv,trace-atbbridge"; reg = <0x0 0xd9003000 0x0 0x1000>; cpus = <&cpu_0>; out-ports { port { cluster0_bridge0_out_port: endpoint { remote-endpoint = <&cluster0_funnel_in_port0>; }; }; }; in-ports { port { cluster0_bridge0_in_port: endpoint { remote-endpoint = <&cluster0_encoder0_out_port>; }; }; }; }; ................. cluster0_funnel: funnel@d9000000 { compatible = "riscv,trace-funnel"; reg = <0x0 0xd9000000 0x0 0x1000>; cpus = <&cpu_0>, <&cpu_1>, <&cpu_2>, <&cpu_3>; out-ports { port { cluster0_funnel_out_port: endpoint { remote-endpoint = <&main_funnel_in_port0>; }; }; }; in-ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; cluster0_funnel_in_port0: endpoint { remote-endpoint = <&cluster0_bridge0_out_port>; }; }; port@1 { reg = <1>; cluster0_funnel_in_port1: endpoint { remote-endpoint = <&cluster0_bridge1_out_port>; }; }; port@2 { reg = <2>; cluster0_funnel_in_port2: endpoint { remote-endpoint = <&cluster0_bridge2_out_port>; }; }; port@3 { reg = <3>; cluster0_funnel_in_port3: endpoint { remote-endpoint = <&cluster0_bridge3_out_port>; }; }; }; }; main_funnel: funnel@d9042000 { compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; reg = <0x0 0xd9042000 0x0 0x1000>; clocks = <&dummy_clk>; clock-names = "apb_pclk"; out-ports { port { main_funnel_out_port: endpoint { remote-endpoint = <&etf_in_port>; }; }; }; in-ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; main_funnel_in_port0: endpoint { remote-endpoint = <&cluster0_funnel_out_port>; }; }; port@1 { reg = <1>; main_funnel_in_port1: endpoint { remote-endpoint = <&cluster1_funnel_out_port>; }; }; port@2 { reg = <2>; main_funnel_in_port2: endpoint { remote-endpoint = <&cluster2_funnel_out_port>; }; }; port@3 { reg = <3>; main_funnel_in_port3: endpoint { remote-endpoint = <&cluster3_funnel_out_port>; }; }; }; }; etf: etf@d9043000 { compatible = "arm,coresight-tmc", "arm,primecell"; reg = <0x0 0xd9043000 0x0 0x1000>; clocks = <&dummy_clk>; clock-names = "apb_pclk"; out-ports { port { etf_out_port: endpoint { remote-endpoint = <&etr_in_port>; }; }; }; in-ports { port { etf_in_port: endpoint { remote-endpoint = <&main_funnel_out_port>; }; }; }; }; etr: etr@d9044000 { compatible = "arm,coresight-tmc", "arm,primecell"; reg = <0x0 0xd9044000 0x0 0x1000>; clocks = <&dummy_clk>; clock-names = "apb_pclk"; arm,scatter-gather; in-ports { port { etr_in_port: endpoint { remote-endpoint = <&etf_out_port>; }; }; }; }; ## Questions The kernel's fw_devlink mechanism detects and "fixes" these cycles, but can I avoid them in the device tree definition? The system works correctly despite the warnings, but I'd like to understand the proper way to define the topology to avoid these messages. Thank you for your guidance! liangzhen(a)linux.spacemit.com

2 weeks, 3 days

Re: [PATCH 1/3] dt-binding: document QCOM platforms for CTCU device

by Suzuki K Poulose

On 03/02/2026 09:36, Konrad Dybcio wrote: > On 2/3/26 10:31 AM, Suzuki K Poulose wrote: >> On 03/02/2026 09:00, Jie Gan wrote: >>> >>> >>> On 2/3/2026 4:50 PM, Konrad Dybcio wrote: >>>> On 2/3/26 9:08 AM, Jie Gan wrote: >>>>> Document the platforms that fallback to using the qcom,sa8775p-ctcu >>>>> compatible for probing. >>>>> >>>>> Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> >>>>> --- >>>>> Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 4 ++++ >>>>> 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight- ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight- ctcu.yaml >>>>> index e002f87361ad..68853db52bef 100644 >>>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>> @@ -29,6 +29,10 @@ properties: >>>>> oneOf: >>>>> - items: >>>>> - enum: >>>>> + - qcom,glymur-ctcu >>>>> + - qcom,hamoa-ctcu >>>>> + - qcom,kaanapali-ctcu >>>>> + - qcom,pakala-ctcu >>>> >>>> Platforms with existing numeric compatibles should continue to use them, >>>> so that the mess is somewhat containable >>> >>> Sure Konrad. So for Pakala, I will change it back to qcom,sm8750-ctcu >> >> Why do we need different compatibles for the others ? Are they not all compliant to the CTCU programming model ? i.e., sa8775p-ctcu ? or even, >> a generic, >> >> qcom,coresight-ctcu > > It's a huge anti-pattern with the DT maintainers, since a compatible is > the only way to effectively differentiate different implementations (i.e. > instances on different SoCs) of an IP block Do you mean, same IP block integrated to different SoC ? Or are they different implementations altogether ? Why are these not applicable for other components ? (e.g., Tnoc, I-Tnoc, TPDA, TPDM etc ?) > > This is important for the case where a DTB is shipped as part of firmware > and can not be replaced - if some quirk needs to be applied retroactively, > we can look for "qcom,glymur-ctcu" without affecting all the 50 other' > users of the effectively-identical IP block Fair enough, thank for the explanation. Kind regards Suzuki > > In this case, we're already reducing the impact on the driver, as that > only looks for the single fallback compatible (qcom,sa8775p-ctcu) > > Konrad

2 weeks, 4 days

Re: [PATCH 1/3] dt-binding: document QCOM platforms for CTCU device

by Suzuki K Poulose

On 03/02/2026 09:00, Jie Gan wrote: > > > On 2/3/2026 4:50 PM, Konrad Dybcio wrote: >> On 2/3/26 9:08 AM, Jie Gan wrote: >>> Document the platforms that fallback to using the qcom,sa8775p-ctcu >>> compatible for probing. >>> >>> Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> >>> --- >>> Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 4 >>> ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight- >>> ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight- >>> ctcu.yaml >>> index e002f87361ad..68853db52bef 100644 >>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>> @@ -29,6 +29,10 @@ properties: >>> oneOf: >>> - items: >>> - enum: >>> + - qcom,glymur-ctcu >>> + - qcom,hamoa-ctcu >>> + - qcom,kaanapali-ctcu >>> + - qcom,pakala-ctcu >> >> Platforms with existing numeric compatibles should continue to use them, >> so that the mess is somewhat containable > > Sure Konrad. So for Pakala, I will change it back to qcom,sm8750-ctcu Why do we need different compatibles for the others ? Are they not all compliant to the CTCU programming model ? i.e., sa8775p-ctcu ? or even, a generic, qcom,coresight-ctcu Suzuki > > Thanks, > Jie > >> >> Konrad >

2 weeks, 4 days

Re: [PATCH v3] coresight: etm3x: Fix cntr_val_show() to match cntr_val_store() behavior

by Suzuki K Poulose

Hello On 02/02/2026 05:09, Kuan-Wei Chiu wrote: > On Tue, Dec 02, 2025 at 09:26:19AM +0000, James Clark wrote: >> >> >> On 02/12/2025 8:26 am, Kuan-Wei Chiu wrote: >>> The cntr_val_show() function was intended to print the values of all >>> counters using a loop. However, due to a buffer overwrite issue with >>> sprintf(), it effectively only displayed the value of the last counter. >>> >>> The companion function, cntr_val_store(), allows users to modify a >>> specific counter selected by 'cntr_idx'. To maintain consistency >>> between read and write operations and to align with the ETM4x driver >>> behavior, modify cntr_val_show() to report only the value of the >>> currently selected counter. >>> >>> This change removes the loop and the "counter %d:" prefix, printing >>> only the hexadecimal value. It also adopts sysfs_emit() for standard >>> sysfs output formatting. >>> >>> Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver") >>> Cc: stable(a)vger.kernel.org >>> Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> >>> --- >>> Build test only. >>> >>> Changes in v3: >>> - Switch format specifier to %#x to include the 0x prefix. >>> - Add Cc stable >>> >>> v2: https://lore.kernel.org/lkml/20251201095228.1905489-1-visitorckw@gmail.com/ >>> >>> .../hwtracing/coresight/coresight-etm3x-sysfs.c | 15 ++++----------- >>> 1 file changed, 4 insertions(+), 11 deletions(-) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>> index 762109307b86..b3c67e96a82a 100644 >>> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>> @@ -717,26 +717,19 @@ static DEVICE_ATTR_RW(cntr_rld_event); >>> static ssize_t cntr_val_show(struct device *dev, >>> struct device_attribute *attr, char *buf) >>> { >>> - int i, ret = 0; >>> u32 val; >>> struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent); >>> struct etm_config *config = &drvdata->config; >>> if (!coresight_get_mode(drvdata->csdev)) { >>> spin_lock(&drvdata->spinlock); >>> - for (i = 0; i < drvdata->nr_cntr; i++) >>> - ret += sprintf(buf, "counter %d: %x\n", >>> - i, config->cntr_val[i]); >>> + val = config->cntr_val[config->cntr_idx]; >>> spin_unlock(&drvdata->spinlock); >>> - return ret; >>> - } >>> - >>> - for (i = 0; i < drvdata->nr_cntr; i++) { >>> - val = etm_readl(drvdata, ETMCNTVRn(i)); >>> - ret += sprintf(buf, "counter %d: %x\n", i, val); >>> + } else { >>> + val = etm_readl(drvdata, ETMCNTVRn(config->cntr_idx)); >>> } >>> - return ret; >>> + return sysfs_emit(buf, "%#x\n", val); >>> } >>> static ssize_t cntr_val_store(struct device *dev, >> >> Reviewed-by: James Clark <james.clark(a)linaro.org> >> > Thanks for the review! > Is there anything else I need to do for this fix to land? Thanks for the patch, I will queue this for the next release (v7.1). Suzuki > > Regards, > Kuan-Wei >

2 weeks, 5 days

Hire SAFEGUARD RECOVERY, a Bitcoin recovery specialist, to retrieve stolen or lost coins.

by sophia fourest

I invested $320,000 in Tether (USDT) on a fraudulent website after falling for a romantic scam. I felt completely helpless and in need of assistance after realizing I had been duped. I started looking for a hacker online and found SAFEGUARD RECOVERY. I had optimism because of his professionalism and knowledge. I'm happy to report that SAFEGUARD RECOVERY successfully recovered my stolen money after working relentlessly to do so! I am immensely appreciative of their help and heartily urge anyone in a comparable circumstance to use their services. I'm grateful Email: safeguardbitcoin(a)consultant.com WhatsApp: +44 7426 168300 Website: https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

2 weeks, 5 days

Hire SAFEGUARD RECOVERY, a Bitcoin recovery specialist, to retrieve stolen or lost coins.

by sophia fourest

2 weeks, 5 days

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight February 2026