CoreSight

coresight@lists.linaro.org

2 participants
2604 discussions

Re: [PATCH v2] perf: Allocate non-contiguous AUX pages by default

by James Clark

On 29/04/2025 10:31 pm, Yabin Cui wrote: > perf always allocates contiguous AUX pages based on aux_watermark. > However, this contiguous allocation doesn't benefit all PMUs. For > instance, ARM SPE and TRBE operate with virtual pages, and Coresight > ETR allocates a separate buffer. For these PMUs, allocating contiguous > AUX pages unnecessarily exacerbates memory fragmentation. This > fragmentation can prevent their use on long-running devices. > > This patch modifies the perf driver to allocate non-contiguous AUX > pages by default. For PMUs that can benefit from contiguous pages ( > Intel PT and BTS), a new PMU capability, PERF_PMU_CAP_AUX_PREFER_LARGE > is introduced to maintain their existing behavior. > > Signed-off-by: Yabin Cui <yabinc(a)google.com> > --- > Changes since v1: > In v1, default is preferring contiguous pages, and add a flag to > allocate non-contiguous pages. In v2, default is allocating > non-contiguous pages, and add a flag to prefer contiguous pages. > > v1 patchset: > perf,coresight: Reduce fragmentation with non-contiguous AUX pages for > cs_etm > > arch/x86/events/intel/bts.c | 3 ++- > arch/x86/events/intel/pt.c | 3 ++- > include/linux/perf_event.h | 1 + > kernel/events/ring_buffer.c | 18 +++++++++++------- > 4 files changed, 16 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c > index a95e6c91c4d7..9129f00e4b9f 100644 > --- a/arch/x86/events/intel/bts.c > +++ b/arch/x86/events/intel/bts.c > @@ -625,7 +625,8 @@ static __init int bts_init(void) > return -ENOMEM; > > bts_pmu.capabilities = PERF_PMU_CAP_AUX_NO_SG | PERF_PMU_CAP_ITRACE | > - PERF_PMU_CAP_EXCLUSIVE; > + PERF_PMU_CAP_EXCLUSIVE | > + PERF_PMU_CAP_AUX_PREFER_LARGE; > bts_pmu.task_ctx_nr = perf_sw_context; > bts_pmu.event_init = bts_event_init; > bts_pmu.add = bts_event_add; > diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c > index fa37565f6418..37179e813b8c 100644 > --- a/arch/x86/events/intel/pt.c > +++ b/arch/x86/events/intel/pt.c > @@ -1866,7 +1866,8 @@ static __init int pt_init(void) > > pt_pmu.pmu.capabilities |= PERF_PMU_CAP_EXCLUSIVE | > PERF_PMU_CAP_ITRACE | > - PERF_PMU_CAP_AUX_PAUSE; > + PERF_PMU_CAP_AUX_PAUSE | > + PERF_PMU_CAP_AUX_PREFER_LARGE; > pt_pmu.pmu.attr_groups = pt_attr_groups; > pt_pmu.pmu.task_ctx_nr = perf_sw_context; > pt_pmu.pmu.event_init = pt_event_init; > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > index 0069ba6866a4..56d77348c511 100644 > --- a/include/linux/perf_event.h > +++ b/include/linux/perf_event.h > @@ -301,6 +301,7 @@ struct perf_event_pmu_context; > #define PERF_PMU_CAP_AUX_OUTPUT 0x0080 > #define PERF_PMU_CAP_EXTENDED_HW_TYPE 0x0100 > #define PERF_PMU_CAP_AUX_PAUSE 0x0200 > +#define PERF_PMU_CAP_AUX_PREFER_LARGE 0x0400 > > /** > * pmu::scope > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c > index 5130b119d0ae..d76249ce4f17 100644 > --- a/kernel/events/ring_buffer.c > +++ b/kernel/events/ring_buffer.c > @@ -679,7 +679,7 @@ int rb_alloc_aux(struct perf_buffer *rb, struct perf_event *event, > { > bool overwrite = !(flags & RING_BUFFER_WRITABLE); > int node = (event->cpu == -1) ? -1 : cpu_to_node(event->cpu); > - int ret = -ENOMEM, max_order; > + int ret = -ENOMEM, max_order = 0; > > if (!has_aux(event)) > return -EOPNOTSUPP; > @@ -689,8 +689,8 @@ int rb_alloc_aux(struct perf_buffer *rb, struct perf_event *event, > > if (!overwrite) { > /* > - * Watermark defaults to half the buffer, and so does the > - * max_order, to aid PMU drivers in double buffering. > + * Watermark defaults to half the buffer, to aid PMU drivers > + * in double buffering. > */ > if (!watermark) > watermark = min_t(unsigned long, > @@ -698,16 +698,20 @@ int rb_alloc_aux(struct perf_buffer *rb, struct perf_event *event, > (unsigned long)nr_pages << (PAGE_SHIFT - 1)); > > /* > - * Use aux_watermark as the basis for chunking to > + * For PMUs that prefer large contiguous buffers, > + * use aux_watermark as the basis for chunking to > * help PMU drivers honor the watermark. > */ > - max_order = get_order(watermark); > + if (event->pmu->capabilities & PERF_PMU_CAP_AUX_PREFER_LARGE) > + max_order = get_order(watermark); > } else { > /* > - * We need to start with the max_order that fits in nr_pages, > + * For PMUs that prefer large contiguous buffers, > + * we need to start with the max_order that fits in nr_pages, > * not the other way around, hence ilog2() and not get_order. > */ > - max_order = ilog2(nr_pages); > + if (event->pmu->capabilities & PERF_PMU_CAP_AUX_PREFER_LARGE) > + max_order = ilog2(nr_pages); Doesn't this one need to be 'PERF_PMU_CAP_AUX_PREFER_LARGE | PERF_PMU_CAP_AUX_NO_SG', otherwise the NO_SG test further down doesn't work for devices that only have NO_SG and not PREFER_LARGE. NO_SG implies PREFER_LARGE behavior, except that NO_SG additionally hard fails if it can't do it in one alloc. But I think you shouldn't have to set them both to get the correct behavior.

8 months, 2 weeks

[PATCH v4 0/7] coresight: Clear self hosted claim tag on probe

by James Clark

I've gotten stuck a few times with unusable Coresight after a warm boot due to lingering claim tags, especially when testing the Coresight panic patchsets. This change does some tidy ups, adds some debug messages and clears the self hosted claim tag on probe. The last two commits are unrelated tidyups but they touch some of the same functions so to avoid extra conflicts I'm including them here. This gets as far as fixing the claim tag issue, but there is some other state not being cleared on probe that results in the following error. This can be fixed up as a later change: coresight tmc_etf0: timeout while waiting for TMC to be Ready coresight tmc_etf0: Failed to enable : TMC is not ready Changes in v4: - Add _unlocked() suffix for consistency - s/cs_access/csdev_access/ - Link to v3: https://lore.kernel.org/r/20250320-james-coresight-claim-tags-v3-0-d3145c15… Changes in v3: - Collapse rename and locked/unlocked addition commits of coresight_clear_self_claim_tag() so we don't change the name twice. - Make coresight_clear_self_claim_tag() a bit more generic by only doing UNLOCK for MMIO devices (although there is no use of this right now) - Link to v2: https://lore.kernel.org/r/20250318-james-coresight-claim-tags-v2-0-e9c8a9cd… Changes in v2: * Revert most of the interface changes, just call coresight_clear_self_claim_tag() directly. This is possible because we're not doing the read first, so it has fewer knock on effects. * Split out the change to add struct cs_access to etm3x * Add another warning for racing with external debugger -- 2.34.1 --- James Clark (7): coresight: Convert tag clear function to take a struct csdev_access coresight: Only check bottom two claim bits coresight: Add claim tag warnings and debug messages coresight: etm3x: Convert raw base pointer to struct coresight access coresight: Clear self hosted claim tag on probe coresight: Remove inlines from static function definitions coresight: Remove extern from function declarations drivers/hwtracing/coresight/coresight-catu.c | 12 +-- drivers/hwtracing/coresight/coresight-core.c | 87 ++++++++++++++-------- drivers/hwtracing/coresight/coresight-cti-core.c | 2 + drivers/hwtracing/coresight/coresight-etb10.c | 4 +- drivers/hwtracing/coresight/coresight-etm.h | 6 +- drivers/hwtracing/coresight/coresight-etm3x-core.c | 28 +++---- .../hwtracing/coresight/coresight-etm3x-sysfs.c | 8 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++- .../hwtracing/coresight/coresight-etm4x-sysfs.c | 4 +- drivers/hwtracing/coresight/coresight-funnel.c | 1 + drivers/hwtracing/coresight/coresight-platform.c | 26 +++---- drivers/hwtracing/coresight/coresight-priv.h | 20 ++--- drivers/hwtracing/coresight/coresight-replicator.c | 3 +- drivers/hwtracing/coresight/coresight-stm.c | 6 +- .../coresight/coresight-syscfg-configfs.c | 2 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 9 ++- drivers/hwtracing/coresight/coresight-tmc-etr.c | 16 ++-- drivers/hwtracing/coresight/coresight-trbe.c | 18 ++--- include/linux/coresight.h | 40 +++++----- 19 files changed, 168 insertions(+), 134 deletions(-) --- base-commit: 5442d22da7dbff3ba8c6720fc6f23ea4934d402d change-id: 20250317-james-coresight-claim-tags-ae1461f1f5e0 Best regards, -- James Clark <james.clark(a)linaro.org>

8 months, 2 weeks

Re: [PATCH v5 0/2] coresight: catu: Introduce refcount and spinlock for enabling/disabling

by Suzuki K Poulose

On Tue, 29 Apr 2025 16:12:58 -0700, Yabin Cui wrote: > When tracing ETM data on multiple CPUs concurrently via the > perf interface, the CATU device is shared across different CPU > paths. This can lead to race conditions when multiple CPUs attempt > to enable or disable the CATU device simultaneously. This patchset > is to fix race conditions when enabling/disabling a CATU device. > > Changes since v4: > - Collect Review-by tags. > - return -EINVAL for unknown types in coresight_enable_path. > > [...] Applied, thanks! [1/2] coresight: catu: Introduce refcount and spinlock for enabling/disabling https://git.kernel.org/coresight/c/a03a0a08 [2/2] coresight: core: Disable helpers for devices that fail to enable https://git.kernel.org/coresight/c/f6028eee Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

8 months, 2 weeks

Re: [PATCH v5 2/2] coresight: core: Disable helpers for devices that fail to enable

by Suzuki K Poulose

On 30/04/2025 00:13, Yabin Cui wrote: > When enabling a SINK or LINK type coresight device fails, the > associated helpers should be disabled. > > Signed-off-by: Yabin Cui <yabinc(a)google.com> > Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> > Reviewed-by: James Clark <james.clark(a)linaro.org> > Reviewed-by: Mike Leach <mike.leach(a)linaro.org> Again, this should have : Fixes: 6148652807ba ("coresight: Enable and disable helper devices adjacent to the path") I have added it locally Rest looks good to me Suzuki > --- > drivers/hwtracing/coresight/coresight-core.c | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index dabec7073aed..d3523f0262af 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -465,7 +465,7 @@ int coresight_enable_path(struct coresight_path *path, enum cs_mode mode, > /* Enable all helpers adjacent to the path first */ > ret = coresight_enable_helpers(csdev, mode, path); > if (ret) > - goto err; > + goto err_disable_path; > /* > * ETF devices are tricky... They can be a link or a sink, > * depending on how they are configured. If an ETF has been > @@ -486,8 +486,10 @@ int coresight_enable_path(struct coresight_path *path, enum cs_mode mode, > * that need disabling. Disabling the path here > * would mean we could disrupt an existing session. > */ > - if (ret) > + if (ret) { > + coresight_disable_helpers(csdev, path); > goto out; > + } > break; > case CORESIGHT_DEV_TYPE_SOURCE: > /* sources are enabled from either sysFS or Perf */ > @@ -497,16 +499,19 @@ int coresight_enable_path(struct coresight_path *path, enum cs_mode mode, > child = list_next_entry(nd, link)->csdev; > ret = coresight_enable_link(csdev, parent, child, source); > if (ret) > - goto err; > + goto err_disable_helpers; > break; > default: > - goto err; > + ret = -EINVAL; > + goto err_disable_helpers; > } > } > > out: > return ret; > -err: > +err_disable_helpers: > + coresight_disable_helpers(csdev, path); > +err_disable_path: > coresight_disable_path_from(path, nd); > goto out; > }

8 months, 2 weeks

Re: [PATCH v5 1/2] coresight: catu: Introduce refcount and spinlock for enabling/disabling

by Suzuki K Poulose

On 30/04/2025 00:12, Yabin Cui wrote: > When tracing ETM data on multiple CPUs concurrently via the > perf interface, the CATU device is shared across different CPU > paths. This can lead to race conditions when multiple CPUs attempt > to enable or disable the CATU device simultaneously. > > To address these race conditions, this patch introduces the > following changes: > > 1. The enable and disable operations for the CATU device are not > reentrant. Therefore, a spinlock is added to ensure that only > one CPU can enable or disable a given CATU device at any point > in time. > > 2. A reference counter is used to manage the enable/disable state > of the CATU device. The device is enabled when the first CPU > requires it and is only disabled when the last CPU finishes > using it. This ensures the device remains active as long as at > least one CPU needs it. > > Signed-off-by: Yabin Cui <yabinc(a)google.com> > Reviewed-by: James Clark <james.clark(a)linaro.org> > Reviewed-by: Leo Yan <leo.yan(a)arm.com> Looks good to me, I will add : Fixes: fcacb5c154ba ("coresight: Introduce support for Coresight Address Translation Unit") Suzuki > --- > drivers/hwtracing/coresight/coresight-catu.c | 25 +++++++++++++------- > drivers/hwtracing/coresight/coresight-catu.h | 1 + > 2 files changed, 18 insertions(+), 8 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c > index 96cb48b140af..d4e2e175e077 100644 > --- a/drivers/hwtracing/coresight/coresight-catu.c > +++ b/drivers/hwtracing/coresight/coresight-catu.c > @@ -458,12 +458,17 @@ static int catu_enable_hw(struct catu_drvdata *drvdata, enum cs_mode cs_mode, > static int catu_enable(struct coresight_device *csdev, enum cs_mode mode, > void *data) > { > - int rc; > + int rc = 0; > struct catu_drvdata *catu_drvdata = csdev_to_catu_drvdata(csdev); > > - CS_UNLOCK(catu_drvdata->base); > - rc = catu_enable_hw(catu_drvdata, mode, data); > - CS_LOCK(catu_drvdata->base); > + guard(raw_spinlock_irqsave)(&catu_drvdata->spinlock); > + if (csdev->refcnt == 0) { > + CS_UNLOCK(catu_drvdata->base); > + rc = catu_enable_hw(catu_drvdata, mode, data); > + CS_LOCK(catu_drvdata->base); > + } > + if (!rc) > + csdev->refcnt++; > return rc; > } > > @@ -486,12 +491,15 @@ static int catu_disable_hw(struct catu_drvdata *drvdata) > > static int catu_disable(struct coresight_device *csdev, void *__unused) > { > - int rc; > + int rc = 0; > struct catu_drvdata *catu_drvdata = csdev_to_catu_drvdata(csdev); > > - CS_UNLOCK(catu_drvdata->base); > - rc = catu_disable_hw(catu_drvdata); > - CS_LOCK(catu_drvdata->base); > + guard(raw_spinlock_irqsave)(&catu_drvdata->spinlock); > + if (--csdev->refcnt == 0) { > + CS_UNLOCK(catu_drvdata->base); > + rc = catu_disable_hw(catu_drvdata); > + CS_LOCK(catu_drvdata->base); > + } > return rc; > } > > @@ -550,6 +558,7 @@ static int __catu_probe(struct device *dev, struct resource *res) > dev->platform_data = pdata; > > drvdata->base = base; > + raw_spin_lock_init(&drvdata->spinlock); > catu_desc.access = CSDEV_ACCESS_IOMEM(base); > catu_desc.pdata = pdata; > catu_desc.dev = dev; > diff --git a/drivers/hwtracing/coresight/coresight-catu.h b/drivers/hwtracing/coresight/coresight-catu.h > index 141feac1c14b..755776cd19c5 100644 > --- a/drivers/hwtracing/coresight/coresight-catu.h > +++ b/drivers/hwtracing/coresight/coresight-catu.h > @@ -65,6 +65,7 @@ struct catu_drvdata { > void __iomem *base; > struct coresight_device *csdev; > int irq; > + raw_spinlock_t spinlock; > }; > > #define CATU_REG32(name, offset) \

8 months, 2 weeks

Re: [PATCH v5 2/2] coresight: core: Disable helpers for devices that fail to enable

by Leo Yan

On Tue, Apr 29, 2025 at 04:13:00PM -0700, Yabin Cui wrote: > When enabling a SINK or LINK type coresight device fails, the > associated helpers should be disabled. > > Signed-off-by: Yabin Cui <yabinc(a)google.com> > Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> > Reviewed-by: James Clark <james.clark(a)linaro.org> > Reviewed-by: Mike Leach <mike.leach(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)arm.com> > --- > drivers/hwtracing/coresight/coresight-core.c | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index dabec7073aed..d3523f0262af 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -465,7 +465,7 @@ int coresight_enable_path(struct coresight_path *path, enum cs_mode mode, > /* Enable all helpers adjacent to the path first */ > ret = coresight_enable_helpers(csdev, mode, path); > if (ret) > - goto err; > + goto err_disable_path; > /* > * ETF devices are tricky... They can be a link or a sink, > * depending on how they are configured. If an ETF has been > @@ -486,8 +486,10 @@ int coresight_enable_path(struct coresight_path *path, enum cs_mode mode, > * that need disabling. Disabling the path here > * would mean we could disrupt an existing session. > */ > - if (ret) > + if (ret) { > + coresight_disable_helpers(csdev, path); > goto out; > + } > break; > case CORESIGHT_DEV_TYPE_SOURCE: > /* sources are enabled from either sysFS or Perf */ > @@ -497,16 +499,19 @@ int coresight_enable_path(struct coresight_path *path, enum cs_mode mode, > child = list_next_entry(nd, link)->csdev; > ret = coresight_enable_link(csdev, parent, child, source); > if (ret) > - goto err; > + goto err_disable_helpers; > break; > default: > - goto err; > + ret = -EINVAL; > + goto err_disable_helpers; > } > } > > out: > return ret; > -err: > +err_disable_helpers: > + coresight_disable_helpers(csdev, path); > +err_disable_path: > coresight_disable_path_from(path, nd); > goto out; > } > -- > 2.49.0.967.g6a0df3ecc3-goog >

8 months, 2 weeks

[PATCH] coresight: Fixes device's owner field for registered using coresight_init_driver()

by Junhao He

The coresight_init_driver() of the coresight-core module is called from the sub coresgiht device (such as tmc/stm/funnle/...) module. It calls amba_driver_register() and Platform_driver_register(), which are macro functions that use the coresight-core's module to initialize the caller's owner field. Therefore, when the sub coresight device calls coresight_init_driver(), an incorrect THIS_MODULE value is captured. The sub coesgiht modules can be removed while their callbacks are running, resulting in a general protection failure. Add module parameter to coresight_init_driver() so can be called with the module of the callback. Fixes: 075b7cd7ad7d ("coresight: Add helpers registering/removing both AMBA and platform drivers") Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- drivers/hwtracing/coresight/coresight-catu.c | 2 +- drivers/hwtracing/coresight/coresight-core.c | 6 +++--- drivers/hwtracing/coresight/coresight-cpu-debug.c | 3 ++- drivers/hwtracing/coresight/coresight-funnel.c | 3 ++- drivers/hwtracing/coresight/coresight-replicator.c | 3 ++- drivers/hwtracing/coresight/coresight-stm.c | 2 +- drivers/hwtracing/coresight/coresight-tmc-core.c | 2 +- drivers/hwtracing/coresight/coresight-tpiu.c | 2 +- include/linux/coresight.h | 2 +- 9 files changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c index bfea880d6dfb..337668f9cfd4 100644 --- a/drivers/hwtracing/coresight/coresight-catu.c +++ b/drivers/hwtracing/coresight/coresight-catu.c @@ -702,7 +702,7 @@ static int __init catu_init(void) { int ret; - ret = coresight_init_driver("catu", &catu_driver, &catu_platform_driver); + ret = coresight_init_driver("catu", &catu_driver, &catu_platform_driver, THIS_MODULE); tmc_etr_set_catu_ops(&etr_catu_buf_ops); return ret; } diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c index 9fc6f6b863e0..c546a417836c 100644 --- a/drivers/hwtracing/coresight/coresight-core.c +++ b/drivers/hwtracing/coresight/coresight-core.c @@ -1399,17 +1399,17 @@ module_init(coresight_init); module_exit(coresight_exit); int coresight_init_driver(const char *drv, struct amba_driver *amba_drv, - struct platform_driver *pdev_drv) + struct platform_driver *pdev_drv, struct module *owner) { int ret; - ret = amba_driver_register(amba_drv); + ret = __amba_driver_register(amba_drv, owner); if (ret) { pr_err("%s: error registering AMBA driver\n", drv); return ret; } - ret = platform_driver_register(pdev_drv); + ret = __platform_driver_register(pdev_drv, owner); if (!ret) return 0; diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c index 75962dae9aa1..cc599c5ef4b2 100644 --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c @@ -774,7 +774,8 @@ static struct platform_driver debug_platform_driver = { static int __init debug_init(void) { - return coresight_init_driver("debug", &debug_driver, &debug_platform_driver); + return coresight_init_driver("debug", &debug_driver, &debug_platform_driver, + THIS_MODULE); } static void __exit debug_exit(void) diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c index 5a819c8970fb..8f451b051ddc 100644 --- a/drivers/hwtracing/coresight/coresight-funnel.c +++ b/drivers/hwtracing/coresight/coresight-funnel.c @@ -433,7 +433,8 @@ static struct amba_driver dynamic_funnel_driver = { static int __init funnel_init(void) { - return coresight_init_driver("funnel", &dynamic_funnel_driver, &funnel_driver); + return coresight_init_driver("funnel", &dynamic_funnel_driver, &funnel_driver, + THIS_MODULE); } static void __exit funnel_exit(void) diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c index 3e55be9c8418..f7607c72857c 100644 --- a/drivers/hwtracing/coresight/coresight-replicator.c +++ b/drivers/hwtracing/coresight/coresight-replicator.c @@ -438,7 +438,8 @@ static struct amba_driver dynamic_replicator_driver = { static int __init replicator_init(void) { - return coresight_init_driver("replicator", &dynamic_replicator_driver, &replicator_driver); + return coresight_init_driver("replicator", &dynamic_replicator_driver, &replicator_driver, + THIS_MODULE); } static void __exit replicator_exit(void) diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c index 117dbb484543..403eea8f95d4 100644 --- a/drivers/hwtracing/coresight/coresight-stm.c +++ b/drivers/hwtracing/coresight/coresight-stm.c @@ -1046,7 +1046,7 @@ static struct platform_driver stm_platform_driver = { static int __init stm_init(void) { - return coresight_init_driver("stm", &stm_driver, &stm_platform_driver); + return coresight_init_driver("stm", &stm_driver, &stm_platform_driver, THIS_MODULE); } static void __exit stm_exit(void) diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c index b54562f392f3..e31e36635394 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-core.c +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c @@ -742,7 +742,7 @@ static struct platform_driver tmc_platform_driver = { static int __init tmc_init(void) { - return coresight_init_driver("tmc", &tmc_driver, &tmc_platform_driver); + return coresight_init_driver("tmc", &tmc_driver, &tmc_platform_driver, THIS_MODULE); } static void __exit tmc_exit(void) diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c index b048e146fbb1..f9ecd05cbe5c 100644 --- a/drivers/hwtracing/coresight/coresight-tpiu.c +++ b/drivers/hwtracing/coresight/coresight-tpiu.c @@ -318,7 +318,7 @@ static struct platform_driver tpiu_platform_driver = { static int __init tpiu_init(void) { - return coresight_init_driver("tpiu", &tpiu_driver, &tpiu_platform_driver); + return coresight_init_driver("tpiu", &tpiu_driver, &tpiu_platform_driver, THIS_MODULE); } static void __exit tpiu_exit(void) diff --git a/include/linux/coresight.h b/include/linux/coresight.h index f09ace92176e..e6c26952ddc2 100644 --- a/include/linux/coresight.h +++ b/include/linux/coresight.h @@ -660,7 +660,7 @@ coresight_find_output_type(struct coresight_platform_data *pdata, union coresight_dev_subtype subtype); int coresight_init_driver(const char *drv, struct amba_driver *amba_drv, - struct platform_driver *pdev_drv); + struct platform_driver *pdev_drv, struct module *owner); void coresight_remove_driver(struct amba_driver *amba_drv, struct platform_driver *pdev_drv); -- 2.33.0

8 months, 2 weeks

Re: [PATCH v3 00/11] (subset) ARM: qcom: fix APQ8064 schema warnings

by Suzuki K Poulose

On Fri, 25 Apr 2025 20:47:00 +0300, Dmitry Baryshkov wrote: > Rob's bot has reported [1] several warnings for Nexus 4 submisson, > however none of those warnings are specific to that device. Fix all > those warnings for all APQ8064 platforms by extending existing schemas, > adding missing schemas and making APQ8064 DT follow all the schema > files. > > [1]: https://lore.kernel.org/linux-arm-msm/174221818190.3957236.3364090534153729… > > [...] Applied, thanks! [06/11] dt-bindings: arm: arm,coresight-static-replicator: add optional clocks https://git.kernel.org/coresight/c/13e3a882 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

8 months, 2 weeks

[PATCH v2 0/2] Add Qualcomm extended CTI support

by Mao Jinlong

The QCOM extended CTI is a heavily parameterized version of ARM’s CSCTI. It allows a debugger to send to trigger events to a processor or to send a trigger event to one or more processors when a trigger event occurs on another processor on the same SoC, or even between SoCs. QCOM extended CTI supports up to 128 triggers. And some of the register offsets are changed. The commands to configure CTI triggers are the same as ARM's CTI. Changes in V2: 1. Add enum for compatible items. 2. Move offset arraies to coresight-cti-core Mao Jinlong (2): dt-bindings: arm: Add Qualcomm extended CTI coresight: cti: Add Qualcomm extended CTI support .../bindings/arm/arm,coresight-cti.yaml | 4 +- .../hwtracing/coresight/coresight-cti-core.c | 127 ++++++++++++++---- .../coresight/coresight-cti-platform.c | 16 ++- .../hwtracing/coresight/coresight-cti-sysfs.c | 124 +++++++++++++---- drivers/hwtracing/coresight/coresight-cti.h | 72 +++++----- 5 files changed, 243 insertions(+), 100 deletions(-) -- 2.25.1

8 months, 2 weeks

Re: [PATCH v4] coresight: prevent deactivate active config while enabling the config

by Leo Yan

Hi Levi, On Wed, Mar 26, 2025 at 07:34:25AM +0000, Yeoreum Yun wrote: [...] > > > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > > > @@ -1020,6 +1020,9 @@ static void etm4_disable_sysfs(struct coresight_device *csdev) > > > smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1); > > > > > > raw_spin_unlock(&drvdata->spinlock); > > > + > > > + cscfg_csdev_disable_active_config(csdev); > > > + > > > > In general, we need to split changes into several patches if each > > addresses a different issue. From my understanding, the change above is > > to fix missing to disable config when disable Sysfs mode. > > > > If so, could we use a seperate patch for this change? > > > > It's not a differnt issue. Without this line, the active count wouldn't > decrese and it raise another issue -- unloadable moudle for active_cnt :( > So I think it should be included in this patch. I read the code again and concluded the change above is not related to locking and would be a separate issue: when we close a Sysfs session, we need to disable a config on a CoreSight device. Could you clarify what is meaning "unloadable moudle for active_cnt"? I only saw "cscfg_mgr->sys_active_cnt" is used for module unloading, but have no clue why "active_cnt" impacts module unloading. > > > cpus_read_unlock(); > > > > > > /* > > > diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c > > > index a70c1454b410..6d8c212ad434 100644 > > > --- a/drivers/hwtracing/coresight/coresight-syscfg.c > > > +++ b/drivers/hwtracing/coresight/coresight-syscfg.c > > > @@ -391,14 +391,17 @@ static void cscfg_owner_put(struct cscfg_load_owner_info *owner_info) > > > static void cscfg_remove_owned_csdev_configs(struct coresight_device *csdev, void *load_owner) > > > { > > > struct cscfg_config_csdev *config_csdev, *tmp; > > > + unsigned long flags; > > > > > > if (list_empty(&csdev->config_csdev_list)) > > > return; > > > > > > + raw_spin_lock_irqsave(&csdev->cscfg_csdev_lock, flags); > > > > I think we should use spinlock to guard the condition checking > > list_empty(). > > > > Here the race condition is the 'config_csdev_list' list and > > configurations on the list. For atomicity, we should use lock to > > protect any operations on the list (read, add, delete, etc). > > Interesting... Would you let me know which race it is? > here to check list_empty(), it already guarded with "cscfg_mutex". Thanks for pointing out this. I read the code and understood that in some scenarios the list is protected by the mutex "cscfg_mutex". I would argue for using locking, we need to make clear for two thigns: - What is the race condition; - What locking is used to protect the race condition. For current case, a CoreSight device has a config list, the race condition is the config list will be manipulated by multiple places (e.g., for module loading / unloading, opening or closing a perf or SysFS session). So a spinlock is used to to protect the config list. "cscfg_mutex" is a high level lock, my understanding is to protect the high level operations from the Sysfs knobs, though sometimes it can mitigate the race condition on configuration list mentioned above, but the spinlock is the locking mechanism for the low level's config list on a CoreSight device. > However list_del() is special case because iterating config_csdev_list > can be done without cscfg_mutex -- see > cscfg_csdev_enable_active_config(). > This gurad with spinlock purpose to guard race unloading and > get the config in cscfg_csdev_enable_active_config() > (Please see my response below...). > > the emptiness of config_csdev_list is guarded with cscfg_mutex. > therefore, It seems enough to guard iterating part with spinlock :) Mixed using cscfg_mutex and spinlock get code complexity, and I am a bit concerned this is not best practice. At a glance, I would say 'cscfg_mutex' is purposed to protect the global 'cscfg_mgr', per CoreSight device's config list should be protected by 'cscfg_csdev_lock'. > > A side topic, as here it adds locks for protecting 'config_csdev_list', > > I am wandering why we do not do the same thing for > > 'feature_csdev_list' (See cscfg_remove_owned_csdev_features() and > > cscfg_get_feat_csdev()). > > In case of feature, It's okay since it couldn't be accessed when it > gets failed to get related config. I looked at cscfg_load_feat_csdev(), it uses 'cscfg_csdev_lock' to protect the feature list. This is why I thought the feature list also need to be protected by the lock. Now it is only partially protected. > When we see cscfg_csdev_enable_active_config(), the config could be > accessed without cscfg_mutex lock. so the config need to be guarded with > spin_lock otherwise it could be acquired while unload module > (after get active_cnt in search logic cscfg_csdev_enable_active_config() > and other running unloading process) To make things more clear, I have a questions. 'cscfg_mgr->sys_active_cnt' is used in the cscfg_unload_config_sets() function to decide if can unload module, if any configuration is active, why this variable cannot prevent unloading module? Sorry for late replying. Leo > But feature list is depends on config, If config is safe from > load/unload, this is not an issue so we don't need it. > > Thanks for your review!

8 months, 2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight