CoreSight

coresight@lists.linaro.org

4 participants
2810 discussions

Re: [PATCH v2] coresight: dummy: add missing MODULE_DEVICE_TABLE()

by Leo Yan

On Mon, Jul 20, 2026 at 07:45:14PM +0800, Pengpeng Hou wrote: > The CoreSight dummy driver has an OF match table wired into its platform > driver, but does not export the table to module metadata. A modular build > therefore lacks OF aliases for automatic loading. > > Export dummy_match with MODULE_DEVICE_TABLE(). > > Fixes: 9d3ba0b6c056 ("Coresight: Add coresight dummy driver") > Reviewed-by: Jie Gan <jie.gan(a)oss.qualcomm.com> > Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn> Reviewed-by: Leo Yan <leo.yan(a)arm.com> > --- > Changes since v1: https://lore.kernel.org/all/20260704121621.48544-1-pengpeng@iscas.ac.cn/ > - add the requested Fixes tag > - carry Jie Gan's conditional Reviewed-by after making that change > - rebase onto v7.2-rc4 > > drivers/hwtracing/coresight/coresight-dummy.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hwtracing/coresight/coresight-dummy.c b/drivers/hwtracing/coresight/coresight-dummy.c > index c176a2f57300..04880d38feb7 100644 > --- a/drivers/hwtracing/coresight/coresight-dummy.c > +++ b/drivers/hwtracing/coresight/coresight-dummy.c > @@ -212,6 +212,7 @@ static const struct of_device_id dummy_match[] = { > {.compatible = "arm,coresight-dummy-sink"}, > {}, > }; > +MODULE_DEVICE_TABLE(of, dummy_match); > > static struct platform_driver dummy_driver = { > .probe = dummy_probe, >

2 weeks, 4 days

Re: [PATCH v3] coresight: Fix scheduling while atomic in coresight_cpu_pm_notify()

by Leo Yan

On Fri, Jul 17, 2026 at 12:41:54AM +0300, Mohamed Ayman wrote: [...] > static struct coresight_path *coresight_cpu_get_active_path(enum cs_mode mode) > { > struct coresight_device *source; > - bool is_active = false; > + struct coresight_path *path = NULL; > > - source = coresight_get_percpu_source_ref(smp_processor_id()); > - if (!source) > - return NULL; > - > - if (coresight_get_mode(source) & mode) > - is_active = true; > + guard(raw_spinlock_irqsave)(&coresight_dev_lock); > > - coresight_put_percpu_source_ref(source); > + source = per_cpu(csdev_source, smp_processor_id()); > + if (source && (coresight_get_mode(source) & mode)) > + path = source->path; I agree the get_device()/put_device() pair in coresight_cpu_get_active_path() is not a good fit for CPU PM notifier, because the put_device() can become the final put while IRQ is disabled. However, my understanding is this patch might cause UAF issue that the existing code is intended to prevent. The raw spinlock (coresight_dev_lock) serializes access to the per-CPU csdev_source pointer. It does not guarantee the lifetime of the source or its _parent_ device. coresight_unregister() is not only reached from module unload; it can also be called when a driver is unbind, for example DT overlay removal or device hotplug/unplug. This is why the UAF issue Sashiko mentioned in patch 03 of [1]. A built CoreSight path currently grabs references for the path components, which keeps module alive, but that is not the same as preventing the parent device/driver from being unbound and tearing down CoreSight device data while an active session still has raw pointers. There are also similar race window before the path is built: for example etm_setup_aux() has to look up source/sink state before coresight_build_path() establishes the path, so it might access released source/sink data if device is unbound. I think a proper fix needs a clearer lifetime model for an active session. E.g., we could consider to call device_link_add() to prevent device unbind / unregister, and unlink device when the session is finished. Once that is in place, the CPU PM notifier can safely use the active path without get_device()/put_device() pair anymore. Hope this is clear and makes sense. Thanks, Leo [1] https://sashiko.dev/#/patchset/20260405-arm_coresight_path_power_management…

3 weeks

Re: [PATCH v3] coresight: Fix scheduling while atomic in coresight_cpu_pm_notify()

by Leo Yan

Hi Mohamed & Sebastian, On Fri, Jul 17, 2026 at 10:14:53AM +0200, Sebastian Andrzej Siewior wrote: [...] > There is coresight_put_percpu_source_ref() with holds coresight_dev_lock > during a put_cpu. I don't know why the lock is held, it is not obvious > to me. But it will lead to a similar problem if the put actually invokes > the release callback. Sorry I am a bit late to join the discussion. Essentially, this is about how to manage a module's lifetime correctly so that the CPU PM notifier can safely access a device. There is an edge case where the CPU PM notifier is accessing the device while, at the same time, the module is being unloaded and the device's resources are being released. For now, I'd suggest please hold on this patch. Give me a bit time to study this thread, I will share back more details. Thanks, Leo

3 weeks

Re: [PATCH v2 00/12] coresight: Add CPU cluster funnel/replicator/tmc support

by Yuanfang Zhang

Hi Sudeep & Suzuki, Gentle reminder on this patch. Any feedback would be appreciated. Thanks, Yuanfang. On 5/25/2026 9:17 PM, Maulik Shah (mkshah) wrote: > > > On 12/19/2025 3:51 PM, Sudeep Holla wrote: >> On Fri, Dec 19, 2025 at 10:13:14AM +0800, yuanfang zhang wrote: >>> >>> >>> On 12/18/2025 7:33 PM, Sudeep Holla wrote: >>>> On Thu, Dec 18, 2025 at 12:09:40AM -0800, Yuanfang Zhang wrote: >>>>> This patch series adds support for CoreSight components local to CPU clusters, >>>>> including funnel, replicator, and TMC, which reside within CPU cluster power >>>>> domains. These components require special handling due to power domain >>>>> constraints. >>>>> >>>> >>>> Could you clarify why PSCI-based power domains associated with clusters in >>>> domain-idle-states cannot address these requirements, given that PSCI CPU-idle >>>> OSI mode was originally intended to support them? My understanding of this >>>> patch series is that OSI mode is unable to do so, which, if accurate, appears >>>> to be a flaw that should be corrected. >>> >>> It is due to the particular characteristics of the CPU cluster power >>> domain.Runtime PM for CPU devices works little different, it is mostly used >>> to manage hierarchicalCPU topology (PSCI OSI mode) to talk with genpd >>> framework to manage the last CPU handling in cluster. >> >> That is indeed the intended design. Could you clarify which specific >> characteristics differentiate it here? > > Sorry for coming very late on this. > > This series is intended to handle coresight components which resides within CPU cluster. > For the cases where cluster is in deepest idle low power mode or all CPUs belonging to cluster > are hotplugged off, access to coresight components can not be done. > > The implementation tried to address in two parts, > 1. Using cluster power-domain to know which coresight component belongs to which cluster/CPUs > 2. Schedule the task on intended cluster's CPU to make sure the CPU (and cluster) power is > ON while coresight component of the cluster is being accessed (using smp_call_function_single()). > > The use of power-domains in (1) will limit this to PSCI OS-Initiated mode, > to have this support on PSCI Platform-Coordinated mode too, probably instead of power-domains, > cpu-maps (which also defines the clusters) from device tree is a better choice which will give > the information on which CPU belongs to which cluster. > > (2) ensured that scheduling happened on intended CPU and while the access is in progress, CPU (and > cluster) will not enter power down in between. > >> >>> It doesn’t really send IPI to wakeup CPU device (It don’t have >>> .power_on/.power_off) callback implemented which gets invoked from >>> .runtime_resume callback. This behavior is aligned with the upstream Kernel. >>> >> >> I am quite lost here. Why is it necessary to wake up the CPU? If I understand >> correctly, all of this complexity is meant to ensure that the cluster power >> domain is enabled before any of the funnel registers are accessed. Is that >> correct? > > Yes, This is to ensure that CPU (and cluster) power is ON while coresight components > for same cluster are being accessed. > >> >> If so, and if the cluster domains are already defined as the power domains for >> these funnel devices, then they should be requested to power on automatically >> before any register access occurs. Is that not the case? > > Cluster power-domains will be only available for PSCI OS-initiated mode but also > will not help for cases where all CPUs in cluster are hotplugged off as hotplugs are > platform coordinated. > > After discussion with our HW team to automatically request power on for coresight > component GPR [1] can be used but they seems not working as intended on the existing > SoCs and will be available on next generation SoC. > > [1] https://developer.arm.com/documentation/ddi0480/d/Functional-Overview/Granu… > >> >> What am I missing in this reasoning? >> >> The only explanation I can see is that the firmware does not properly honor >> power-domain requests coming directly from the OS. I believe that may be the >> case, but I would be glad to be proven wrong. >> > > please see below comment for more details, This seems not a firmware issue. > >>>> >>>>> Unlike system-level CoreSight devices, these components share the CPU cluster's >>>>> power domain. When the cluster enters low-power mode (LPM), their registers >>>>> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster >>>>> out of LPM, making standard register access unreliable. >>>>> >>>> >>>> Are these devices the only ones on the system that are uniquely bound to >>>> cluster-level power domains? If not, what additional devices share this >>>> dependency so that we can understand how they are managed in comparison? >>>> >>> >>> Yes, devices like ETM and TRBE also share this power domain and access constraint. >>> Their drivers naturally handle enablement/disablement on the specific CPU they >>> belong to (e.g., via hotplug callbacks or existing smp_call_function paths). >> >> I understand many things are possible to implement, but the key question >> remains: why doesn’t the existing OSI mechanism - added specifically to cover >> cases like this solve the problem today? >> >> Especially on platforms with OSI enabled, what concrete limitation forces us >> into this additional “wake-up” path instead of relying on OSI to manage the >> dependency/power sequencing? > > + Ulf in loop. > > Current platforms with OSI enabled, Linux PSCI do not implement the power_on/power_off > requests, as far as i know, runtime PM was never meant to implement this part and > pm_runtime_get_sync() (from drivers/cpuidle/cpuidle-psci.c) call is only used to convey > to cluster power domains about a child CPU/ sub domain being on after it has already > been landed in Linux. > > The standalone invoke of pm_runtime_get_sync() from another CPU do not really turn on/get > the CPU (and cluster), as the CPUs either use CPUidle / CPU hotplug paths to enter/exit > low power mode. > > To put it other way, > For a hot-plugged off CPU, invoking a pm_runtime_get_sync() won't get the CPU (and make > its cluster power domain) ON. In order to turn on the CPU, one has to still request > the online of the CPU, say via sysfs command echo 1 > /sys/devices/system/cpu/cpuX/online > which would invoke PSCI CPU_ON function and the power domain for CPU gets marked as ON > only after CPU already landed in Linux via psci_idle_cpuhp_up() invoking pm_runtime_get_sync(). > > I used specific hotplug example but same applies to idle powered down CPU (or Cluster) too. > >> >>>>> To address this, the series introduces: >>>>> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components` >>>>> device tree property. >>>> >>>> Really, no please. >>>> >>> >>> Our objective is to determine which CoreSight components are physically locate >>> within the CPU cluster power domain. >>> >>> Would it be acceptable to derive this relationship from the existing >>> power-domains binding? >> >> In my opinion, this is not merely a possibility but an explicit expectation. >> >>> For example, if a Funnel or Replicator node is linked to a power-domains >>> entry that specifies a cpumask, the driver could recognize this shared >>> dependency and automatically apply the appropriate cluster-aware behavior. >>> >> >> Sure, but for the driver to use that information, we need clear explanation >> for all the questions above. In short, why it is not working with the existing >> PSCI domain idle support. >> > > Explained above. > > Thanks, > Maulik

3 weeks

[PATCH 0/2] perf cs-etm: Fix bogus branch samples

by Leo Yan

This series fixes the bogus branch samples in the CoreSight ETM trace. When an interrupt occurs immediately after an untaken branch, the decoder incorrectly synthesizes a branch sample for that branch. The first patch fixes this issue. The second patch consolidate the branch check so make sure the flush flow to apply the same check to avoid generate bogus samples. The series has been verified on Orion6 board. Signed-off-by: Leo Yan <leo.yan(a)arm.com> --- Leo Yan (2): perf cs-etm: Avoid bogus branch samples before async exceptions perf cs-etm: Centralize branch sample checks tools/perf/util/cs-etm.c | 44 ++++++++++++++++++++------------------------ 1 file changed, 20 insertions(+), 24 deletions(-) --- base-commit: ef3af1df4f3372bd8ad47619452a283048b3bc8d change-id: 20260713-perf_cs_etm_fix_non_taken-5b4d7f73f41e Best regards, -- Leo Yan <leo.yan(a)arm.com>

3 weeks, 4 days

Re: [PATCH v6 2/5] coresight: tnoc: Bind Aggregator TNOC on the platform bus

by Leo Yan

On Fri, Jul 10, 2026 at 10:39:01AM +0800, Jie Gan wrote: [...] > The ATID-unsupported handling keyed off dev_is_amba(), which disabled ATID > allocation for every platform-bus device. With the Aggregator TNOC now on > the platform bus, that check would wrongly disable its ATID, even though > the Aggregator TNOC owns the ATID that tags the whole aggregation path. > The Interconnect TNOC aggregates trace within its subsystem but carries no > ATID of its own, because the downstream Aggregator TNOC already owns the > ATID for the path. So base the check on the "qcom,coresight-itnoc" > compatible and let every other form allocate a trace ID. > > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> Reviewed-by: Leo Yan <leo.yan(a)arm.com>

4 weeks

Re: [PATCH v2 2/2] coresight: tnoc: Fix clock refcount imbalance on platform remove

by Leo Yan

On Thu, Jul 02, 2026 at 04:54:20PM +0800, Jie Gan wrote: [...] > Resume the device with pm_runtime_get_sync() before tearing it down so > the clock is enabled again and balances the devm-managed disable. Then > pm_runtime_set_suspended() and pm_runtime_put_noidle() leave the device > in a coherent runtime PM state (suspended, usage count balanced) once > the devm action has disabled the clock. > > Fixes: 1abc1b212eff ("coresight: Appropriately disable programming clocks") > Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com> Reviewed-by: Leo Yan <leo.yan(a)arm.com>

4 weeks, 1 day

[PATCH v2 0/4] coresight: Prevent per-thread events from sharing a sink

by James Clark

Concurrent per-thread events results in a WARN on N1SDP which leads to the realization that per-thread events shouldn't have been sharing sinks in the first place. This slips through because different events will have the same PID if owned by the same process, and we only check the PID and nothing else. That results in unexpected WARNs because it looks like we assumed it couldn't happen (although exclusive PMU rules allow it). But even if it was supported it would result in trace from the wrong thread in another event's per-thread buffer, so we should disallow it. Fix it everywhere the same PID checking logic was copy pasted. Then the PIDs can be dropped from a few structs as they are now unused. Signed-off-by: James Clark <james.clark(a)linaro.org> --- Changes in v2: - Fix inherited events by following event->parent - Link to v1: https://lore.kernel.org/r/20260709-james-cs-multiple-per-threads-v1-0-d384e… --- James Clark (4): coresight: tmc-etr: Prevent per-thread events from sharing a sink coresight: tmc-etf: Prevent per-thread events from sharing a sink coresight: etb10: Prevent per-thread events from sharing a sink coresight: ultrasoc-smb: Prevent per-thread events from sharing a sink drivers/hwtracing/coresight/coresight-core.c | 31 ++++++++++++++++++++++++ drivers/hwtracing/coresight/coresight-etb10.c | 30 ++++++----------------- drivers/hwtracing/coresight/coresight-priv.h | 2 -- drivers/hwtracing/coresight/coresight-tmc-core.c | 2 -- drivers/hwtracing/coresight/coresight-tmc-etf.c | 23 ++++++------------ drivers/hwtracing/coresight/coresight-tmc-etr.c | 20 +++++---------- drivers/hwtracing/coresight/coresight-tmc.h | 2 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 22 +++++------------ drivers/hwtracing/coresight/ultrasoc-smb.h | 5 ++-- include/linux/coresight.h | 3 +++ 10 files changed, 64 insertions(+), 76 deletions(-) --- base-commit: 98495b5a4d77dd22e106f462b76e1093a55b29a7 change-id: 20260708-james-cs-multiple-per-threads-ed1d25ed1734 Best regards, -- James Clark <james.clark(a)linaro.org>

4 weeks, 1 day

Re: [PATCH v2 1/2] coresight: Fix clock refcount imbalance on platform remove

by Leo Yan

On Thu, Jul 02, 2026 at 04:54:19PM +0800, Jie Gan wrote: [...] > static void etm4_remove_platform_dev(struct platform_device *pdev) > { > struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev); > > if (drvdata) > etm4_remove_dev(drvdata); I understood this is not an issue caused by this patch, could you refine a bit as blow so can be consistent: if (WARN_ON(!drvdata)) return; > + /* > + * Resume the device so its clocks are enabled again, balancing the > + * clk_disable_unprepare() that devm runs when the driver detaches. > + * Then mark it suspended and drop the usage count taken here. > + */ > + pm_runtime_get_sync(&pdev->dev); etm4_remove_dev(drvdata); > pm_runtime_disable(&pdev->dev); > + pm_runtime_set_suspended(&pdev->dev); > + pm_runtime_put_noidle(&pdev->dev); > } With above change: Reviewed-by: Leo Yan <leo.yan(a)arm.com>

4 weeks, 1 day

[PATCH 0/4] coresight: Prevent per-thread events from sharing a sink

by James Clark

Concurrent per-thread events results in a WARN on N1SDP which leads to the realization that per-thread events shouldn't have been sharing sinks in the first place. This slips through because different events will have the same PID if owned by the same process, and we only check the PID and nothing else. That results in unexpected WARNs because it looks like we assumed it couldn't happen (although exclusive PMU rules allow it). But even if it was supported it would result in trace from the wrong thread in another event's per-thread buffer, so we should disallow it. Fix it everywhere the same PID checking logic was copy pasted. Then the PIDs can be dropped from a few structs as they are now unused. Signed-off-by: James Clark <james.clark(a)linaro.org> --- James Clark (4): coresight: tmc-etr: Prevent per-thread events from sharing a sink coresight: tmc-etf: Prevent per-thread events from sharing a sink coresight: etb10: Prevent per-thread events from sharing a sink coresight: ultrasoc-smb: Prevent per-thread events from sharing a sink drivers/hwtracing/coresight/coresight-core.c | 24 +++++++++++++++++++ drivers/hwtracing/coresight/coresight-etb10.c | 30 +++++++----------------- drivers/hwtracing/coresight/coresight-priv.h | 2 -- drivers/hwtracing/coresight/coresight-tmc-core.c | 2 -- drivers/hwtracing/coresight/coresight-tmc-etf.c | 23 ++++++------------ drivers/hwtracing/coresight/coresight-tmc-etr.c | 20 +++++----------- drivers/hwtracing/coresight/coresight-tmc.h | 2 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 22 +++++------------ drivers/hwtracing/coresight/ultrasoc-smb.h | 5 ++-- include/linux/coresight.h | 3 +++ 10 files changed, 57 insertions(+), 76 deletions(-) --- base-commit: 98495b5a4d77dd22e106f462b76e1093a55b29a7 change-id: 20260708-james-cs-multiple-per-threads-ed1d25ed1734 Best regards, -- James Clark <james.clark(a)linaro.org>

4 weeks, 1 day

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight