* [PATCH v9 06/20] coresight: etm3x: Set per-CPU path on local CPU
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>
Set the path pointer on the local CPU during ETMv3 enable and disable
operations.
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-etm3x-core.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
index aeeb284abdbe4b6a0960da45baa1138e203f3e3c..46ea66b5cf1985bd7129688f175f6f92372d04ad 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
@@ -441,6 +441,7 @@ static int etm_enable_hw(struct etm_drvdata *drvdata)
struct etm_enable_arg {
struct etm_drvdata *drvdata;
+ struct coresight_path *path;
int rc;
};
@@ -462,8 +463,12 @@ static void etm_enable_sysfs_smp_call(void *info)
arg->rc = etm_enable_hw(arg->drvdata);
/* The tracer didn't start */
- if (arg->rc)
+ if (arg->rc) {
coresight_set_mode(csdev, CS_MODE_DISABLED);
+ return;
+ }
+
+ coresight_set_percpu_local_path(arg->path);
}
void etm_release_trace_id(struct etm_drvdata *drvdata)
@@ -492,10 +497,13 @@ static int etm_enable_perf(struct coresight_device *csdev,
ret = etm_enable_hw(drvdata);
/* Failed to start tracer; roll back to DISABLED mode */
- if (ret)
+ if (ret) {
coresight_set_mode(csdev, CS_MODE_DISABLED);
+ return ret;
+ }
- return ret;
+ coresight_set_percpu_local_path(path);
+ return 0;
}
static int etm_enable_sysfs(struct coresight_device *csdev, struct coresight_path *path)
@@ -514,6 +522,7 @@ static int etm_enable_sysfs(struct coresight_device *csdev, struct coresight_pat
*/
if (cpu_online(drvdata->cpu)) {
arg.drvdata = drvdata;
+ arg.path = path;
ret = smp_call_function_single(drvdata->cpu,
etm_enable_sysfs_smp_call, &arg, 1);
if (!ret)
@@ -583,6 +592,7 @@ static void etm_disable_sysfs_smp_call(void *info)
etm_disable_hw(drvdata);
+ coresight_set_percpu_local_path(NULL);
coresight_set_mode(drvdata->csdev, CS_MODE_DISABLED);
}
@@ -607,6 +617,7 @@ static void etm_disable_perf(struct coresight_device *csdev)
CS_LOCK(drvdata->csa.base);
+ coresight_set_percpu_local_path(NULL);
coresight_set_mode(drvdata->csdev, CS_MODE_DISABLED);
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v9 04/20] coresight: Take hotplug lock in enable_source_store() for Sysfs mode
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, Mike Leach
In-Reply-To: <20260401-arm_coresight_path_power_management_improvement-v9-0-091d73e44072@arm.com>
The hotplug lock is acquired and released in etm{3|4}_disable_sysfs(),
which are low-level functions. This prevents us from a new solution for
hotplug.
Firstly, hotplug callbacks cannot invoke etm{3|4}_disable_sysfs() to
disable the source; otherwise, a deadlock issue occurs. The reason is
that, in the hotplug flow, the kernel acquires the hotplug lock before
calling callbacks. Subsequently, if coresight_disable_source() is
invoked and it calls etm{3|4}_disable_sysfs(), the hotplug lock will be
acquired twice, leading to a double lock issue.
Secondly, when hotplugging a CPU on or off, if we want to manipulate all
components on a path attached to the CPU, we need to maintain atomicity
for the entire path. Otherwise, a race condition may occur with users
setting the same path via the Sysfs knobs, ultimately causing mess
states in CoreSight components.
This patch moves the hotplug locking from etm{3|4}_disable_sysfs() into
enable_source_store(). As a result, when users control the Sysfs knobs,
the whole flow is protected by hotplug locking, ensuring it is mutual
exclusive with hotplug callbacks.
Note, the paired function etm{3|4}_enable_sysfs() does not use hotplug
locking, which is why this patch does not modify it.
Reviewed-by: Mike Leach <mike.leach@linaro.org>
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-etm3x-core.c | 8 --------
drivers/hwtracing/coresight/coresight-etm4x-core.c | 9 ---------
drivers/hwtracing/coresight/coresight-sysfs.c | 7 +++++++
3 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
index ab47f69e923fb191b48b82367dce465c79b3a93d..aeeb284abdbe4b6a0960da45baa1138e203f3e3c 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
@@ -620,13 +620,6 @@ static void etm_disable_sysfs(struct coresight_device *csdev)
{
struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
- /*
- * Taking hotplug lock here protects from clocks getting disabled
- * with tracing being left on (crash scenario) if user disable occurs
- * after cpu online mask indicates the cpu is offline but before the
- * DYING hotplug callback is serviced by the ETM driver.
- */
- cpus_read_lock();
spin_lock(&drvdata->spinlock);
/*
@@ -637,7 +630,6 @@ static void etm_disable_sysfs(struct coresight_device *csdev)
drvdata, 1);
spin_unlock(&drvdata->spinlock);
- cpus_read_unlock();
/*
* we only release trace IDs when resetting sysfs.
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 66a8058098376264d3f8c5815763a75ebffb352e..a776ebb3b2b0360c99a8dadacfde4c2303dd59d6 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -1106,13 +1106,6 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
- /*
- * Taking hotplug lock here protects from clocks getting disabled
- * with tracing being left on (crash scenario) if user disable occurs
- * after cpu online mask indicates the cpu is offline but before the
- * DYING hotplug callback is serviced by the ETM driver.
- */
- cpus_read_lock();
raw_spin_lock(&drvdata->spinlock);
/*
@@ -1126,8 +1119,6 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
cscfg_csdev_disable_active_config(csdev);
- cpus_read_unlock();
-
/*
* we only release trace IDs when resetting sysfs.
* This permits sysfs users to read the trace ID after the trace
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index 3b1e7152dd108408d837c404ce607ba511ca14a6..f398dbfbcb8de0c5a873837c19b3fdcf97b64abe 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -360,6 +360,13 @@ static ssize_t enable_source_store(struct device *dev,
if (ret)
return ret;
+ /*
+ * CoreSight hotplug callbacks in core layer control a activated path
+ * from its source to sink. Taking hotplug lock here protects a race
+ * condition with hotplug callbacks.
+ */
+ guard(cpus_read_lock)();
+
if (val) {
ret = coresight_enable_sysfs(csdev);
if (ret)
--
2.34.1
^ permalink raw reply related
* [PATCH v9 03/20] coresight: Remove .cpu_id() callback from source ops
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 CPU ID can be fetched directly from the coresight_device structure,
so the .cpu_id() callback is no longer needed.
Remove the .cpu_id() callback from source ops and update callers
accordingly.
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 8 ++++----
drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
drivers/hwtracing/coresight/coresight-etm3x-core.c | 8 --------
drivers/hwtracing/coresight/coresight-etm4x-core.c | 8 --------
drivers/hwtracing/coresight/coresight-sysfs.c | 4 ++--
include/linux/coresight.h | 3 ---
6 files changed, 7 insertions(+), 26 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 89911fc27128b2bb78c8ba704f2af5a5d4efe83c..6907da35ed02fa58f8d30f5576627a6ce3b88362 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -787,7 +787,7 @@ static int _coresight_build_path(struct coresight_device *csdev,
goto out;
if (coresight_is_percpu_source(csdev) && coresight_is_percpu_sink(sink) &&
- sink == per_cpu(csdev_sink, source_ops(csdev)->cpu_id(csdev))) {
+ sink == per_cpu(csdev_sink, csdev->cpu)) {
if (_coresight_build_path(sink, source, sink, path) == 0) {
found = true;
goto out;
@@ -1014,7 +1014,7 @@ coresight_find_default_sink(struct coresight_device *csdev)
/* look for a default sink if we have not found for this device */
if (!csdev->def_sink) {
if (coresight_is_percpu_source(csdev))
- csdev->def_sink = per_cpu(csdev_sink, source_ops(csdev)->cpu_id(csdev));
+ csdev->def_sink = per_cpu(csdev_sink, csdev->cpu);
if (!csdev->def_sink)
csdev->def_sink = coresight_find_sink(csdev, &depth);
}
@@ -1752,10 +1752,10 @@ int coresight_etm_get_trace_id(struct coresight_device *csdev, enum cs_mode mode
{
int cpu, trace_id;
- if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE || !source_ops(csdev)->cpu_id)
+ if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE)
return -EINVAL;
- cpu = source_ops(csdev)->cpu_id(csdev);
+ cpu = csdev->cpu;
switch (mode) {
case CS_MODE_SYSFS:
trace_id = coresight_trace_id_get_cpu_id(cpu);
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f85dedf89a3f9e85d568ca4c320fa6fa6d9059ff..cae6738e9906c35d291e4b0f3feae37306b95c06 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -824,7 +824,7 @@ static void etm_addr_filters_sync(struct perf_event *event)
int etm_perf_symlink(struct coresight_device *csdev, bool link)
{
char entry[sizeof("cpu9999999")];
- int ret = 0, cpu = source_ops(csdev)->cpu_id(csdev);
+ int ret = 0, cpu = csdev->cpu;
struct device *pmu_dev = etm_pmu.dev;
struct device *cs_dev = &csdev->dev;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
index eb665db1a37d9970f7f55395c0aa23b98a7f3118..ab47f69e923fb191b48b82367dce465c79b3a93d 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
@@ -466,13 +466,6 @@ static void etm_enable_sysfs_smp_call(void *info)
coresight_set_mode(csdev, CS_MODE_DISABLED);
}
-static int etm_cpu_id(struct coresight_device *csdev)
-{
- struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
-
- return drvdata->cpu;
-}
-
void etm_release_trace_id(struct etm_drvdata *drvdata)
{
coresight_trace_id_put_cpu_id(drvdata->cpu);
@@ -684,7 +677,6 @@ static void etm_disable(struct coresight_device *csdev,
}
static const struct coresight_ops_source etm_source_ops = {
- .cpu_id = etm_cpu_id,
.enable = etm_enable,
.disable = etm_disable,
};
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index b1e0254a534027d7ede8591e56be28745d0b9974..66a8058098376264d3f8c5815763a75ebffb352e 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -227,13 +227,6 @@ static void etm4_cs_unlock(struct etmv4_drvdata *drvdata,
CS_UNLOCK(csa->base);
}
-static int etm4_cpu_id(struct coresight_device *csdev)
-{
- struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
-
- return drvdata->cpu;
-}
-
void etm4_release_trace_id(struct etmv4_drvdata *drvdata)
{
coresight_trace_id_put_cpu_id(drvdata->cpu);
@@ -1201,7 +1194,6 @@ static void etm4_pause_perf(struct coresight_device *csdev)
}
static const struct coresight_ops_source etm4_source_ops = {
- .cpu_id = etm4_cpu_id,
.enable = etm4_enable,
.disable = etm4_disable,
.resume_perf = etm4_resume_perf,
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index d2a6ed8bcc74d64dccc735463f14790b4e80d101..3b1e7152dd108408d837c404ce607ba511ca14a6 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -232,7 +232,7 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
* be a single session per tracer (when working from sysFS)
* a per-cpu variable will do just fine.
*/
- cpu = source_ops(csdev)->cpu_id(csdev);
+ cpu = csdev->cpu;
per_cpu(tracer_path, cpu) = path;
break;
case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:
@@ -282,7 +282,7 @@ void coresight_disable_sysfs(struct coresight_device *csdev)
switch (csdev->subtype.source_subtype) {
case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
- cpu = source_ops(csdev)->cpu_id(csdev);
+ cpu = csdev->cpu;
path = per_cpu(tracer_path, cpu);
per_cpu(tracer_path, cpu) = NULL;
break;
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 687190ca11ddeaa83193caa3903a480bac3060d1..e9c20ceb9016fa3db256b8c1147c1fd2027b7b0d 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -395,15 +395,12 @@ struct coresight_ops_link {
/**
* struct coresight_ops_source - basic operations for a source
* Operations available for sources.
- * @cpu_id: returns the value of the CPU number this component
- * is associated to.
* @enable: enables tracing for a source.
* @disable: disables tracing for a source.
* @resume_perf: resumes tracing for a source in perf session.
* @pause_perf: pauses tracing for a source in perf session.
*/
struct coresight_ops_source {
- int (*cpu_id)(struct coresight_device *csdev);
int (*enable)(struct coresight_device *csdev, struct perf_event *event,
enum cs_mode mode, struct coresight_path *path);
void (*disable)(struct coresight_device *csdev,
--
2.34.1
^ permalink raw reply related
* [PATCH v9 01/20] coresight: Extract device init into coresight_init_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>
This commit extracts the allocation and initialization of the coresight
device structure into a separate function to make future extensions
easier.
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 46f247f73cf64a97b9353b84ba5b76b991676f5f..5452de9367d450de399a2107016c3fddb894fc82 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1322,20 +1322,16 @@ void coresight_release_platform_data(struct device *dev,
devm_kfree(dev, pdata);
}
-struct coresight_device *coresight_register(struct coresight_desc *desc)
+static struct coresight_device *
+coresight_init_device(struct coresight_desc *desc)
{
- int ret;
struct coresight_device *csdev;
- bool registered = false;
csdev = kzalloc_obj(*csdev);
- if (!csdev) {
- ret = -ENOMEM;
- goto err_out;
- }
+ if (!csdev)
+ return ERR_PTR(-ENOMEM);
csdev->pdata = desc->pdata;
-
csdev->type = desc->type;
csdev->subtype = desc->subtype;
csdev->ops = desc->ops;
@@ -1348,6 +1344,21 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
csdev->dev.release = coresight_device_release;
csdev->dev.bus = &coresight_bustype;
+ return csdev;
+}
+
+struct coresight_device *coresight_register(struct coresight_desc *desc)
+{
+ int ret;
+ struct coresight_device *csdev;
+ bool registered = false;
+
+ csdev = coresight_init_device(desc);
+ if (IS_ERR(csdev)) {
+ ret = PTR_ERR(csdev);
+ goto err_out;
+ }
+
if (csdev->type == CORESIGHT_DEV_TYPE_SINK ||
csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) {
raw_spin_lock_init(&csdev->perf_sink_id_map.lock);
--
2.34.1
^ permalink raw reply related
* [PATCH v9 02/20] coresight: Populate CPU ID into coresight_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>
Add a new flag CORESIGHT_DESC_CPU_BOUND to indicate components that
are CPU bound. Populate CPU ID into the coresight_device structure;
otherwise, set CPU ID to -1 for non CPU bound devices.
Use the {0} initializer to clear coresight_desc structures to avoid
uninitialized values.
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
drivers/hwtracing/coresight/coresight-catu.c | 2 +-
drivers/hwtracing/coresight/coresight-core.c | 13 +++++++++++++
drivers/hwtracing/coresight/coresight-cti-core.c | 9 ++++++---
drivers/hwtracing/coresight/coresight-etm3x-core.c | 2 ++
drivers/hwtracing/coresight/coresight-etm4x-core.c | 2 ++
drivers/hwtracing/coresight/coresight-trbe.c | 2 ++
include/linux/coresight.h | 8 ++++++++
7 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
index ce71dcddfca2558eddd625de58a709b151f2e07e..43abe13995cf3c96e70dcf97856872d70f71345a 100644
--- a/drivers/hwtracing/coresight/coresight-catu.c
+++ b/drivers/hwtracing/coresight/coresight-catu.c
@@ -514,7 +514,7 @@ static int __catu_probe(struct device *dev, struct resource *res)
int ret = 0;
u32 dma_mask;
struct catu_drvdata *drvdata;
- struct coresight_desc catu_desc;
+ struct coresight_desc catu_desc = { 0 };
struct coresight_platform_data *pdata = NULL;
void __iomem *base;
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 5452de9367d450de399a2107016c3fddb894fc82..89911fc27128b2bb78c8ba704f2af5a5d4efe83c 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1338,6 +1338,19 @@ coresight_init_device(struct coresight_desc *desc)
csdev->access = desc->access;
csdev->orphan = true;
+ if (desc->flags & CORESIGHT_DESC_CPU_BOUND) {
+ csdev->cpu = desc->cpu;
+ } else {
+ /* A per-CPU source or sink must set CPU_BOUND flag */
+ if (coresight_is_percpu_source(csdev) ||
+ coresight_is_percpu_sink(csdev)) {
+ kfree(csdev);
+ return ERR_PTR(-EINVAL);
+ }
+
+ csdev->cpu = -1;
+ }
+
csdev->dev.type = &coresight_dev_type[desc->type];
csdev->dev.groups = desc->groups;
csdev->dev.parent = desc->dev;
diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
index 2f4c9362709a90b12a1aeb5016905b7d4474b912..b2c9a4db13b4e5554bca565c17ed299fdfdb30ff 100644
--- a/drivers/hwtracing/coresight/coresight-cti-core.c
+++ b/drivers/hwtracing/coresight/coresight-cti-core.c
@@ -659,7 +659,7 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
void __iomem *base;
struct device *dev = &adev->dev;
struct cti_drvdata *drvdata = NULL;
- struct coresight_desc cti_desc;
+ struct coresight_desc cti_desc = { 0 };
struct coresight_platform_data *pdata = NULL;
struct resource *res = &adev->res;
@@ -702,11 +702,14 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
* eCPU ID. System CTIs will have the name cti_sys<I> where I is an
* index allocated by order of discovery.
*/
- if (drvdata->ctidev.cpu >= 0)
+ if (drvdata->ctidev.cpu >= 0) {
+ cti_desc.cpu = drvdata->ctidev.cpu;
+ cti_desc.flags = CORESIGHT_DESC_CPU_BOUND;
cti_desc.name = devm_kasprintf(dev, GFP_KERNEL, "cti_cpu%d",
drvdata->ctidev.cpu);
- else
+ } else {
cti_desc.name = coresight_alloc_device_name("cti_sys", dev);
+ }
if (!cti_desc.name)
return -ENOMEM;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
index a547a6d2e0bde84748f753e5529d316c4f5e82e2..eb665db1a37d9970f7f55395c0aa23b98a7f3118 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
@@ -891,6 +891,8 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
desc.pdata = pdata;
desc.dev = dev;
desc.groups = coresight_etm_groups;
+ desc.cpu = drvdata->cpu;
+ desc.flags = CORESIGHT_DESC_CPU_BOUND;
drvdata->csdev = coresight_register(&desc);
if (IS_ERR(drvdata->csdev))
return PTR_ERR(drvdata->csdev);
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index d565a73f0042e3e0b21fcf9cb94009cc25834d3d..b1e0254a534027d7ede8591e56be28745d0b9974 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -2260,6 +2260,8 @@ static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg)
desc.pdata = pdata;
desc.dev = dev;
desc.groups = coresight_etmv4_groups;
+ desc.cpu = drvdata->cpu;
+ desc.flags = CORESIGHT_DESC_CPU_BOUND;
drvdata->csdev = coresight_register(&desc);
if (IS_ERR(drvdata->csdev))
return PTR_ERR(drvdata->csdev);
diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
index 1511f8eb95afb5b4610b8fbdacc8b174b6b08530..14e35b9660d76e47619cc6026b94929b3bb3e02b 100644
--- a/drivers/hwtracing/coresight/coresight-trbe.c
+++ b/drivers/hwtracing/coresight/coresight-trbe.c
@@ -1289,6 +1289,8 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp
desc.ops = &arm_trbe_cs_ops;
desc.groups = arm_trbe_groups;
desc.dev = dev;
+ desc.cpu = cpu;
+ desc.flags = CORESIGHT_DESC_CPU_BOUND;
trbe_csdev = coresight_register(&desc);
if (IS_ERR(trbe_csdev))
goto cpu_clear;
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 2131febebee93d609df1aea8534a10898b600be2..687190ca11ddeaa83193caa3903a480bac3060d1 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -141,6 +141,8 @@ struct csdev_access {
.base = (_addr), \
})
+#define CORESIGHT_DESC_CPU_BOUND BIT(0)
+
/**
* struct coresight_desc - description of a component required from drivers
* @type: as defined by @coresight_dev_type.
@@ -153,6 +155,8 @@ struct csdev_access {
* in the component's sysfs sub-directory.
* @name: name for the coresight device, also shown under sysfs.
* @access: Describe access to the device
+ * @flags: The descritpion flags.
+ * @cpu: The CPU this component is affined to.
*/
struct coresight_desc {
enum coresight_dev_type type;
@@ -163,6 +167,8 @@ struct coresight_desc {
const struct attribute_group **groups;
const char *name;
struct csdev_access access;
+ u32 flags;
+ int cpu;
};
/**
@@ -260,6 +266,7 @@ struct coresight_trace_id_map {
* device's spinlock when the coresight_mutex held and mode ==
* CS_MODE_SYSFS. Otherwise it must be accessed from inside the
* spinlock.
+ * @cpu: The CPU this component is affined to (-1 for not CPU bound).
* @orphan: true if the component has connections that haven't been linked.
* @sysfs_sink_activated: 'true' when a sink has been selected for use via sysfs
* by writing a 1 to the 'enable_sink' file. A sink can be
@@ -286,6 +293,7 @@ struct coresight_device {
struct device dev;
atomic_t mode;
int refcnt;
+ int cpu;
bool orphan;
/* sink specific fields */
bool sysfs_sink_activated;
--
2.34.1
^ permalink raw reply related
* [PATCH v9 00/20] CoreSight: Refactor power management for CoreSight path
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, Mike Leach
This series focuses on CoreSight path power management. The changes can
be divided into four parts for review:
Patches 01 - 04: Refactor the CPU ID storing in csdev, later patches
consume csdev->cpu. Move CPU lock to sysfs layer so
it is safe for later changes.
Patches 05 - 09: Refactor the CPU idle flow with moving common code into
the CoreSight core layer.
Patches 10 - 15: Refactor path enabling and disabling with range, add
path control during CPU idle.
Patches 16 - 17: Support the sink (TRBE) control during CPU idle.
Patches 18 - 20: Move CPU hotplug into the core layer, and fix sysfs
mode for hotplug.
This series is rebased on the coresight-next branch and has been verified
on Juno-r2 (ETM + ETR) and FVP RevC (ETE + TRBE). Built successfully
for armv7 (ARCH=arm).
---
Changes in v9:
- Changed to use per-CPU path pointer with lockless access.
- Removed the change for adding csdev->path, the related refactoring
will be sent separately.
- Re-orged patches to avoid intermediate breakage (sashiko).
- Link to v8: https://lore.kernel.org/r/20260325-arm_coresight_path_power_management_improvement-v8-0-7b1902e18041@arm.com
Changes in v8:
- Moved the "cpu" field in coresight_device for better pack with new
patch 01 (Suzuki).
- Added check if not set CPU for per_cpu_source/per_cpu_sink (Suzuki).
- Renamed spinlock name in syscfg (Suzuki).
- Refactored paired enable and disable path with new patches
10 and 12 (Suzuki).
- Link to v7: https://lore.kernel.org/r/20260320-arm_coresight_path_power_management_improvement-v7-0-327ddd36b58b@arm.com
Changes in v7:
- Added a flag in coresight_desc to indicate CPU bound device (Suzuki).
- Used coresight_mutex to protect per-CPU source pointer (Suzuki).
- Added a spinlock for exclusive access per-CPU source pointer (Suzuki).
- Dropped .pm_is_needed() callback (Suzuki).
- Supported range in path enabling / disabling (Suzuki).
- Gathered test and review tags (Levi / James).
- Link to v6: https://lore.kernel.org/r/20260305-arm_coresight_path_power_management_improvement-v6-0-eff765d211a9@arm.com
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
Leo Yan (19):
coresight: Extract device init into coresight_init_device()
coresight: Populate CPU ID into coresight_device
coresight: Remove .cpu_id() callback from source ops
coresight: Take hotplug lock in enable_source_store() for Sysfs mode
coresight: etm4x: Set per-CPU path on local CPU
coresight: etm3x: Set per-CPU path on local CPU
coresight: Register CPU PM notifier in core layer
coresight: etm4x: Hook CPU PM callbacks
coresight: etm4x: Remove redundant condition checks in save and restore
coresight: syscfg: Use spinlock to protect active variables
coresight: Move source helper disabling to coresight_disable_path()
coresight: Control path with range
coresight: Use helpers to fetch first and last nodes
coresight: Introduce coresight_enable_source() helper
coresight: Control path during CPU idle
coresight: Add PM callbacks for sink device
coresight: sysfs: Increment refcount only for system tracers
coresight: Move CPU hotplug callbacks to core layer
coresight: sysfs: Validate CPU online status for per-CPU sources
Yabin Cui (1):
coresight: trbe: Save and restore state across CPU low power state
drivers/hwtracing/coresight/coresight-catu.c | 2 +-
drivers/hwtracing/coresight/coresight-core.c | 371 ++++++++++++++++++---
drivers/hwtracing/coresight/coresight-cti-core.c | 9 +-
drivers/hwtracing/coresight/coresight-etm-perf.c | 4 +-
drivers/hwtracing/coresight/coresight-etm3x-core.c | 73 +---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 156 ++-------
drivers/hwtracing/coresight/coresight-priv.h | 4 +
drivers/hwtracing/coresight/coresight-syscfg.c | 21 +-
drivers/hwtracing/coresight/coresight-syscfg.h | 2 +
drivers/hwtracing/coresight/coresight-sysfs.c | 50 ++-
drivers/hwtracing/coresight/coresight-trbe.c | 61 +++-
include/linux/coresight.h | 13 +-
12 files changed, 503 insertions(+), 263 deletions(-)
---
base-commit: ec687ba84000d7d50cf243558041f6729d1d8119
change-id: 20251104-arm_coresight_path_power_management_improvement-dab4966f8280
Best regards,
--
Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* RE: Re: Re: Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 18:03 UTC (permalink / raw)
To: Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <ac1T282yvpdAp_TP@e142607>
Hi Liviu
Thanks a lot for your sharing.
> On Wed, Apr 01, 2026 at 03:59:23PM +0000, Guangliu Ding wrote:
> > Hi Liviu
> >
> > > On Wed, Apr 01, 2026 at 10:31:01AM +0000, Guangliu Ding wrote:
> > > > Hi Liviu
> > > >
> > > > > On Wed, Apr 01, 2026 at 09:43:12AM +0000, Guangliu Ding wrote:
> > > > > > Hi Daniel
> > > > > >
> > > > > > > On 4/1/26 11:48, Guangliu Ding wrote:
> > > > > > > > [You don't often get email from guangliu.ding@nxp.com.
> > > > > > > > Learn why this is important at
> > > > > > > > https://aka.ms/LearnAboutSenderIdentification
> > > > > > > > ]
> > > > > > > >
> > > > > > > > Hi Liviu
> > > > > > > >
> > > > > > > > Thanks for your review. Please refer to my comments below:
> > > > > > > >
> > > > > > > >> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding
> wrote:
> > > > > > > >>> Add compatible string of Mali G310 GPU on i.MX952 board.
> > > > > > > >>>
> > > > > > > >>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > > > > > > >>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> > > > > > > >>> ---
> > > > > > > >>>
> > > > > > > >>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-c
> > > > > > > >>> sf.y
> > > > > > > >>> aml
> > > > > > > >>> | 1
> > > > > > > >>> +
> > > > > > > >>> 1 file changed, 1 insertion(+)
> > > > > > > >>>
> > > > > > > >>> diff --git
> > > > > > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall
> > > > > > > >>> -csf
> > > > > > > >>> .yam
> > > > > > > >>> l
> > > > > > > >> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.
> > > > > > > >> yaml
> > > > > > > >>> index 8eccd4338a2b..6a10843a26e2 100644
> > > > > > > >>> ---
> > > > > > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall
> > > > > > > >>> -csf
> > > > > > > >>> .yam
> > > > > > > >>> l
> > > > > > > >>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-val
> > > > > > > >>> +++ hall
> > > > > > > >>> +++ -csf
> > > > > > > >>> +++ .yam
> > > > > > > >>> +++ l
> > > > > > > >>> @@ -20,6 +20,7 @@ properties:
> > > > > > > >>> - enum:
> > > > > > > >>> - mediatek,mt8196-mali
> > > > > > > >>> - nxp,imx95-mali # G310
> > > > > > > >>> + - nxp,imx952-mali # G310
> > > > > > > >> Can you explain why this is needed? Can it not be covered
> > > > > > > >> by the existing compatible?
> > > > > > > > There are functional differences in GPU module (GPUMIX)
> > > > > > > > between
> > > > > > > > i.MX95 and i.MX952. So they cannot be fully covered by a
> > > > > > > > single existing
> > > > > compatible.
> > > > > > > > On i.MX952, The GPU clock is controlled by hardware GPU
> > > > > > > > auto clock-gating mechanism, while the GPU clock is
> > > > > > > > managed explicitly by the
> > > > > > > driver on i.MX95.
> > > > > > > > Because of these behavioral differences, separate
> > > > > > > > compatible strings "nxp,imx95-mali" and "nxp,imx952-mali"
> > > > > > > > are needed to allow the driver to handle the two variants
> > > > > > > > independently and to keep room for future
> > > > > > > divergence.
> > > > > > >
> > > > > > >
> > > > > > > This information should be added in the commit message
> > > > > > > explaining why
> > > > > > >
> > > > > > > the change is needed.
> > > > > > >
> > > > > > >
> > > > > > > But then where is the driver code taking care of these diferences?
> > > > > > >
> > > > > >
> > > > > > Yes. Currently the driver does not require "nxp,imx952-mali" string.
> > > > > > However, when GPU ipa_counters are enabled to calculate the
> > > > > > GPU busy_time/idle_time for GPU DVFS feature, they will
> > > > > > conflict with the hardware GPU auto clock‑gating mechanism,
> > > > > > causing GPU clock to remain
> > > > > always on.
> > > > > > In such cases, ipa_counters need to be disabled so that the
> > > > > > GPU auto clock‑gating mechanism can operate normally, using
> > > "nxp,imx952-mali"
> > > > > string.
> > > > >
> > > > > OK, I understand that you're following guidance from some other
> > > > > senior people on how to upstream patches so you've tried to
> > > > > create the smallest patchset to ensure that it gets reviewed and
> > > > > accepted, but in this case we need to see the other patches as
> > > > > well to decide if your approach is the right one and we do need
> > > > > a separate compatible
> > > string.
> > > > >
> > > > > If enabling GPU ipa_counters causes the clocks to get stuck
> > > > > active, that feels like a hardware bug, so figuring out how to
> > > > > handle that is more important than adding a compatible string.
> > > > >
> > > > > Either add the patch(es) that use the compatible to this series
> > > > > in v2, or put a comment in the commit message on where we can
> > > > > see the
> > > driver changes.
> > > > >
> > > >
> > > > According to discussions with the GPU vendor, this is a hardware
> > > > limitation of Mali-G310 rather than a hardware bug, and it has
> > > > been addressed in newer Mali GPU families.
> > >
> > > I represent the said GPU vendor and I think I know what you're
> > > talking about, but you're taking the wrong approach. All G310s have
> > > a problem where in order to enable access to the ipa_counters the
> > > automatic clock gating gets disabled. So the solution that needs to
> > > be implemented when we add support for IPA_COUNTERs will apply to all
> GPUs, not just MX952.
> >
> > Yes. We have bring-up G310 (V2) GPU on both i.MX95 and i.MX952. And
> > auto clock gating mechanism is firstly introduced in i.MX952 (not supported
> on i.MX95).
> > According to your update, solution needs to be implemented to all GPUs
> > which support auto clock gating mechanism after IPA_COUNTERs are
> supported in the driver, right?
>
> A solution is needed, yes.
>
> > What's your suggestions for 952 gpu dtb node?
>
> There is no IPA_COUNTER use in Panthor at the moment. Unless your DVFS
> controller uses that, I would suggest that we don't introduce a compatible for
> 952 until the time we add support for reading the counters.
>
> It helps if you think in terms of what is already in upstream, rather than mixing
> with the tests that uses kbase code. Does your hardware need extra code in
> upstream in order to function? If so, where is that code? If not, then let's not
> introduce the compatible until we are absolutely sure we need it because we
> have code specific to that SoC. For everything else we will implement an
> architecture fix if needed.
>
Got it. The following compatible string is the correct choice since the GPU on
i.MX952 is fully compatible with the GPU on i.MX95 now.
compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
I will not mix tests with kbase code in the following upstream patches for panthor driver.
> Best regards,
> Liviu
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
^ permalink raw reply
* RE: [EXT] Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 17:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <562530e9-a607-4dae-9b43-786a3946f795@kernel.org>
Hi Krzysztof
Thank you for the helpful guidance.
After going through the writing binding file and the corresponding
driver/dts code, I have a few updates to share:
> On 01/04/2026 13:27, Guangliu Ding wrote:
> >>>>
> >>>> We discuss only the lack of compatibility in terms of DT, how DT
> >>>> sees compatible devices.
> >>>>
> >>>> And lack of driver code is clear indication that devices are
> >>>> compatible in terms how DT understands it. Feel encouraged to bring
> >>>> actual arguments in commit msgs in the future.
> >>>>
> >>>> Best regards,
> >>>> Krzysztof
> >>>
> >>> So the best approach is only reserve "arm,mali-valhall-csf" for now,
> >>> since currently there is no need for an additional compatible entry
> >>> from a DT
> >> compatibility perspective.
> >>> We can introduce "nxp,imx952-mali" in future commits if hardware or
> >>> driver differences actually require it, and include more detailed
> >>> justification
> >> in the commit message. Right?
> >>
> >> So does that mean you decided not to read writing bindings document?
> >
> > Actually, I followed the compatible string of gpu node in imx952.dtsi
> > during code work since they share the same GPU IP.
> > gpu: gpu@4d900000 {
> > compatible = "nxp,imx95-mali", "arm,mali-valhall-csf"; >
> >
> > Is this line in writing bindings document that you want to mention about?
> > Could you please share more suggestions about the patch optimization?
> > DO add new compatibles in case there are new features or
> bugs.
>
> Please read entire file. I feel like you avoid doing this and just ask me to give
> you shortcut.
>
> There is more than one point from that trivial writing bindings file which
> applies here.
>
> Best regards,
> Krzysztof
DO use fallback compatibles when devices are the same as or a superset of prior implementations.
Under this rule, the following compatible string is correct since the GPU on
i.MX952 is fully compatible with the GPU on i.MX95 now.
compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
DO add new compatibles in case there are new features or bugs.
Under this rule, the new compatible string is required to support new feature
and the old one must be kept if the GPU auto clock gating mechanism on i.MX952
needs additional fixes after ipa_counters are enabled in the driver.
compatible = "nxp,imx952-mali", "nxp,imx95-mali", "arm,mali-valhall-csf";
^ permalink raw reply
* Re: [PATCH 12/33] rust: macros: update `extract_if` MSRV TODO comment
From: Miguel Ojeda @ 2026-04-01 17:45 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <DHHVSX66206Y.3E7I9QUNTCJ8I@garyguo.net>
On Wed, Apr 1, 2026 at 4:18 PM Gary Guo <gary@garyguo.net> wrote:
>
> When I write the comment the intention is to enable the unstable feature and
> switch.
Yeah, that is what I meant as the alternative in the commit message.
I am OK with either.
(By the way, I wondered why you mentioned 1.85 in the comment, I guess
it was supposed to be 1.86 instead originally, i.e. "above" as in >
1.86)
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 09/33] rust: kbuild: make `--remap-path-prefix` workaround conditional
From: Miguel Ojeda @ 2026-04-01 17:39 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <DHHVLQAOMLWB.3FHHSYKNM5TNP@garyguo.net>
On Wed, Apr 1, 2026 at 4:08 PM Gary Guo <gary@garyguo.net> wrote:
>
> Okay, I see what the comments mean now. Perhaps squash this to the previous
> commit?
This one was mostly to ensure the workaround was not needed anymore,
i.e. it is more "optional" than the other.
In fact, we may want to just not have neither of the patches, i.e. we
could just remove the workaround given the timelines of the branches
-- please see my reply on the previous one on this.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Jason Gunthorpe @ 2026-04-01 17:36 UTC (permalink / raw)
To: Robin Murphy
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
Jon Hunter, patches, Samiullah Khawaja, stable, Vasant Hegde
In-Reply-To: <ee2c2044-e329-4cdd-ac35-9365824d3677@arm.com>
On Wed, Apr 01, 2026 at 05:33:28PM +0100, Robin Murphy wrote:
> > io-pgtable might have intended to allow the driver to choose between
> > gather or immediate flush because it passed gather to
> > ops->tlb_add_page(), however no driver does anything with it.
>
> Apart from arm-smmu-v3...
Bah, I did my research on the wrong tree and missed this.
> > mtk uses io-pgtable-arm-v7s but added the range to the gather in the
> > unmap callback. Move this into the io-pgtable-arm unmap itself. That
> > will fix all the armv7 using drivers (arm-smmu, qcom_iommu,
> > ipmmu-vmsa).
>
> io-pgtable-arm-v7s != io-pgtable-arm. You're *breaking* MTK (and failing
> to fix the other v7s user, which is MSM).
I was very confused what you were talking about, but I see now that
the hunk adding iommu_iotlb_gather_add_range() to v7 got lost somehow!
@@ -596,6 +596,9 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
__arm_v7s_set_pte(ptep, 0, num_entries, &iop->cfg);
+ if (!iommu_iotlb_gather_queued(gather))
+ iommu_iotlb_gather_add_range(gather, iova, size);
+
for (i = 0; i < num_entries; i++) {
if (ARM_V7S_PTE_IS_TABLE(pte[i], lvl)) {
/* Also flush any partial walks */
> > arm-smmu uses both ARM_V7S and ARM LPAE formats. The LPAE formats
> > already have the gather population because SMMUv3 requires it, so it
> > becomes consistent.
>
> Huh? arm-smmu-v3 invokes iommu_iotlb_gather_add_page() itself, because
> arm-smmu-v3 uses gathers
Yeah, I missed this whole bit, it needs some changes.
> Invoking add range before add_page will end up defeating the
> iommu_iotlb_gather_is_disjoint() check and making SMMUv3
> overinvalidate between disjoint ranges.
Right, that flow needs fixing.
> I guess now I remember why we weren't validating gathers in core code
> before :(
My point is not filling the gather is a micro-optimization that
benefits a few drivers. I think it is so small compared to an IOTLB
flush that it isn't worth worrying about.
So, I'd like to make everything the same and populate the gather
correctly in all flows. I'll fix the SMMUv3 thing and lets look again,
this patch is not so scary to make me think we shouldn't do that.
> @@ -2714,6 +2714,10 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
> pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
> iova, unmapped_page);
> + /* If the driver itself isn't using the gather, mark it used */
> + if (iotlb_gather->end <= iotlb_gather->start)
> + iommu_iotlb_gather_add_range(&iotlb_gather, iova, unmapped_page);
The gathers can be joined across unmaps and now we are inviting subtly
ill-formed gathers as only the first unmap will get included.
We do have error cases where the gather is legitimately empty, and
this would squash that, it probably needs to check unmapped_page for 0
too, at least.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH 08/33] rust: kbuild: simplify `--remap-path-prefix` workaround
From: Miguel Ojeda @ 2026-04-01 17:36 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <DHHVEPJHLGDW.1E6KDP9BUFG5U@garyguo.net>
On Wed, Apr 1, 2026 at 3:59 PM Gary Guo <gary@garyguo.net> wrote:
>
> I'm not sure that I parse this. You do remove the filter-out completely below?
(I see you saw the other commit)
> Looks like this is going to conflict with rust-fixes (which adds the
> --remap-path-scope). Perhaps worth doing a back merge?
It would be only a couple lines conflicting, so it should be fine.
Having said that, when I was doing this, I wondered if we should even
consider keeping the workaround. In other words, locally for
`rust-next`, the "normal" commit would be to remove the workaround
entirely because there the flag doesn't exist to begin with (i.e. the
workaround should have been removed back when the revert landed).
Then, when conflict happens in linux-next, we can just keep the
addition of the flag from your commit -- the rest can say as-is, i.e.
no workaround needed, because you only enable both flags in a version
(1.95.0) where there is no need for the workaround (which was for <
1.87.0).
It is also why I added the second commit here, i.e. the "make it
conditional", because I was testing that indeed we didn't need the
workaround anymore.
So it may just simpler to do that. What I thought was that perhaps the
workaround is good even if we ourselves don't pass the flag, e.g.
someone else may be passing it. But the chances are very low,
restricted to a couple versions, and the error is obvious and at build
time anyway.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] arch/arm: Drop CONFIG_FIRMWARE_EDID from defconfig files
From: Kevin Hilman @ 2026-04-01 17:33 UTC (permalink / raw)
To: Thomas Zimmermann, linux, aaro.koskinen, jmkrzyszt, tony, andreas,
rogerq, arnd
Cc: linux-arm-kernel, linux-kernel, linux-omap, soc, linux-fbdev,
dri-devel, Thomas Zimmermann
In-Reply-To: <20260401082533.214103-1-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> CONFIG_FIRMWARE_EDID=y depends on X86 or EFI_GENERIC_STUB. Neither is
> true here, so drop the lines from the defconfig files.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/configs/davinci_all_defconfig | 1 -
> arch/arm/configs/omap1_defconfig | 1 -
> arch/arm/configs/omap2plus_defconfig | 1 -
For omap*_defconfig:
Acked-by: Kevin Hilman (TI) <khilman@baylibre.com>
Kevin
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers
From: Sebastian Ene @ 2026-04-01 17:21 UTC (permalink / raw)
To: Marc Zyngier
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: <86341e4to0.wl-maz@kernel.org>
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);
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
Thanks,
Sebastian
^ permalink raw reply
* Re: Re: Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Liviu Dudau @ 2026-04-01 17:20 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB4707604AF2C445971C7474EFF350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On Wed, Apr 01, 2026 at 03:59:23PM +0000, Guangliu Ding wrote:
> Hi Liviu
>
> > On Wed, Apr 01, 2026 at 10:31:01AM +0000, Guangliu Ding wrote:
> > > Hi Liviu
> > >
> > > > On Wed, Apr 01, 2026 at 09:43:12AM +0000, Guangliu Ding wrote:
> > > > > Hi Daniel
> > > > >
> > > > > > On 4/1/26 11:48, Guangliu Ding wrote:
> > > > > > > [You don't often get email from guangliu.ding@nxp.com. Learn
> > > > > > > why this is important at
> > > > > > > https://aka.ms/LearnAboutSenderIdentification
> > > > > > > ]
> > > > > > >
> > > > > > > Hi Liviu
> > > > > > >
> > > > > > > Thanks for your review. Please refer to my comments below:
> > > > > > >
> > > > > > >> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> > > > > > >>> Add compatible string of Mali G310 GPU on i.MX952 board.
> > > > > > >>>
> > > > > > >>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > > > > > >>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> > > > > > >>> ---
> > > > > > >>>
> > > > > > >>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.y
> > > > > > >>> aml
> > > > > > >>> | 1
> > > > > > >>> +
> > > > > > >>> 1 file changed, 1 insertion(+)
> > > > > > >>>
> > > > > > >>> diff --git
> > > > > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf
> > > > > > >>> .yam
> > > > > > >>> l
> > > > > > >> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.
> > > > > > >> yaml
> > > > > > >>> index 8eccd4338a2b..6a10843a26e2 100644
> > > > > > >>> ---
> > > > > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf
> > > > > > >>> .yam
> > > > > > >>> l
> > > > > > >>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall
> > > > > > >>> +++ -csf
> > > > > > >>> +++ .yam
> > > > > > >>> +++ l
> > > > > > >>> @@ -20,6 +20,7 @@ properties:
> > > > > > >>> - enum:
> > > > > > >>> - mediatek,mt8196-mali
> > > > > > >>> - nxp,imx95-mali # G310
> > > > > > >>> + - nxp,imx952-mali # G310
> > > > > > >> Can you explain why this is needed? Can it not be covered by
> > > > > > >> the existing compatible?
> > > > > > > There are functional differences in GPU module (GPUMIX)
> > > > > > > between
> > > > > > > i.MX95 and i.MX952. So they cannot be fully covered by a
> > > > > > > single existing
> > > > compatible.
> > > > > > > On i.MX952, The GPU clock is controlled by hardware GPU auto
> > > > > > > clock-gating mechanism, while the GPU clock is managed
> > > > > > > explicitly by the
> > > > > > driver on i.MX95.
> > > > > > > Because of these behavioral differences, separate compatible
> > > > > > > strings "nxp,imx95-mali" and "nxp,imx952-mali" are needed to
> > > > > > > allow the driver to handle the two variants independently and
> > > > > > > to keep room for future
> > > > > > divergence.
> > > > > >
> > > > > >
> > > > > > This information should be added in the commit message
> > > > > > explaining why
> > > > > >
> > > > > > the change is needed.
> > > > > >
> > > > > >
> > > > > > But then where is the driver code taking care of these diferences?
> > > > > >
> > > > >
> > > > > Yes. Currently the driver does not require "nxp,imx952-mali" string.
> > > > > However, when GPU ipa_counters are enabled to calculate the GPU
> > > > > busy_time/idle_time for GPU DVFS feature, they will conflict with
> > > > > the hardware GPU auto clock‑gating mechanism, causing GPU clock to
> > > > > remain
> > > > always on.
> > > > > In such cases, ipa_counters need to be disabled so that the GPU
> > > > > auto clock‑gating mechanism can operate normally, using
> > "nxp,imx952-mali"
> > > > string.
> > > >
> > > > OK, I understand that you're following guidance from some other
> > > > senior people on how to upstream patches so you've tried to create
> > > > the smallest patchset to ensure that it gets reviewed and accepted,
> > > > but in this case we need to see the other patches as well to decide
> > > > if your approach is the right one and we do need a separate compatible
> > string.
> > > >
> > > > If enabling GPU ipa_counters causes the clocks to get stuck active,
> > > > that feels like a hardware bug, so figuring out how to handle that
> > > > is more important than adding a compatible string.
> > > >
> > > > Either add the patch(es) that use the compatible to this series in
> > > > v2, or put a comment in the commit message on where we can see the
> > driver changes.
> > > >
> > >
> > > According to discussions with the GPU vendor, this is a hardware
> > > limitation of Mali-G310 rather than a hardware bug, and it has been
> > > addressed in newer Mali GPU families.
> >
> > I represent the said GPU vendor and I think I know what you're talking about,
> > but you're taking the wrong approach. All G310s have a problem where in
> > order to enable access to the ipa_counters the automatic clock gating gets
> > disabled. So the solution that needs to be implemented when we add support
> > for IPA_COUNTERs will apply to all GPUs, not just MX952.
>
> Yes. We have bring-up G310 (V2) GPU on both i.MX95 and i.MX952. And auto clock
> gating mechanism is firstly introduced in i.MX952 (not supported on i.MX95).
> According to your update, solution needs to be implemented to all GPUs which support
> auto clock gating mechanism after IPA_COUNTERs are supported in the driver, right?
A solution is needed, yes.
> What's your suggestions for 952 gpu dtb node?
There is no IPA_COUNTER use in Panthor at the moment. Unless your DVFS controller uses
that, I would suggest that we don't introduce a compatible for 952 until the time we
add support for reading the counters.
It helps if you think in terms of what is already in upstream, rather than mixing with
the tests that uses kbase code. Does your hardware need extra code in upstream in order
to function? If so, where is that code? If not, then let's not introduce the compatible
until we are absolutely sure we need it because we have code specific to that SoC. For
everything else we will implement an architecture fix if needed.
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH] ASoC: mxs-sgtl5000: disable MCLK on error paths of mxs_sgtl5000_probe()
From: Mark Brown @ 2026-04-01 13:03 UTC (permalink / raw)
To: lgirdwood, perex, tiwai, shawnguo, s.hauer, kernel, festevam,
Haoxiang Li
Cc: linux-sound, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260401053051.586290-1-lihaoxiang@isrc.iscas.ac.cn>
On Wed, 01 Apr 2026 13:30:51 +0800, Haoxiang Li wrote:
> ASoC: mxs-sgtl5000: disable MCLK on error paths of mxs_sgtl5000_probe()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1
Thanks!
[1/1] ASoC: mxs-sgtl5000: disable MCLK on error paths of mxs_sgtl5000_probe()
https://git.kernel.org/broonie/sound/c/c8ef13d692f1
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [GIT PULL 2/2] arm64: defconfig: TI K3 updates for v7.1
From: Vignesh Raghavendra @ 2026-04-01 17:18 UTC (permalink / raw)
To: SoC, arm
Cc: SoC list, linux-arm-kernel, linux-kernel, Tero Kristo,
Nishanth Menon
In-Reply-To: <e724f95d-09d0-4ede-9ed4-0ce782d81058@ti.com>
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v7.1
for you to fetch changes up to 079a2e18b776f391d6b16b8710af79976fba14aa:
arm64: defconfig: Enable DP83TG720 PHY driver (2026-03-29 19:51:25 +0530)
----------------------------------------------------------------
TI K3 defconfig updates for v7.1
Generic Fixes/Cleanups:
- Remove SENSORS_SA67MCU as the driver is dropped
Board Specific Features and Fixes:
AM69:
- Enable configurations for Toradex Aquila AM69
AM64 / AM62:
- Enable DP83TG720 PHY driver
----------------------------------------------------------------
Francesco Dolcini (1):
arm64: defconfig: Enable configurations for Toradex Aquila AM69
Meghana Malladi (1):
arm64: defconfig: Enable DP83TG720 PHY driver
Michael Walle (1):
arm64: defconfig: remove SENSORS_SA67MCU
arch/arm64/configs/defconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL 1/2] arm64: dts: ti: K3 updates for v7.1
From: Vignesh Raghavendra @ 2026-04-01 17:14 UTC (permalink / raw)
To: SoC, arm
Cc: SoC list, linux-arm-kernel, linux-kernel, Tero Kristo,
Nishanth Menon, Vignesh Raghavendra
[-- Attachment #1.1: Type: text/plain, Size: 10418 bytes --]
Hi ARM SoC maintainers
Please pull DT updates for K3 Platforms for v7.1.
Note there is a patch touching embedded-controller/kontron,sl28cpld.yaml as it is part of
series that removes of Kontron SMARC-sAM67 board support.
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-dt-for-v7.1
for you to fetch changes up to 47c806de9e9cf171d197f2f0df86df7f2bd1aa56:
arm64: dts: ti: k3-pinctrl: sort shift values numerically (2026-03-27 19:55:06 +0530)
----------------------------------------------------------------
TI K3 device tree updates for v7.1
Generic Fixes/Cleanups:
- k3-pinctrl: Cleanup alignment and reorder macros
- ti,min-output-impedance addition to all K3 board DT files
SoC Specific Features and Fixes:
AM62L:
- Add RNG node
- Support cpufreq scaling
J721S2:
- Make MAIN domain system control bus a simple-bus
- Add second DSI node
J722S:
- Add main_i2c4 device node
J7200:
- Make MAIN domain system control bus a simple-bus
Board Specific Features and Fixes:
AM642 EVM:
- Add ICSSG0 overlay for dual EMAC support
AM62:
- LP-SK: Enable internal pulls for MMC0 data pins
- SK: Enable Main UART wakeup
- phycore-som: Add 128MiB of global CMA
- Verdin: Add Zinnia board support and misc cleanup
AM62A7-SK:
- Enable Main UART wakeup
- Fix pin name in comment from M19 to N22
AM62D2 EVM:
- Enable Main UART wakeup and set wakeup-source system-states
AM62L3 EVM:
- Disable MMC1 internal pulls on data pins
- Enable Main UART wakeup and enable wkup_uart0 pins/target node
AM62P:
- SK: Disable MMC1 internal pulls on data pins and enable Main UART
wakeup
- Verdin: Add Zinnia support and misc cleanup
AM68 PHYBoard:
- Add DSI->LVDS bridge, LVDS-Display overlay and PEB-AV-15 overlay
AM69 Aquila:
- Fix DP regulator enable GPIO
J721S2 CPB:
- Add QSPI flash partition details
Removal of SMARC-sAM67 board:
- Kontron SMARC-sAM67 board support along with all bindings
are dropped as board is no longer planned for production
----------------------------------------------------------------
Andrew Davis (2):
arm64: dts: ti: k3-j7200: Make MAIN domain system control bus a simple-bus
arm64: dts: ti: k3-j721s2: Make MAIN domain system control bus a simple-bus
Aniket Limaye (1):
arm64: dts: ti: k3-j722s: Add main_i2c4 device node
Anurag Dutta (1):
arm64: dts: ti: k3-j721s2-common-proc-board: Add QSPI flash partition details
Dhruva Gole (1):
arm64: dts: ti: k3-am62l: support cpufreq scaling
Dominik Haller (5):
arm64: dts: ti: k3-am68-phyboard-izar: Assign dss clocks
arm64: dts: ti: k3-am68-phycore-som: Add DSI->LVDS bridge
arm64: dts: ti: k3-am68-phyboard-izar: Add LVDS-Display
arm64: dts: ti: k3-j721s2-main: Add DSI1
arm64: dts: ti: k3-am68-phyboard-izar: Add PEB-AV-15 overlay
Francesco Dolcini (8):
arm64: dts: ti: am62-verdin: Enable pullup for eMMC data pins
dt-bindings: arm: ti: Add verdin am62/am62p zinnia board
arm64: dts: ti: k3-am62-verdin: Fix SPI_1 GPIO CS pinctrl label
arm64: dts: ti: k3-am62-verdin: Split UART_2 pinctrl group
arm64: dts: ti: k3-am62-verdin: Add Zinnia
arm64: dts: ti: k3-am62p-verdin: Split UART_2 pinctrl group
arm64: dts: ti: k3-am62p-verdin: Add SPI_1_CS as GPIO
arm64: dts: ti: k3-am62p-verdin: Add Zinnia
Franz Schnyder (2):
arm64: dts: ti: k3-am69-aquila-dev: Fix DP regulator enable GPIO
arm64: dts: ti: k3-am69-aquila-clover: Fix DP regulator enable GPIO
Judith Mendez (3):
arm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pins
arm64: dts: ti: k3-am62l3-evm: Disable MMC1 internal pulls on data pins
arm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pins
Kendall Willis (10):
arm64: dts: ti: k3-am62d2-evm: Set wakeup-source system-states
arm64: dts: ti: k3-am62l: include WKUP_UART0 in wakeup peripheral window
arm64: boot: dts: ti: k3-am62l-wakeup: create label for wkup_uart0 target-module
arm64: boot: dts: ti: k3-am62l3-evm: define wkup_uart0 pins
arm64: boot: dts: ti: k3-am62l3-evm: enable wkup_uart0_target node
arm64: dts: ti: k3-am62x-sk-common: Enable Main UART wakeup
arm64: dts: ti: k3-am62a7-sk: Enable Main UART wakeup
arm64: dts: ti: k3-am62p5-sk: Enable Main UART wakeup
arm64: dts: ti: k3-am62l3-evm: Enable Main UART wakeup
arm64: dts: ti: k3-am62d2-evm: Enable Main UART wakeup
Meghana Malladi (1):
arm64: dts: ti: k3-am642-evm: Add ICSSG0 overlay for dual EMAC support
Michael Walle (3):
arm64: dts: ti: remove the Kontron SMARC-sAM67
dt-bindings: mfd: sl28cpld: Drop sa67mcu compatible
dt-bindings: arm: ti: Drop Kontron SMARC-sAM67 module
Rasmus Villemoes (2):
arm64: dts: ti: k3-pinctrl: consistently use tabs for alignment
arm64: dts: ti: k3-pinctrl: sort shift values numerically
Shiva Tripathi (1):
arm64: dts: ti: k3-am62l-main: Add RNG node
Siddharth Vadapalli (5):
arm64: dts: ti: k3-am642-{evm,sk}: add ti,min-output-impedance
arm64: dts: ti: k3-am654-base-board: add ti,min-output-impedance
arm64: dts: ti: k3-j7200-common-proc-board: add ti,min-output-impedance
arm64: dts: ti: k3-j721e-common-proc-board: add ti,min-output-impedance
arm64: dts: ti: k3-am62a7-sk: Fix pin name in comment from M19 to N22
Thomas Richard (TI) (1):
arm64: dts: ti: k3-j721s2: Use ti,j7200-padconf compatible
Wadim Egorov (1):
arm64: dts: ti: k3-am62-phycore-som: Add 128MiB of global CMA
Documentation/devicetree/bindings/arm/ti/k3.yaml | 5 +-
.../bindings/embedded-controller/kontron,sl28cpld.yaml | 7 +-
arch/arm64/boot/dts/ti/Makefile | 27 +-
arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts | 14 +-
arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi | 7 +
arch/arm64/boot/dts/ti/k3-am62-verdin-zinnia.dtsi | 493 +++++
arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 42 +-
arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-zinnia.dts | 22 +
arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-zinnia.dts | 22 +
arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 15 +-
arch/arm64/boot/dts/ti/k3-am62d2-evm.dts | 82 +-
arch/arm64/boot/dts/ti/k3-am62l-main.dtsi | 7 +
arch/arm64/boot/dts/ti/k3-am62l-wakeup.dtsi | 7 +-
arch/arm64/boot/dts/ti/k3-am62l.dtsi | 5 +-
arch/arm64/boot/dts/ti/k3-am62l3-evm.dts | 32 +-
arch/arm64/boot/dts/ti/k3-am62l3.dtsi | 47 +
arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 13 +-
arch/arm64/boot/dts/ti/k3-am62p-verdin-zinnia.dtsi | 469 ++++
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 29 +-
arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 19 +-
arch/arm64/boot/dts/ti/k3-am62p5-verdin-nonwifi-zinnia.dts | 22 +
arch/arm64/boot/dts/ti/k3-am62p5-verdin-wifi-zinnia.dts | 22 +
arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 13 +-
arch/arm64/boot/dts/ti/k3-am642-evm-icssg0.dtso | 168 ++
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 1 +
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 2 +
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 1 +
arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-ads2.dtso | 146 --
arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-base.dts | 1091 ----------
arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-gbe1.dtso | 26 -
arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-gpios.dtso | 61 -
arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-rtc-rv8263.dtso | 31 -
.../boot/dts/ti/k3-am68-phyboard-izar-lvds-ph128800t006.dtso | 125 ++
arch/arm64/boot/dts/ti/k3-am68-phyboard-izar-peb-av-15.dtso | 191 ++
arch/arm64/boot/dts/ti/k3-am68-phyboard-izar.dts | 17 +
arch/arm64/boot/dts/ti/k3-am68-phycore-som.dtsi | 17 +
arch/arm64/boot/dts/ti/k3-am69-aquila-clover.dts | 2 +-
arch/arm64/boot/dts/ti/k3-am69-aquila-dev.dts | 2 +-
arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts | 1 +
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 5 +-
arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 1 +
arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts | 42 +
arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 50 +-
arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 12 +-
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 13 +
arch/arm64/boot/dts/ti/k3-j722s.dtsi | 3 +-
arch/arm64/boot/dts/ti/k3-pinctrl.h | 82 +-
47 files changed, 2030 insertions(+), 1481 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am62p-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am62p5-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am62p5-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg0.dtso
delete mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-ads2.dtso
delete mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-base.dts
delete mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-gbe1.dtso
delete mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-gpios.dtso
delete mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-rtc-rv8263.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am68-phyboard-izar-lvds-ph128800t006.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am68-phyboard-izar-peb-av-15.dtso
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply
* RE: [PATCH 04/11] Drivers: hv: Refactor mshv_vtl for ARM64 support to be added
From: Michael Kelley @ 2026-04-01 16:56 UTC (permalink / raw)
To: Naman Jain, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, Michael Kelley,
linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <20260316121241.910764-5-namjain@linux.microsoft.com>
From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
>
> Refactor MSHV_VTL driver to move some of the x86 specific code to arch
> specific files, and add corresponding functions for arm64.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
> arch/arm64/include/asm/mshyperv.h | 10 +++
> arch/x86/hyperv/hv_vtl.c | 98 ++++++++++++++++++++++++++++
> arch/x86/include/asm/mshyperv.h | 1 +
> drivers/hv/mshv_vtl_main.c | 102 +-----------------------------
> 4 files changed, 111 insertions(+), 100 deletions(-)
>
> diff --git a/arch/arm64/include/asm/mshyperv.h
> b/arch/arm64/include/asm/mshyperv.h
> index b721d3134ab6..804068e0941b 100644
> --- a/arch/arm64/include/asm/mshyperv.h
> +++ b/arch/arm64/include/asm/mshyperv.h
> @@ -60,6 +60,16 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
> ARM_SMCCC_SMC_64, \
> ARM_SMCCC_OWNER_VENDOR_HYP, \
> HV_SMCCC_FUNC_NUMBER)
> +#ifdef CONFIG_HYPERV_VTL_MODE
> +/*
> + * Get/Set the register. If the function returns `1`, that must be done via
> + * a hypercall. Returning `0` means success.
> + */
> +static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u64 shared)
> +{
> + return 1;
> +}
> +#endif
>
> #include <asm-generic/mshyperv.h>
>
> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> index 9b6a9bc4ab76..72a0bb4ae0c7 100644
> --- a/arch/x86/hyperv/hv_vtl.c
> +++ b/arch/x86/hyperv/hv_vtl.c
> @@ -17,6 +17,8 @@
> #include <asm/realmode.h>
> #include <asm/reboot.h>
> #include <asm/smap.h>
> +#include <uapi/asm/mtrr.h>
> +#include <asm/debugreg.h>
> #include <linux/export.h>
> #include <../kernel/smpboot.h>
> #include "../../kernel/fpu/legacy.h"
> @@ -281,3 +283,99 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
> kernel_fpu_end();
> }
> EXPORT_SYMBOL(mshv_vtl_return_call);
> +
> +/* Static table mapping register names to their corresponding actions */
> +static const struct {
> + enum hv_register_name reg_name;
> + int debug_reg_num; /* -1 if not a debug register */
> + u32 msr_addr; /* 0 if not an MSR */
> +} reg_table[] = {
> + /* Debug registers */
> + {HV_X64_REGISTER_DR0, 0, 0},
> + {HV_X64_REGISTER_DR1, 1, 0},
> + {HV_X64_REGISTER_DR2, 2, 0},
> + {HV_X64_REGISTER_DR3, 3, 0},
> + {HV_X64_REGISTER_DR6, 6, 0},
> + /* MTRR MSRs */
> + {HV_X64_REGISTER_MSR_MTRR_CAP, -1, MSR_MTRRcap},
> + {HV_X64_REGISTER_MSR_MTRR_DEF_TYPE, -1, MSR_MTRRdefType},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE0, -1, MTRRphysBase_MSR(0)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE1, -1, MTRRphysBase_MSR(1)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE2, -1, MTRRphysBase_MSR(2)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE3, -1, MTRRphysBase_MSR(3)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE4, -1, MTRRphysBase_MSR(4)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE5, -1, MTRRphysBase_MSR(5)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE6, -1, MTRRphysBase_MSR(6)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE7, -1, MTRRphysBase_MSR(7)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE8, -1, MTRRphysBase_MSR(8)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE9, -1, MTRRphysBase_MSR(9)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEA, -1, MTRRphysBase_MSR(0xa)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEB, -1, MTRRphysBase_MSR(0xb)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEC, -1, MTRRphysBase_MSR(0xc)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASED, -1, MTRRphysBase_MSR(0xd)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEE, -1, MTRRphysBase_MSR(0xe)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEF, -1, MTRRphysBase_MSR(0xf)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK0, -1, MTRRphysMask_MSR(0)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK1, -1, MTRRphysMask_MSR(1)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK2, -1, MTRRphysMask_MSR(2)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK3, -1, MTRRphysMask_MSR(3)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK4, -1, MTRRphysMask_MSR(4)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK5, -1, MTRRphysMask_MSR(5)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK6, -1, MTRRphysMask_MSR(6)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK7, -1, MTRRphysMask_MSR(7)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK8, -1, MTRRphysMask_MSR(8)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK9, -1, MTRRphysMask_MSR(9)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKA, -1, MTRRphysMask_MSR(0xa)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKB, -1, MTRRphysMask_MSR(0xb)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKC, -1, MTRRphysMask_MSR(0xc)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKD, -1, MTRRphysMask_MSR(0xd)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKE, -1, MTRRphysMask_MSR(0xe)},
> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKF, -1, MTRRphysMask_MSR(0xf)},
> + {HV_X64_REGISTER_MSR_MTRR_FIX64K00000, -1, MSR_MTRRfix64K_00000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX16K80000, -1, MSR_MTRRfix16K_80000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX16KA0000, -1, MSR_MTRRfix16K_A0000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX4KC0000, -1, MSR_MTRRfix4K_C0000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX4KC8000, -1, MSR_MTRRfix4K_C8000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX4KD0000, -1, MSR_MTRRfix4K_D0000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX4KD8000, -1, MSR_MTRRfix4K_D8000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX4KE0000, -1, MSR_MTRRfix4K_E0000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX4KE8000, -1, MSR_MTRRfix4K_E8000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX4KF0000, -1, MSR_MTRRfix4K_F0000},
> + {HV_X64_REGISTER_MSR_MTRR_FIX4KF8000, -1, MSR_MTRRfix4K_F8000},
> +};
> +
> +int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u64 shared)
> +{
> + u64 *reg64;
> + enum hv_register_name gpr_name;
> + int i;
> +
> + gpr_name = regs->name;
> + reg64 = ®s->value.reg64;
> +
> + /* Search for the register in the table */
> + for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
> + if (reg_table[i].reg_name != gpr_name)
> + continue;
> + if (reg_table[i].debug_reg_num != -1) {
> + /* Handle debug registers */
> + if (gpr_name == HV_X64_REGISTER_DR6 && !shared)
> + goto hypercall;
> + if (set)
> + native_set_debugreg(reg_table[i].debug_reg_num, *reg64);
> + else
> + *reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
> + } else {
> + /* Handle MSRs */
> + if (set)
> + wrmsrl(reg_table[i].msr_addr, *reg64);
> + else
> + rdmsrl(reg_table[i].msr_addr, *reg64);
> + }
> + return 0;
> + }
> +
> +hypercall:
> + return 1;
> +}
> +EXPORT_SYMBOL(hv_vtl_get_set_reg);
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index f64393e853ee..d5355a5b7517 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -304,6 +304,7 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
> void mshv_vtl_return_call_init(u64 vtl_return_offset);
> void mshv_vtl_return_hypercall(void);
> void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
> +int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u64 shared);
Can this move to asm-generic/mshyperv.h? The function is no longer specific
to x86/x64, so one would want to not declare it in the arch/x86 version
of mshyperv.h. But maybe moving it to asm-generic/mshyperv.h breaks
compilation on arm64 because there's also the static inline stub there.
> #else
> static inline void __init hv_vtl_init_platform(void) {}
> static inline int __init hv_vtl_early_init(void) { return 0; }
> diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
> index 5856975f32e1..b607b6e7e121 100644
> --- a/drivers/hv/mshv_vtl_main.c
> +++ b/drivers/hv/mshv_vtl_main.c
> @@ -19,10 +19,8 @@
> #include <linux/poll.h>
> #include <linux/file.h>
> #include <linux/vmalloc.h>
> -#include <asm/debugreg.h>
> #include <asm/mshyperv.h>
> #include <trace/events/ipi.h>
> -#include <uapi/asm/mtrr.h>
> #include <uapi/linux/mshv.h>
> #include <hyperv/hvhdk.h>
>
> @@ -505,102 +503,6 @@ static int mshv_vtl_ioctl_set_poll_file(struct mshv_vtl_set_poll_file __user *us
> return 0;
> }
>
> -/* Static table mapping register names to their corresponding actions */
> -static const struct {
> - enum hv_register_name reg_name;
> - int debug_reg_num; /* -1 if not a debug register */
> - u32 msr_addr; /* 0 if not an MSR */
> -} reg_table[] = {
> - /* Debug registers */
> - {HV_X64_REGISTER_DR0, 0, 0},
> - {HV_X64_REGISTER_DR1, 1, 0},
> - {HV_X64_REGISTER_DR2, 2, 0},
> - {HV_X64_REGISTER_DR3, 3, 0},
> - {HV_X64_REGISTER_DR6, 6, 0},
> - /* MTRR MSRs */
> - {HV_X64_REGISTER_MSR_MTRR_CAP, -1, MSR_MTRRcap},
> - {HV_X64_REGISTER_MSR_MTRR_DEF_TYPE, -1, MSR_MTRRdefType},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE0, -1, MTRRphysBase_MSR(0)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE1, -1, MTRRphysBase_MSR(1)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE2, -1, MTRRphysBase_MSR(2)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE3, -1, MTRRphysBase_MSR(3)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE4, -1, MTRRphysBase_MSR(4)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE5, -1, MTRRphysBase_MSR(5)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE6, -1, MTRRphysBase_MSR(6)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE7, -1, MTRRphysBase_MSR(7)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE8, -1, MTRRphysBase_MSR(8)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE9, -1, MTRRphysBase_MSR(9)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEA, -1, MTRRphysBase_MSR(0xa)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEB, -1, MTRRphysBase_MSR(0xb)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEC, -1, MTRRphysBase_MSR(0xc)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASED, -1, MTRRphysBase_MSR(0xd)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEE, -1, MTRRphysBase_MSR(0xe)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEF, -1, MTRRphysBase_MSR(0xf)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK0, -1, MTRRphysMask_MSR(0)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK1, -1, MTRRphysMask_MSR(1)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK2, -1, MTRRphysMask_MSR(2)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK3, -1, MTRRphysMask_MSR(3)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK4, -1, MTRRphysMask_MSR(4)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK5, -1, MTRRphysMask_MSR(5)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK6, -1, MTRRphysMask_MSR(6)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK7, -1, MTRRphysMask_MSR(7)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK8, -1, MTRRphysMask_MSR(8)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK9, -1, MTRRphysMask_MSR(9)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKA, -1, MTRRphysMask_MSR(0xa)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKB, -1, MTRRphysMask_MSR(0xb)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKC, -1, MTRRphysMask_MSR(0xc)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKD, -1, MTRRphysMask_MSR(0xd)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKE, -1, MTRRphysMask_MSR(0xe)},
> - {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKF, -1, MTRRphysMask_MSR(0xf)},
> - {HV_X64_REGISTER_MSR_MTRR_FIX64K00000, -1, MSR_MTRRfix64K_00000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX16K80000, -1, MSR_MTRRfix16K_80000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX16KA0000, -1, MSR_MTRRfix16K_A0000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX4KC0000, -1, MSR_MTRRfix4K_C0000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX4KC8000, -1, MSR_MTRRfix4K_C8000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX4KD0000, -1, MSR_MTRRfix4K_D0000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX4KD8000, -1, MSR_MTRRfix4K_D8000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX4KE0000, -1, MSR_MTRRfix4K_E0000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX4KE8000, -1, MSR_MTRRfix4K_E8000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX4KF0000, -1, MSR_MTRRfix4K_F0000},
> - {HV_X64_REGISTER_MSR_MTRR_FIX4KF8000, -1, MSR_MTRRfix4K_F8000},
> -};
> -
> -static int mshv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set)
> -{
> - u64 *reg64;
> - enum hv_register_name gpr_name;
> - int i;
> -
> - gpr_name = regs->name;
> - reg64 = ®s->value.reg64;
> -
> - /* Search for the register in the table */
> - for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
> - if (reg_table[i].reg_name != gpr_name)
> - continue;
> - if (reg_table[i].debug_reg_num != -1) {
> - /* Handle debug registers */
> - if (gpr_name == HV_X64_REGISTER_DR6 &&
> - !mshv_vsm_capabilities.dr6_shared)
> - goto hypercall;
> - if (set)
> - native_set_debugreg(reg_table[i].debug_reg_num, *reg64);
> - else
> - *reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
> - } else {
> - /* Handle MSRs */
> - if (set)
> - wrmsrl(reg_table[i].msr_addr, *reg64);
> - else
> - rdmsrl(reg_table[i].msr_addr, *reg64);
> - }
> - return 0;
> - }
> -
> -hypercall:
> - return 1;
> -}
> -
> static void mshv_vtl_return(struct mshv_vtl_cpu_context *vtl0)
> {
> struct hv_vp_assist_page *hvp;
> @@ -720,7 +622,7 @@ mshv_vtl_ioctl_get_regs(void __user *user_args)
> sizeof(reg)))
> return -EFAULT;
>
> - ret = mshv_vtl_get_set_reg(®, false);
> + ret = hv_vtl_get_set_reg(®, false, mshv_vsm_capabilities.dr6_shared);
> if (!ret)
> goto copy_args; /* No need of hypercall */
> ret = vtl_get_vp_register(®);
> @@ -751,7 +653,7 @@ mshv_vtl_ioctl_set_regs(void __user *user_args)
> if (copy_from_user(®, (void __user *)args.regs_ptr, sizeof(reg)))
> return -EFAULT;
>
> - ret = mshv_vtl_get_set_reg(®, true);
> + ret = hv_vtl_get_set_reg(®, true, mshv_vsm_capabilities.dr6_shared);
> if (!ret)
> return ret; /* No need of hypercall */
> ret = vtl_set_vp_register(®);
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: Use the correct buffer size during RXTX_MAP
From: Sebastian Ene @ 2026-04-01 17:09 UTC (permalink / raw)
To: Sudeep Holla; +Cc: linux-arm-kernel, linux-kernel, android-kvm
In-Reply-To: <20260401-agile-agouti-of-atheism-cb342c@sudeepholla>
On Wed, Apr 01, 2026 at 05:21:02PM +0100, Sudeep Holla wrote:
> On Wed, Apr 01, 2026 at 11:17:38AM +0000, Sebastian Ene wrote:
> > Don't use the discovered buffer size from an FFA_FEATURES call directly
> > since we can run on a system that has the PAGE_SIZE larger than the
> > returned size which makes the alloc_pages_exact for the buffer to be
> > rounded up.
> >
> > Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()")
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > drivers/firmware/arm_ffa/driver.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> > index f2f94d4d533e..d0c926aca120 100644
> > --- a/drivers/firmware/arm_ffa/driver.c
> > +++ b/drivers/firmware/arm_ffa/driver.c
> > @@ -2078,7 +2078,7 @@ static int __init ffa_init(void)
> >
> > ret = ffa_rxtx_map(virt_to_phys(drv_info->tx_buffer),
> > virt_to_phys(drv_info->rx_buffer),
> > - rxtx_bufsz / FFA_PAGE_SIZE);
> > + DIV_ROUND_UP(rxtx_bufsz, PAGE_SIZE) / FFA_PAGE_SIZE);
>
> Did you mean to use PAGE_ALIGN() instead of DIV_ROUND_UP() ?
Yes, PAGE_ALIGN() my bad, I will send a v2 for this.
>
> The new pg_cnt calculation is dimensionally incorrect and evaluates to 0 for
> all the supported buffer sizes, so FFA_RXTX_MAP is always called with an
> invalid page count.
>
> Example: with rxtx_bufsz = 4K, the expression becomes 1 / 4096 on 4K/16K/64K
> page kernel, so pg_cnt == 0. Wouldn’t this cause a boot-time regression for
> FF-A driver init ? Have you tested this ? I am trying to understand what I
> might be missing here.
>
Thanks,
Sebastian
> --
> Regards,
> Sudeep
^ permalink raw reply
* RE: [PATCH 00/11] Drivers: hv: Add ARM64 support in mshv_vtl
From: Michael Kelley @ 2026-04-01 16:54 UTC (permalink / raw)
To: Naman Jain, Michael Kelley, K . Y . Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <a8f856a0-49a8-4041-9036-4e9ade79532b@linux.microsoft.com>
From: Naman Jain <namjain@linux.microsoft.com> Sent: Tuesday, March 17, 2026 9:23 PM
>
> On 3/18/2026 3:33 AM, Michael Kelley wrote:
> > From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
> >>
> >> The series intends to add support for ARM64 to mshv_vtl driver.
No need to be tentative. :-) Just write as:
"The series adds support for ARM64 to the mshv_vtl driver."
> >> For this, common Hyper-V code is refactored, necessary support is added,
> >> mshv_vtl_main.c is refactored and then finally support is added in
> >> Kconfig.
> >>
> >> Based on commit 1f318b96cc84 ("Linux 7.0-rc3")
> >
> > There's now an online LLM-based tool that is automatically reviewing
> > kernel patches. For this patch set, the results are here:
> >
> > https://sashiko.dev/#/patchset/20260316121241.910764-1-namjain%40linux.microsoft.com
> >
> > It has flagged several things that are worth checking, but I haven't
> > reviewed them to see if they are actually valid.
> >
> > FWIW, the announcement about sashiko.dev is here:
> >
> > https://lore.kernel.org/lkml/7ia4o6kmpj5s.fsf@castle.c.googlers.com/
> >
> > Michael
>
>
> Thanks for sharing Michael,
> I'll check it out and do the needful.
>
I've done a full review of this patch set and provided comments in the
individual patches. Some of my comments reference the Sashiko AI
comments, but there are still some Sashiko AI comments to consider
that I haven't referenced.
FWIW, the Sashiko AI comments are quite good -- it found some things
here that I missed on my own, and in my earlier reviews of the original VTL
code. :-(
Michael
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
From: Catalin Marinas @ 2026-04-01 17:09 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Sascha Bischoff, Will Deacon
In-Reply-To: <20260401170017.369529-1-maz@kernel.org>
On Wed, Apr 01, 2026 at 06:00:17PM +0100, Marc Zyngier wrote:
> As we are missing ID_AA64PFR2_EL1.GCIE from the kernel feature set,
> userspace cannot write ID_AA64PFR2_EL1 with GCIE set, even if we are
> on a GICv5 host.
>
> Add the required field description.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
From: Marc Zyngier @ 2026-04-01 17:00 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Will Deacon, Catalin Marinas
As we are missing ID_AA64PFR2_EL1.GCIE from the kernel feature set,
userspace cannot write ID_AA64PFR2_EL1 with GCIE set, even if we are
on a GICv5 host.
Add the required field description.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kernel/cpufeature.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 32c2dbcc0c641..5bca6e064ca72 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -327,6 +327,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTEFAR_SHIFT, 4, ID_AA64PFR2_EL1_MTEFAR_NI),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTESTOREONLY_SHIFT, 4, ID_AA64PFR2_EL1_MTESTOREONLY_NI),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
ARM64_FTR_END,
};
--
2.47.3
^ permalink raw reply related
* RE: [PATCH 11/11] Drivers: hv: Kconfig: Add ARM64 support for MSHV_VTL
From: Michael Kelley @ 2026-04-01 16:58 UTC (permalink / raw)
To: Naman Jain, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, Michael Kelley,
linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <20260316121241.910764-12-namjain@linux.microsoft.com>
From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
>
Nit: In keeping with past practice, the "Subject" prefix for this patch could
just be "Drivers: hv:"
> Enable ARM64 support in MSHV_VTL Kconfig now that all the necessary
> support is present.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
> drivers/hv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 7937ac0cbd0f..393cef272590 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -87,7 +87,7 @@ config MSHV_ROOT
>
> config MSHV_VTL
> tristate "Microsoft Hyper-V VTL driver"
> - depends on X86_64 && HYPERV_VTL_MODE
> + depends on (X86_64 || ARM64) && HYPERV_VTL_MODE
> depends on HYPERV_VMBUS
> # Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
> # VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
> --
> 2.43.0
>
The nit notwithstanding,
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
^ permalink raw reply
* RE: [PATCH 10/11] Drivers: hv: Add support for arm64 in MSHV_VTL
From: Michael Kelley @ 2026-04-01 16:58 UTC (permalink / raw)
To: Naman Jain, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, Michael Kelley,
linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <20260316121241.910764-11-namjain@linux.microsoft.com>
From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
>
> Add necessary support to make MSHV_VTL work for arm64 architecture.
> * Add stub implementation for mshv_vtl_return_call_init(): not required
> for arm64
> * Remove fpu/legacy.h header inclusion, as this is not required
> * handle HV_REGISTER_VSM_CODE_PAGE_OFFSETS register: not supported
> in arm64
> * Configure custom percpu_vmbus_handler by using
> hv_setup_percpu_vmbus_handler()
> * Handle hugepage functions by config checks
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
> arch/arm64/include/asm/mshyperv.h | 2 ++
> drivers/hv/mshv_vtl_main.c | 21 ++++++++++++++-------
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/mshyperv.h
> b/arch/arm64/include/asm/mshyperv.h
> index 36803f0386cc..027a7f062d70 100644
> --- a/arch/arm64/include/asm/mshyperv.h
> +++ b/arch/arm64/include/asm/mshyperv.h
> @@ -83,6 +83,8 @@ static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u
> return 1;
> }
>
> +static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
> +
> void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
> bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu);
> #endif
> diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
> index 4c9ae65ad3e8..5702fe258500 100644
> --- a/drivers/hv/mshv_vtl_main.c
> +++ b/drivers/hv/mshv_vtl_main.c
> @@ -23,8 +23,6 @@
> #include <trace/events/ipi.h>
> #include <uapi/linux/mshv.h>
> #include <hyperv/hvhdk.h>
> -
> -#include "../../kernel/fpu/legacy.h"
Was there a particular code change that made this unnecessary? Or was it
unnecessary from the start of this source code file? Just curious ....
> #include "mshv.h"
> #include "mshv_vtl.h"
> #include "hyperv_vmbus.h"
> @@ -206,18 +204,21 @@ static void mshv_vtl_synic_enable_regs(unsigned int cpu)
> static int mshv_vtl_get_vsm_regs(void)
> {
> struct hv_register_assoc registers[2];
> - int ret, count = 2;
> + int ret, count = 0;
>
> - registers[0].name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
> - registers[1].name = HV_REGISTER_VSM_CAPABILITIES;
> + registers[count++].name = HV_REGISTER_VSM_CAPABILITIES;
> + /* Code page offset register is not supported on ARM */
> + if (IS_ENABLED(CONFIG_X86_64))
> + registers[count++].name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
>
> ret = hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
> count, input_vtl_zero, registers);
> if (ret)
> return ret;
>
> - mshv_vsm_page_offsets.as_uint64 = registers[0].value.reg64;
> - mshv_vsm_capabilities.as_uint64 = registers[1].value.reg64;
> + mshv_vsm_capabilities.as_uint64 = registers[0].value.reg64;
> + if (IS_ENABLED(CONFIG_X86_64))
> + mshv_vsm_page_offsets.as_uint64 = registers[1].value.reg64;
>
> return ret;
> }
This function has gotten somewhat messy to handle the x86 and arm64
differences. Let me suggest a different approach. Have this function only
get the VSM capabilities register, as that is generic across x86 and
arm64. Then, update x86 mshv_vtl_return_call_init() to get the
PAGE_OFFSETS register and then immediately use the value to update
the static call. The global variable mshv_vms_page_offsets is no longer
necessary.
My suggestion might be little more code because hv_call_get_vp_registers()
is invoked in two different places. But it cleanly separates the two use
cases, and keeps the x86 hackery under arch/x86.
> @@ -280,10 +281,13 @@ static int hv_vtl_setup_synic(void)
>
> /* Use our isr to first filter out packets destined for userspace */
> hv_setup_vmbus_handler(mshv_vtl_vmbus_isr);
> + /* hv_setup_vmbus_handler() is stubbed for ARM64, add per-cpu VMBus handlers instead */
> + hv_setup_percpu_vmbus_handler(mshv_vtl_vmbus_isr);
>
> ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "hyperv/vtl:online",
> mshv_vtl_alloc_context, NULL);
> if (ret < 0) {
> + hv_setup_percpu_vmbus_handler(vmbus_isr);
> hv_setup_vmbus_handler(vmbus_isr);
> return ret;
> }
> @@ -296,6 +300,7 @@ static int hv_vtl_setup_synic(void)
> static void hv_vtl_remove_synic(void)
> {
> cpuhp_remove_state(mshv_vtl_cpuhp_online);
> + hv_setup_percpu_vmbus_handler(vmbus_isr);
> hv_setup_vmbus_handler(vmbus_isr);
> }
>
> @@ -1080,10 +1085,12 @@ static vm_fault_t mshv_vtl_low_huge_fault(struct vm_fault *vmf, unsigned int ord
> ret = vmf_insert_pfn_pmd(vmf, pfn, vmf->flags & FAULT_FLAG_WRITE);
> return ret;
>
> +#if defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
> case PUD_ORDER:
> if (can_fault(vmf, PUD_SIZE, &pfn))
> ret = vmf_insert_pfn_pud(vmf, pfn, vmf->flags & FAULT_FLAG_WRITE);
> return ret;
> +#endif
>
> default:
> return VM_FAULT_SIGBUS;
> --
> 2.43.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