CoreSight

coresight@lists.linaro.org

2 participants
2792 discussions

Re: [PATCH v6 01/12] dt-bindings: document access-controllers property for coresight peripherals

by Suzuki K Poulose

Hi On 26/02/2026 10:30, Gatien Chevallier wrote: > Document the access-controllers for coresight peripherals in case some > access checks need to be performed to use them. > > Signed-off-by: Gatien Chevallier <gatien.chevallier(a)foss.st.com> > Reviewed-by: Rob Herring (Arm) <robh(a)kernel.org> > --- > Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml | 3 +++ > .../devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml | 3 +++ > Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml | 3 +++ > Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml | 3 +++ > Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml | 3 +++ > Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml | 3 +++ Are you sure, you are not missing "replicator" in the list ? Otherwise, looks good to me. Acked-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> > 6 files changed, 18 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > index 2a91670ccb8c..949444aba1f8 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml > @@ -128,6 +128,9 @@ properties: > "#address-cells": > const: 1 > > + access-controllers: > + maxItems: 1 > + > patternProperties: > '^trig-conns@([0-9]+)$': > type: object > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml > index b74db15e5f8a..b0693cd46d27 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml > @@ -78,6 +78,9 @@ properties: > description: Output connection to CoreSight Trace bus > $ref: /schemas/graph.yaml#/properties/port > > + access-controllers: > + maxItems: 1 > + > required: > - compatible > - reg > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml > index 71f2e1ed27e5..10ebbbeadf93 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml > @@ -118,6 +118,9 @@ properties: > description: Output connection from the ETM to CoreSight Trace bus. > $ref: /schemas/graph.yaml#/properties/port > > + access-controllers: > + maxItems: 1 > + > required: > - compatible > - clocks > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml > index 378380c3f5aa..f243e76f597f 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml > @@ -73,6 +73,9 @@ properties: > description: Output connection to the CoreSight Trace bus. > $ref: /schemas/graph.yaml#/properties/port > > + access-controllers: > + maxItems: 1 > + > required: > - compatible > - reg > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > index 96dd5b5f771a..9dc096698c65 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml > @@ -128,6 +128,9 @@ properties: > - const: tracedata > - const: metadata > > + access-controllers: > + maxItems: 1 > + > required: > - compatible > - reg > diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml > index a207f6899e67..29bbc3961fdf 100644 > --- a/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml > +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml > @@ -70,6 +70,9 @@ properties: > description: Input connection from the CoreSight Trace bus. > $ref: /schemas/graph.yaml#/properties/port > > + access-controllers: > + maxItems: 1 > + > required: > - compatible > - reg >

4 months, 1 week

Re: [PATCH] coresight: ctcu: fix the spin_bug

by Suzuki K Poulose

On Thu, 19 Feb 2026 22:46:57 +0800, Jie Gan wrote: > Acquiring an uninitialized raw_spin_lock is invalid and may trigger > unexpected behavior or spin_bug. > > Applied, thanks! [1/1] coresight: ctcu: fix the spin_bug https://git.kernel.org/coresight/c/36ffbbc2b387 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

4 months, 1 week

[PATCH 0/8] coresight: cti: Miscellaneous fixes and CPU PM cleanup

by Leo Yan

The CPU power management issue in the CTI driver was first observed in series [1]; this series resolves that issue. It fixes bugs and removes CPU PM operations from the CoreSight CTI driver, the goal is to use the CoreSight core layer as the central place for CPU power management. Removing CPU PM from CTI driver can avoid conflicts with the core layer. Based on review of the Arm ARM, ASICCTL is the only CTI register that could potentially reside in the CPU power domain. However, this is considered highly unlikely for the following reasons: - Standard Arm CTIs place the ASICCTL register in the debug power domain; - ASICCTL is implemented only when CTIDEVID.EXTMUXNUM is non-zero, which is rare for CPU CTIs. As a result, it is safe to remove the CPU PM code as done in this series. In addition, avoiding support local CPU access (via SMP calls) to ASICCTL significantly reduces driver complexity. If a future hardware implements ASICCTL in the CPU power domain, we can consider adding a property to describe that characteristic. That said, from a software point of view, keeping all CTI registers in the same power domain is preferable, as it makes the driver implementation much simpler. This series can be divided into: Patches 01 ~ 02: Fix spinlock with irqsave and register read with CS lock. Patches 03 ~ 08: Access ASICCTL condintioanlly, remove CPU PM code, and refactor register access in sysfs knob. This series is based on coresight-next branch and has been validated on Juno r1 and r2 platforms, pass normal sysfs and perf test, as well as CPU PM stress testing. [1] https://lore.kernel.org/all/20250915-arm_coresight_power_management_fix-v3-… Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- Leo Yan (8): coresight: cti: Make spinlock usage consistent coresight: cti: Fix register reads coresight: cti: Access ASICCTL only when implemented coresight: cti: Remove CPU power management code coresight: cti: Rename cti_active() to cti_is_active() coresight: cti: Remove hw_powered flag coresight: cti: Remove hw_enabled flag coresight: cti: Refactor cti_reg32_{show|store}() drivers/hwtracing/coresight/coresight-cti-core.c | 278 ++++------------------ drivers/hwtracing/coresight/coresight-cti-sysfs.c | 168 ++++++------- drivers/hwtracing/coresight/coresight-cti.h | 13 +- 3 files changed, 134 insertions(+), 325 deletions(-) --- base-commit: eebe8dbd8630f51cf70b1f68a440cd3d7f7a914d change-id: 20251223-arm_coresight_cti_refactor_v1-76e1bda8b716 Best regards, -- Leo Yan <leo.yan(a)arm.com>

4 months, 1 week

[PATCH v4 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. --- Changes in v4: - Applied James' review tags on patches 01-07. - Kept the "registered" flag to use central place for mutex release (James / Suzuki). - Link to v3: https://lore.kernel.org/r/20260202-arm_coresight_refactor_dev_register-v3-0… 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 bus unregistration via coresight_unregister() drivers/hwtracing/coresight/coresight-catu.c | 4 +- drivers/hwtracing/coresight/coresight-core.c | 214 +++++++++++++-------- 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, 167 insertions(+), 153 deletions(-) --- base-commit: eebe8dbd8630f51cf70b1f68a440cd3d7f7a914d change-id: 20260120-arm_coresight_refactor_dev_register-f16c069db41d Best regards, -- Leo Yan <leo.yan(a)arm.com>

4 months, 1 week

[PATCH] coresight: cti: Move resource release to cti_remove()

by Leo Yan

Currently, CTI driver releases resource by deferring cti_device_release() to the device unregistration: cti_remove() `> coresight_unregister() `> cti_remove_assoc_from_csdev() `> device_unregister() `> cti_device_release() `> mutex_lock(&ect_mutex) `> release CTI resource `> mutex_unlock(&ect_mutex) In the above flow, two different CTI release callbacks are involved: cti_remove_assoc_from_csdev() and cti_device_release(). The former is used by a CoreSight device to unbind its associated CTI helper device, while the latter releases resources for the CTI device itself. Since there is no dependency between them, it is unnecessary to defer the CTI resource release until device unregistration. This commit releases the resources directly in cti_remove() and remove the injected release callback. Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- drivers/hwtracing/coresight/coresight-cti-core.c | 24 +++--------------------- drivers/hwtracing/coresight/coresight-cti.h | 2 -- 2 files changed, 3 insertions(+), 23 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c index bfbc365bb2ef2744efab11c056b8450472957005..7a8f1ef6b94e8ab3363ea62db95b0bc302292cd7 100644 --- a/drivers/hwtracing/coresight/coresight-cti-core.c +++ b/drivers/hwtracing/coresight/coresight-cti-core.c @@ -823,16 +823,13 @@ static const struct coresight_ops cti_ops = { .helper_ops = &cti_ops_ect, }; -/* - * Free up CTI specific resources - * called by dev->release, need to call down to underlying csdev release. - */ -static void cti_device_release(struct device *dev) +static void cti_remove(struct amba_device *adev) { - struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent); + struct cti_drvdata *drvdata = dev_get_drvdata(&adev->dev); struct cti_drvdata *ect_item, *ect_tmp; mutex_lock(&ect_mutex); + cti_remove_conn_xrefs(drvdata); cti_pm_release(drvdata); /* remove from the list */ @@ -844,17 +841,6 @@ static void cti_device_release(struct device *dev) } mutex_unlock(&ect_mutex); - if (drvdata->csdev_release) - drvdata->csdev_release(dev); -} -static void cti_remove(struct amba_device *adev) -{ - struct cti_drvdata *drvdata = dev_get_drvdata(&adev->dev); - - mutex_lock(&ect_mutex); - cti_remove_conn_xrefs(drvdata); - mutex_unlock(&ect_mutex); - coresight_unregister(drvdata->csdev); } @@ -947,10 +933,6 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id) cti_update_conn_xrefs(drvdata); mutex_unlock(&ect_mutex); - /* set up release chain */ - drvdata->csdev_release = drvdata->csdev->dev.release; - drvdata->csdev->dev.release = cti_device_release; - /* all done - dec pm refcount */ pm_runtime_put(&adev->dev); dev_info(&drvdata->csdev->dev, "CTI initialized\n"); diff --git a/drivers/hwtracing/coresight/coresight-cti.h b/drivers/hwtracing/coresight/coresight-cti.h index 4f89091ee93f5fb046d93b97a4085051fca6b39d..daff9e32a6daca90f4d5f4726f163fdd9106191c 100644 --- a/drivers/hwtracing/coresight/coresight-cti.h +++ b/drivers/hwtracing/coresight/coresight-cti.h @@ -170,7 +170,6 @@ struct cti_config { * @spinlock: Control data access to one at a time. * @config: Configuration data for this CTI device. * @node: List entry of this device in the list of CTI devices. - * @csdev_release: release function for underlying coresight_device. */ struct cti_drvdata { void __iomem *base; @@ -179,7 +178,6 @@ struct cti_drvdata { raw_spinlock_t spinlock; struct cti_config config; struct list_head node; - void (*csdev_release)(struct device *dev); }; /* --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260224-arm_coresight_refactor_cti_resource_release-24d9bde4f13c Best regards, -- Leo Yan <leo.yan(a)arm.com>

4 months, 1 week

Re: [PATCH] coresight: ctcu: fix the spin_bug

by James Clark

On 19/02/2026 2:46 pm, Jie Gan wrote: > Acquiring an uninitialized raw_spin_lock is invalid and may trigger > unexpected behavior or spin_bug. > > Fixes: f78d206f3d73 ("Coresight: Add Coresight TMC Control Unit driver") > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > --- > drivers/hwtracing/coresight/coresight-ctcu-core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hwtracing/coresight/coresight-ctcu-core.c b/drivers/hwtracing/coresight/coresight-ctcu-core.c > index abed15eb72b4..a505b90c09e3 100644 > --- a/drivers/hwtracing/coresight/coresight-ctcu-core.c > +++ b/drivers/hwtracing/coresight/coresight-ctcu-core.c > @@ -228,6 +228,7 @@ static int ctcu_probe(struct platform_device *pdev) > desc.dev = dev; > desc.ops = &ctcu_ops; > desc.access = CSDEV_ACCESS_IOMEM(base); > + raw_spin_lock_init(&drvdata->spin_lock); > > drvdata->csdev = coresight_register(&desc); > if (IS_ERR(drvdata->csdev)) > > --- > base-commit: 44982d352c33767cd8d19f8044e7e1161a587ff7 > change-id: 20260219-fix-spin-lock-issue-c563c32c5441 > > Best regards, Reviewed-by: James Clark <james.clark(a)linaro.org> I checked the other ones and they're all initialized, this was the only missing one.

4 months, 2 weeks

OpenCSD - release version 1.8.0

by Mike Leach

OpenCSD has been released at version 1.8.0 This includes:- - Support for FEAT_S!PE01. - Support for additional Arm V8M class instructions. - Support for windows build with ARM64 tools. - Build fixes for later CLANG versions. - Other minor build updates & fixes. Regards Mike

4 months, 3 weeks

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

4 months, 3 weeks

[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

5 months

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

5 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight