* Re: [PATCH] drm: mxsfb: lcdif: enforce 64-byte pitch alignment for scanout
From: Advait Dhamorikar @ 2026-04-14 6:35 UTC (permalink / raw)
To: Philipp Zabel
Cc: marex, simona, imx, festevam, kernel, dri-devel, Frank.Li,
s.hauer, maarten.lankhorst, linux-kernel, mripard, stefan,
tzimmermann, airlied, linux-arm-kernel
In-Reply-To: <99fdddde59e1b0fe13d5014182b1c97de4fbec86.camel@pengutronix.de>
Hello Philipp,
> I wonder if setting 4320 bytes stride works if you reduce the burst
> size, for example by reverting commit 2215cb3be5c2 ("drm: lcdif: change
> burst size to 256B") to test.
Unfortunately, reverting the commit doesn't seem to fix the issue.
I tested with the reduced/default burst size as well as explicitly
setting it to 128 bytes, but a pitch of 4320 bytes still results in a
corrupted output(stretched and choppy display).
However, using a 64 byte aligned pitch works in all cases without having
to alter the burst size.
Best regards,
Advait
On Mon, Apr 13, 2026 at 7:16 PM Philipp Zabel <p.zabel@pengutronix.de> wrote:
>
> Hi,
>
> On Mo, 2026-04-13 at 17:14 +0530, Advait Dhamorikar wrote:
> > The LCDIF controller expects framebuffer pitch to be aligned to a
> > 64 byte boundary for reliable scanout.
> >
> > While byte-granular pitches are
> > supported by the interface, the i.MX8MP reference manual
> > recommends 64-byte alignment for optimal operation.
> >
> > Corrupted output was observed with XR24 framebuffers where a pitch of
> > 4320 bytes caused visible corruption and choppy display, while an aligned
> > pitch of 4352 bytes worked correctly.
>
> This happens to be divisible by 256, which is is the burst size
> currently set in the undocumented CTRLDESCL0_3 register fields,
> according to the comment in lcdif_set_mode().
>
> I wonder if setting 4320 bytes stride works if you reduce the burst
> size, for example by reverting commit 2215cb3be5c2 ("drm: lcdif: change
> burst size to 256B") to test.
>
> If that is the case, it might be better to allow unaligned pitches but
> configure the burst size depending on pitch alignment.
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH] mm/arm: pgtable: remove young bit check for pte_valid_user
From: Brian Ruley @ 2026-04-14 6:28 UTC (permalink / raw)
To: Will Deacon
Cc: Russell King (Oracle), Steve Capper, linux-arm-kernel,
linux-kernel, catalin.marinas
In-Reply-To: <ad0Ky09tLcFx7JCa@zoo11.fihel.lab.ge-healthcare.net>
On Apr 13, Brian Ruley wrote:
>
> Applied the fix and so far so good. We're going to run `stress-ng'
> tests overnight to be sure. In the meanwhile, I'll see if I can add
> some instrumentation to verify this is the bug we're seeing.
No failures in any of our tests. I can confirm that this solved our
problem.
Would you like me to submit the patch or will you guys take care of it?
BR,
Brian
^ permalink raw reply
* Re: [PATCH v10 00/20] CoreSight: Refactor power management for CoreSight path
From: Leo Yan @ 2026-04-14 6:09 UTC (permalink / raw)
To: Jie Gan
Cc: 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, Thomas Gleixner, Peter Zijlstra, coresight,
linux-arm-kernel
In-Reply-To: <633b8a0e-5e78-4c4d-83d8-d4c8ea71bf15@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 11:30:39AM +0800, Jie Gan wrote:
[...]
> > > Tested-by: Jie Gan <jie.gan@oss.qualcomm.com>
> >
> > Just heads up: since Sashiko [1] pointed out a corner case where an SMP call
> > may fail when disabling the source device, the per-CPU path pointer
> > might not be cleared. If the ETMv4 device is then removed (e.g. if the
> > user unloads the ETMv4 module), CPU PM notifier might access the stale
> > path pointer. Though this is a rare case, we should handle it safely.
> > This is why the series was not picked for the v7.1 merge window.
> >
> > Thanks a lot for the testing, Jie! It's very helpful, and I will add
> > your test tags in the next spin.
> >
> > Anyway, please expect more iterations.
>
> Noted, will run the test cases on new iterations.
Thank you!
^ permalink raw reply
* Re: [PATCH v10 00/20] CoreSight: Refactor power management for CoreSight path
From: Jie Gan @ 2026-04-14 3:30 UTC (permalink / raw)
To: Leo Yan
Cc: 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, Thomas Gleixner, Peter Zijlstra, coresight,
linux-arm-kernel
In-Reply-To: <20260413163130.GC356832@e132581.arm.com>
On 4/14/2026 12:31 AM, Leo Yan wrote:
> On Mon, Apr 13, 2026 at 06:30:18PM +0800, Jie Gan wrote:
>
> [...]
>
>> tested on QCOM sa8775-ride:
>>
>> === 1. Sysfs mode: basic enable/disable ===
>> PASS: Sink tmc_etr0 enabled
>> PASS: Source etm0 enabled
>> PASS: Source etm0 disabled cleanly
>> PASS: Sink tmc_etr0 disabled cleanly
>>
>> === 2. Sysfs mode: repeated enable/disable cycles (10x) ===
>> PASS: 10 enable/disable cycles completed without error
>>
>> === 3. Sysfs mode: enable source with no active sink ===
>> PASS: Enable without sink returned error (expected)
>>
>> === 4. Sysfs mode: enable/disable all per-CPU sources ===
>> etm0 (cpu0): enabled OK
>> etm1 (cpu1): enabled OK
>> etm2 (cpu2): enabled OK
>> etm3 (cpu3): enabled OK
>> etm4 (cpu4): enabled OK
>> etm5 (cpu5): enabled OK
>> etm6 (cpu6): enabled OK
>> etm7 (cpu7): enabled OK
>> PASS: All online per-CPU sources enabled/disabled successfully
>>
>> === 5. CPU hotplug: offline CPU while sysfs tracing active ===
>> Using source etm1 on cpu1
>> Tracing active on cpu1, offlining CPU...
>> [ 82.805359] psci: CPU1 killed (polled 0 ms)
>> PASS: Source auto-disabled on CPU offline
>> [ 83.346033] Detected PIPT I-cache on CPU1
>> [ 83.346114] GICv3: CPU1: found redistributor 100 region
>> 0:0x0000000017a80000
>> [ 83.346283] CPU1: Booted secondary processor 0x0000000100 [0x410fd4b2]
>> PASS: Source re-enabled after CPU re-online
>>
>> === 6. Sysfs: enable source on offline CPU (expect ENODEV) ===
>> [ 84.013788] psci: CPU1 killed (polled 0 ms)
>> PASS: Enable on offline cpu1 rejected (enable_source=0)
>> [ 84.349558] Detected PIPT I-cache on CPU1
>> [ 84.349640] GICv3: CPU1: found redistributor 100 region
>> 0:0x0000000017a80000
>> [ 84.349811] CPU1: Booted secondary processor 0x0000000100 [0x410fd4b2]
>>
>> === 7. CPU PM: trace survives CPU idle entry/exit ===
>> Sleeping 3s to allow CPU idle entry...
>> Idle entries on cpu0 during test: 35
>> PASS: Source still enabled after idle (PM save/restore working)
>>
>> === 8. Perf mode: basic cs_etm recording ===
>> SKIP: perf not found in PATH
>>
>> === 11. TRBE: check save/restore sysfs nodes (if present) ===
>> SKIP: No TRBE devices found
>>
>> Tested-by: Jie Gan <jie.gan@oss.qualcomm.com>
>
> Just heads up: since Sashiko [1] pointed out a corner case where an SMP call
> may fail when disabling the source device, the per-CPU path pointer
> might not be cleared. If the ETMv4 device is then removed (e.g. if the
> user unloads the ETMv4 module), CPU PM notifier might access the stale
> path pointer. Though this is a rare case, we should handle it safely.
> This is why the series was not picked for the v7.1 merge window.
>
> Thanks a lot for the testing, Jie! It's very helpful, and I will add
> your test tags in the next spin.
>
> Anyway, please expect more iterations.
Noted, will run the test cases on new iterations.
Thanks,
Jie
>
> Thanks,
> Leo
>
> [1] https://sashiko.dev/#/patchset/20260405-arm_coresight_path_power_management_improvement-v10-0-13e94754a8be%40arm.com?part=5
^ permalink raw reply
* [PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 3/3] fs/resctrl: Migrate IOMMU groups when removing resource groups
From: Zeng Heng @ 2026-04-14 3:26 UTC (permalink / raw)
To: ben.horgan, james.morse, Dave.Martin, fenghuay, reinette.chatre
Cc: xiaqinxin, sunnanyong, jonathan.cameron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260414032610.1523958-1-zengheng4@huawei.com>
When deleting a control group, monitor group, or unmounting the resctrl
filesystem, migrate all associated IOMMU groups to the appropriate
destination:
* Control group deletion: move IOMMU groups to the default group
* Monitor group deletion: move IOMMU groups to the parent control group
* Filesystem unmount: move all IOMMU groups to the default group
Without this migration, IOMMU groups remain bound to stale PARTID/PMG
values of the destroyed group, causing them to "disappear" from the
resctrl interface.
Add rdt_move_group_iommus() to handle this migration, mirroring the
existing rdt_move_group_tasks() pattern for task migration.
When deleting a control group or unmounting the resctrl file system, it
is necessary to move its all iommu_groups back to the default group. When
removing a monitor group, need to move its iommu_groups back to the parent
control group.
Otherwise, these iommu_groups remain bound to the old PARTID and PMG, and
they will appear to "disappear" from the resctrl fs.
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
fs/resctrl/rdtgroup.c | 47 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index e92b5dcb6f2e..351e430bde1a 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -3292,6 +3292,44 @@ static void rdt_move_group_tasks(struct rdtgroup *from, struct rdtgroup *to,
read_unlock(&tasklist_lock);
}
+static int rdt_move_group_iommus(struct rdtgroup *from, struct rdtgroup *to)
+{
+ struct kset *iommu_groups;
+ struct iommu_group *group;
+ int err = 0, iommu_group_id;
+ struct kobject *group_kobj = NULL;
+
+ if (!IS_ENABLED(CONFIG_RESCTRL_IOMMU))
+ return 0;
+
+ if (from == to)
+ return 0;
+
+ iommu_groups = iommu_get_group_kset();
+
+ while ((group_kobj = kset_get_next_obj(iommu_groups, group_kobj))) {
+ /* iommu_group_get_from_kobj() wants to drop a reference */
+ kobject_get(group_kobj);
+
+ group = iommu_group_get_from_kobj(group_kobj);
+ if (!group)
+ continue;
+
+ if (!from || iommu_matches_rdtgroup(group, from)) {
+ err = kstrtoint(group_kobj->name, 0, &iommu_group_id);
+ if (err)
+ break;
+
+ err = rdtgroup_move_iommu(iommu_group_id, to);
+ if (err)
+ break;
+ }
+ }
+
+ kset_put(iommu_groups);
+ return err;
+}
+
static void free_all_child_rdtgrp(struct rdtgroup *rdtgrp)
{
struct rdtgroup *sentry, *stmp;
@@ -3320,6 +3358,9 @@ static void rmdir_all_sub(void)
/* Move all tasks to the default resource group */
rdt_move_group_tasks(NULL, &rdtgroup_default, NULL);
+ /* Move all iommu_groups to the default resource group */
+ rdt_move_group_iommus(NULL, &rdtgroup_default);
+
list_for_each_entry_safe(rdtgrp, tmp, &rdt_all_groups, rdtgroup_list) {
/* Free any child rmids */
free_all_child_rdtgrp(rdtgrp);
@@ -4189,6 +4230,9 @@ static int rdtgroup_rmdir_mon(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)
/* Give any tasks back to the parent group */
rdt_move_group_tasks(rdtgrp, prdtgrp, tmpmask);
+ /* Give any iommu_groups back to the parent group */
+ rdt_move_group_iommus(rdtgrp, prdtgrp);
+
/*
* Update per cpu closid/rmid of the moved CPUs first.
* Note: the closid will not change, but the arch code still needs it.
@@ -4239,6 +4283,9 @@ static int rdtgroup_rmdir_ctrl(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)
/* Give any tasks back to the default group */
rdt_move_group_tasks(rdtgrp, &rdtgroup_default, tmpmask);
+ /* Give any iommu_groups back to the default group */
+ rdt_move_group_iommus(rdtgrp, &rdtgroup_default);
+
/* Give any CPUs back to the default group */
cpumask_or(&rdtgroup_default.cpu_mask,
&rdtgroup_default.cpu_mask, &rdtgrp->cpu_mask);
--
2.25.1
^ permalink raw reply related
* [PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 2/3] fs/resctrl: Remove unused 'of' parameter from rdtgroup_move_iommu()
From: Zeng Heng @ 2026-04-14 3:26 UTC (permalink / raw)
To: ben.horgan, james.morse, Dave.Martin, fenghuay, reinette.chatre
Cc: xiaqinxin, sunnanyong, jonathan.cameron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260414032610.1523958-1-zengheng4@huawei.com>
The 'of' (kernfs_open_file) parameter in rdtgroup_move_iommu() is
not used within the function body. Remove it to simplify the
interface and eliminate the unnecessary argument passing.
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
fs/resctrl/rdtgroup.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 1810ace9538f..e92b5dcb6f2e 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -767,8 +767,7 @@ static int rdtgroup_move_task(pid_t pid, struct rdtgroup *rdtgrp,
return ret;
}
-static int rdtgroup_move_iommu(int iommu_group_id, struct rdtgroup *rdtgrp,
- struct kernfs_open_file *of)
+static int rdtgroup_move_iommu(int iommu_group_id, struct rdtgroup *rdtgrp)
{
const struct cred *cred = current_cred();
struct iommu_group *iommu_group;
@@ -849,7 +848,7 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
if (is_iommu) {
- ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp, of);
+ ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp);
if (ret) {
rdt_last_cmd_printf("Error while processing iommu_group %d\n",
iommu_group_id);
--
2.25.1
^ permalink raw reply related
* [PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 1/3] fs/resctrl: Fix incorrect PID parsing after IOMMU group token
From: Zeng Heng @ 2026-04-14 3:26 UTC (permalink / raw)
To: ben.horgan, james.morse, Dave.Martin, fenghuay, reinette.chatre
Cc: xiaqinxin, sunnanyong, jonathan.cameron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260414032610.1523958-1-zengheng4@huawei.com>
When the tasks interface receives an "iommu_group:id" configuration,
the original code fails to skip the PID parsing logic after processing
the IOMMU group. This causes the same token to be incorrectly passed
to kstrtoint() as a PID, resulting in -EINVAL.
Restructure the conditional logic to use explicit if-else branches,
ensuring that IOMMU group tokens are processed by rdtgroup_move_iommu()
and then skipped.
This fix also enables proper handling of mixed configurations with
multiple consecutive iommu_group:id and pid entries (e.g.,
echo "iommu_group:1,1234,iommu_group:2,5678" > tasks).
Fixes: 98b622c413ee ("fs/resctrl: Add support for assigning iommu_groups to resctrl groups")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
fs/resctrl/rdtgroup.c | 39 ++++++++++++++++++++++++---------------
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 5381233adceb..1810ace9538f 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -848,24 +848,33 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
pid_str = strim(strsep(&buf, ","));
is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
- if (is_iommu)
+ if (is_iommu) {
ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp, of);
- else if (kstrtoint(pid_str, 0, &pid)) {
- rdt_last_cmd_printf("Task list parsing error pid %s\n", pid_str);
- ret = -EINVAL;
- break;
- }
+ if (ret) {
+ rdt_last_cmd_printf("Error while processing iommu_group %d\n",
+ iommu_group_id);
+ break;
+ }
+ } else {
+ if (kstrtoint(pid_str, 0, &pid)) {
+ rdt_last_cmd_printf("Task list parsing error pid %s\n",
+ pid_str);
+ ret = -EINVAL;
+ break;
+ }
- if (pid < 0) {
- rdt_last_cmd_printf("Invalid pid %d\n", pid);
- ret = -EINVAL;
- break;
- }
+ if (pid < 0) {
+ rdt_last_cmd_printf("Invalid pid %d\n", pid);
+ ret = -EINVAL;
+ break;
+ }
- ret = rdtgroup_move_task(pid, rdtgrp, of);
- if (ret) {
- rdt_last_cmd_printf("Error while processing task %d\n", pid);
- break;
+ ret = rdtgroup_move_task(pid, rdtgrp, of);
+ if (ret) {
+ rdt_last_cmd_printf("Error while processing task %d\n",
+ pid);
+ break;
+ }
}
}
--
2.25.1
^ permalink raw reply related
* [PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 0/3] fs/resctrl: IOMMU group fixes for tasks interface and cleanup
From: Zeng Heng @ 2026-04-14 3:26 UTC (permalink / raw)
To: ben.horgan, james.morse, Dave.Martin, fenghuay, reinette.chatre
Cc: xiaqinxin, sunnanyong, jonathan.cameron, linux-kernel,
linux-arm-kernel
This fix patch is against the mpam/snapshot+extras/v6.18-rc1 branch at
https://kernel.googlesource.com/pub/scm/linux/kernel/git/morse/linux.git .
The patch series fixes several issues with IOMMU group handling in the
resctrl filesystem.
Changes
=======
Compared with v1:
- Split patch 2 into separate patches 2 and 3.
Previous Versions
=================
v1: https://lore.kernel.org/all/20251107063300.1580046-1-zengheng4@huawei.com/
---
Zeng Heng (3):
fs/resctrl: Fix incorrect PID parsing after IOMMU group token
fs/resctrl: Remove unused 'of' parameter from rdtgroup_move_iommu()
fs/resctrl: Migrate IOMMU groups when removing resource groups
fs/resctrl/rdtgroup.c | 91 ++++++++++++++++++++++++++++++++++---------
1 file changed, 73 insertions(+), 18 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH bpf-next v14 1/5] bpf: Move constants blinding out of arch-specific JITs
From: Xu Kuohai @ 2026-04-14 3:20 UTC (permalink / raw)
To: bot+bpf-ci, bpf, linux-kernel, linux-arm-kernel
Cc: ast, daniel, andrii, martin.lau, eddyz87, memxor, yonghong.song,
puranjay, a.s.protopopov, alexis.lothore, list+bpf, linux,
yangtiezhu, hengqi.chen, johan.almbladh, paulburton, hbathini,
chleroy, naveen, luke.r.nels, xi.wang, bjorn, pulehui, iii, hca,
gor, davem, udknight, martin.lau, clm, ihor.solodrai
In-Reply-To: <fa46a9034904c7622f935d3e3a60264a37afda290705f40c816c9846c9d3f3f8@mail.kernel.org>
On 4/13/2026 9:47 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 066b86e7233c..fc9fb3c07866 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>
> [ ... ]
>
>> /**
>> * bpf_prog_select_runtime - select exec runtime for BPF program
>> * @fp: bpf_prog populated with BPF program
>
> [ ... ]
>
>> - /* eBPF JITs can rewrite the program in case constant
>> - * blinding is active. However, in case of error during
>> - * blinding, bpf_int_jit_compile() must always return a
>> - * valid program, which in this case would simply not
>> - * be JITed, but falls back to the interpreter.
>> - */
>> + /* eBPF JITs can rewrite the program in case constant
>> + * blinding is active. However, in case of error during
>> + * blinding, bpf_int_jit_compile() must always return a
>> + * valid program, which in this case would simply not
>> + * be JITed, but falls back to the interpreter.
>> + */
>
> This isn't a bug, but this comment still references bpf_int_jit_compile()
> even though the code now calls bpf_prog_jit_compile(). Should this be
> updated to match?
>
This comment is not touched by the patch, it was already there before
the patch, so I'd leave it as is.
>> - fp = bpf_int_jit_compile(fp);
>> + fp = bpf_prog_jit_compile(fp);
>
>> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
>> index 67c9b28767e1..ec8afd6a9369 100644
>> --- a/kernel/bpf/fixups.c
>> +++ b/kernel/bpf/fixups.c
>
> [ ... ]
>
>> +out_jit_err:
>> + if (blinded) {
>> + bpf_jit_prog_release_other(orig_prog, prog);
>> + /* roll back to the clean original prog */
>> + prog = env->prog = orig_prog;
>> + goto out_restore;
>> + } else {
>> + if (err != -EFAULT) {
>> + /*
>> + * We will fall back to interpreter mode when err is not -EFAULT, before
>> + * that, insn->off and insn->imm should be restored to their original
>> + * values since they were modified by __jit_subprogs.
>> + */
>
> The comment references __jit_subprogs, but the function is named
> jit_subprogs (no double underscore prefix). Should this be updated?
>
Yes, it should be jit_subprogs.
In addition, sashiko reported an issue that subprog_start of the fake
exit subprog is not restored on the rollback path. It said that
bpf_fixup_call_args() relies on this sentinel to detect the end of the
last subprog. I checked the bpf_fixup_call_args() function and its child
functions, but could not find any usage of the sentinel.
IIUC, the sentinel is only used to compute the length of the last subprog
and is not used after jit_subprogs fails, so not restoring it does not
to be a real issue.
However, leaving the sentinel unrestored seems error-prone, and for code
consistency, I'll restore it in the next version.
>> + for (i = 0, insn = prog->insnsi; i < prog->len; i++, insn++) {
>> + if (!bpf_pseudo_call(insn))
>> + continue;
>> + insn->off = 0;
>> + insn->imm = env->insn_aux_data[i].call_imm;
>> + }
>> + }
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24345549165
^ permalink raw reply
* Re: [PATCH v7 0/2] arm64: dts/defconfig: enable BST C1200 eMMC
From: Albert Yang @ 2026-04-14 3:10 UTC (permalink / raw)
To: Gordon Ge
Cc: Albert Yang, krzk, arnd, krzk+dt, robh, conor+dt, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260310091211.4171307-1-yangzh0906@thundersoft.com>
Hi Gordon,
Could you please help with:
1) Reviewing the remaining 2 patches in this series.
If acceptable, please reply with an Acked-by on each patch below:
- [PATCH v7 1/2] arm64: dts: bst: enable eMMC controller in C1200 CDCU1.0 board
- [PATCH v7 2/2] arm64: defconfig: enable BST SDHCI controller
I will carry your tags in the next revision.
Thanks,
Albert
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Padmashree S S @ 2026-04-14 2:13 UTC (permalink / raw)
To: Rob Herring
Cc: andrew, gregory.clement, sebastian.hesselbarth, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260407184455.GA3369046-robh@kernel.org>
On Wed, Apr 8, 2026 at 12:14 AM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, Mar 27, 2026 at 05:16:53PM +0530, Padmashree S S wrote:
> > Convert armada-380-mpcore-soc-ctrl to DT schema
> >
> > Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> > ---
> > .../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
> > .../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
> > 2 files changed, 32 insertions(+), 14 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
> > create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
>
> Please move this to
> bindings/soc/marvell/marvell,armada-380-mpcore-soc-ctrl.yaml
>
> Don't forget to update the '$id' value.
>
> Rob
Thank you for the review, I'll move the binding and change the $id in
the next version of this patch.
^ permalink raw reply
* RE: [EXT] Re: [PATCH v2] pmdomain: imx: Make IMX8M/IMX9 BLK_CTRL tristate
From: Zhipeng Wang @ 2026-04-14 1:59 UTC (permalink / raw)
To: Marco Felsch
Cc: ulfh@kernel.org, Frank Li, s.hauer@pengutronix.de,
imx@lists.linux.dev, linux-pm@vger.kernel.org, Xuegang Liu,
Jindong Yue, linux-kernel@vger.kernel.org, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <ql2c6m54fjjwifycaan3hcr3p3bp4phva2vdux2qcramt7wrvy@4dsvpyct5tqx>
> On 26-04-13, Zhipeng Wang wrote:
> > Convert IMX8M_BLK_CTRL and IMX9_BLK_CTRL from bool to tristate to
> > allow building as loadable modules.
>
> Out of curiosity, why do you want to have a PM driver to be buildable as
> module?
>
> Regards,
> Marco
>
Hi Marco,
Thank you for your question.
The primary motivation is to support Google's GKI (Generic Kernel Image)
requirement for Android devices.
GKI separates the kernel into two parts:
1. A unified kernel image (GKI) that is common across all Android devices
2. Vendor-specific drivers that must be built as loadable modules
Under the GKI architecture, SoC-specific drivers like IMX8M/IMX9 BLK_CTRL
cannot be built into the core kernel image. Instead, they must be loadable
modules that vendors can ship separately. This allows:
- A single kernel binary to support multiple hardware platforms
- Vendors to update their drivers independently without rebuilding the entire kernel
- Better compliance with Android's kernel update and security policies
For i.MX8M/i.MX9 devices running Android with GKI kernels, the BLK_CTRL
drivers need to be loaded as modules during boot. Without tristate support,
these devices cannot properly initialize their power domains, making them
non-functional under GKI.
Best regards,
Zhipeng Wang
> > Add prompt strings to make these options visible and configurable in
> > menuconfig, keeping them enabled by default on appropriate platforms.
> >
> > Also remove the IMX_GPCV2_PM_DOMAINS dependency from
> IMX9_BLK_CTRL.
> > This dependency was incorrect from the beginning - i.MX93 uses a
> > different power domain architecture compared to i.MX8M series:
> >
> > - i.MX8M uses GPCv2 (General Power Controller v2) for power domain
> > management, hence IMX8M_BLK_CTRL correctly depends on it.
> >
> > - i.MX93 uses BLK_CTRL directly without GPCv2. The hardware doesn't
> > have GPCv2 at all.
> >
> > Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
> > ---
> > drivers/pmdomain/imx/Kconfig | 11 +++++++----
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pmdomain/imx/Kconfig
> > b/drivers/pmdomain/imx/Kconfig index 00203615c65e..9168d183b0c5
> 100644
> > --- a/drivers/pmdomain/imx/Kconfig
> > +++ b/drivers/pmdomain/imx/Kconfig
> > @@ -10,15 +10,18 @@ config IMX_GPCV2_PM_DOMAINS
> > default y if SOC_IMX7D
> >
> > config IMX8M_BLK_CTRL
> > - bool
> > - default SOC_IMX8M && IMX_GPCV2_PM_DOMAINS
> > + tristate "i.MX8M BLK CTRL driver"
> > + depends on SOC_IMX8M
> > + depends on IMX_GPCV2_PM_DOMAINS
> > depends on PM_GENERIC_DOMAINS
> > depends on COMMON_CLK
> > + default y
> >
> > config IMX9_BLK_CTRL
> > - bool
> > - default SOC_IMX9 && IMX_GPCV2_PM_DOMAINS
> > + tristate "i.MX93 BLK CTRL driver"
> > + depends on SOC_IMX9
> > depends on PM_GENERIC_DOMAINS
> > + default y
> >
> > config IMX_SCU_PD
> > bool "IMX SCU Power Domain driver"
> > --
> > 2.34.1
> >
> >
> >
>
> --
> #gernperDu
> #CallMeByMyFirstName
>
> Pengutronix e.K. |
> |
> Steuerwalder Str. 21 |
> https://www.pe/
> ngutronix.de%2F&data=05%7C02%7Czhipeng.wang_1%40nxp.com%7Cb056e
> 81e107a466e482a08de995e4054%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C639116827251261199%7CUnknown%7CTWFpbGZsb3d8eyJFb
> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qeSCoz6%2BawDiK1ISgG6Rs
> %2BtKScilTDoryyrt08WQYiA%3D&reserved=0 |
> 31137 Hildesheim, Germany | Phone:
> +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9
> |
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/2] bpf, arm64: Remove redundant bpf_flush_icache() after pack allocator finalize
From: Xu Kuohai @ 2026-04-14 1:55 UTC (permalink / raw)
To: Puranjay Mohan, bpf
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Catalin Marinas, Will Deacon,
Luke Nelson, Xi Wang, Björn Töpel, Pu Lehui,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
linux-arm-kernel, linux-riscv, linux-kernel
In-Reply-To: <20260413191111.3426023-2-puranjay@kernel.org>
On 4/14/2026 3:11 AM, Puranjay Mohan wrote:
> bpf_flush_icache() calls flush_icache_range() to clean the data cache
> and invalidate the instruction cache for the JITed code region. However,
> since commit 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory
> management"), this flush is redundant.
>
> bpf_jit_binary_pack_finalize() copies the JITed instructions to the ROX
> region via bpf_arch_text_copy() -> aarch64_insn_copy() -> __text_poke(),
> and __text_poke() already calls flush_icache_range() on the written
> range. The subsequent bpf_flush_icache() repeats the same cache
> maintenance on an overlapping range, including an unnecessary second
> synchronous IPI to all CPUs via kick_all_cpus_sync().
>
So icache is flushed twice: once per instruction and again after all
instructions are copied. I think it's better to remove the per-instruction
flush and retain the single final flush to avoid repeating flush overhead
for each instruction.
> Remove the redundant bpf_flush_icache() call and its now-unused
> definition.
>
> Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management")
> Acked-by: Song Liu <song@kernel.org>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
> ---
> arch/arm64/net/bpf_jit_comp.c | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> index adf84962d579..7417d24a5b6f 100644
> --- a/arch/arm64/net/bpf_jit_comp.c
> +++ b/arch/arm64/net/bpf_jit_comp.c
> @@ -18,7 +18,6 @@
>
> #include <asm/asm-extable.h>
> #include <asm/byteorder.h>
> -#include <asm/cacheflush.h>
> #include <asm/cpufeature.h>
> #include <asm/debug-monitors.h>
> #include <asm/insn.h>
> @@ -1961,11 +1960,6 @@ static int validate_ctx(struct jit_ctx *ctx)
> return 0;
> }
>
> -static inline void bpf_flush_icache(void *start, void *end)
> -{
> - flush_icache_range((unsigned long)start, (unsigned long)end);
> -}
> -
> static void priv_stack_init_guard(void __percpu *priv_stack_ptr, int alloc_size)
> {
> int cpu, underflow_idx = (alloc_size - PRIV_STACK_GUARD_SZ) >> 3;
> @@ -2204,12 +2198,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> prog = orig_prog;
> goto out_off;
> }
> - /*
> - * The instructions have now been copied to the ROX region from
> - * where they will execute. Now the data cache has to be cleaned to
> - * the PoU and the I-cache has to be invalidated for the VAs.
> - */
> - bpf_flush_icache(ro_header, ctx.ro_image + ctx.idx);
> } else {
> jit_data->ctx = ctx;
> jit_data->ro_image = ro_image_ptr;
^ permalink raw reply
* RE: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS suspend skip
From: Hongxing Zhu @ 2026-04-14 1:53 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: mani@kernel.org, Frank Li, jingoohan1@gmail.com,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <20260410225341.GA598942@bhelgaas>
> -----Original Message-----
> From: Bjorn Helgaas <helgaas@kernel.org>
> Sent: 2026年4月11日 6:54
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: mani@kernel.org; Frank Li <frank.li@nxp.com>; jingoohan1@gmail.com;
> l.stach@pengutronix.de; lpieralisi@kernel.org; kwilczynski@kernel.org;
> robh@kernel.org; bhelgaas@google.com; s.hauer@pengutronix.de;
> kernel@pengutronix.de; festevam@gmail.com; linux-pci@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev;
> linux-kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS
> suspend skip
>
> On Wed, Apr 08, 2026 at 02:38:35AM +0000, Hongxing Zhu wrote:
> > ...
>
> > One additional note regarding NVMe: ASPM (Active State Power
> > Management) is disabled locally on i.MX platforms for NVMe devices.
> > This decision was made after encountering a system hang issue similar
> > to the one reported by Hans a few months ago in his patch listed below.
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Flinux-nvme%2F20250502032051.920990-1-hans.zhang%40cix
> tec
> >
> h.com%2F&data=05%7C02%7Chongxing.zhu%40nxp.com%7Cbcdec1ffa5144c
> dc70ec0
> >
> 8de97540509%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639114
> 5842866
> >
> 17247%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> LjAuMDAw
> >
> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
> &sdat
> >
> a=Lpafp%2Fo3n%2FzCC%2F9iwxviRdFZzT8azQC%2FzSjTbArDV8E%3D&reserve
> d=0
>
> Where is ASPM disabled for i.MX? I don't see anything in pci-imx6.c.
Hi Bjorn:
Thanks for your concerns.
You're correct - the ASPM L1SS disabling for NVMe is currently implemented as
a local quirk patch, not in pci-imx6.c.
>
> It doesn't sound architecturally clean to me to disable ASPM based on
> whether an NVMe device is involved.
I agree this approach isn't ideal. The quirk-based solution was a temporary
workaround.
Best Regards
Richard Zhu
^ permalink raw reply
* Re: [PATCH bpf-next v2 2/2] bpf, riscv: Remove redundant bpf_flush_icache() after pack allocator finalize
From: Pu Lehui @ 2026-04-14 1:13 UTC (permalink / raw)
To: Puranjay Mohan, bpf
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Xu Kuohai, Catalin Marinas,
Will Deacon, Luke Nelson, Xi Wang, Björn Töpel,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
linux-arm-kernel, linux-riscv, linux-kernel
In-Reply-To: <20260413191111.3426023-3-puranjay@kernel.org>
On 2026/4/14 3:11, Puranjay Mohan wrote:
> bpf_flush_icache() calls flush_icache_range() to clean the data cache
> and invalidate the instruction cache for the JITed code region. However,
> since commit 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the
> BPF JIT"), this flush is redundant.
>
> bpf_jit_binary_pack_finalize() copies the JITed instructions to the ROX
> region via bpf_arch_text_copy() -> patch_text_nosync(), and
> patch_text_nosync() already calls flush_icache_range() on the written
> range. The subsequent bpf_flush_icache() repeats the same cache
> maintenance on an overlapping range.
>
> Remove the redundant bpf_flush_icache() call and its now-unused
> definition.
>
> Fixes: 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT")
> Acked-by: Song Liu <song@kernel.org>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
> ---
> arch/riscv/net/bpf_jit.h | 6 ------
> arch/riscv/net/bpf_jit_core.c | 7 -------
> 2 files changed, 13 deletions(-)
>
> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
> index 632ced07bca4..da0271790244 100644
> --- a/arch/riscv/net/bpf_jit.h
> +++ b/arch/riscv/net/bpf_jit.h
> @@ -11,7 +11,6 @@
>
> #include <linux/bpf.h>
> #include <linux/filter.h>
> -#include <asm/cacheflush.h>
>
> /* verify runtime detection extension status */
> #define rv_ext_enabled(ext) \
> @@ -105,11 +104,6 @@ static inline void bpf_fill_ill_insns(void *area, unsigned int size)
> memset(area, 0, size);
> }
>
> -static inline void bpf_flush_icache(void *start, void *end)
> -{
> - flush_icache_range((unsigned long)start, (unsigned long)end);
> -}
> -
> /* Emit a 4-byte riscv instruction. */
> static inline void emit(const u32 insn, struct rv_jit_context *ctx)
> {
> diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
> index b3581e926436..f7fd4afc3ca3 100644
> --- a/arch/riscv/net/bpf_jit_core.c
> +++ b/arch/riscv/net/bpf_jit_core.c
> @@ -183,13 +183,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> prog = orig_prog;
> goto out_offset;
> }
> - /*
> - * The instructions have now been copied to the ROX region from
> - * where they will execute.
> - * Write any modified data cache blocks out to memory and
> - * invalidate the corresponding blocks in the instruction cache.
> - */
> - bpf_flush_icache(jit_data->ro_header, ctx->ro_insns + ctx->ninsns);
> for (i = 0; i < prog->len; i++)
> ctx->offset[i] = ninsns_rvoff(ctx->offset[i]);
> bpf_prog_fill_jited_linfo(prog, ctx->offset);
Reviewed-by: Pu Lehui <pulehui@huawei.com>
^ permalink raw reply
* Re: [GIT PULL] CRC updates for 7.1
From: pr-tracker-bot @ 2026-04-14 0:37 UTC (permalink / raw)
To: Eric Biggers
Cc: Linus Torvalds, linux-crypto, linux-arm-kernel, linux-kernel,
Ard Biesheuvel, Demian Shulhan
In-Reply-To: <20260412002343.GB6632@sol>
The pull request you sent on Sat, 11 Apr 2026 17:23:43 -0700:
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git tags/crc-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d142ab35ee0b7f9e84115fe3e4c3de4a9ac35f5e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] Crypto library updates for 7.1
From: pr-tracker-bot @ 2026-04-14 0:37 UTC (permalink / raw)
To: Eric Biggers
Cc: Linus Torvalds, linux-crypto, linux-arm-kernel, linux-kernel,
Ard Biesheuvel, Jason A. Donenfeld, Herbert Xu, AlanSong-oc,
Arnd Bergmann, Dan Williams, David Howells, Johannes Berg,
Randy Dunlap
In-Reply-To: <20260412003225.GC6632@sol>
The pull request you sent on Sat, 11 Apr 2026 17:32:25 -0700:
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git tags/libcrypto-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/370c3883195566ee3e7d79e0146c3d735a406573
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Remove PCE_MC_EN_MASK bit in REG_FE_PCE_CFG configuration
From: patchwork-bot+netdevbpf @ 2026-04-14 0:20 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260412-airoha_fe_init_remove_mc_en_bit-v1-1-7b6a5a25a74d@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 12 Apr 2026 11:56:25 +0200 you wrote:
> PCE_MC_EN_MASK bit in REG_FE_PCE_CFG configuration performed in
> airoha_fe_init() is used to duplicate multicast packets and send a copy
> to the CPU when the traffic is offloaded. This is necessary just if
> it is requested by the user. Disable multicast packets duplication by
> default.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net-next] net: airoha: Remove PCE_MC_EN_MASK bit in REG_FE_PCE_CFG configuration
https://git.kernel.org/netdev/net-next/c/34e1a98ff2a8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v2 4/4] KVM: arm64: Fallback to a supported value for unsupported guest TGx
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260414000334.3947257-1-weilin.chang@arm.com>
When KVM derives the translation granule for emulated stage-1 and
stage-2 walks, it decodes TCR/VTCR.TGx and treats the granule as-is.
This is wrong when the guest programs a granule size that is not
advertised in the guest's ID_AA64MMFR0_EL1.TGRAN* fields.
Architecturally, such a value must be treated as an implemented granule
size. Choose an available one while prioritizing PAGE_SIZE.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/at.c | 52 +++++++++++++++++++++-
arch/arm64/kvm/nested.c | 98 +++++++++++++++++++++++++++++------------
2 files changed, 121 insertions(+), 29 deletions(-)
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index 927226266081..702ce531afd5 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -135,6 +135,30 @@ static void compute_s1poe(struct kvm_vcpu *vcpu, struct s1_walk_info *wi)
wi->e0poe = (wi->regime != TR_EL2) && (val & TCR2_EL1_E0POE);
}
+#define _has_tgran(__r, __sz) \
+ ({ \
+ u64 _s1, _mmfr0 = __r; \
+ \
+ _s1 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
+ TGRAN##__sz, _mmfr0); \
+ \
+ _s1 != ID_AA64MMFR0_EL1_TGRAN##__sz##_NI; \
+ })
+
+static bool has_tgran(u64 mmfr0, unsigned int shift)
+{
+ switch (shift) {
+ case 12:
+ return _has_tgran(mmfr0, 4);
+ case 14:
+ return _has_tgran(mmfr0, 16);
+ case 16:
+ return _has_tgran(mmfr0, 64);
+ default:
+ BUG();
+ }
+}
+
static unsigned int tcr_to_tg0_pgshift(u64 tcr)
{
u64 tg0 = tcr & TCR_TG0_MASK;
@@ -165,8 +189,23 @@ static unsigned int tcr_to_tg1_pgshift(u64 tcr)
}
}
-static unsigned int tcr_tg_pgshift(u64 tcr, bool upper_range)
+static unsigned int fallback_tgran_shift(u64 mmfr0)
+{
+ if (has_tgran(mmfr0, PAGE_SHIFT))
+ return PAGE_SHIFT;
+ else if (has_tgran(mmfr0, 12))
+ return 12;
+ else if (has_tgran(mmfr0, 14))
+ return 14;
+ else if (has_tgran(mmfr0, 16))
+ return 16;
+ else
+ return PAGE_SHIFT;
+}
+
+static unsigned int tcr_tg_pgshift(struct kvm *kvm, u64 tcr, bool upper_range)
{
+ u64 mmfr0 = kvm_read_vm_id_reg(kvm, SYS_ID_AA64MMFR0_EL1);
unsigned int shift;
/* Someone was silly enough to encode TG0/TG1 differently */
@@ -175,6 +214,15 @@ static unsigned int tcr_tg_pgshift(u64 tcr, bool upper_range)
else
shift = tcr_to_tg0_pgshift(tcr);
+ /*
+ * If TGx is programmed to an unimplemented value (not advertised in
+ * ID_AA64MMFR0_EL1), we should treat it as if an implemented value is
+ * written, as per the architecture. Choose an available one while
+ * prioritizing PAGE_SIZE.
+ */
+ if (!has_tgran(mmfr0, shift))
+ return fallback_tgran_shift(mmfr0);
+
return shift;
}
@@ -222,7 +270,7 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
else
wi->txsz = FIELD_GET(TCR_T0SZ_MASK, tcr);
- wi->pgshift = tcr_tg_pgshift(tcr, upper_range);
+ wi->pgshift = tcr_tg_pgshift(vcpu->kvm, tcr, upper_range);
wi->pa52bit = has_52bit_pa(vcpu, wi, tcr);
ia_bits = get_ia_size(wi);
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index a732d7b0bd5d..327a6aaa45db 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -378,25 +378,83 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
return 0;
}
+#define _has_tgran_2(__r, __sz) \
+ ({ \
+ u64 _s1, _s2, _mmfr0 = __r; \
+ \
+ _s2 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
+ TGRAN##__sz##_2, _mmfr0); \
+ \
+ _s1 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
+ TGRAN##__sz, _mmfr0); \
+ \
+ ((_s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_NI && \
+ _s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz) || \
+ (_s2 == ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz && \
+ _s1 != ID_AA64MMFR0_EL1_TGRAN##__sz##_NI)); \
+ })
+
+static bool has_tgran_2(u64 mmfr0, unsigned int shift)
+{
+ switch (shift) {
+ case 12:
+ return _has_tgran_2(mmfr0, 4);
+ case 14:
+ return _has_tgran_2(mmfr0, 16);
+ case 16:
+ return _has_tgran_2(mmfr0, 64);
+ default:
+ BUG();
+ }
+}
+
+static unsigned int fallback_tgran2_shift(u64 mmfr0)
+{
+ if (has_tgran_2(mmfr0, PAGE_SHIFT))
+ return PAGE_SHIFT;
+ else if (has_tgran_2(mmfr0, 12))
+ return 12;
+ else if (has_tgran_2(mmfr0, 14))
+ return 14;
+ else if (has_tgran_2(mmfr0, 16))
+ return 16;
+ else
+ return PAGE_SHIFT;
+}
-static unsigned int vtcr_to_tg0_pgshift(u64 vtcr)
+static unsigned int vtcr_to_tg0_pgshift(struct kvm *kvm, u64 vtcr)
{
u64 tg0 = FIELD_GET(VTCR_EL2_TG0_MASK, vtcr);
+ u64 mmfr0 = kvm_read_vm_id_reg(kvm, SYS_ID_AA64MMFR0_EL1);
+ unsigned int shift;
switch (tg0) {
case VTCR_EL2_TG0_4K:
- return 12;
+ shift = 12;
+ break;
case VTCR_EL2_TG0_16K:
- return 14;
+ shift = 14;
+ break;
case VTCR_EL2_TG0_64K:
default: /* IMPDEF: treat any other value as 64k */
- return 16;
+ shift = 16;
}
+
+ /*
+ * If TGx is programmed to an unimplemented value (not advertised in
+ * ID_AA64MMFR0_EL1), we should treat it as if an implemented value is
+ * written, as per the architecture. Choose an available one while
+ * prioritizing PAGE_SIZE.
+ */
+ if (!has_tgran_2(mmfr0, shift))
+ return fallback_tgran2_shift(mmfr0);
+
+ return shift;
}
-static size_t vtcr_to_tg0_pgsize(u64 vtcr)
+static size_t vtcr_to_tg0_pgsize(struct kvm *kvm, u64 vtcr)
{
- return BIT(vtcr_to_tg0_pgshift(vtcr));
+ return BIT(vtcr_to_tg0_pgshift(kvm, vtcr));
}
static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
@@ -405,7 +463,7 @@ static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
wi->baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
wi->t0sz = vtcr & VTCR_EL2_T0SZ_MASK;
- wi->pgshift = vtcr_to_tg0_pgshift(vtcr);
+ wi->pgshift = vtcr_to_tg0_pgshift(vcpu->kvm, vtcr);
wi->sl = FIELD_GET(VTCR_EL2_SL0_MASK, vtcr);
/* Global limit for now, should eventually be per-VM */
wi->max_oa_bits = min(get_kvm_ipa_limit(),
@@ -524,7 +582,8 @@ static u8 get_guest_mapping_ttl(struct kvm_s2_mmu *mmu, u64 addr)
u64 tmp, sz = 0;
kvm_pte_t pte;
u8 ttl, level;
- size_t tg0_size = vtcr_to_tg0_pgsize(mmu->tlb_vtcr);
+ struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
+ size_t tg0_size = vtcr_to_tg0_pgsize(kvm, mmu->tlb_vtcr);
lockdep_assert_held_write(&kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
@@ -608,7 +667,7 @@ unsigned long compute_tlb_inval_range(struct kvm_s2_mmu *mmu, u64 val)
if (!max_size) {
/* Compute the maximum extent of the invalidation */
- switch (vtcr_to_tg0_pgsize(mmu->tlb_vtcr)) {
+ switch (vtcr_to_tg0_pgsize(kvm, mmu->tlb_vtcr)) {
case SZ_4K:
max_size = SZ_1G;
break;
@@ -1504,21 +1563,6 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
}
}
-#define has_tgran_2(__r, __sz) \
- ({ \
- u64 _s1, _s2, _mmfr0 = __r; \
- \
- _s2 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
- TGRAN##__sz##_2, _mmfr0); \
- \
- _s1 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
- TGRAN##__sz, _mmfr0); \
- \
- ((_s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_NI && \
- _s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz) || \
- (_s2 == ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz && \
- _s1 != ID_AA64MMFR0_EL1_TGRAN##__sz##_NI)); \
- })
/*
* Our emulated CPU doesn't support all the possible features. For the
* sake of simplicity (and probably mental sanity), wipe out a number
@@ -1600,15 +1644,15 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
*/
switch (PAGE_SIZE) {
case SZ_4K:
- if (has_tgran_2(orig_val, 4))
+ if (_has_tgran_2(orig_val, 4))
val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN4_2, IMP);
fallthrough;
case SZ_16K:
- if (has_tgran_2(orig_val, 16))
+ if (_has_tgran_2(orig_val, 16))
val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN16_2, IMP);
fallthrough;
case SZ_64K:
- if (has_tgran_2(orig_val, 64))
+ if (_has_tgran_2(orig_val, 64))
val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN64_2, IMP);
break;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] KVM: arm64: Factor out TG0/1 decoding of VTCR and TCR
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260414000334.3947257-1-weilin.chang@arm.com>
The current code decodes TCR.TG0/TG1 and VTCR.TG0 inline at several
places. Extract this logic into helpers so the granule size can be
derived in one place. This enables us to alter the effective granule
size in the same place, which we will do in a later patch.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/at.c | 77 ++++++++++++++++++++++++++---------------
arch/arm64/kvm/nested.c | 27 +++++++++------
2 files changed, 65 insertions(+), 39 deletions(-)
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index a024d9a770dc..927226266081 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -135,14 +135,58 @@ static void compute_s1poe(struct kvm_vcpu *vcpu, struct s1_walk_info *wi)
wi->e0poe = (wi->regime != TR_EL2) && (val & TCR2_EL1_E0POE);
}
+static unsigned int tcr_to_tg0_pgshift(u64 tcr)
+{
+ u64 tg0 = tcr & TCR_TG0_MASK;
+
+ switch (tg0) {
+ case TCR_TG0_4K:
+ return 12;
+ case TCR_TG0_16K:
+ return 14;
+ case TCR_TG0_64K:
+ default: /* IMPDEF: treat any other value as 64k */
+ return 16;
+ }
+}
+
+static unsigned int tcr_to_tg1_pgshift(u64 tcr)
+{
+ u64 tg1 = tcr & TCR_TG1_MASK;
+
+ switch (tg1) {
+ case TCR_TG1_4K:
+ return 12;
+ case TCR_TG1_16K:
+ return 14;
+ case TCR_TG1_64K:
+ default: /* IMPDEF: treat any other value as 64k */
+ return 16;
+ }
+}
+
+static unsigned int tcr_tg_pgshift(u64 tcr, bool upper_range)
+{
+ unsigned int shift;
+
+ /* Someone was silly enough to encode TG0/TG1 differently */
+ if (upper_range)
+ shift = tcr_to_tg1_pgshift(tcr);
+ else
+ shift = tcr_to_tg0_pgshift(tcr);
+
+ return shift;
+}
+
static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
struct s1_walk_result *wr, u64 va)
{
- u64 hcr, sctlr, tcr, tg, ps, ia_bits, ttbr;
+ u64 hcr, sctlr, tcr, ps, ia_bits, ttbr;
unsigned int stride, x;
- bool va55, tbi, lva;
+ bool va55, tbi, lva, upper_range;
va55 = va & BIT(55);
+ upper_range = va55 && wi->regime != TR_EL2;
if (vcpu_has_nv(vcpu)) {
hcr = __vcpu_sys_reg(vcpu, HCR_EL2);
@@ -173,35 +217,12 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
BUG();
}
- /* Someone was silly enough to encode TG0/TG1 differently */
- if (va55 && wi->regime != TR_EL2) {
+ if (upper_range)
wi->txsz = FIELD_GET(TCR_T1SZ_MASK, tcr);
- tg = FIELD_GET(TCR_TG1_MASK, tcr);
-
- switch (tg << TCR_TG1_SHIFT) {
- case TCR_TG1_4K:
- wi->pgshift = 12; break;
- case TCR_TG1_16K:
- wi->pgshift = 14; break;
- case TCR_TG1_64K:
- default: /* IMPDEF: treat any other value as 64k */
- wi->pgshift = 16; break;
- }
- } else {
+ else
wi->txsz = FIELD_GET(TCR_T0SZ_MASK, tcr);
- tg = FIELD_GET(TCR_TG0_MASK, tcr);
-
- switch (tg << TCR_TG0_SHIFT) {
- case TCR_TG0_4K:
- wi->pgshift = 12; break;
- case TCR_TG0_16K:
- wi->pgshift = 14; break;
- case TCR_TG0_64K:
- default: /* IMPDEF: treat any other value as 64k */
- wi->pgshift = 16; break;
- }
- }
+ wi->pgshift = tcr_tg_pgshift(tcr, upper_range);
wi->pa52bit = has_52bit_pa(vcpu, wi, tcr);
ia_bits = get_ia_size(wi);
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index f20402d0d7e5..40d52e9100d6 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -378,28 +378,33 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
return 0;
}
-static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
-{
- u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
- wi->baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
- wi->t0sz = vtcr & VTCR_EL2_T0SZ_MASK;
+static unsigned int vtcr_to_tg0_pgshift(u64 vtcr)
+{
+ u64 tg0 = FIELD_GET(VTCR_EL2_TG0_MASK, vtcr);
- switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
+ switch (tg0) {
case VTCR_EL2_TG0_4K:
- wi->pgshift = 12; break;
+ return 12;
case VTCR_EL2_TG0_16K:
- wi->pgshift = 14; break;
+ return 14;
case VTCR_EL2_TG0_64K:
- default: /* IMPDEF: treat any other value as 64k */
- wi->pgshift = 16; break;
+ default: /* IMPDEF: treat any other value as 64k */
+ return 16;
}
+}
+
+static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
+{
+ u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
+ wi->baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
+ wi->t0sz = vtcr & VTCR_EL2_T0SZ_MASK;
+ wi->pgshift = vtcr_to_tg0_pgshift(vtcr);
wi->sl = FIELD_GET(VTCR_EL2_SL0_MASK, vtcr);
/* Global limit for now, should eventually be per-VM */
wi->max_oa_bits = min(get_kvm_ipa_limit(),
ps_to_output_size(FIELD_GET(VTCR_EL2_PS_MASK, vtcr), false));
-
wi->ha = vtcr & VTCR_EL2_HA;
wi->be = vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_EE;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] KVM: arm64: nv: Use literal granule size in TLBI range calculation
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260414000334.3947257-1-weilin.chang@arm.com>
TLBI handling derives the invalidation range from guest VTCR_EL2.TG0 in
get_guest_mapping_ttl() and compute_tlb_inval_range(). Switch these to
use a helper that returns the decoded VTCR_EL2.TG0 granule size instead
of decoding it inline.
This keeps the granule size derivation in one place and prepares for
following changes that adjust the effective granule size.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/nested.c | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 40d52e9100d6..a732d7b0bd5d 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -394,6 +394,11 @@ static unsigned int vtcr_to_tg0_pgshift(u64 vtcr)
}
}
+static size_t vtcr_to_tg0_pgsize(u64 vtcr)
+{
+ return BIT(vtcr_to_tg0_pgshift(vtcr));
+}
+
static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
{
u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
@@ -516,20 +521,21 @@ static u8 pgshift_level_to_ttl(u16 shift, u8 level)
*/
static u8 get_guest_mapping_ttl(struct kvm_s2_mmu *mmu, u64 addr)
{
- u64 tmp, sz = 0, vtcr = mmu->tlb_vtcr;
+ u64 tmp, sz = 0;
kvm_pte_t pte;
u8 ttl, level;
+ size_t tg0_size = vtcr_to_tg0_pgsize(mmu->tlb_vtcr);
lockdep_assert_held_write(&kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
- switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
- case VTCR_EL2_TG0_4K:
+ switch (tg0_size) {
+ case SZ_4K:
ttl = (TLBI_TTL_TG_4K << 2);
break;
- case VTCR_EL2_TG0_16K:
+ case SZ_16K:
ttl = (TLBI_TTL_TG_16K << 2);
break;
- case VTCR_EL2_TG0_64K:
+ case SZ_64K:
default: /* IMPDEF: treat any other value as 64k */
ttl = (TLBI_TTL_TG_64K << 2);
break;
@@ -539,19 +545,19 @@ static u8 get_guest_mapping_ttl(struct kvm_s2_mmu *mmu, u64 addr)
again:
/* Iteratively compute the block sizes for a particular granule size */
- switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
- case VTCR_EL2_TG0_4K:
+ switch (tg0_size) {
+ case SZ_4K:
if (sz < SZ_4K) sz = SZ_4K;
else if (sz < SZ_2M) sz = SZ_2M;
else if (sz < SZ_1G) sz = SZ_1G;
else sz = 0;
break;
- case VTCR_EL2_TG0_16K:
+ case SZ_16K:
if (sz < SZ_16K) sz = SZ_16K;
else if (sz < SZ_32M) sz = SZ_32M;
else sz = 0;
break;
- case VTCR_EL2_TG0_64K:
+ case SZ_64K:
default: /* IMPDEF: treat any other value as 64k */
if (sz < SZ_64K) sz = SZ_64K;
else if (sz < SZ_512M) sz = SZ_512M;
@@ -602,14 +608,14 @@ unsigned long compute_tlb_inval_range(struct kvm_s2_mmu *mmu, u64 val)
if (!max_size) {
/* Compute the maximum extent of the invalidation */
- switch (FIELD_GET(VTCR_EL2_TG0_MASK, mmu->tlb_vtcr)) {
- case VTCR_EL2_TG0_4K:
+ switch (vtcr_to_tg0_pgsize(mmu->tlb_vtcr)) {
+ case SZ_4K:
max_size = SZ_1G;
break;
- case VTCR_EL2_TG0_16K:
+ case SZ_16K:
max_size = SZ_32M;
break;
- case VTCR_EL2_TG0_64K:
+ case SZ_64K:
default: /* IMPDEF: treat any other value as 64k */
/*
* No, we do not support 52bit IPA in nested yet. Once
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] KVM: arm64: nv: Rename vtcr_to_walk_info() to setup_s2_walk()
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260414000334.3947257-1-weilin.chang@arm.com>
This rename aligns the stage-2 walker better with the stage-1 walker.
Also set up other non-VTCR walk info in the function.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/nested.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 2c43097248b2..f20402d0d7e5 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -378,9 +378,12 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
return 0;
}
-static void vtcr_to_walk_info(u64 vtcr, struct s2_walk_info *wi)
+static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
{
- wi->t0sz = vtcr & TCR_EL2_T0SZ_MASK;
+ u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
+
+ wi->baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
+ wi->t0sz = vtcr & VTCR_EL2_T0SZ_MASK;
switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
case VTCR_EL2_TG0_4K:
@@ -398,12 +401,12 @@ static void vtcr_to_walk_info(u64 vtcr, struct s2_walk_info *wi)
ps_to_output_size(FIELD_GET(VTCR_EL2_PS_MASK, vtcr), false));
wi->ha = vtcr & VTCR_EL2_HA;
+ wi->be = vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_EE;
}
int kvm_walk_nested_s2(struct kvm_vcpu *vcpu, phys_addr_t gipa,
struct kvm_s2_trans *result)
{
- u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
struct s2_walk_info wi;
int ret;
@@ -412,11 +415,7 @@ int kvm_walk_nested_s2(struct kvm_vcpu *vcpu, phys_addr_t gipa,
if (!vcpu_has_nv(vcpu))
return 0;
- wi.baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
-
- vtcr_to_walk_info(vtcr, &wi);
-
- wi.be = vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_EE;
+ setup_s2_walk(vcpu, &wi);
ret = walk_nested_s2_pgd(vcpu, gipa, &wi, result);
if (ret)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] KVM: arm64: Handle unsupported guest translation granule sizes
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
Hi,
This is v2 of fixing the granule size selection for software stage-1
and stage-2 walks. Thanks to Marc for the feedback on v1 ([1]).
* Changes from v1:
- Take the entire (v)tcr value for TGx decode helpers.
- Rename vtcr_to_walk_info() to setup_s2_walk() as preparation, also
pass vcpu as the argument instead of kvm.
- Use TCR_* instead of TCR_EL1_* definitions.
- Return unsigned int instead of u64 when returning a granule shift.
- Split unit changes in get_guest_mapping_ttl() and
compute_tlb_inval_range() into its own patch.
Thanks!
[1]: https://lore.kernel.org/kvmarm/20260406164618.3312473-1-weilin.chang@arm.com/
Wei-Lin Chang (4):
KVM: arm64: nv: Rename vtcr_to_walk_info() to setup_s2_walk()
KVM: arm64: Factor out TG0/1 decoding of VTCR and TCR
KVM: arm64: nv: Use literal granule size in TLBI range calculation
KVM: arm64: Fallback to a supported value for unsupported guest TGx
arch/arm64/kvm/at.c | 125 ++++++++++++++++++++++++++--------
arch/arm64/kvm/nested.c | 144 +++++++++++++++++++++++++++-------------
2 files changed, 196 insertions(+), 73 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: airoha: Preliminary series to support multiple net_devices connected to the same GDM port
From: patchwork-bot+netdevbpf @ 2026-04-14 0:00 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev, xuegang.lu
In-Reply-To: <20260412-airoha-multi-serdes-preliminary-patch-v1-0-08d5b670ca8f@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 12 Apr 2026 19:13:11 +0200 you wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner.
> This series introduces some preliminary changes necessary to introduce
> support for multiple net_devices connected to the same Frame Engine (FE)
> GDM port (GDM3 or GDM4).
>
> [...]
Here is the summary with links:
- [net-next,1/3] net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signature
https://git.kernel.org/netdev/net-next/c/360d745a5319
- [net-next,2/3] net: airoha: Rely on net_device pointer in HTB callbacks
https://git.kernel.org/netdev/net-next/c/8baf4bf72ef9
- [net-next,3/3] net: airoha: Rely on net_device pointer in ETS callbacks
https://git.kernel.org/netdev/net-next/c/ae32f80018f0
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] iommu/mediatek-v1: add .of_xlate and defer arm_iommu_create_mapping()
From: Daniel Golle @ 2026-04-13 23:27 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Will Deacon, Robin Murphy,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Helgaas,
Rob Herring, Jason Gunthorpe, iommu, linux-mediatek, linux-kernel,
linux-arm-kernel
Since commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper
probe path") the iommu core populates the device's iommu_fwspec via
of_iommu_xlate() -> ops->of_xlate() before calling ops->probe_device().
mtk_iommu_v1 did not provide .of_xlate and instead parsed the "iommus"
property itself from probe_device(); with the new flow of_iommu_xlate()
returns -ENODEV, the fwspec is never populated, probe_device() is never
called, and the device_link from consumers (disp-ovl, disp-rdma, ...)
to their smi-larb supplier is never created. As a result the larb is
never runtime-resumed, its SMI clocks are gated by clk_disable_unused(),
and display and GPU DMA through the SMI bus fabric hang as soon as
unused clocks are disabled at late_initcall_sync.
Register mtk_iommu_v1_of_xlate() as .of_xlate and simplify
mtk_iommu_v1_probe_device() to just consume the already-populated
fwspec. arm_iommu_create_mapping() cannot run from the of_xlate path
because it eventually calls iommu_paging_domain_alloc() ->
dev_has_iommu(), which returns -ENODEV while the device is still in
the middle of its iommu setup and not yet attached to an iommu_group.
Move the mapping creation to probe_finalize(), which runs once the
iommu group has been set up for the device.
Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/iommu/mtk_iommu_v1.c | 58 +++++++++++++-----------------------
1 file changed, 20 insertions(+), 38 deletions(-)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index ac97dd2868d4b..e33e123fedc7b 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -413,12 +413,10 @@ static const struct iommu_ops mtk_iommu_v1_ops;
* MTK generation one iommu HW only support one iommu domain, and all the client
* sharing the same iova address space.
*/
-static int mtk_iommu_v1_create_mapping(struct device *dev,
- const struct of_phandle_args *args)
+static int mtk_iommu_v1_of_xlate(struct device *dev,
+ const struct of_phandle_args *args)
{
- struct mtk_iommu_v1_data *data;
struct platform_device *m4updev;
- struct dma_iommu_mapping *mtk_mapping;
int ret;
if (args->args_count != 1) {
@@ -442,47 +440,17 @@ static int mtk_iommu_v1_create_mapping(struct device *dev,
put_device(&m4updev->dev);
}
- ret = iommu_fwspec_add_ids(dev, args->args, 1);
- if (ret)
- return ret;
-
- data = dev_iommu_priv_get(dev);
- mtk_mapping = data->mapping;
- if (!mtk_mapping) {
- /* MTK iommu support 4GB iova address space. */
- mtk_mapping = arm_iommu_create_mapping(dev, 0, 1ULL << 32);
- if (IS_ERR(mtk_mapping))
- return PTR_ERR(mtk_mapping);
-
- data->mapping = mtk_mapping;
- }
-
- return 0;
+ return iommu_fwspec_add_ids(dev, args->args, 1);
}
static struct iommu_device *mtk_iommu_v1_probe_device(struct device *dev)
{
- struct iommu_fwspec *fwspec = NULL;
- struct of_phandle_args iommu_spec;
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct mtk_iommu_v1_data *data;
- int err, idx = 0, larbid, larbidx;
+ int idx, larbid, larbidx;
struct device_link *link;
struct device *larbdev;
- while (!of_parse_phandle_with_args(dev->of_node, "iommus",
- "#iommu-cells",
- idx, &iommu_spec)) {
-
- err = mtk_iommu_v1_create_mapping(dev, &iommu_spec);
- of_node_put(iommu_spec.np);
- if (err)
- return ERR_PTR(err);
-
- /* dev->iommu_fwspec might have changed */
- fwspec = dev_iommu_fwspec_get(dev);
- idx++;
- }
-
if (!fwspec)
return ERR_PTR(-ENODEV);
@@ -516,9 +484,22 @@ static struct iommu_device *mtk_iommu_v1_probe_device(struct device *dev)
static void mtk_iommu_v1_probe_finalize(struct device *dev)
{
- __maybe_unused struct mtk_iommu_v1_data *data = dev_iommu_priv_get(dev);
+ struct mtk_iommu_v1_data *data = dev_iommu_priv_get(dev);
+ struct dma_iommu_mapping *mtk_mapping;
int err;
+ mtk_mapping = data->mapping;
+ if (!mtk_mapping) {
+ /* MTK iommu supports 4GB iova address space. */
+ mtk_mapping = arm_iommu_create_mapping(dev, 0, 1ULL << 32);
+ if (IS_ERR(mtk_mapping)) {
+ dev_err(dev, "Failed to create IOMMU mapping: %ld\n",
+ PTR_ERR(mtk_mapping));
+ return;
+ }
+ data->mapping = mtk_mapping;
+ }
+
err = arm_iommu_attach_device(dev, data->mapping);
if (err)
dev_err(dev, "Can't create IOMMU mapping - DMA-OPS will not work\n");
@@ -585,6 +566,7 @@ static const struct iommu_ops mtk_iommu_v1_ops = {
.probe_finalize = mtk_iommu_v1_probe_finalize,
.release_device = mtk_iommu_v1_release_device,
.device_group = generic_device_group,
+ .of_xlate = mtk_iommu_v1_of_xlate,
.owner = THIS_MODULE,
.default_domain_ops = &(const struct iommu_domain_ops) {
.attach_dev = mtk_iommu_v1_attach_device,
--
2.53.0
^ permalink raw reply related
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