* [PATCH v9 15/20] coresight: Control path during CPU idle
From: Leo Yan @ 2026-04-01 18:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Yeoreum Yun,
Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz
Cc: coresight, linux-arm-kernel, Leo Yan
In-Reply-To: <20260401-arm_coresight_path_power_management_improvement-v9-0-091d73e44072@arm.com>
Control links and helpers on an active path during CPU idle.
Retrieves the per-CPU path pointer. Since the path pointer is only set
via an SMP call on the local CPU, which is serialized with CPU PM
notifiers. If the CPU PM notifier retrieves a non-NULL path pointer, it
is safe to iterate over the path and control it up to the node before
the sink to avoid latency.
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index c0f76ea7857e2bf368f9e5abbb023d7a34b4caf5..7fafec04de3e8262b7ca66671c6de635b671ceba 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1768,13 +1768,32 @@ static void coresight_pm_device_restore(struct coresight_device *csdev)
static int coresight_pm_save(struct coresight_path *path)
{
struct coresight_device *source = coresight_get_source(path);
+ struct coresight_node *from, *to;
+ int ret;
+
+ ret = coresight_pm_device_save(source);
+ if (ret)
+ return ret;
- return coresight_pm_device_save(source);
+ from = coresight_path_first_node(path);
+ /* Up to the node before sink to avoid latency */
+ to = list_prev_entry(coresight_path_last_node(path), link);
+ coresight_disable_path_from_to(path, from, to);
+
+ return 0;
}
static void coresight_pm_restore(struct coresight_path *path)
{
struct coresight_device *source = coresight_get_source(path);
+ struct coresight_node *from, *to;
+
+ from = coresight_path_first_node(path);
+ /* Up to the node before sink to avoid latency */
+ to = list_prev_entry(coresight_path_last_node(path), link);
+ if (coresight_enable_path_from_to(path, coresight_get_mode(source),
+ from, to))
+ return;
coresight_pm_device_restore(source);
}
--
2.34.1
^ permalink raw reply related
* [PATCH v9 17/20] coresight: trbe: Save and restore state across CPU low power state
From: Leo Yan @ 2026-04-01 18:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Yeoreum Yun,
Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz
Cc: coresight, linux-arm-kernel, Leo Yan
In-Reply-To: <20260401-arm_coresight_path_power_management_improvement-v9-0-091d73e44072@arm.com>
From: Yabin Cui <yabinc@google.com>
Similar to ETE, TRBE may lose its context when a CPU enters low power
state. To make things worse, if ETE is restored without TRBE being
restored, an enabled source device with no enabled sink devices can
cause CPU hang on some devices (e.g., Pixel 9).
The save and restore flows are described in the section K5.5 "Context
switching" of Arm ARM (ARM DDI 0487 L.a). This commit adds save and
restore callbacks with following the software usages defined in the
architecture manual.
Given that some bit fields may be reset to an unknown value after a CPU
power cycle, this commit always save and restore all register contexts.
Signed-off-by: Yabin Cui <yabinc@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Co-developed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-trbe.c | 59 +++++++++++++++++++++++++++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
index 14e35b9660d76e47619cc6026b94929b3bb3e02b..c7cbca45f2debd4047b93283ea9fe5dd9e1f2ebf 100644
--- a/drivers/hwtracing/coresight/coresight-trbe.c
+++ b/drivers/hwtracing/coresight/coresight-trbe.c
@@ -116,6 +116,20 @@ static int trbe_errata_cpucaps[] = {
*/
#define TRBE_WORKAROUND_OVERWRITE_FILL_MODE_SKIP_BYTES 256
+/*
+ * struct trbe_save_state: Register values representing TRBE state
+ * @trblimitr - Trace Buffer Limit Address Register value
+ * @trbbaser - Trace Buffer Base Register value
+ * @trbptr - Trace Buffer Write Pointer Register value
+ * @trbsr - Trace Buffer Status Register value
+ */
+struct trbe_save_state {
+ u64 trblimitr;
+ u64 trbbaser;
+ u64 trbptr;
+ u64 trbsr;
+};
+
/*
* struct trbe_cpudata: TRBE instance specific data
* @trbe_flag - TRBE dirty/access flag support
@@ -134,6 +148,7 @@ struct trbe_cpudata {
enum cs_mode mode;
struct trbe_buf *buf;
struct trbe_drvdata *drvdata;
+ struct trbe_save_state save_state;
DECLARE_BITMAP(errata, TRBE_ERRATA_MAX);
};
@@ -1189,6 +1204,46 @@ static irqreturn_t arm_trbe_irq_handler(int irq, void *dev)
return IRQ_HANDLED;
}
+static int arm_trbe_save(struct coresight_device *csdev)
+{
+ struct trbe_cpudata *cpudata = dev_get_drvdata(&csdev->dev);
+ struct trbe_save_state *state = &cpudata->save_state;
+
+ state->trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
+
+ /* Disable the unit, ensure the writes to memory are complete */
+ if (state->trblimitr & TRBLIMITR_EL1_E)
+ trbe_drain_and_disable_local(cpudata);
+
+ state->trbbaser = read_sysreg_s(SYS_TRBBASER_EL1);
+ state->trbptr = read_sysreg_s(SYS_TRBPTR_EL1);
+ state->trbsr = read_sysreg_s(SYS_TRBSR_EL1);
+ return 0;
+}
+
+static void arm_trbe_restore(struct coresight_device *csdev)
+{
+ struct trbe_cpudata *cpudata = dev_get_drvdata(&csdev->dev);
+ struct trbe_save_state *state = &cpudata->save_state;
+
+ write_sysreg_s(state->trbbaser, SYS_TRBBASER_EL1);
+ write_sysreg_s(state->trbptr, SYS_TRBPTR_EL1);
+ write_sysreg_s(state->trbsr, SYS_TRBSR_EL1);
+
+ if (!(state->trblimitr & TRBLIMITR_EL1_E)) {
+ write_sysreg_s(state->trblimitr, SYS_TRBLIMITR_EL1);
+ } else {
+ /*
+ * The section K5.5 Context switching, Arm ARM (ARM DDI 0487
+ * L.a), S_PKLXF requires a Context synchronization event to
+ * guarantee the Trace Buffer Unit will observe the new values
+ * of the system registers.
+ */
+ isb();
+ set_trbe_enabled(cpudata, state->trblimitr);
+ }
+}
+
static const struct coresight_ops_sink arm_trbe_sink_ops = {
.enable = arm_trbe_enable,
.disable = arm_trbe_disable,
@@ -1198,7 +1253,9 @@ static const struct coresight_ops_sink arm_trbe_sink_ops = {
};
static const struct coresight_ops arm_trbe_cs_ops = {
- .sink_ops = &arm_trbe_sink_ops,
+ .pm_save_disable = arm_trbe_save,
+ .pm_restore_enable = arm_trbe_restore,
+ .sink_ops = &arm_trbe_sink_ops,
};
static ssize_t align_show(struct device *dev, struct device_attribute *attr, char *buf)
--
2.34.1
^ permalink raw reply related
* [PATCH v9 16/20] coresight: Add PM callbacks for sink device
From: Leo Yan @ 2026-04-01 18:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Yeoreum Yun,
Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz
Cc: coresight, linux-arm-kernel, Leo Yan
In-Reply-To: <20260401-arm_coresight_path_power_management_improvement-v9-0-091d73e44072@arm.com>
Unlike a system level's sink, the per-CPU sink may lose power during CPU
idle states. Currently, this refers specifically to TRBE as the sink.
This commit invokes save and restore callbacks for the sink in the PM
notifier.
Tested-by: James Clark <james.clark@linaro.org>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 7fafec04de3e8262b7ca66671c6de635b671ceba..a41e77da4f083d4b5d162e7b70905f22bddf7ca2 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1757,11 +1757,17 @@ static bool coresight_pm_is_needed(struct coresight_path *path)
static int coresight_pm_device_save(struct coresight_device *csdev)
{
+ if (!csdev || !coresight_ops(csdev)->pm_save_disable)
+ return 0;
+
return coresight_ops(csdev)->pm_save_disable(csdev);
}
static void coresight_pm_device_restore(struct coresight_device *csdev)
{
+ if (!csdev || !coresight_ops(csdev)->pm_restore_enable)
+ return;
+
coresight_ops(csdev)->pm_restore_enable(csdev);
}
@@ -1780,20 +1786,35 @@ static int coresight_pm_save(struct coresight_path *path)
to = list_prev_entry(coresight_path_last_node(path), link);
coresight_disable_path_from_to(path, from, to);
+ ret = coresight_pm_device_save(coresight_get_sink(path));
+ if (ret)
+ goto failed_out;
+
return 0;
+
+failed_out:
+ coresight_enable_path_from_to(path, coresight_get_mode(source),
+ from, to);
+ coresight_pm_device_restore(source);
+ return ret;
}
static void coresight_pm_restore(struct coresight_path *path)
{
struct coresight_device *source = coresight_get_source(path);
+ struct coresight_device *sink = coresight_get_sink(path);
struct coresight_node *from, *to;
+ coresight_pm_device_restore(sink);
+
from = coresight_path_first_node(path);
/* Up to the node before sink to avoid latency */
to = list_prev_entry(coresight_path_last_node(path), link);
if (coresight_enable_path_from_to(path, coresight_get_mode(source),
- from, to))
+ from, to)) {
+ coresight_pm_device_save(sink);
return;
+ }
coresight_pm_device_restore(source);
}
--
2.34.1
^ permalink raw reply related
* [PATCH v9 18/20] coresight: sysfs: Increment refcount only for system tracers
From: Leo Yan @ 2026-04-01 18:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Yeoreum Yun,
Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz
Cc: coresight, linux-arm-kernel, Leo Yan
In-Reply-To: <20260401-arm_coresight_path_power_management_improvement-v9-0-091d73e44072@arm.com>
Except for system tracers (e.g. STM), other sources treat multiple
enables as equivalent to a single enable. The device mode already
tracks the binary state, so it is redundant to operate refcount.
Refactor to maintain the refcount only for system sources. This
simplifies future CPU PM handling without refcount logic.
Tested-by: James Clark <james.clark@linaro.org>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-sysfs.c | 34 ++++++++++++++++++++-------
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index 9449de66ba3941614928924086100866f3c88a54..75dd8c9f78174b7e604fbad6e8735656a2d643a0 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -53,6 +53,28 @@ ssize_t coresight_simple_show32(struct device *_dev,
}
EXPORT_SYMBOL_GPL(coresight_simple_show32);
+static void coresight_source_get_refcnt(struct coresight_device *csdev)
+{
+ /*
+ * There could be multiple applications driving the software
+ * source. So keep the refcount for each such user when the
+ * source is already enabled.
+ *
+ * No need to increment the reference counter for other source
+ * types, as multiple enables are the same as a single enable.
+ */
+ if (csdev->subtype.source_subtype ==
+ CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE)
+ csdev->refcnt++;
+}
+
+static void coresight_source_put_refcnt(struct coresight_device *csdev)
+{
+ if (csdev->subtype.source_subtype ==
+ CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE)
+ csdev->refcnt--;
+}
+
static int coresight_enable_source_sysfs(struct coresight_device *csdev,
enum cs_mode mode,
struct coresight_path *path)
@@ -71,7 +93,7 @@ static int coresight_enable_source_sysfs(struct coresight_device *csdev,
return ret;
}
- csdev->refcnt++;
+ coresight_source_get_refcnt(csdev);
return 0;
}
@@ -93,7 +115,7 @@ static bool coresight_disable_source_sysfs(struct coresight_device *csdev,
if (coresight_get_mode(csdev) != CS_MODE_SYSFS)
return false;
- csdev->refcnt--;
+ coresight_source_put_refcnt(csdev);
if (csdev->refcnt == 0) {
coresight_disable_source(csdev, data);
return true;
@@ -188,13 +210,7 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
* doesn't hold coresight_mutex.
*/
if (coresight_get_mode(csdev) == CS_MODE_SYSFS) {
- /*
- * There could be multiple applications driving the software
- * source. So keep the refcount for each such user when the
- * source is already enabled.
- */
- if (subtype == CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE)
- csdev->refcnt++;
+ coresight_source_get_refcnt(csdev);
goto out;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v9 19/20] coresight: Move CPU hotplug callbacks to core layer
From: Leo Yan @ 2026-04-01 18:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Yeoreum Yun,
Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz
Cc: coresight, linux-arm-kernel, Leo Yan
In-Reply-To: <20260401-arm_coresight_path_power_management_improvement-v9-0-091d73e44072@arm.com>
This commit moves CPU hotplug callbacks from ETMv4 driver to core layer.
The motivation is the core layer can control all components on an
activated path rather but not only managing tracer in ETMv4 driver.
The perf event layer will disable CoreSight PMU event 'cs_etm' when
hotplug off a CPU. That means a perf mode will be always converted to
disabled mode in CPU hotplug. Arm CoreSight CPU hotplug callbacks only
need to handle the Sysfs mode and ignore the perf mode.
The core layer disables and releases the active path when hotplug-off a
CPU. When hotplug-in a CPU, it does not re-enable the path, in this
case, users need to re-enable the trace via Sysfs interface.
Tested-by: James Clark <james.clark@linaro.org>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 36 ++++++++++++++++++-
drivers/hwtracing/coresight/coresight-etm3x-core.c | 40 ----------------------
drivers/hwtracing/coresight/coresight-etm4x-core.c | 37 --------------------
3 files changed, 35 insertions(+), 78 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index a41e77da4f083d4b5d162e7b70905f22bddf7ca2..5ebe0640129ade401de9d2ebb97819c6d1809d83 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1847,13 +1847,47 @@ static struct notifier_block coresight_cpu_pm_nb = {
.notifier_call = coresight_cpu_pm_notify,
};
+static int coresight_dying_cpu(unsigned int cpu)
+{
+ struct coresight_path *path = coresight_get_percpu_local_path();
+ struct coresight_device *source = coresight_get_source(path);
+
+ if (!path || !source)
+ return 0;
+
+ /*
+ * The perf event layer will disable PMU events in the CPU hotplug.
+ * CoreSight driver should never handle the CS_MODE_PERF case.
+ */
+ if (coresight_get_mode(source) != CS_MODE_SYSFS)
+ return 0;
+
+ coresight_disable_source(source, NULL);
+ coresight_disable_path(path);
+ coresight_release_path(path);
+ return 0;
+}
+
static int __init coresight_pm_setup(void)
{
- return cpu_pm_register_notifier(&coresight_cpu_pm_nb);
+ int ret;
+
+ ret = cpu_pm_register_notifier(&coresight_cpu_pm_nb);
+ if (ret)
+ return ret;
+
+ ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING,
+ "arm/coresight-core:starting",
+ NULL, coresight_dying_cpu);
+ if (ret)
+ cpu_pm_unregister_notifier(&coresight_cpu_pm_nb);
+
+ return ret;
}
static void coresight_pm_cleanup(void)
{
+ cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
cpu_pm_unregister_notifier(&coresight_cpu_pm_nb);
}
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
index 46ea66b5cf1985bd7129688f175f6f92372d04ad..5c6b131465c52fd8ab9161bf36fc78ba9a7dd99b 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
@@ -699,35 +699,6 @@ static int etm_online_cpu(unsigned int cpu)
return 0;
}
-static int etm_starting_cpu(unsigned int cpu)
-{
- if (!etmdrvdata[cpu])
- return 0;
-
- spin_lock(&etmdrvdata[cpu]->spinlock);
- if (!etmdrvdata[cpu]->os_unlock) {
- etm_os_unlock(etmdrvdata[cpu]);
- etmdrvdata[cpu]->os_unlock = true;
- }
-
- if (coresight_get_mode(etmdrvdata[cpu]->csdev))
- etm_enable_hw(etmdrvdata[cpu]);
- spin_unlock(&etmdrvdata[cpu]->spinlock);
- return 0;
-}
-
-static int etm_dying_cpu(unsigned int cpu)
-{
- if (!etmdrvdata[cpu])
- return 0;
-
- spin_lock(&etmdrvdata[cpu]->spinlock);
- if (coresight_get_mode(etmdrvdata[cpu]->csdev))
- etm_disable_hw(etmdrvdata[cpu]);
- spin_unlock(&etmdrvdata[cpu]->spinlock);
- return 0;
-}
-
static bool etm_arch_supported(u8 arch)
{
switch (arch) {
@@ -795,13 +766,6 @@ static int __init etm_hp_setup(void)
{
int ret;
- ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING,
- "arm/coresight:starting",
- etm_starting_cpu, etm_dying_cpu);
-
- if (ret)
- return ret;
-
ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
"arm/coresight:online",
etm_online_cpu, NULL);
@@ -812,15 +776,11 @@ static int __init etm_hp_setup(void)
return 0;
}
- /* failed dyn state - remove others */
- cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
-
return ret;
}
static void etm_hp_clear(void)
{
- cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
if (hp_online) {
cpuhp_remove_state_nocalls(hp_online);
hp_online = 0;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 087a32fe34890528c6fa6ada601aeb742f04c41b..a10a40098659e9814b4d20c15f01bf7d0c2fbe26 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -1834,33 +1834,6 @@ static int etm4_online_cpu(unsigned int cpu)
return 0;
}
-static int etm4_starting_cpu(unsigned int cpu)
-{
- if (!etmdrvdata[cpu])
- return 0;
-
- raw_spin_lock(&etmdrvdata[cpu]->spinlock);
- if (!etmdrvdata[cpu]->os_unlock)
- etm4_os_unlock(etmdrvdata[cpu]);
-
- if (coresight_get_mode(etmdrvdata[cpu]->csdev))
- etm4_enable_hw(etmdrvdata[cpu]);
- raw_spin_unlock(&etmdrvdata[cpu]->spinlock);
- return 0;
-}
-
-static int etm4_dying_cpu(unsigned int cpu)
-{
- if (!etmdrvdata[cpu])
- return 0;
-
- raw_spin_lock(&etmdrvdata[cpu]->spinlock);
- if (coresight_get_mode(etmdrvdata[cpu]->csdev))
- etm4_disable_hw(etmdrvdata[cpu]);
- raw_spin_unlock(&etmdrvdata[cpu]->spinlock);
- return 0;
-}
-
static int etm4_cpu_save(struct coresight_device *csdev)
{
int i, ret = 0;
@@ -2110,13 +2083,6 @@ static int __init etm4_pm_setup(void)
{
int ret;
- ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING,
- "arm/coresight4:starting",
- etm4_starting_cpu, etm4_dying_cpu);
-
- if (ret)
- return ret;
-
ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
"arm/coresight4:online",
etm4_online_cpu, NULL);
@@ -2127,14 +2093,11 @@ static int __init etm4_pm_setup(void)
return 0;
}
- /* failed dyn state - remove others */
- cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
return ret;
}
static void etm4_pm_clear(void)
{
- cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
if (hp_online) {
cpuhp_remove_state_nocalls(hp_online);
hp_online = 0;
--
2.34.1
^ permalink raw reply related
* [PATCH v9 20/20] coresight: sysfs: Validate CPU online status for per-CPU sources
From: Leo Yan @ 2026-04-01 18:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Yeoreum Yun,
Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz
Cc: coresight, linux-arm-kernel, Leo Yan
In-Reply-To: <20260401-arm_coresight_path_power_management_improvement-v9-0-091d73e44072@arm.com>
The current SysFS flow first enables the links and sink, then rolls back
to disable them if the source fails to enable. This failure can occur if
the associated CPU is offline, which causes the SMP call to fail.
Validate whether the associated CPU is online for a per-CPU tracer. If
the CPU is offline, return -ENODEV and bail out.
Tested-by: James Clark <james.clark@linaro.org>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-sysfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index 75dd8c9f78174b7e604fbad6e8735656a2d643a0..b79c0abfeb77ed6f8fa299f083e0b6c656e0e6c1 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -184,6 +184,9 @@ static int coresight_validate_source_sysfs(struct coresight_device *csdev,
return -EINVAL;
}
+ if (coresight_is_percpu_source(csdev) && !cpu_online(csdev->cpu))
+ return -ENODEV;
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V5 0/2] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
From: Catalin Marinas @ 2026-04-01 18:13 UTC (permalink / raw)
To: linux-arm-kernel, Anshuman Khandual
Cc: Will Deacon, Ryan Roberts, David Hildenbrand, Yang Shi,
Christoph Lameter, linux-kernel
In-Reply-To: <20260309025725.455004-1-anshuman.khandual@arm.com>
On Mon, 09 Mar 2026 02:57:23 +0000, Anshuman Khandual wrote:
> This series enables batched TLB flush in unmap_hotplug_range() which avoids
> individual page TLB flush for potential CONT blocks in linear mapping while
> also improving performance due to range based TLB operation along with less
> synchronization barrier instructions.
>
> It also now rejects memory removal that might split a leaf entry in kernel
> mapping, which would have otherwise required re-structuring using the break
> before make (BBM) semantics. But kernel cannot tolerate BBM, so remapping to
> fine grained leaves would not be possible on systems without BBML2_NOABORT.
>
> [...]
Applied to arm64 (for-next/hotplug-batched-tlbi), thanks!
[1/2] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
https://git.kernel.org/arm64/c/48478b9f7913
[2/2] arm64/mm: Reject memory removal that splits a kernel leaf mapping
https://git.kernel.org/arm64/c/95a58852b0e5
^ permalink raw reply
* Re: [PATCH v2] arm64: mm: Use generic enum pgtable_level
From: Catalin Marinas @ 2026-04-01 18:13 UTC (permalink / raw)
To: linux-arm-kernel, Kevin Brodsky
Cc: Will Deacon, linux-kernel, David Hildenbrand (Arm), Ryan Roberts
In-Reply-To: <20260318092543.73331-1-kevin.brodsky@arm.com>
On Wed, 18 Mar 2026 09:25:43 +0000, Kevin Brodsky wrote:
> enum pgtable_type was introduced for arm64 by commit c64f46ee1377
> ("arm64: mm: use enum to identify pgtable level instead of
> *_SHIFT"). In the meantime, the generic enum pgtable_level got
> introduced by commit b22cc9a9c7ff ("mm/rmap: convert "enum
> rmap_level" to "enum pgtable_level"").
>
> Let's switch to the generic enum pgtable_level. The only difference
> is that it also includes PGD level; __pgd_pgtable_alloc() isn't
> expected to create PGD tables so we add a VM_WARN_ON() for that
> case.
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: mm: Use generic enum pgtable_level
https://git.kernel.org/arm64/c/5e0deb0a6b4e
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers
From: Marc Zyngier @ 2026-04-01 18:28 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, joey.gouly, korneld, mrigendra.chaubey, oupton,
perlarsen, suzuki.poulose, will, yuzenghui
In-Reply-To: <ac1UNj7Z1uVL4Nf6@google.com>
On Wed, 01 Apr 2026 18:21:58 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> On Wed, Apr 01, 2026 at 03:55:11PM +0100, Marc Zyngier wrote:
> > On Wed, 01 Apr 2026 13:32:01 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > Make the SMC handlers accept a 64bit value for the function-id to keep
> > > it uniform with the rest of the code and prevent a u64 -> u32 -> u64
> > > conversion as it currently happens when we handle PSCI.
> >
> > That seems overly creative. The spec says (2.5, from ARM DEN 0028 1.6
> > G):
>
> I'm not plannig to be *overly creative*. Thanks for pointing out the ARM
> spec.
>
> >
> > "The Function Identifier is passed on W0 on every SMC and HVC
> > call. Its 32-bit integer value indicates which function is being
> > requested by the caller. It is always passed as the first argument to
> > every SMC or HVC call in R0 or W0."
> >
> > which indicates that it is *always* a 32bit value.
> >
> > So if you have a 64bit value somewhere, *that* should be fixed, not
> > propagated arbitrarily.
>
> If you have a non SMCCC call that happen to have the first 32-bits of
> the function-id matching either PSCI or FF-A you will end up handling
> them instead of forwarding it to Trustzone because func_id is declared as:
>
> DECLARE_REG(u64, func_id, host_ctxt, 0);
Again, the correct approach to prevent the propagation of something
that is known to be wrong. Something like this:
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 007fc993f2319..dae993a1d081b 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -694,6 +694,11 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
DECLARE_REG(u64, func_id, host_ctxt, 0);
bool handled;
+ if (upper_32_bits(func_id)) {
+ cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
+ kvm_skip_host_instr();
+ }
+
func_id &= ~ARM_SMCCC_CALL_HINTS;
handled = kvm_host_psci_handler(host_ctxt, func_id);
Because forwarding something that is blatantly illegal to the secure
side is not something we should accept at all (just like we now refuse
non-zero SMC immediate values).
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers
From: Marc Zyngier @ 2026-04-01 18:34 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, joey.gouly, korneld, mrigendra.chaubey, oupton,
perlarsen, suzuki.poulose, will, yuzenghui
In-Reply-To: <877bqqcz77.wl-maz@kernel.org>
On Wed, 01 Apr 2026 19:28:28 +0100,
Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 01 Apr 2026 18:21:58 +0100,
> Sebastian Ene <sebastianene@google.com> wrote:
> >
> > On Wed, Apr 01, 2026 at 03:55:11PM +0100, Marc Zyngier wrote:
> > > On Wed, 01 Apr 2026 13:32:01 +0100,
> > > Sebastian Ene <sebastianene@google.com> wrote:
> > > >
> > > > Make the SMC handlers accept a 64bit value for the function-id to keep
> > > > it uniform with the rest of the code and prevent a u64 -> u32 -> u64
> > > > conversion as it currently happens when we handle PSCI.
> > >
> > > That seems overly creative. The spec says (2.5, from ARM DEN 0028 1.6
> > > G):
> >
> > I'm not plannig to be *overly creative*. Thanks for pointing out the ARM
> > spec.
> >
> > >
> > > "The Function Identifier is passed on W0 on every SMC and HVC
> > > call. Its 32-bit integer value indicates which function is being
> > > requested by the caller. It is always passed as the first argument to
> > > every SMC or HVC call in R0 or W0."
> > >
> > > which indicates that it is *always* a 32bit value.
> > >
> > > So if you have a 64bit value somewhere, *that* should be fixed, not
> > > propagated arbitrarily.
> >
> > If you have a non SMCCC call that happen to have the first 32-bits of
> > the function-id matching either PSCI or FF-A you will end up handling
> > them instead of forwarding it to Trustzone because func_id is declared as:
> >
> > DECLARE_REG(u64, func_id, host_ctxt, 0);
>
> Again, the correct approach to prevent the propagation of something
> that is known to be wrong. Something like this:
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 007fc993f2319..dae993a1d081b 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -694,6 +694,11 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> DECLARE_REG(u64, func_id, host_ctxt, 0);
> bool handled;
>
> + if (upper_32_bits(func_id)) {
> + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> + kvm_skip_host_instr();
Plus the obviously missing:
+ return;
> + }
> +
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* RE: [PATCH v3 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by passing delay_us=0
From: Gupta, Suraj @ 2026-04-01 18:37 UTC (permalink / raw)
To: Alex Bereza, Vinod Koul, Frank Li, Simek, Michal,
Geert Uytterhoeven, Ulf Hansson, Arnd Bergmann, Tony Lindgren,
Rao, Appana Durga Kedareswara
Cc: dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v3-0-85508f0aedde@bereza.email>
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Alex Bereza <alex@bereza.email>
> Sent: Wednesday, April 1, 2026 4:27 PM
> To: Vinod Koul <vkoul@kernel.org>; Frank Li <Frank.Li@kernel.org>; Simek,
> Michal <michal.simek@amd.com>; Geert Uytterhoeven
> <geert+renesas@glider.be>; Ulf Hansson <ulf.hansson@linaro.org>; Arnd
> Bergmann <arnd@arndb.de>; Tony Lindgren <tony@atomide.com>; Rao,
> Appana Durga Kedareswara <appana.durga.kedareswara.rao@amd.com>
> Cc: dmaengine@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Alex Bereza <alex@bereza.email>
> Subject: [PATCH v3 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by
> passing delay_us=0
>
> [You don't often get email from alex@bereza.email. Learn why this is important
> at https://aka.ms/LearnAboutSenderIdentification ]
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Signed-off-by: Alex Bereza <alex@bereza.email>
> ---
For the series, Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Thanks!
Suraj
> Changes in v3:
> - patch 1/2:
> - Fix commit message: remove blank line between tags
> - patch 2/2: nothing
> - Link to v2: https://patch.msgid.link/20260401-fix-atomic-poll-timeout-
> regression-v2-0-68a265e3770f@bereza.email
>
> Changes in v2:
> - Fixed the Fixes: tags as suggested by Geert Uytterhoeven
> <geert+renesas@glider.be> - thanks!
> - Split the renaming of XILINX_DMA_LOOP_COUNT into separate commit
> - Link to v1: https://patch.msgid.link/20260331-fix-atomic-poll-timeout-
> regression-v1-1-5b7bd96eaca0@bereza.email
>
> ---
> Alex Bereza (2):
> dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
> dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
>
> drivers/dma/xilinx/xilinx_dma.c | 26 ++++++++++++++++----------
> 1 file changed, 16 insertions(+), 10 deletions(-)
> ---
> base-commit: b7560798466a07d9c3fb011698e92c335ab28baf
> change-id: 20260330-fix-atomic-poll-timeout-regression-4f4e3baf3fd7
>
> Best regards,
> --
> Alex Bereza <alex@bereza.email>
>
^ permalink raw reply
* [PATCH 1/2] media: cedrus: Fix missing cleanup in error path
From: Andrey Skvortsov @ 2026-04-01 19:14 UTC (permalink / raw)
To: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans Verkuil, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
Cc: Andrey Skvortsov
From: Samuel Holland <samuel@sholland.org>
From: Samuel Holland <samuel@sholland.org>
According to the documentation struct v4l2_fh has to be cleaned up with
v4l2_fh_exit() before being freed. [1]
1. https://docs.kernel.org/driver-api/media/v4l2-fh.html
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 6600245dff0e2..1d2130f35fffc 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -391,6 +391,7 @@ static int cedrus_open(struct file *file)
err_m2m_release:
v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
err_free:
+ v4l2_fh_exit(&ctx->fh);
kfree(ctx);
mutex_unlock(&dev->dev_mutex);
--
2.51.0
^ permalink raw reply related
* [PATCH 2/2] media: cedrus: Fix failure to clean up hardware on probe failure
From: Andrey Skvortsov @ 2026-04-01 19:14 UTC (permalink / raw)
To: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans Verkuil, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
Cc: Andrey Skvortsov
In-Reply-To: <20260401191441.1217646-1-andrej.skvortzov@gmail.com>
From: Samuel Holland <samuel@sholland.org>
From: Samuel Holland <samuel@sholland.org>
cedrus_hw_remove undoes, that was done by cedrus_hw_probe previously,
like disabling runtime power management, releasing claimed sram.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 1d2130f35fffc..ee0e286add67d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -477,7 +477,7 @@ static int cedrus_probe(struct platform_device *pdev)
ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
if (ret) {
dev_err(&pdev->dev, "Failed to register V4L2 device\n");
- return ret;
+ goto err_hw;
}
vfd = &dev->vfd;
@@ -538,6 +538,8 @@ static int cedrus_probe(struct platform_device *pdev)
v4l2_m2m_release(dev->m2m_dev);
err_v4l2:
v4l2_device_unregister(&dev->v4l2_dev);
+err_hw:
+ cedrus_hw_remove(dev);
return ret;
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 0/5] crc64: Tweak intrinsics code and enable it for ARM
From: Eric Biggers @ 2026-04-01 19:59 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel, Demian Shulhan
In-Reply-To: <20260330144630.33026-7-ardb@kernel.org>
On Mon, Mar 30, 2026 at 04:46:31PM +0200, Ard Biesheuvel wrote:
> Apply some tweaks to the new arm64 crc64 NEON intrinsics code, and wire
> it up for the 32-bit ARM build. Note that true 32-bit ARM CPUs usually
> don't implement the prerequisite 64x64 PMULL instructions, but 32-bit
> kernels are commonly used on 64-bit capable hardware too, which do
> implement the 32-bit versions of the crypto instructions if they are
> implemented for the 64-bit ISA (as per the architecture).
>
> Cc: Demian Shulhan <demyansh@gmail.com>
> Cc: Eric Biggers <ebiggers@kernel.org>
>
> Ard Biesheuvel (5):
> lib/crc: arm64: Drop unnecessary chunking logic from crc64
> lib/crc: arm64: Use existing macros for kernel-mode FPU cflags
> ARM: Add a neon-intrinsics.h header like on arm64
> lib/crc: arm64: Simplify intrinsics implementation
> lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
I think patches 3 and 4 should be swapped, so it's cleanups first (which
make sense regardless of the 32-bit ARM support) and then the 32-bit ARM
support.
I do think we should be aware that even with the code mostly shared
using the NEON intrinsics, the 32-bit ARM support (which works only on
CPUs that support PMULL, i.e. are also 64-bit capable) doesn't come for
free. We should expect to deal with occasional issues related to the
intrinsics with certain compiler versions, compiler flags, etc.
I assume that "32-bit kernels on ARMv8 CPUs" is currently still a big
enough niche to bother with this, despite that niche getting smaller
over time. But as I mentioned I do think we should try to simplify it
as much as possible, e.g. by supporting little-endian only and avoiding
#ifdefs based on things like the compiler whenever possible.
- Eric
^ permalink raw reply
* Re: [PATCH 6.1.y 5/8] nvme-apple: remove an extra queue reference
From: Fedor Pchelkin @ 2026-04-01 20:45 UTC (permalink / raw)
To: Heyne, Maximilian, Christoph Hellwig
Cc: Sagi Grimberg, stable@vger.kernel.org, Sven Peter,
Chaitanya Kulkarni, Keith Busch, Jens Axboe, Hector Martin,
Alyssa Rosenzweig, James E.J. Bottomley, Martin K. Petersen,
Alim Akhtar, Avri Altman, Bart Van Assche, Sasha Levin,
Peter Wang, Greg Kroah-Hartman, Seunghui Lee, Sanjeev Yadav,
Wonkon Kim, Brian Kao, Hannes Reinecke, Ming Lei,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <20260401-pliny-ashley-ff03a0b6@mheyne-amazon>
Hello,
"Heyne, Maximilian" <mheyne@amazon.de> wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> [ Upstream commit 941f7298c70c7668416e7845fa76eb72c07d966b ]
>
> Now that blk_mq_destroy_queue does not release the queue reference, there
> is no need for a second admin queue reference to be held by the
> apple_nvme structure.
This patch is probably buggy in upstream. It removes extra reference
->get, but doesn't remove the corresponding ->put which is located
inside apple_nvme_free_ctrl().
I'm reporting here currently just for the heads up - was looking at the
same nvme regression problem at 6.1.y, found this thread, and the
nvme-apple changes appeared suspicious.
nvme-apple patch is not required to fix the regression (this also holds
true for [PATCH 6.1.y 3/8] scsi: remove an extra queue reference). Maybe
they shouldn't go to stable.
That said, the other part of the backport series FWIW looks good to me,
and I've also verified it resolves the 6.1.y regression.
Thanks.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
> Reviewed-by: Sven Peter <sven@svenpeter.dev>
> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
> Reviewed-by: Keith Busch <kbusch@kernel.org>
> Link: https://lore.kernel.org/r/20221018135720.670094-5-hch@lst.de
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
> ---
> drivers/nvme/host/apple.c | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
> index c5fc293c22123..c84ebfcfdeb88 100644
> --- a/drivers/nvme/host/apple.c
> +++ b/drivers/nvme/host/apple.c
> @@ -1507,15 +1507,6 @@ static int apple_nvme_probe(struct platform_device *pdev)
> goto put_dev;
> }
>
> - if (!blk_get_queue(anv->ctrl.admin_q)) {
> - nvme_start_admin_queue(&anv->ctrl);
> - blk_mq_destroy_queue(anv->ctrl.admin_q);
> - blk_put_queue(anv->ctrl.admin_q);
> - anv->ctrl.admin_q = NULL;
> - ret = -ENODEV;
> - goto put_dev;
> - }
> -
> nvme_reset_ctrl(&anv->ctrl);
> async_schedule(apple_nvme_async_probe, anv);
>
> --
> 2.50.1
^ permalink raw reply
* Re: [RFT PATCH 0/7] perf tool: Support iostat for multiple platforms
From: Ian Rogers @ 2026-04-01 20:52 UTC (permalink / raw)
To: wangyushan
Cc: mike.leach, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, adrian.hunter, peterz, john.g.garry,
Jonathan.Cameron, shiju.jose, will, linux-perf-users,
linux-arm-kernel, linuxarm, liuyonglong, prime.zeng, fanghao11,
wangzhou1
In-Reply-To: <d8639ed9-63d9-4a61-8cce-72f4b7fcb872@huawei.com>
On Thu, Jan 29, 2026 at 7:15 AM wangyushan <wangyushan12@huawei.com> wrote:
>
>
>
> On 1/27/2026 1:01 AM, Ian Rogers wrote:
> > On Mon, Jan 26, 2026 at 4:35 AM Yushan Wang <wangyushan12@huawei.com> wrote:
> >> Currently, platform-specific iostat code for PMUs is implemented as a
> >> common iostat callback interface and invoked based on what is being
> >> built. This approach limits support for iostat across different types of
> >> PMUs.
> >>
> >> Support of HiSilicon PCIe PMU iostat was raised at [1], which uses the
> >> similar approach.
> >>
> >> To extend support of iostat across platforms, change common iostat
> >> interface to framework to allow perf to probe PMU capabilities during
> >> runtime and route iostat request to the correct PMU-specific functions.
> >> Then HiSilicon PCIe PMU iostat is supported with the new framework.
> >>
> >> Request For Test:
> >> Refactors has been made to x86 iostat to adapt the iostat framework, the
> >> probe function that checks if there's any PMU's name contains 'x86-iio'
> >> may not work properly, tests of that would be appreciated.
> >>
> >> [1] https://lore.kernel.org/all/4688a613-c94a-49b0-9d0f-09173c64082d@arm.com/
> >>
> >> Shiju Jose (2):
> >> perf-iostat: Extend iostat interface to support different iostat PMUs
> >> perf-iostat: Make x86 iostat compatible with new iostat framework
> >>
> >> Yicong Yang (1):
> >> perf-iostat: Enable iostat mode for HiSilicon PCIe PMU
> >>
> >> Yushan Wang (4):
> >> perf stat: Check color's length instead of the pointer
> >> perf stat: Save unnecessary print_metric() call
> >> perf-x86: iostat: Change iostat_prefix() to static
> >> perf-iostat: Support wilder wildcard-match for pmus
> > Hi,
> >
> > Thanks for the changes! Given the iostat code is display code, it'd be
> > great if we could avoid the arch directory usage. For example, I may
> > record data on a machine with a HiSilicon PCIe PMU but then want to
> > look at the data on an x86 laptop, as the code is under arch/arm64 it
> > won't get built.Given the PMU name is unique, is it possible to put
> > this code into tools/perf/util and determine whether to use it or not
> > by seeing if the PMU is present by its name? I know that means
> > refactoring the x86 code that hasn't done this.
>
> Yes, iostat itself didn't do much more than rearrange the display
> format. I can try to refactor that to the util directory, though x86
> iostat may need even more testing :)
>
> > A thought that is away from the iostat code and may simplify the code
> > base is that we could introduce system PMU, rather than CPU, dependent
> > metrics. Perhaps the iostat code could be replaced by a particular
> > metric group like Default or TopdownL1, so `perf iostat` becomes
> > something of a synonym for `perf stat -M iostat`. An example of what
> > this may look like is (unmerged):
> > https://lore.kernel.org/lkml/20260108191105.695131-34-irogers@google.com/
> > where I introduce a memory bandwidth saturation metric dependent on
> > uncore PMUs (either cbox or cha) on Intel. There is a metric
> > "have_event" function that can be used to make a metric conditional.
> > If you `perf stat record` a metric today and then look at the
> > perf.data with `perf script --fields metric` (IIRC) then every metric
> > that has the recorded events within it will be computed, although the
> > code needs better testing, etc. I suspect the biggest downside to this
> > approach is in how the output looks, but perhaps that can be tweaked.
> > For example, the `ilist.py` command:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/python/ilist.py?h=perf-tools-next
> > supports regular metrics.
> Since iostat is a small sub-command with not many events involved,
> it is great to have some events extracted as system metrics, like PCIe
> bandwidth etc.
>
> But the variety of bdf filtering and display may be difficult to adapt
> to the way metric does it. What do you think if we leave the iostat as
> is for now and maybe merge it to system metric infrastructure later?
>
> > That said, I'm not against the changes, the arch directory usage, not
> > using json metrics, etc. and this change is doing clean up, following
> > existing patterns, etc. Sometimes the codebase has evolved but certain
> > commands haven't kept up. I think `perf iostat` is a command like
> > that.
>
> And we are trying to make it follow up!
Hi Yushan, thanks for your effort on iostat! Did you have chance to
work on follow up?
Thanks,
Ian
> > Thanks,
> > Ian
>
> Thanks for the feedback!
> Yushan
> >> tools/perf/arch/arm64/util/Build | 1 +
> >> tools/perf/arch/arm64/util/hisi-iostat.c | 479 +++++++++++++++++++++++
> >> tools/perf/arch/x86/util/iostat.c | 105 +++--
> >> tools/perf/builtin-script.c | 2 +-
> >> tools/perf/util/iostat.c | 79 ++--
> >> tools/perf/util/iostat.h | 21 +-
> >> tools/perf/util/pmus.c | 12 +-
> >> tools/perf/util/pmus.h | 3 +
> >> tools/perf/util/stat-display.c | 4 +-
> >> tools/perf/util/stat-shadow.c | 4 +-
> >> 10 files changed, 638 insertions(+), 72 deletions(-)
> >> create mode 100644 tools/perf/arch/arm64/util/hisi-iostat.c
> >>
> >> --
> >> 2.33.0
> >>
>
^ permalink raw reply
* [GIT PULL] Rockchip dts64 changes for 7.1 #2
From: Heiko Stuebner @ 2026-04-01 21:27 UTC (permalink / raw)
To: arm; +Cc: soc, linux-rockchip, linux-arm-kernel
Hi soc maintainers,
please find below some more Rockchip DT changes for the merge-window
for 7.1 .
This time they have also marinated longer in next without complaints.
Please pull.
Thanks
Heiko
The following changes since commit d7787a77cf8b129304f590233032556dec10dfc6:
arm64: dts: rockchip: enable vicap dvp on wolfvision pf5 io expander (2026-03-13 21:39:34 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.1-rockchip-dts64-2
for you to fetch changes up to 6cb4ec63ba9a5831621cf951b7af55c67beeb97b:
arm64: dts: rockchip: configure hdmirx in Rock 5 ITX (2026-03-26 00:34:54 +0100)
----------------------------------------------------------------
New board, the Khadas Edge 2L. Newly added peripherals are the
OTP nvmem controllers for RK3528, RK3562 and RK3566/8, SPDIF on RK3576.
The RK3566/8 SoCs now also control the Pipe-clocks on their PCIe
controllers and UFSHC controller on RK3576 got an additional reset line.
Apart from that are of course individual board changes and fixes for
older issues that are not specific to the current development cycle.
----------------------------------------------------------------
Anand Moon (1):
arm64: dts: rockchip: Enable PCIe CLKREQ# for RK3588 on Rock 5b-5bp-5t series
Chris Morgan (2):
arm64: dts: rockchip: Correct Fan Supply for Gameforce Ace
arm64: dts: rockchip: Correct Joystick Axes on Gameforce Ace
David Heidelberg (1):
arm64: dts: rockchip: assign pipe clock to rk356x PCIe lanes
Gray Huang (2):
dt-bindings: arm: rockchip: Add Khadas Edge 2L board
arm64: dts: rockchip: Add Khadas Edge 2L board
Heiko Stuebner (2):
arm64: dts: rockchip: Enable OTP controller for RK3562
arm64: dts: rockchip: Enable OTP controller for RK356x
Jonas Karlman (1):
arm64: dts: rockchip: Enable OTP controller for RK3528
Ming Wang (1):
arm64: dts: rockchip: Fix Bluetooth stability on LCKFB TaiShan Pi
Pedro Alves (1):
arm64: dts: rockchip: configure hdmirx in Rock 5 ITX
Robin Murphy (1):
Revert "arm64: dts: rockchip: add SPDIF audio to Beelink A1"
Sebastian Reichel (2):
arm64: dts: rockchip: Add SPDIF nodes to RK3576 device tree
arm64: dts: rockchip: add SD/eMMC aliases for ArmSom Sige5
Shawn Lin (1):
arm64: dts: rockchip: Add mphy reset to ufshc node
谢致邦 (XIE Zhibang) (1):
arm64: dts: rockchip: Fix RK3562 EVB2 model name
.../devicetree/bindings/arm/rockchip.yaml | 5 ++
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 23 ------
arch/arm64/boot/dts/rockchip/rk3528.dtsi | 47 ++++++++++++
arch/arm64/boot/dts/rockchip/rk3562-evb2-v10.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3562.dtsi | 46 ++++++++++++
arch/arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts | 4 +-
arch/arm64/boot/dts/rockchip/rk3568.dtsi | 12 ++-
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 52 ++++++++++++-
.../boot/dts/rockchip/rk3576-armsom-sige5.dts | 2 +
.../boot/dts/rockchip/rk3576-khadas-edge-2l.dts | 34 +++++++++
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 87 +++++++++++++++++++++-
arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 12 +++
.../boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 6 +-
.../boot/dts/rockchip/rk3588s-gameforce-ace.dts | 12 +--
15 files changed, 303 insertions(+), 42 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
^ permalink raw reply
* [GIT PULL] ARM: soc/omap updates for v7.1
From: Kevin Hilman @ 2026-04-01 21:28 UTC (permalink / raw)
To: soc; +Cc: linux-omap, linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git tags/omap-for-v7.1/soc-signed
for you to fetch changes up to 9ceb17ccd15ea32f19c9066f5f1b340d8340bd0b:
ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4 (2026-03-30 14:21:20 -0700)
----------------------------------------------------------------
ARM: soc/omap updates for v7.1
----------------------------------------------------------------
Aaro Koskinen (1):
ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX
Julian Braha (1):
ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4
Randy Dunlap (1):
ARM: omap: fix all kernel-doc warnings
Thorsten Blum (1):
ARM: omap2: Replace scnprintf with strscpy in omap3_cpuinfo
arch/arm/mach-omap1/clock_data.c | 4 ++--
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mach-omap2/id.c | 3 ++-
include/linux/platform_data/voltage-omap.h | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply
* [GIT PULL] arm: OMAP defconfig updates for v7.1
From: Kevin Hilman @ 2026-04-01 21:29 UTC (permalink / raw)
To: soc; +Cc: linux-omap, linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git tags/omap-for-v7.1/defconfig-signed
for you to fetch changes up to adcf290f9de2fc4768e5ba07c700e91faf9c86bf:
arm: multi_v7_defconfig: Enable more OMAP 3/4 related configs (2026-03-05 16:45:57 -0800)
----------------------------------------------------------------
arm: OMAP defconfig updates for v7.1
----------------------------------------------------------------
Andreas Kemnade (1):
arm: multi_v7_defconfig: Enable more OMAP 3/4 related configs
Kory Maincent (TI) (1):
ARM: multi_v7_defconfig: omap2plus_defconfig: Enable ITE IT66121 driver
arch/arm/configs/multi_v7_defconfig | 28 ++++++++++++++++++++++++++++
arch/arm/configs/omap2plus_defconfig | 1 +
2 files changed, 29 insertions(+)
^ permalink raw reply
* [GIT PULL] ARM: dts: updates for ti/omap for v7.1
From: Kevin Hilman @ 2026-04-01 21:29 UTC (permalink / raw)
To: soc; +Cc: linux-omap, linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git tags/omap-for-v7.1/dt-signed
for you to fetch changes up to 2c4059f54f65ff1ee2d430fa023d25487cfb5b99:
ARM: dts: am335x: Add Seeed Studio BeagleBone HDMI cape overlay (2026-03-31 17:15:17 -0700)
----------------------------------------------------------------
ARM: dts: updates for ti/omap for v7.1
----------------------------------------------------------------
Andrew Goodbody (1):
ARM: dts: omap: dm816x: Correct pinctrl register
Charan Pedumuru (1):
arm: dts: ti: omap: align node patterns with established convention
Kory Maincent (TI) (2):
ARM: dts: ti: Enable overlays for am335x BeagleBoard devicetrees
ARM: dts: am335x: Add Seeed Studio BeagleBone HDMI cape overlay
Mithil Bavishi (8):
ARM: dts: twl6032: Add DTS file for TWL6032 PMIC
dt-bindings: vendor-prefixes: Add Doestek
dt-bindings: display: bridge: lvds-codec: add doestek,dtc34lm85am
dt-bindings: display: panel-lvds: Add compatibles for Samsung LTN070NL01 and LTN101AL03 panels
ARM: dts: ti: omap: espresso-common: Add common device tree for Samsung Galaxy Tab 2 series
dt-bindings: omap: Add Samsung Galaxy Tab 2 7.0 and 10.1
ARM: dts: ti: omap: samsung-espresso7: Add initial support for Galaxy Tab 2 7.0
ARM: dts: ti: omap: samsung-espresso10: Add initial support for Galaxy Tab 2 10.1
Documentation/devicetree/bindings/arm/ti/omap.yaml | 2 +
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 4 +
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/ti/omap/Makefile | 15 ++++
arch/arm/boot/dts/ti/omap/am335x-bone-hdmi-00a0.dtso | 157 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/ti/omap/dm816x.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-samsung-espresso-common.dtsi | 744 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/ti/omap/omap4-samsung-espresso10.dts | 101 +++++++++++++++++++++
arch/arm/boot/dts/ti/omap/omap4-samsung-espresso7.dts | 70 +++++++++++++++
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/twl6032.dtsi | 77 ++++++++++++++++
14 files changed, 1180 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/ti/omap/am335x-bone-hdmi-00a0.dtso
create mode 100644 arch/arm/boot/dts/ti/omap/omap4-samsung-espresso-common.dtsi
create mode 100644 arch/arm/boot/dts/ti/omap/omap4-samsung-espresso10.dts
create mode 100644 arch/arm/boot/dts/ti/omap/omap4-samsung-espresso7.dts
create mode 100644 arch/arm/boot/dts/ti/omap/twl6032.dtsi
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.0.0-rc6, upstream-arm-next, 90aebc1e)
From: cki-project @ 2026-04-01 21:52 UTC (permalink / raw)
To: will, linux-arm-kernel, catalin.marinas
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge remote-tracking branch 'origin/nocache-cleanup' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2424361415
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v10 04/12] arm64: support WFET in smp_cond_load_relaxed_timeout()
From: Ankur Arora @ 2026-04-01 22:31 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ankur Arora, linux-kernel, linux-arch, linux-arm-kernel, linux-pm,
bpf, arnd, will, peterz, akpm, mark.rutland, harisokn, cl, ast,
rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai, rdunlap,
david.laight.linux, joao.m.martins, boris.ostrovsky, konrad.wilk
In-Reply-To: <acz3D1SkqDqyH0Dy@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> On Sun, Mar 15, 2026 at 06:36:43PM -0700, Ankur Arora wrote:
>> To handle WFET use __cmpwait_timeout() similarly to __cmpwait(). These
>> call out to the respective __cmpwait_case_timeout_##sz(),
>> __cmpwait_case_##sz() functions.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Great. Thanks Catalin.
--
ankur
^ permalink raw reply
* Re: [PATCH v15 4/5] ring-buffer: Add persistent ring buffer invalid-page inject test
From: Steven Rostedt @ 2026-04-01 22:40 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Catalin Marinas, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel
In-Reply-To: <177494619065.71933.9842685686800241005.stgit@mhiramat.tok.corp.google.com>
I replied with mostly grammar fixes and some rewrites of text.
On Tue, 31 Mar 2026 17:36:30 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> Add a self-destractive test for the persistent ring buffer.
"self-destractive"? Do you mean "self-destructive"?
Probably better to call it a "self-corrupting test".
>
> This will inject erroneous value to some sub-buffer pages (where
inject an erroneous
> the index is even or multiples of 5) in the persistent ring buffer
> when kernel gets panic, and check whether the number of detected
when the kernel panics, and checks whether
> invalid pages and the total entry_bytes are the same as recorded
same as the recorded
> values after reboot.
>
> This can ensure the kernel correctly recover partially corrupted
This ensures that the kernel can correctly recover a partially corrupted
> persistent ring buffer when boot.
after a reboot or panic.
>
> The test only runs on the persistent ring buffer whose name is
> "ptracingtest". And user has to fill it up with events before
The user has to fill it with events before a kernel panic.
> kernel panics.
>
> To run the test, enable CONFIG_RING_BUFFER_PERSISTENT_INJECT
> and you have to setup the kernel cmdline;
and add the following kernel cmdline:
Note, it's more proper to use a colon (:) than a semi-colon (;) when
referencing an example on the next line.
>
> reserve_mem=20M:2M:trace trace_instance=ptracingtest^traceoff@trace
> panic=1
>
> And run following commands after the 1st boot;
Run the following commands after the 1st boot:
>
> cd /sys/kernel/tracing/instances/ptracingtest
> echo 1 > tracing_on
> echo 1 > events/enable
> sleep 3
> echo c > /proc/sysrq-trigger
>
> After panic message, the kernel will reboot and run the verification
> on the persistent ring buffer, e.g.
>
> Ring buffer meta [2] invalid buffer page detected
> Ring buffer meta [2] is from previous boot! (318 pages discarded)
> Ring buffer testing [2] invalid pages: PASSED (318/318)
> Ring buffer testing [2] entry_bytes: PASSED (1300476/1300476)
>
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> ---
> Changes in v15:
> - Use pr_warn() for test result.
> - Inject errors on the page index is multiples of 5 so that
> this can reproduce contiguous empty pages.
> Changes in v14:
> - Rename config to CONFIG_RING_BUFFER_PERSISTENT_INJECT.
> - Clear meta->nr_invalid/entry_bytes after testing.
> - Add test commands in config comment.
> Changes in v10:
> - Add entry_bytes test.
> - Do not compile test code if CONFIG_RING_BUFFER_PERSISTENT_SELFTEST=n.
> Changes in v9:
> - Test also reader pages.
> ---
> include/linux/ring_buffer.h | 1 +
> kernel/trace/Kconfig | 31 ++++++++++++++++++
> kernel/trace/ring_buffer.c | 74 +++++++++++++++++++++++++++++++++++++++++++
> kernel/trace/trace.c | 4 ++
> 4 files changed, 110 insertions(+)
>
> diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
> index 994f52b34344..0670742b2d60 100644
> --- a/include/linux/ring_buffer.h
> +++ b/include/linux/ring_buffer.h
> @@ -238,6 +238,7 @@ int ring_buffer_subbuf_size_get(struct trace_buffer *buffer);
>
> enum ring_buffer_flags {
> RB_FL_OVERWRITE = 1 << 0,
> + RB_FL_TESTING = 1 << 1,
> };
>
> #ifdef CONFIG_RING_BUFFER
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index e130da35808f..07305ed6d745 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -1202,6 +1202,37 @@ config RING_BUFFER_VALIDATE_TIME_DELTAS
> Only say Y if you understand what this does, and you
> still want it enabled. Otherwise say N
>
> +config RING_BUFFER_PERSISTENT_INJECT
> + bool "Enable persistent ring buffer error injection test"
> + depends on RING_BUFFER
> + help
> + Run a selftest on the persistent ring buffer which names
> + "ptracingtest" (and its backup) when panic_on_reboot by
Does this do anything with the backup?
> + invalidating ring buffer pages.
This option will have the kernel check if the persistent ring
buffer is named "ptracingtest", and if so, it will corrupt some
of its pages on a kernel panic. This is used to test if the
persistent ring buffer can recover from some of its sub-buffers
being corrupted.
[space]
> + To use this, boot kernel with "ptracingtest" persistent
, boot a kernel with a "ptracingtest" persistent
> + ring buffer, e.g.
> +
> + reserve_mem=20M:2M:trace trace_instance=ptracingtest@trace panic=1
> +
> + And after the 1st boot, run test command, like;
, run the following commands:
> +
> + cd /sys/kernel/tracing/instances/ptracingtest
> + echo 1 > events/enable
> + echo 1 > tracing_on
> + sleep 3
> + echo c > /proc/sysrq-trigger
> +
> + After panic message, the kernel reboots and show test results
> + on the boot log.
After the panic message, the kernel will reboot and will show the
test results in the console output.
> +
> + Note that user has to enable events on the persistent ring
> + buffer manually to fill up ring buffers before rebooting.
Note that events for the ring buffer needs to be enabled prior to
crashing the kernel so that the ring buffer has content that the
test will corrupt.
> + Since this invalidates the data on test target ring buffer,
> + "ptracingtest" persistent ring buffer must not be used for
> + actual tracing, but only for testing.
As the test will corrupt events in the "ptracingtest" persistent
ring buffer, it should not be used for any other purpose other
than his test.
> +
> + If unsure, say N
> +
> config MMIOTRACE_TEST
> tristate "Test module for mmiotrace"
> depends on MMIOTRACE && m
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 5ff632ca3858..fb098b0b4505 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -64,6 +64,10 @@ struct ring_buffer_cpu_meta {
> unsigned long commit_buffer;
> __u32 subbuf_size;
> __u32 nr_subbufs;
> +#ifdef CONFIG_RING_BUFFER_PERSISTENT_INJECT
> + __u32 nr_invalid;
> + __u32 entry_bytes;
> +#endif
> int buffers[];
> };
>
> @@ -2079,6 +2083,21 @@ static void rb_meta_validate_events(struct
> ring_buffer_per_cpu *cpu_buffer) if (discarded)
> pr_cont(" (%d pages discarded)", discarded);
> pr_cont("\n");
> +
> +#ifdef CONFIG_RING_BUFFER_PERSISTENT_INJECT
> + if (meta->nr_invalid)
> + pr_warn("Ring buffer testing [%d] invalid pages: %s (%d/%d)\n",
> + cpu_buffer->cpu,
> + (discarded == meta->nr_invalid) ? "PASSED" : "FAILED",
> + discarded, meta->nr_invalid);
> + if (meta->entry_bytes)
> + pr_warn("Ring buffer testing [%d] entry_bytes: %s (%ld/%ld)\n",
> + cpu_buffer->cpu,
> + (entry_bytes == meta->entry_bytes) ? "PASSED" : "FAILED",
> + (long)entry_bytes, (long)meta->entry_bytes);
> + meta->nr_invalid = 0;
> + meta->entry_bytes = 0;
> +#endif
> return;
>
> invalid:
> @@ -2559,12 +2578,67 @@ static void rb_free_cpu_buffer(struct
> ring_buffer_per_cpu *cpu_buffer) kfree(cpu_buffer);
> }
>
> +#ifdef CONFIG_RING_BUFFER_PERSISTENT_INJECT
> +static void rb_test_inject_invalid_pages(struct trace_buffer *buffer)
> +{
> + struct ring_buffer_per_cpu *cpu_buffer;
> + struct ring_buffer_cpu_meta *meta;
> + struct buffer_data_page *dpage;
> + u32 entry_bytes = 0;
> + unsigned long ptr;
> + int subbuf_size;
> + int invalid = 0;
> + int cpu;
> + int i;
> +
> + if (!(buffer->flags & RB_FL_TESTING))
> + return;
> +
> + guard(preempt)();
> + cpu = smp_processor_id();
> +
> + cpu_buffer = buffer->buffers[cpu];
> + meta = cpu_buffer->ring_meta;
> + ptr = (unsigned long)rb_subbufs_from_meta(meta);
> + subbuf_size = meta->subbuf_size;
> +
> + for (i = 0; i < meta->nr_subbufs; i++) {
> + int idx = meta->buffers[i];
> +
> + dpage = (void *)(ptr + idx * subbuf_size);
> + /* Skip unused pages */
> + if (!local_read(&dpage->commit))
> + continue;
> +
> + /*
> + * Invalidate even pages or multiples of 5. This will lead 3
This will cause 3
-- Steve
> + * contiguous invalidated(empty) pages.
> + */
> + if (!(i & 0x1) || !(i % 5)) {
> + local_add(subbuf_size + 1, &dpage->commit);
> + invalid++;
> + } else {
> + /* Count total commit bytes. */
> + entry_bytes += local_read(&dpage->commit);
> + }
> + }
> +
> + pr_info("Inject invalidated %d pages on CPU%d, total size: %ld\n",
> + invalid, cpu, (long)entry_bytes);
> + meta->nr_invalid = invalid;
> + meta->entry_bytes = entry_bytes;
> +}
^ permalink raw reply
* Re: [PATCH v3 2/2] dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
From: Frank Li @ 2026-04-01 22:40 UTC (permalink / raw)
To: Alex Bereza
Cc: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana,
dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v3-2-85508f0aedde@bereza.email>
On Wed, Apr 01, 2026 at 12:56:33PM +0200, Alex Bereza wrote:
> Rename XILINX_DMA_LOOP_COUNT to XILINX_DMA_POLL_TIMEOUT_US because the
> former is incorrect. It is a timeout value for polling various register
> bits in microseconds. It is not a loop count.
Rename XILINX_DMA_LOOP_COUNT to XILINX_DMA_POLL_TIMEOUT_US because it is a
timeout value, not a loop count for polling register in microseconds.
No functional changes.
Frank
>
> Signed-off-by: Alex Bereza <alex@bereza.email>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 345a738bab2c..253c27fd1a0e 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -165,8 +165,8 @@
> #define XILINX_DMA_FLUSH_MM2S 2
> #define XILINX_DMA_FLUSH_BOTH 1
>
> -/* Delay loop counter to prevent hardware failure */
> -#define XILINX_DMA_LOOP_COUNT 1000000
> +/* Timeout for polling various registers */
> +#define XILINX_DMA_POLL_TIMEOUT_US 1000000
> /* Delay between polls (avoid a delay of 0 to prevent CPU stalls) */
> #define XILINX_DMA_POLL_DELAY_US 10
>
> @@ -1336,7 +1336,7 @@ static int xilinx_dma_stop_transfer(struct xilinx_dma_chan *chan)
> return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> val & XILINX_DMA_DMASR_HALTED,
> XILINX_DMA_POLL_DELAY_US,
> - XILINX_DMA_LOOP_COUNT);
> + XILINX_DMA_POLL_TIMEOUT_US);
> }
>
> /**
> @@ -1352,7 +1352,7 @@ static int xilinx_cdma_stop_transfer(struct xilinx_dma_chan *chan)
> return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> val & XILINX_DMA_DMASR_IDLE,
> XILINX_DMA_POLL_DELAY_US,
> - XILINX_DMA_LOOP_COUNT);
> + XILINX_DMA_POLL_TIMEOUT_US);
> }
>
> /**
> @@ -1370,7 +1370,7 @@ static void xilinx_dma_start(struct xilinx_dma_chan *chan)
> err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> !(val & XILINX_DMA_DMASR_HALTED),
> XILINX_DMA_POLL_DELAY_US,
> - XILINX_DMA_LOOP_COUNT);
> + XILINX_DMA_POLL_TIMEOUT_US);
>
> if (err) {
> dev_err(chan->dev, "Cannot start channel %p: %x\n",
> @@ -1787,7 +1787,7 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
> err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMACR, tmp,
> !(tmp & XILINX_DMA_DMACR_RESET),
> XILINX_DMA_POLL_DELAY_US,
> - XILINX_DMA_LOOP_COUNT);
> + XILINX_DMA_POLL_TIMEOUT_US);
>
> if (err) {
> dev_err(chan->dev, "reset timeout, cr %x, sr %x\n",
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Frank Li @ 2026-04-01 22:45 UTC (permalink / raw)
To: Alex Bereza
Cc: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana,
dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260401-fix-atomic-poll-timeout-regression-v3-1-85508f0aedde@bereza.email>
On Wed, Apr 01, 2026 at 12:56:32PM +0200, Alex Bereza wrote:
> Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a
> condition that is never fulfilled, the CPU busy-waits for prolonged time
> and the timeout triggers only with a massive delay causing a CPU stall.
>
> This happens due to a huge underestimation of wall clock time in
> poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use
> timekeeping in read_poll_timeout_atomic()") changed the behavior to no
> longer use ktime_get at the expense of underestimation of wall clock
> time which appears to be very large for delay_us=0. Instead of timing
> out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout
> takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for
> loop in poll_timeout_us_atomic takes) which is in the range of several
> minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero
> value for delay_us. Use delay_us=10 to keep the delay in the hot path of
> starting DMA transfers minimal but still avoid CPU stalls in case of
> unexpected hardware failures.
>
> One-off measurement with delay_us=0 causes the cpu to busy wait around 7
> minutes in the timeout case. After applying this patch with delay_us=10
> the measured timeout was 1053428 microseconds which is roughly
> equivalent to the expected 1000000 microseconds specified in
> XILINX_DMA_LOOP_COUNT.
>
> Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.
>
> Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's")
> Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()")
> Signed-off-by: Alex Bereza <alex@bereza.email>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/dma/xilinx/xilinx_dma.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 02a05f215614..345a738bab2c 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -167,6 +167,8 @@
>
> /* Delay loop counter to prevent hardware failure */
> #define XILINX_DMA_LOOP_COUNT 1000000
> +/* Delay between polls (avoid a delay of 0 to prevent CPU stalls) */
> +#define XILINX_DMA_POLL_DELAY_US 10
>
> /* AXI DMA Specific Registers/Offsets */
> #define XILINX_DMA_REG_SRCDSTADDR 0x18
> @@ -1332,7 +1334,8 @@ static int xilinx_dma_stop_transfer(struct xilinx_dma_chan *chan)
>
> /* Wait for the hardware to halt */
> return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> - val & XILINX_DMA_DMASR_HALTED, 0,
> + val & XILINX_DMA_DMASR_HALTED,
> + XILINX_DMA_POLL_DELAY_US,
> XILINX_DMA_LOOP_COUNT);
> }
>
> @@ -1347,7 +1350,8 @@ static int xilinx_cdma_stop_transfer(struct xilinx_dma_chan *chan)
> u32 val;
>
> return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> - val & XILINX_DMA_DMASR_IDLE, 0,
> + val & XILINX_DMA_DMASR_IDLE,
> + XILINX_DMA_POLL_DELAY_US,
> XILINX_DMA_LOOP_COUNT);
> }
>
> @@ -1364,7 +1368,8 @@ static void xilinx_dma_start(struct xilinx_dma_chan *chan)
>
> /* Wait for the hardware to start */
> err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
> - !(val & XILINX_DMA_DMASR_HALTED), 0,
> + !(val & XILINX_DMA_DMASR_HALTED),
> + XILINX_DMA_POLL_DELAY_US,
> XILINX_DMA_LOOP_COUNT);
>
> if (err) {
> @@ -1780,7 +1785,8 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
>
> /* Wait for the hardware to finish reset */
> err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMACR, tmp,
> - !(tmp & XILINX_DMA_DMACR_RESET), 0,
> + !(tmp & XILINX_DMA_DMACR_RESET),
> + XILINX_DMA_POLL_DELAY_US,
> XILINX_DMA_LOOP_COUNT);
>
> if (err) {
>
> --
> 2.53.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox