* Re: [PATCH rc v2 2/5] iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump
From: Nicolin Chen @ 2026-04-24 18:44 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, kevin.tian, joro, praan, baolu.lu,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <20260424165927.GD3444440@nvidia.com>
On Fri, Apr 24, 2026 at 01:59:27PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 15, 2026 at 02:17:37PM -0700, Nicolin Chen wrote:
> > +static bool arm_smmu_is_attach_deferred(struct device *dev)
> > +{
> > + struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > + struct arm_smmu_device *smmu = master->smmu;
> > + int i;
> > +
> > + if (!(smmu->options & ARM_SMMU_OPT_KDUMP))
> > + return false;
> > +
> > + for (i = 0; i < master->num_streams; i++) {
> > + u32 sid = master->streams[i].id;
> > + struct arm_smmu_ste *step;
> > +
> > + /* Guard against unpopulated L2 entries in the adopted table */
> > + if ((smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) &&
> > + !smmu->strtab_cfg.l2.l2ptrs[arm_smmu_strtab_l1_idx(sid)])
> > + continue;
>
> This can probably just call arm_smmu_init_sid_strtab()
>
> I think it is OK to allocate another level 2 here and it also has
> protections for SID out of range..
Actually, sashiko pointed out that this guard is a dead code.
arm_smmu_init_sid_strtab() is called in arm_smmu_insert_master().
Thanks
Nicolin
^ permalink raw reply
* [PATCH] EDAC/xilinx: Fix stack off-by-one in debugfs UE injection handlers
From: Shengzhuo Wei @ 2026-04-24 18:49 UTC (permalink / raw)
To: Shubhrajyoti Datta, Sai Krishna Potthuri, Borislav Petkov,
Tony Luck, Michal Simek
Cc: linux-edac, linux-kernel, linux-arm-kernel, Shengzhuo Wei
Two EDAC debugfs write handlers copy up to sizeof(buf) bytes into a
fixed-size stack buffer and then unconditionally NUL-terminate it via
buf[len] = '\0'. When userspace writes >= sizeof(buf) bytes, len
becomes sizeof(buf) and the NUL write lands 1 byte past the end of the
stack buffer.
Fix by clamping the copy length to sizeof(buf) - 1 so that the NUL
terminator is always in-bounds.
Fixes: 3bd2706c910f ("EDAC/zynqmp: Add EDAC support for Xilinx ZynqMP OCM")
Fixes: 83bf24051a60 ("EDAC/versal: Make the bit position of injected errors configurable")
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
---
drivers/edac/versal_edac.c | 2 +-
drivers/edac/zynqmp_edac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/versal_edac.c b/drivers/edac/versal_edac.c
index 5a43b5d43ca28027c829f53aea50588297484c5c..917d7d1762aa9ec9f752e8419c24fd265048ff28 100644
--- a/drivers/edac/versal_edac.c
+++ b/drivers/edac/versal_edac.c
@@ -856,7 +856,7 @@ static ssize_t inject_data_ue_store(struct file *file, const char __user *data,
u8 len, ue0, ue1;
int i, ret;
- len = min_t(size_t, count, sizeof(buf));
+ len = min_t(size_t, count, sizeof(buf) - 1);
if (copy_from_user(buf, data, len))
return -EFAULT;
diff --git a/drivers/edac/zynqmp_edac.c b/drivers/edac/zynqmp_edac.c
index cdffc9e4194d42d4d11c5218c9f341ac46301a94..048a7b9becd622a5eeebf9c893ffdf9e163f5e9b 100644
--- a/drivers/edac/zynqmp_edac.c
+++ b/drivers/edac/zynqmp_edac.c
@@ -304,7 +304,7 @@ static ssize_t inject_ue_write(struct file *file, const char __user *data,
if (!data)
return -EFAULT;
- len = min_t(size_t, count, sizeof(buf));
+ len = min_t(size_t, count, sizeof(buf) - 1);
if (copy_from_user(buf, data, len))
return -EFAULT;
---
base-commit: dd6c438c3e64a5ff0b5d7e78f7f9be547803ef1b
change-id: 20260425-edac-stack-off-by-one-f6703cfe8213
Best regards,
--
Shengzhuo Wei <me@cherr.cc>
^ permalink raw reply related
* Re: [PATCH RFC 1/2] arm64: vdso: Prepare for robust futex unlock support
From: André Almeida @ 2026-04-24 18:53 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, linux-arm-kernel, linux-kernel,
linux-arch, kernel-dev
In-Reply-To: <1a06fee7-65ff-4828-85f1-e3ee1e82610f@t-8ch.de>
Em 22/04/2026 10:17, Thomas Weißschuh escreveu:
> On 2026-04-22 15:02:45+0200, Thomas Weißschuh wrote:
>> On 2026-04-17 11:56:10-0300, André Almeida wrote:
>>> There will be a VDSO function to unlock non-contended robust futexes in
>>> user space. The unlock sequence is racy vs. clearing the list_pending_op
>>> pointer in the task's robust list head. To plug this race the kernel needs
>>> to know the critical section window so it can clear the pointer when the
>>> task is interrupted within that race window. The window is determined by
>>> labels in the inline assembly.
>>>
>>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>>> ---
>>> RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
>>>
>>> ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
>>> arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
>>> ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
>>> arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
>>
>> arch/arm64/kernel/vdso.o is a kernel object.
>> __futex_list64_try_unlock_cs_success is a vDSO symbol.
>> They live in wholly different objects, which are never linked together.
>> Look at VDSO_SYMBOL() to get the offset of the vDSO symbol in kernel code.
>>
>> (...)
>
> The diff below shows the idea. Compat code is not fixed, and I didn't
> even try to run it. Also please use CONFIG_COMPAT_VDSO over plain
> CONFIG_COMPAT.
>
VDSO_SYMBOL() did the tricky, I fixed this for the v2, thanks Thomas!
André
^ permalink raw reply
* [PATCH RFC v2 0/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()
From: André Almeida @ 2026-04-24 18:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, Thomas Weißschuh
Cc: linux-arm-kernel, linux-kernel, linux-arch, kernel-dev, LKML,
André Almeida
Hi folks,
This is my take on implementing the new vDSO for unlocking a robust futex in
arm64. If you don't know what's that, Thomas wrote a good summary,
including the motivation for this work and the x86 implementation:
https://lore.kernel.org/lkml/878qb89g7b.ffs@tglx/
There are some loose ends in my patchset so I'm sending as a RFC to ask
some questions:
- If the process is interrupted between the labels, we need to check the
conditional flags and clear the op_pending address from the register. Using
objdump I see that op_pending addr is being stored at x2, but I suspect that
this isn't stable, so I need to figure out how to make sure that the address
will always be stored in the same register.
- So far I have implemented only the LL/SC version to make review easier, but I
can do the LSE version as well.
This patchset works fine with the tests proposed at
https://lore.kernel.org/lkml/20260330120118.012924430@kernel.org/
Changes from v1:
- s/CONFIG_COMPAT/CONFIG_COMPAT_VDSO (Thomas Weißschuh)
- Fixed linker not finding the symbols (Thomas Weißschuh)
v1: https://patch.msgid.link/20260417-tonyk-robust_arm-v1-0-03aa64e2ff1a@igalia.com
---
André Almeida (2):
arm64: vdso: Prepare for robust futex unlock support
arm64: vdso: Implement __vdso_futex_robust_try_unlock()
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/futex_robust.h | 35 +++++++++++++
arch/arm64/kernel/vdso.c | 30 +++++++++++
arch/arm64/kernel/vdso/Makefile | 9 +++-
arch/arm64/kernel/vdso/vdso.lds.S | 11 ++++
.../kernel/vdso/vfutex_robust_list_try_unlock.c | 59 ++++++++++++++++++++++
6 files changed, 144 insertions(+), 1 deletion(-)
---
base-commit: 0e8896e9899b607bb168c1cce340596b8c2e3e2b
change-id: 20260416-tonyk-robust_arm-54ff77d2c4e4
Best regards,
--
André Almeida <andrealmeid@igalia.com>
^ permalink raw reply
* [PATCH RFC v2 1/2] arm64: vdso: Prepare for robust futex unlock support
From: André Almeida @ 2026-04-24 18:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, Thomas Weißschuh
Cc: linux-arm-kernel, linux-kernel, linux-arch, kernel-dev, LKML,
André Almeida
In-Reply-To: <20260424-tonyk-robust_arm-v2-0-db4e46f752cf@igalia.com>
There will be a VDSO function to unlock non-contended robust futexes in
user space. The unlock sequence is racy vs. clearing the list_pending_op
pointer in the task's robust list head. To plug this race the kernel needs
to know the critical section window so it can clear the pointer when the
task is interrupted within that race window. The window is determined by
labels in the inline assembly.
Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
Changes from v1:
- Fixed linker not finding VDSO symbols
---
arch/arm64/kernel/vdso.c | 30 ++++++++++++++++++++++++++++++
arch/arm64/kernel/vdso/vdso.lds.S | 7 +++++++
2 files changed, 37 insertions(+)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 592dd8668de4..f9c520a1c942 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -11,6 +11,7 @@
#include <linux/clocksource.h>
#include <linux/elf.h>
#include <linux/err.h>
+#include <linux/futex.h>
#include <linux/errno.h>
#include <linux/gfp.h>
#include <linux/kernel.h>
@@ -57,6 +58,33 @@ static struct vdso_abi_info vdso_info[] __ro_after_init = {
#endif /* CONFIG_COMPAT_VDSO */
};
+#ifdef CONFIG_FUTEX_ROBUST_UNLOCK
+static void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm)
+{
+ unsigned long vdso = (unsigned long) mm->context.vdso;
+ struct futex_mm_data *fd = &mm->futex;
+ uintptr_t success, end;
+
+ if (abi == VDSO_ABI_AA64) {
+ success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_success);
+ end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_end);
+
+ futex_set_vdso_cs_range(fd, 0, vdso, success, end, false);
+ }
+
+#ifdef CONFIG_COMPAT_VDSO
+ if (abi == VDSO_ABI_AA32) {
+ success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_success);
+ end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_end);
+
+ futex_set_vdso_cs_range(fd, 1, vdso, success, end, true);
+ }
+#endif
+}
+#else
+static inline void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm) { }
+#endif /* CONFIG_FUTEX_ROBUST_UNLOCK */
+
static int vdso_mremap(const struct vm_special_mapping *sm,
struct vm_area_struct *new_vma)
{
@@ -134,6 +162,8 @@ static int __setup_additional_pages(enum vdso_abi abi,
if (IS_ERR(ret))
goto up_fail;
+ vdso_futex_robust_unlock_update_ips(abi, mm);
+
return 0;
up_fail:
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index 52314be29191..c532dae6ac8e 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -112,3 +112,10 @@ VERSION
* Make the sigreturn code visible to the kernel.
*/
VDSO_sigtramp = __kernel_rt_sigreturn;
+
+VDSO_futex_list64_try_unlock_cs_success = __futex_list64_try_unlock_cs_success;
+VDSO_futex_list64_try_unlock_cs_end = __futex_list64_try_unlock_cs_end;
+#ifdef CONFIG_COMPAT_VDSO
+VDSO_futex_list32_try_unlock_cs_success = __futex_list32_try_unlock_cs_success;
+VDSO_futex_list32_try_unlock_cs_end = __futex_list32_try_unlock_cs_end;
+#endif
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v2 2/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()
From: André Almeida @ 2026-04-24 18:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, Thomas Weißschuh
Cc: linux-arm-kernel, linux-kernel, linux-arch, kernel-dev, LKML,
André Almeida
In-Reply-To: <20260424-tonyk-robust_arm-v2-0-db4e46f752cf@igalia.com>
Based on the x86 implementation, implement the vDSO function for unlocking
a robust futex correctly.
Commit xxxxxxxxxxxx ("x86/vdso: Implement __vdso_futex_robust_try_unlock()") has
the full explanation about why this mechanism is needed.
The unlock assembly sequence for arm64 is:
__futex_list64_try_unlock_cs_start:
ldxr x3, [x0] // Load the value at *futex
cmp x1, x3 // Compare with TID
b.ne __futex_list64_try_unlock_cs_end
stlxr w1, xzr, [x0] // Try to clear *futex
cbnz w1, __futex_list64_try_unlock_cs_start
__futex_list64_try_unlock_cs_success:
str xzr, [x2] // After clearing *futex, clear *op_pending
__futex_list64_try_unlock_cs_end:
The decision regarding if the pointer should be cleared or not lies on checking
the condition flag zero:
return (regs->user_regs.pstate & PSR_Z_BIT) ?
(void __user *) regs->user_regs.regs[2] : NULL;
If it's not zero, that means that the comparassion worked and the kernel should
clear op_pending (if userspace didn't managed to) stored at x2.
Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
RFC:
- Should I duplicate the explanation found in the x86 commit or can I just
point to it?
- Only LL/SC for now but I can add LSE later if this looks good
- It the objdump I see that op_pending is store at x2. But how stable is this,
how can I write it in a way that's always x2?
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/futex_robust.h | 35 +++++++++++++
arch/arm64/kernel/vdso/Makefile | 9 +++-
arch/arm64/kernel/vdso/vdso.lds.S | 4 ++
.../kernel/vdso/vfutex_robust_list_try_unlock.c | 59 ++++++++++++++++++++++
5 files changed, 107 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 427151a9db7f..e10cb97a51c7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -249,6 +249,7 @@ config ARM64
select HAVE_RELIABLE_STACKTRACE
select HAVE_POSIX_CPU_TIMERS_TASK_WORK
select HAVE_FUNCTION_ARG_ACCESS_API
+ select HAVE_FUTEX_ROBUST_UNLOCK
select MMU_GATHER_RCU_TABLE_FREE
select HAVE_RSEQ
select HAVE_RUST if RUSTC_SUPPORTS_ARM64
diff --git a/arch/arm64/include/asm/futex_robust.h b/arch/arm64/include/asm/futex_robust.h
new file mode 100644
index 000000000000..f2b7a2b15cb5
--- /dev/null
+++ b/arch/arm64/include/asm/futex_robust.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM64_FUTEX_ROBUST_H
+#define _ASM_ARM64_FUTEX_ROBUST_H
+
+#include <asm/ptrace.h>
+
+static __always_inline void __user *arm64_futex_robust_unlock_get_pop(struct pt_regs *regs)
+{
+ /*
+ * RFC: According to the objdump bellow, x2 is the address of
+ * op_pending. How stable is this?
+
+ <__futex_list64_try_unlock_cs_start>:
+ ldxr x3, [x0]
+ cmp x1, x3
+ b.ne d7c <__futex_list64_try_unlock_cs_end> // b.any
+ stlxr w1, xzr, [x0]
+ cbnz w1, d64 <__futex_list64_try_unlock_cs_start>
+
+ <__futex_list64_try_unlock_cs_success>:
+ str xzr, [x2]
+
+ <__futex_list64_try_unlock_cs_end>:
+ mov w0, w3
+ ret
+ */
+
+ return (regs->user_regs.pstate & PSR_Z_BIT) ? NULL
+ : (void __user *) regs->user_regs.regs[2];
+}
+
+#define arch_futex_robust_unlock_get_pop(regs) \
+ arm64_futex_robust_unlock_get_pop(regs)
+
+#endif /* _ASM_ARM64_FUTEX_ROBUST_H */
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 7dec05dd33b7..a65893d8100e 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -9,7 +9,8 @@
# Include the generic Makefile to check the built vdso.
include $(srctree)/lib/vdso/Makefile.include
-obj-vdso := vgettimeofday.o note.o sigreturn.o vgetrandom.o vgetrandom-chacha.o
+obj-vdso := vgettimeofday.o note.o sigreturn.o vgetrandom.o vgetrandom-chacha.o \
+ vfutex_robust_list_try_unlock.o
# Build rules
targets := $(obj-vdso) vdso.so vdso.so.dbg
@@ -45,9 +46,11 @@ CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_REMOVE_VDSO)
CFLAGS_REMOVE_vgetrandom.o = $(CC_FLAGS_REMOVE_VDSO)
+CFLAGS_REMOVE_vfutex_robust_list_try_unlock.o = $(CC_FLAGS_REMOVE_VDSO)
CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
+CFLAGS_vfutex_robust_list_try_unlock.o = $(CC_FLAGS_ADD_VDSO)
ifneq ($(c-gettimeofday-y),)
CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
@@ -57,6 +60,10 @@ ifneq ($(c-getrandom-y),)
CFLAGS_vgetrandom.o += -include $(c-getrandom-y)
endif
+ifneq ($(c-vfutex_robust_list_try_unlock-y),)
+ CFLAGS_vfutex_robust_list_try_unlock.o += -include $(c-vfutex_robust_list_try_unlock-y)
+endif
+
targets += vdso.lds
CPPFLAGS_vdso.lds += -P -C -U$(ARCH)
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index c532dae6ac8e..c324764cb6f9 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -104,6 +104,10 @@ VERSION
__kernel_clock_gettime;
__kernel_clock_getres;
__kernel_getrandom;
+ __vdso_futex_robust_list64_try_unlock;
+#ifdef CONFIG_COMPAT_VDSO
+ __vdso_futex_robust_list32_try_unlock;
+#endif
local: *;
};
}
diff --git a/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
new file mode 100644
index 000000000000..e8a8fb22a2fa
--- /dev/null
+++ b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+#include <vdso/futex.h>
+#include <linux/stringify.h>
+
+#define LABEL(name, sz) __stringify(__futex_list##sz##_try_unlock_cs_##name)
+
+#define GLOBLS(sz) ".globl " LABEL(start, sz) ", " LABEL(success, sz) ", " LABEL(end, sz) "\n"
+
+__u32 __vdso_futex_robust_list64_try_unlock(__u32 *lock, __u32 tid, __u64 *pop)
+{
+ __u32 val, result;
+
+ asm volatile (
+ GLOBLS(64)
+ " prfm pstl1strm, %[lock] \n"
+ LABEL(start, 64)": \n"
+ " ldxr %[val], %[lock] \n"
+ " cmp %[tid], %[val] \n"
+ " bne " LABEL(end, 64)" \n"
+ " stlxr %w[result], xzr, %[lock] \n"
+ " cbnz %w[result], " LABEL(start, 64)" \n"
+ LABEL(success, 64)": \n"
+ " str xzr, %[pop] \n"
+ LABEL(end, 64)": \n"
+
+ : [val] "=&r" (val), [result] "=r" (result)
+ : [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
+ : "memory"
+ );
+
+ return val;
+}
+
+#ifdef CONFIG_COMPAT_VDSO
+__u32 __vdso_futex_robust_list32_try_unlock(__u32 *lock, __u32 tid, __u32 *pop)
+{
+ __u32 val, result;
+
+ asm volatile (
+ GLOBLS(32)
+ " prfm pstl1strm, %[lock] \n"
+ LABEL(start, 32)": \n"
+ " ldxr %w[val], %[lock] \n"
+ " cmp %w[tid], %w[val] \n"
+ " bne " LABEL(end, 32)" \n"
+ " stlxr %w[result], wzr, %w[lock] \n"
+ " cbnz %w[result], " LABEL(start, 32)" \n"
+ LABEL(success, 32)": \n"
+ " str wzr, %w[pop] \n"
+ LABEL(end, 32)": \n"
+
+ : [val] "=&r" (val), [result] "=r" (result)
+ : [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
+ : "memory"
+ );
+
+ return val;
+}
+#endif
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 05/11] iommu: Change group->devices to RCU-protected list
From: Nicolin Chen @ 2026-04-24 19:12 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Baolu Lu, Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <20260424131148.GB3444440@nvidia.com>
On Fri, Apr 24, 2026 at 10:11:48AM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 23, 2026 at 08:08:59PM -0700, Nicolin Chen wrote:
> > On Fri, Apr 24, 2026 at 10:53:49AM +0800, Baolu Lu wrote:
> > > On 4/17/26 07:28, Nicolin Chen wrote:
> > > mutex_unlock(&group->mutex);
> > > /*
> > > * FIXME: Mis-locked because the ops->probe_finalize() call-back
> > > * of some IOMMU drivers calls arm_iommu_attach_device() which
> > > * in-turn might call back into IOMMU core code, where it tries
> > > * to take group->mutex, resulting in a deadlock.
> > > */
> > > for_each_group_device(group, gdev)
> > > iommu_group_do_probe_finalize(gdev->dev);
> > > }
> > >
> > > return 0;
> > > }
> > >
> > > Will the change above trigger a lockdep splat due to this "mis-locked"
> > > case?"
> >
> > Oh, I missed this one. That's a good finding!
> >
> > Perhaps we can just change it to list_for_each_entry_rcu holding
> > rcu_read_lock() and drop the FIXME.
>
> You can't hold rcu across that function IIRC
Oh right. I didn't think too carefully...
I tend to keep it as-is. So, maybe just list_for_each_entry?
Nicolin
^ permalink raw reply
* [PATCH v4 0/3] ARM: dts: aspeed-g6: add AST2600 I3C nodes and bindings
From: Dawid Glazik @ 2026-04-24 20:20 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed
Cc: devicetree, linux-arm-kernel, linux-kernel, dawid.glazik,
maciej.lawniczak
This series reworks and resubmits AST2600 I3C DTS updates that were
originally posted in 2024, but stalled without further upstream
progress.[1] The series was rebased onto the current tree and merge
conflicts were resolved.
The patches first move I2C controller nodes under the APB simple-bus
for layout consistency, then document aspeed,ast2600-i3c-global in
the syscon binding, and finally add AST2600 I3C controller nodes in
aspeed-g6.dtsi.
Jeremy agreed in a separate email thread that I can continue this
series under my authorship.
Link: https://lore.kernel.org/all/9d8c03d742fa9767f30e23d75ddf0baf4296c88e.1714647917.git.jk@codeconstruct.com.au/
Dawid Glazik (3):
ARM: dts: aspeed-g6: move i2c controllers directly into apb node
dt-bindings: mfd: syscon: add aspeed,ast2600-i3c-global compatible
ARM: dts: aspeed-g6: Add nodes for i3c controllers
.../devicetree/bindings/mfd/syscon.yaml | 2 +
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 543 ++++++++++--------
2 files changed, 318 insertions(+), 227 deletions(-)
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
--
2.43.0
^ permalink raw reply
* [PATCH v4 1/3] ARM: dts: aspeed-g6: move i2c controllers directly into apb node
From: Dawid Glazik @ 2026-04-24 20:20 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed
Cc: devicetree, linux-arm-kernel, linux-kernel, dawid.glazik,
maciej.lawniczak, Jeremy Kerr
In-Reply-To: <cover.1777058942.git.dawid.glazik@linux.intel.com>
We currently have the apb's mapping of the i2c controller space as a
labelled mostly-empty node:
apb {
i2c: bus@1e78a000 {
ranges = <...>;
};
}
... and then define the contents of the i2c block later:
i2c: {
i2c0: i2c-bus@80 {
reg = <0x80 0x80>;
};
i2c1: i2c-bus@100 {
reg = <0x100 0x80>;
};
}
Krzysztof mentions[1] that isn't convention though, with the top-level
simple-bus being empty and linked via the label. So, drop the label
usage and move the i2c bus definition into the simple-bus node directly
under the apb:
apb {
bus@1e78a000 {
ranges = <...>;
i2c0: i2c-bus@80 {
reg = <0x80 0x80>;
};
i2c1: i2c-bus@100 {
reg = <0x100 0x80>;
};
};
}
This will allow us to be consistent when we add new definitions for the
i3c nodes, which would require the latter format.
Link: https://lore.kernel.org/linux-devicetree/c5331cf8-7295-4e6a-ba39-e0751a2c357e@kernel.org/ [1]
Suggested-by: Jeremy Kerr <jk@codeconstruct.com.au>
Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
---
v3:
- pick up series after two years
- rebase on top of latest tree and solve conflicts
- as agreed with Jeremy off-list, he said I can take authorship of this going forward
v2:
- new patch: reorganise i2c nodes before adding new-format i3c nodes
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 452 ++++++++++++------------
1 file changed, 225 insertions(+), 227 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 189bc3bbb47c..f5641128614f 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -835,11 +835,235 @@ uart9: serial@1e790300 {
status = "disabled";
};
- i2c: bus@1e78a000 {
+ bus@1e78a000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1e78a000 0x1000>;
+
+ i2c0: i2c@80 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x80 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1_default>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x100 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2_default>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@180 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x180 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3_default>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@200 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x200 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4_default>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@280 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x280 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c5_default>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@300 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x300 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c6_default>;
+ status = "disabled";
+ };
+
+ i2c6: i2c@380 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x380 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c7_default>;
+ status = "disabled";
+ };
+
+ i2c7: i2c@400 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x400 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c8_default>;
+ status = "disabled";
+ };
+
+ i2c8: i2c@480 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x480 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c9_default>;
+ status = "disabled";
+ };
+
+ i2c9: i2c@500 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x500 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c10_default>;
+ status = "disabled";
+ };
+
+ i2c10: i2c@580 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x580 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c11_default>;
+ status = "disabled";
+ };
+
+ i2c11: i2c@600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x600 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c12_default>;
+ status = "disabled";
+ };
+
+ i2c12: i2c@680 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x680 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c13_default>;
+ status = "disabled";
+ };
+
+ i2c13: i2c@700 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x700 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c14_default>;
+ status = "disabled";
+ };
+
+ i2c14: i2c@780 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x780 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c15_default>;
+ status = "disabled";
+ };
+
+ i2c15: i2c@800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x800 0x80>;
+ compatible = "aspeed,ast2600-i2c-bus";
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ resets = <&syscon ASPEED_RESET_I2C>;
+ interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+ bus-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c16_default>;
+ status = "disabled";
+ };
};
fsim0: fsi@1e79b000 {
@@ -870,229 +1094,3 @@ fsim1: fsi@1e79b100 {
};
#include "aspeed-g6-pinctrl.dtsi"
-
-&i2c {
- i2c0: i2c@80 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x80 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c1_default>;
- status = "disabled";
- };
-
- i2c1: i2c@100 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x100 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c2_default>;
- status = "disabled";
- };
-
- i2c2: i2c@180 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x180 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c3_default>;
- status = "disabled";
- };
-
- i2c3: i2c@200 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x200 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c4_default>;
- status = "disabled";
- };
-
- i2c4: i2c@280 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x280 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c5_default>;
- status = "disabled";
- };
-
- i2c5: i2c@300 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x300 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c6_default>;
- status = "disabled";
- };
-
- i2c6: i2c@380 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x380 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c7_default>;
- status = "disabled";
- };
-
- i2c7: i2c@400 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x400 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c8_default>;
- status = "disabled";
- };
-
- i2c8: i2c@480 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x480 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c9_default>;
- status = "disabled";
- };
-
- i2c9: i2c@500 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x500 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c10_default>;
- status = "disabled";
- };
-
- i2c10: i2c@580 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x580 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c11_default>;
- status = "disabled";
- };
-
- i2c11: i2c@600 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x600 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c12_default>;
- status = "disabled";
- };
-
- i2c12: i2c@680 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x680 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c13_default>;
- status = "disabled";
- };
-
- i2c13: i2c@700 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x700 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c14_default>;
- status = "disabled";
- };
-
- i2c14: i2c@780 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x780 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c15_default>;
- status = "disabled";
- };
-
- i2c15: i2c@800 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x800 0x80>;
- compatible = "aspeed,ast2600-i2c-bus";
- clocks = <&syscon ASPEED_CLK_APB2>;
- resets = <&syscon ASPEED_RESET_I2C>;
- interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
- bus-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c16_default>;
- status = "disabled";
- };
-};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/3] dt-bindings: mfd: syscon: add aspeed,ast2600-i3c-global compatible
From: Dawid Glazik @ 2026-04-24 20:21 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed
Cc: devicetree, linux-arm-kernel, linux-kernel, dawid.glazik,
maciej.lawniczak
In-Reply-To: <cover.1777058942.git.dawid.glazik@linux.intel.com>
Add aspeed,ast2600-i3c-global to the syscon binding compatible
lists to document the AST2600 I3C global register syscon node.
Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
---
Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index e57add2bacd3..50c07038122f 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -49,6 +49,7 @@ select:
- apm,xgene-mcb
- apm,xgene-rb
- apm,xgene-scu
+ - aspeed,ast2600-i3c-global
- atmel,sama5d2-sfrbu
- atmel,sama5d3-nfc-io
- atmel,sama5d3-sfrbu
@@ -161,6 +162,7 @@ properties:
- apm,xgene-mcb
- apm,xgene-rb
- apm,xgene-scu
+ - aspeed,ast2600-i3c-global
- atmel,sama5d2-sfrbu
- atmel,sama5d3-nfc-io
- atmel,sama5d3-sfrbu
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/3] ARM: dts: aspeed-g6: Add nodes for i3c controllers
From: Dawid Glazik @ 2026-04-24 20:21 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed
Cc: devicetree, linux-arm-kernel, linux-kernel, dawid.glazik,
maciej.lawniczak, Jeremy Kerr
In-Reply-To: <cover.1777058942.git.dawid.glazik@linux.intel.com>
Add the i3c controller devices to the ast2600 g6 common dts. We add all
6 busses to the common g6 definition, but leave disabled through the
status property, to be enabled per-platform.
Suggested-by: Jeremy Kerr <jk@codeconstruct.com.au>
Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
---
v4:
- removed i3c aliases
- renamed i3c-global node name to generic: syscon
v3:
- add i3c aliases
- rebase on top of latest tree and solve conflicts
- as agreed with Jeremy off-list, he said I can take authorship of this going forward
v2:
- use inline bus representation, without the i3c: label
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 91 +++++++++++++++++++++++++
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index f5641128614f..51a6a4157f1b 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -1066,6 +1066,97 @@ i2c15: i2c@800 {
};
};
+ bus@1e7a0000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1e7a0000 0x8000>;
+
+ i3c_global: syscon@0 {
+ compatible = "aspeed,ast2600-i3c-global", "syscon";
+ reg = <0x0 0x1000>;
+ resets = <&syscon ASPEED_RESET_I3C_DMA>;
+ };
+
+ i3c0: i3c@2000 {
+ compatible = "aspeed,ast2600-i3c";
+ reg = <0x2000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ clocks = <&syscon ASPEED_CLK_GATE_I3C0CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c1_default>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+ aspeed,global-regs = <&i3c_global 0>;
+ status = "disabled";
+ };
+
+ i3c1: i3c@3000 {
+ compatible = "aspeed,ast2600-i3c";
+ reg = <0x3000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ clocks = <&syscon ASPEED_CLK_GATE_I3C1CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c2_default>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ aspeed,global-regs = <&i3c_global 1>;
+ status = "disabled";
+ };
+
+ i3c2: i3c@4000 {
+ compatible = "aspeed,ast2600-i3c";
+ reg = <0x4000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ clocks = <&syscon ASPEED_CLK_GATE_I3C2CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c3_default>;
+ interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+ aspeed,global-regs = <&i3c_global 2>;
+ status = "disabled";
+ };
+
+ i3c3: i3c@5000 {
+ compatible = "aspeed,ast2600-i3c";
+ reg = <0x5000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ clocks = <&syscon ASPEED_CLK_GATE_I3C3CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c4_default>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ aspeed,global-regs = <&i3c_global 3>;
+ status = "disabled";
+ };
+
+ i3c4: i3c@6000 {
+ compatible = "aspeed,ast2600-i3c";
+ reg = <0x6000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ clocks = <&syscon ASPEED_CLK_GATE_I3C4CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c5_default>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ aspeed,global-regs = <&i3c_global 4>;
+ status = "disabled";
+ };
+
+ i3c5: i3c@7000 {
+ compatible = "aspeed,ast2600-i3c";
+ reg = <0x7000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ clocks = <&syscon ASPEED_CLK_GATE_I3C5CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c6_default>;
+ interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+ aspeed,global-regs = <&i3c_global 5>;
+ status = "disabled";
+ };
+ };
+
fsim0: fsi@1e79b000 {
#interrupt-cells = <1>;
compatible = "aspeed,ast2600-fsi-master";
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 1/4] kernel: param: initialize module_kset on-demand
From: Gary Guo @ 2026-04-24 19:26 UTC (permalink / raw)
To: Shashank Balaji, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Richard Cochran, Jonathan Corbet, Shuah Khan
Cc: Rahul Bukte, linux-kernel, coresight, linux-arm-kernel,
driver-core, rust-for-linux, linux-doc, Daniel Palmer, Tim Bird
In-Reply-To: <20260422-acpi_mod_name-v3-1-a184eff9ff6f@sony.com>
On Wed Apr 22, 2026 at 10:49 AM BST, Shashank Balaji wrote:
> module_kset is initialized in param_sysfs_init(), a subsys_initcall. A number
> of platform drivers register themselves prior to subsys_initcalls. With an
> upcoming patch ("driver core: platform: set mod_name in driver registration")
> that sets their mod_name in struct device_driver, lookup_or_create_module()
> will be called for those drivers, which calls kset_find_object(module_kset, mod_name).
> This fails because module_kset isn't alive yet.
>
> Fix this by initializing module_kset on-demand in lookup_or_create_module().
> Retain the param_sysfs_init() subsys_initcall to ensure that module_kset is
> live after subsys_initcalls (assuming no OOM) for any users who may need it,
> on the off chance that it wasn't init'd on-demand because of no
> pre-subsys_initcall drivers.
>
> This on-demand path can trigger before subsys_initcall. kset_create_and_add()
> be should safe in those contexts because the allocator is up and running by then,
> no userspace to start uevent helper or listen to a uevent socket.
>
> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
>
> ---
>
> Patch 3 depends on this patch.
> ---
> kernel/params.c | 41 +++++++++++++++++++++++++----------------
> 1 file changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index 74d620bc2521..f25d6fda159c 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -745,6 +745,26 @@ void module_param_sysfs_remove(struct module *mod)
> }
> #endif
>
> +static int uevent_filter(const struct kobject *kobj)
> +{
> + const struct kobj_type *ktype = get_ktype(kobj);
> +
> + if (ktype == &module_ktype)
> + return 1;
> + return 0;
> +}
> +
> +static const struct kset_uevent_ops module_uevent_ops = {
> + .filter = uevent_filter,
> +};
> +
> +static struct kset *__init_or_module ensure_module_kset(void)
> +{
> + if (!module_kset)
> + module_kset = kset_create_and_add("module", &module_uevent_ops, NULL);
> + return module_kset;
> +}
> +
> struct module_kobject * __init_or_module
> lookup_or_create_module_kobject(const char *name)
> {
> @@ -752,6 +772,9 @@ lookup_or_create_module_kobject(const char *name)
> struct kobject *kobj;
> int err;
>
> + if (!ensure_module_kset())
> + return NULL;
> +
> kobj = kset_find_obj(module_kset, name);
> if (kobj)
> return to_module_kobject(kobj);
> @@ -911,19 +934,6 @@ static const struct sysfs_ops module_sysfs_ops = {
> .store = module_attr_store,
> };
>
> -static int uevent_filter(const struct kobject *kobj)
> -{
> - const struct kobj_type *ktype = get_ktype(kobj);
> -
> - if (ktype == &module_ktype)
> - return 1;
> - return 0;
> -}
> -
> -static const struct kset_uevent_ops module_uevent_ops = {
> - .filter = uevent_filter,
> -};
> -
> struct kset *module_kset;
>
> static void module_kobj_release(struct kobject *kobj)
> @@ -940,7 +950,7 @@ const struct kobj_type module_ktype = {
> };
>
> /*
> - * param_sysfs_init - create "module" kset
> + * param_sysfs_init - create module_kset if not already done
> *
> * This must be done before the initramfs is unpacked and
> * request_module() thus becomes possible, because otherwise the
> @@ -948,8 +958,7 @@ const struct kobj_type module_ktype = {
> */
> static int __init param_sysfs_init(void)
> {
> - module_kset = kset_create_and_add("module", &module_uevent_ops, NULL);
> - if (!module_kset) {
> + if (!ensure_module_kset()) {
> printk(KERN_WARNING "%s (%d): error creating kset\n",
> __FILE__, __LINE__);
> return -ENOMEM;
I don't think lazily creation of module_kset is the correct approach.
The only thing that param_sysfs_init does is create a kset_create_and_add, which
can be done really early. Driver core creates a couple of them during
initialization too.
This is ultimately just an init order problem, and you need things to be
initialized earlier. Given lack of dependency of anything else, this could just
be a pure_initcall which will be initialized before everything else.
Best,
Gary
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-24 19:44 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Mathias Stearn, Dmitry Vyukov, Jinjie Ruan, linux-man,
Mark Rutland, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Blake Oler
In-Reply-To: <20260424150318.GE641209@noisy.programming.kicks-ass.net>
On Fri, Apr 24 2026 at 17:03, Peter Zijlstra wrote:
> On Fri, Apr 24, 2026 at 04:16:08PM +0200, Thomas Gleixner wrote:
>> > I was really hoping that we would only need to do the "redundant"
>> > cpu_id_start writes would only be needed on membarrier_rseq IPIs where
>> > it really is a pay-for-what-you-use functionality,
>>
>> That's fine and can be solved without adding this sequence overhead into
>> the scheduler hotpath.
>
> Something like so? (probably needs help for !GENERIC bits)
Yes and yes :)
Let me stare at that !generic tif bits case.
^ permalink raw reply
* Re: [PATCH 1/1] KVM: arm64: nv: Avoid full shadow s2 unmap
From: Wei-Lin Chang @ 2026-04-24 19:45 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, kvmarm, linux-kernel, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <867bq72n7l.wl-maz@kernel.org>
On Thu, Apr 16, 2026 at 11:50:38AM +0100, Marc Zyngier wrote:
> On Thu, 16 Apr 2026 00:05:40 +0100,
> Wei-Lin Chang <weilin.chang@arm.com> wrote:
> >
> > On Wed, Apr 15, 2026 at 09:38:55AM +0100, Marc Zyngier wrote:
>
> [...]
>
> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > index 851f6171751c..a97bd461c1e1 100644
> > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > @@ -217,6 +217,10 @@ struct kvm_s2_mmu {
> > > > */
> > > > bool nested_stage2_enabled;
> > > >
> > > > + /* canonical IPA to nested IPA range lookup */
> > > > + struct maple_tree nested_revmap_mt;
> > > > + bool nested_revmap_broken;
> > > > +
> > >
> > > Consider moving this boolean next to the other ones so that you don't
> > > create too many holes in the kvm_s2_mmu structure (use pahole to find out).
> > >
> > > But I have some misgivings about the way things are structured
> > > here. Only NV needs a revmap, yet this is present irrelevant of the
> > > nature of the VM and bloats the data structure a bit.
> > >
> > > My naive approach would have been to only keep a pointer to the
> > > revmap, and make that pointer NULL when the tree is "broken", and
> > > freed under RCU if the context isn't the correct one.
> >
> > Can you explain what you mean by "if the context isn't the correct one"?
> > If this refers to when selecting a specific kvm_s2_mmu instance for
> > another context, then IIUC refcnt would already be 0 and there would be
> > no other user of the tree.
>
> Sorry, "context" is an overloaded word. I meant a situation in which
> you couldn't immediately free the maple-tree because you're holding
> locks and freeing (hypothetically) requires a sleeping "context". in
> this case, freeing under RCU, purely as a deferring mechanism, might
> be useful.
I experimented using RCU to free the tree as a deferring mechanism.
Here are a few observations:
- At reverse map record time, if maple tree store fails, we have to
change the maple tree pointer to a NULL, which is an RCU write
operation. Therefore we need to either take another lock, or use a
xchg(ptr, NULL) to avoid the lock.
- Because we're holding the read-side mmu_lock, we shouldn't block
during reverse map record. Therefore we should use call_rcu()
instead of synchronize_rcu() to free the "broken" tree. This implies
a pointer to a maple tree in kvm_s2_mmu will not suffice, an
additional structure with both the maple tree and an rcu_head have
to be created.
IMO looking at RCU calls mixed with mtree_{, un}lock(), and having a new
wrapper struct to make this dynamic allocation scheme work is not very
attractive to me.
Instead, what do you think if I aggregate all strictly NV-related
fields in kvm_s2_mmu i.e. tlb_vttbr, tlb_vtcr, nested_stage2_enabled,
shadow_pt_debugfs_dentry, pending_unmap, into a struct maybe called
kvm_s2_mmu_nested, add a maple tree in it, and have a pointer to this
struct in kvm_s2_mmu? kvm_s2_mmu_nested can then be allocated only if we
init a nested s2 mmu.
Do you think this can work and is better than the current approaches?
Thanks,
Wei-Lin Chang
>
> [...]
>
> > > > +/*
> > > > + * Per shadow S2 reverse map (IPA -> nested IPA range) maple tree payload
> > > > + * layout:
> > > > + *
> > > > + * bit 63: valid, 1 for non-polluted entries, prevents the case where the
> > > > + * nested IPA is 0 and turns the whole value to 0
> > > > + * bits 55-12: nested IPA bits 55-12
> > > > + * bit 0: polluted, 1 for polluted, 0 for not
> > > > + */
> > > > +#define VALID_ENTRY BIT(63)
> > > > +#define NESTED_IPA_MASK GENMASK_ULL(55, 12)
> > > > +#define UNKNOWN_IPA BIT(0)
> > > > +
> > >
> > > This only works because you are using the "advanced" API, right?
> > > Otherwise, you'd be losing the high bit. It'd be good to add a comment
> > > so that people keep that in mind.
> >
> > Sorry, I can't find any relationship between the advanced API and the
> > top most bit of the maple tree value, what am I missing?
>
> From Documentation/core-api/maple_tree.rst:
>
> <quote>
> The Maple Tree can store values between ``0`` and ``ULONG_MAX``. The Maple
> Tree reserves values with the bottom two bits set to '10' which are below 4096
> (ie 2, 6, 10 .. 4094) for internal use. If the entries may use reserved
> entries then the users can convert the entries using xa_mk_value() and convert
> them back by calling xa_to_value(). If the user needs to use a reserved
> value, then the user can convert the value when using the
> :ref:`maple-tree-advanced-api`, but are blocked by the normal API.
> </quote>
>
> So depending how you read this, you can conclude that the bit patterns
> you encode in the MT may be considered as invalid. xa_mk_value() would
> make things always work, but that shifts the value left by one bit,
> hence you'd lose bit 63 (see how we use trap_config in
> emulate-nested.c to deal with this).
>
> I think you are lucky that bits [11:1] are always 0 here, but that
> looks extremely fragile to me, so you never hit the [1:0]==10
> condition, but that's really fragile.
>
> >
> > >
> > > > void kvm_init_nested(struct kvm *kvm)
> > > > {
> > > > kvm->arch.nested_mmus = NULL;
> > > > @@ -769,12 +783,57 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
> > > > return s2_mmu;
> > > > }
> > > >
> > > > +void kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
> > > > + gpa_t fault_ipa, size_t map_size)
> > > > +{
> > > > + struct maple_tree *mt = &mmu->nested_revmap_mt;
> > > > + gpa_t start = ipa;
> > > > + gpa_t end = ipa + map_size - 1;
> > > > + u64 entry, new_entry = 0;
> > > > + MA_STATE(mas, mt, start, end);
> > > > +
> > > > + if (mmu->nested_revmap_broken)
> > > > + return;
> > > > +
> > > > + mtree_lock(mt);
> > > > + entry = (u64)mas_find_range(&mas, end);
> > > > +
> > > > + if (entry) {
> > > > + /* maybe just a perm update... */
> > > > + if (!(entry & UNKNOWN_IPA) && mas.index == start &&
> > > > + mas.last == end &&
> > > > + fault_ipa == (entry & NESTED_IPA_MASK))
> > > > + goto unlock;
> > > > + /*
> > > > + * Create a "polluted" range that spans all the overlapping
> > > > + * ranges and store it.
> > > > + */
> > > > + while (entry && mas.index <= end) {
> > > > + start = min(mas.index, start);
> > > > + end = max(mas.last, end);
> > > > + entry = (u64)mas_find_range(&mas, end);
> > > > + }
> > > > + new_entry |= UNKNOWN_IPA;
> > > > + } else {
> > > > + new_entry |= fault_ipa;
> > > > + new_entry |= VALID_ENTRY;
> > > > + }
> > > > +
> > > > + mas_set_range(&mas, start, end);
> > > > + if (mas_store_gfp(&mas, (void *)new_entry, GFP_NOWAIT | __GFP_ACCOUNT))
> > > > + mmu->nested_revmap_broken = true;
> > >
> > > Can we try and minimise the risk of allocation failure here?
> > >
> > > user_mem_abort() tries very hard to pre-allocate pages for page
> > > tables by maintaining an memcache. Can we have a similar approach for
> > > the revmap?
> >
> > Unfortunately, as I understand the maple tree can only pre-allocate for
> > a store when the range and the entry to be stored is given, but in this
> > case we must inspect the tree to get that information after we hold the
> > mmu and maple tree locks. It is possible to do a two pass approach:
> >
> > pre-allocate -> take MMU lock -> take maple tree lock -> revalidate what
> > we pre-allocated is still usable (nobody changed the tree before we took
> > the maple tree lock)
> >
> > But I am not fond of this extra complexity..
>
> Fair enough. It would at least be interesting to get a feel for how
> often this happens, because if we fail often, it won't help much.
>
> [...]
>
> > > My other concern here is related to TLB invalidation. As the guest
> > > performs TLB invalidations that remove entries from the shadow S2,
> > > there is no way to update the revmap to account for this.
> > >
> > > This obviously means that the revmap becomes more and more inaccurate
> > > over time, and that is likely to accumulate conflicting entries.
> > >
> > > What is the plan to improve the situation on this front?
> >
> > Right now I think using a direct map which goes from nested IPA to
> > canonical IPA could work while not generating too much complexity, if we
> > keep the reverse map and direct map in lockstep (direct map keeping the
> > same mappings as the reverse map but just in reverse).
>
> Right, so that'd effectively a mirror of the guest's page tables at
> the point of taking the fault.
>
> > I'll try to do that and include it in the next iteration.
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Paul Moore @ 2026-04-24 20:15 UTC (permalink / raw)
To: Yeoreum Yun, Mimi Zohar, roberto.sassu
Cc: Jonathan McDowell, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aesGU8a3mbVzvteH@e129823.arm.com>
On Fri, Apr 24, 2026 at 1:57 AM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > On Thu, Apr 23, 2026 at 2:13 PM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > >
> > > Sounds good. Once the patch is posted, I’ll review it as well.
> > > Sorry again for the noise, and thanks for your patience ;)
> >
> > My apologies for not getting a chance to look at this patchset sooner.
> >
> > This seems like an obvious, perhaps even stupid, question, but I have
> > to ask: if IMA can be properly initialized via late_initcall_sync(),
> > why not simply do the initialization in late_initcall_sync() and drop
> > the late_initcall() initialization?
> >
> > Does any IMA functionality suffer if initialization waits until
> > late_initcall_sync()? If so, it seems non-critical if waiting until
> > _sync() is acceptable, as it appears in these patches/comments.
>
> This is the way first patch did, and here is some discussion for this
> (Might you have seen, but in case of you missed):
> - https://lore.kernel.org/all/a6a0e15286c983d720de227c6827adbe976c5b9b.camel@linux.ibm.com/
Thanks for the pointer.
Unfortunately, my concern remains the same: it's either "safe" to
initialize IMA at late_initcall_sync() or it isn't. Attempting to
initialize IMA twice seems both odd and wrong.
I understand the need to ensure that the TPM is available, but if it
isn't safe to wait to initialize IMA at late_initcall_sync() then it
would seem like this is a bad option and we need another mechanism to
synchronize IMA with TPM devices. If it is safe to initalize IMA in
late_initcall_sync(), just do that and be done with it.
I'm also guessing a two stage init process, e.g. some in
late_initcall() and some in late_initcall_sync(), doesn't make much
sense here, but that could be one other thing to consider if some IMA
tasks must be done in late_initcall().
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH v3 2/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-24 20:25 UTC (permalink / raw)
To: Jonathan McDowell, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, roberto.sassu, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene, Yeoreum Yun
In-Reply-To: <5552c20c6d6d2ae3bbb6b35124af5d98d2f79163.1777036497.git.noodles@meta.com>
Thanks, Jonathan!
On Fri, 2026-04-24 at 14:24 +0100, Jonathan McDowell wrote:
> -static int __init init_ima(void)
> +static int __init init_ima(bool late)
> {
> int error;
>
> @@ -1247,10 +1247,26 @@ static int __init init_ima(void)
> return 0;
> }
>
> + /*
> + * If we found the TPM during our first attempt, or we know there's no
> + * TPM, nothing further to do
> + */
Perhaps it's just me, but the comment wording is a bit off. Could I change it
to: If we either found the TPM or knew there's no TPM during our first attempt,
nothing futher to do.
Otherwise the patch looks good.
Mimi
> + if (late && (ima_tpm_chip || !IS_ENABLED(CONFIG_TCG_TPM)))
> + return 0;
> +
> + ima_tpm_chip = tpm_default_chip();
> + if (!ima_tpm_chip && !late && IS_ENABLED(CONFIG_TCG_TPM)) {
> + pr_debug("TPM not available, will try later\n");
> + return -EPROBE_DEFER;
> + }
> +
> + if (!ima_tpm_chip)
> + pr_info("No TPM chip found, activating TPM-bypass!\n");
> +
^ permalink raw reply
* Re: [PATCH rc v2 1/5] iommu/arm-smmu-v3: Add arm_smmu_adopt_strtab() for kdump
From: Jason Gunthorpe @ 2026-04-24 20:50 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, kevin.tian, joro, praan, baolu.lu,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <aeu3bNxCsy8azLOO@Asurada-Nvidia>
On Fri, Apr 24, 2026 at 11:33:16AM -0700, Nicolin Chen wrote:
> On Fri, Apr 24, 2026 at 01:56:13PM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 15, 2026 at 02:17:36PM -0700, Nicolin Chen wrote:
> > > +static int arm_smmu_adopt_strtab_2lvl(struct arm_smmu_device *smmu, u32 cfg_reg,
> [..]
> > > + cfg->l2.l1tab = devm_memremap(
> > > + smmu->dev, dma, num_l1_ents * sizeof(struct arm_smmu_strtab_l1),
> > > + MEMREMAP_WB);
> >
> > WB shouldn't be unconditional? If the SMMU is working non-coherently
> > we need to map it NC. Same remark everwhere
>
> Hmm, I am trying to add a coherent-only gate for the series.
OK, may just add a comment to that effect here
> MEMREMAP_WC might work. But we cannot verify that on a coherent
> SMMU, right?
At most you could fake the smmu to noncoherent and check it maps the
right thing and assume the arch code does it right
Jason
^ permalink raw reply
* Re: [PATCH rc v2 2/5] iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump
From: Jason Gunthorpe @ 2026-04-24 20:51 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, kevin.tian, joro, praan, baolu.lu,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <aeu5/HsLwfhNWpbm@Asurada-Nvidia>
On Fri, Apr 24, 2026 at 11:44:12AM -0700, Nicolin Chen wrote:
> On Fri, Apr 24, 2026 at 01:59:27PM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 15, 2026 at 02:17:37PM -0700, Nicolin Chen wrote:
> > > +static bool arm_smmu_is_attach_deferred(struct device *dev)
> > > +{
> > > + struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > > + struct arm_smmu_device *smmu = master->smmu;
> > > + int i;
> > > +
> > > + if (!(smmu->options & ARM_SMMU_OPT_KDUMP))
> > > + return false;
> > > +
> > > + for (i = 0; i < master->num_streams; i++) {
> > > + u32 sid = master->streams[i].id;
> > > + struct arm_smmu_ste *step;
> > > +
> > > + /* Guard against unpopulated L2 entries in the adopted table */
> > > + if ((smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) &&
> > > + !smmu->strtab_cfg.l2.l2ptrs[arm_smmu_strtab_l1_idx(sid)])
> > > + continue;
> >
> > This can probably just call arm_smmu_init_sid_strtab()
> >
> > I think it is OK to allocate another level 2 here and it also has
> > protections for SID out of range..
>
> Actually, sashiko pointed out that this guard is a dead code.
>
> arm_smmu_init_sid_strtab() is called in arm_smmu_insert_master().
Even better
Jason
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-24 20:57 UTC (permalink / raw)
To: Paul Moore, Yeoreum Yun, roberto.sassu
Cc: Jonathan McDowell, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <CAHC9VhSaT_quKYnpFjAfqvL07JNbWMgM6c4pB9F46NHawX3DCA@mail.gmail.com>
On Fri, 2026-04-24 at 16:15 -0400, Paul Moore wrote:
> On Fri, Apr 24, 2026 at 1:57 AM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > On Thu, Apr 23, 2026 at 2:13 PM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > >
> > > > Sounds good. Once the patch is posted, I’ll review it as well.
> > > > Sorry again for the noise, and thanks for your patience ;)
> > >
> > > My apologies for not getting a chance to look at this patchset sooner.
> > >
> > > This seems like an obvious, perhaps even stupid, question, but I have
> > > to ask: if IMA can be properly initialized via late_initcall_sync(),
> > > why not simply do the initialization in late_initcall_sync() and drop
> > > the late_initcall() initialization?
> > >
> > > Does any IMA functionality suffer if initialization waits until
> > > late_initcall_sync()? If so, it seems non-critical if waiting until
> > > _sync() is acceptable, as it appears in these patches/comments.
> >
> > This is the way first patch did, and here is some discussion for this
> > (Might you have seen, but in case of you missed):
> > - https://lore.kernel.org/all/a6a0e15286c983d720de227c6827adbe976c5b9b.camel@linux.ibm.com/
>
> Thanks for the pointer.
>
> Unfortunately, my concern remains the same: it's either "safe" to
> initialize IMA at late_initcall_sync() or it isn't. Attempting to
> initialize IMA twice seems both odd and wrong.
Agreed. However, IMA should be initialized as soon as the TPM becomes
available, not delayed.
In patch 2/4 patch description, Jonathan describes the reasoning:
Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM
devices) are not reliably available during the initcall_late stage,
resulting in a log error:
ima: No TPM chip found, activating TPM-bypass!
and no measurements into the TPM by IMA. We can avoid this by doing IMA
init in the initcall_late_sync stage, after the drivers have completed
their init + registration.
Rather than do this everywhere, and needlessly delay the initialisation
of IMA when there is no need to do so, we continue to try to initialise
at the earlier stage, only deferring to the later point if the TPM is
not available yet.
>
> I understand the need to ensure that the TPM is available, but if it
> isn't safe to wait to initialize IMA at late_initcall_sync() then it
> would seem like this is a bad option and we need another mechanism to
> synchronize IMA with TPM devices. If it is safe to initalize IMA in
> late_initcall_sync(), just do that and be done with it.
Within the same initcall level there is no way of ordering the initialization.
Yeorum attempted to address the ordering issue in commit 0e0546eabcd6
("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"),
which is being reverted in this patch set.
Ordering within an initcall level needs to be fixed, but for now retrying at
late_initcall_sync works for some, hopefully most, cases.
>
> I'm also guessing a two stage init process, e.g. some in
> late_initcall() and some in late_initcall_sync(), doesn't make much
> sense here, but that could be one other thing to consider if some IMA
> tasks must be done in late_initcall().
Perhaps something to think about for the future.
Mimi
^ permalink raw reply
* [PATCH] ASoC: dt-bindings: mediatek,mt6351: convert to DT schema
From: Manish Baing @ 2026-04-24 21:03 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt
Cc: matthias.bgg, angelogioacchino.delregno, kaichieh.chuang,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, manishbaing2789
Convert MediaTek MT6351 Audio CODEC bindings from text format to
YAML schema to enable dtbs_check validation.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
.../bindings/sound/mediatek,mt6351-sound.yaml | 32 +++++++++++++++++++
.../devicetree/bindings/sound/mt6351.txt | 16 ----------
2 files changed, 32 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt6351-sound.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mt6351.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt6351-sound.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt6351-sound.yaml
new file mode 100644
index 000000000000..f9fab8962325
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt6351-sound.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt6351-sound.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6351 Audio CODEC
+
+maintainers:
+ - KaiChieh Chuang <kaichieh.chuang@mediatek.com>
+
+description:
+ MT6351 Audio CODEC is a part of the MediaTek MT6351 PMIC.
+ It communicates with the SoC through the MediaTek PMIC wrapper(pwrap).
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: mediatek,mt6351-sound
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt6351-sound";
+ };
diff --git a/Documentation/devicetree/bindings/sound/mt6351.txt b/Documentation/devicetree/bindings/sound/mt6351.txt
deleted file mode 100644
index 7fb2cb99245e..000000000000
--- a/Documentation/devicetree/bindings/sound/mt6351.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Mediatek MT6351 Audio Codec
-
-The communication between MT6351 and SoC is through Mediatek PMIC wrapper.
-For more detail, please visit Mediatek PMIC wrapper documentation.
-
-Must be a child node of PMIC wrapper.
-
-Required properties:
-
-- compatible : "mediatek,mt6351-sound".
-
-Example:
-
-mt6351_snd {
- compatible = "mediatek,mt6351-sound";
-};
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Paul Moore @ 2026-04-24 21:08 UTC (permalink / raw)
To: Mimi Zohar
Cc: Yeoreum Yun, roberto.sassu, Jonathan McDowell,
linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, jmorris, serge, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <014cf39aa8d6a0bcfa1a95c069675977ac67b843.camel@linux.ibm.com>
On Fri, Apr 24, 2026 at 4:58 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Fri, 2026-04-24 at 16:15 -0400, Paul Moore wrote:
> > On Fri, Apr 24, 2026 at 1:57 AM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > On Thu, Apr 23, 2026 at 2:13 PM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > >
> > > > > Sounds good. Once the patch is posted, I’ll review it as well.
> > > > > Sorry again for the noise, and thanks for your patience ;)
> > > >
> > > > My apologies for not getting a chance to look at this patchset sooner.
> > > >
> > > > This seems like an obvious, perhaps even stupid, question, but I have
> > > > to ask: if IMA can be properly initialized via late_initcall_sync(),
> > > > why not simply do the initialization in late_initcall_sync() and drop
> > > > the late_initcall() initialization?
> > > >
> > > > Does any IMA functionality suffer if initialization waits until
> > > > late_initcall_sync()? If so, it seems non-critical if waiting until
> > > > _sync() is acceptable, as it appears in these patches/comments.
> > >
> > > This is the way first patch did, and here is some discussion for this
> > > (Might you have seen, but in case of you missed):
> > > - https://lore.kernel.org/all/a6a0e15286c983d720de227c6827adbe976c5b9b.camel@linux.ibm.com/
> >
> > Thanks for the pointer.
> >
> > Unfortunately, my concern remains the same: it's either "safe" to
> > initialize IMA at late_initcall_sync() or it isn't. Attempting to
> > initialize IMA twice seems both odd and wrong.
>
> Agreed. However, IMA should be initialized as soon as the TPM becomes
> available, not delayed.
>
> In patch 2/4 patch description, Jonathan describes the reasoning:
>
> Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM
> devices) are not reliably available during the initcall_late stage,
> resulting in a log error:
>
> ima: No TPM chip found, activating TPM-bypass!
>
> and no measurements into the TPM by IMA. We can avoid this by doing IMA
> init in the initcall_late_sync stage, after the drivers have completed
> their init + registration.
>
> Rather than do this everywhere, and needlessly delay the initialisation
> of IMA when there is no need to do so, we continue to try to initialise
> at the earlier stage, only deferring to the later point if the TPM is
> not available yet.
Once again, that heavily implies that it is safe to initialize IMA in late-sync.
Put another way, what breaks if IMA's initialization is delayed to
late-sync? If the answer is nothing, just move the initialization to
late-sync. However, if something *is* broken and we are just doing
this because of TPM delays at boot, this patchset just creates
additional problems and we need a different solution. I can't
envision a scenario where it makes sense to attempt initialization
twice.
> > I understand the need to ensure that the TPM is available, but if it
> > isn't safe to wait to initialize IMA at late_initcall_sync() then it
> > would seem like this is a bad option and we need another mechanism to
> > synchronize IMA with TPM devices. If it is safe to initalize IMA in
> > late_initcall_sync(), just do that and be done with it.
>
> Within the same initcall level there is no way of ordering the initialization.
> Yeorum attempted to address the ordering issue in commit 0e0546eabcd6
> ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"),
> which is being reverted in this patch set.
>
> Ordering within an initcall level needs to be fixed, but for now retrying at
> late_initcall_sync works for some, hopefully most, cases.
That's not a good answer. Ignoring the TPM issue for a moment, can
you confirm that moving IMA's initialization to late-sync is safe? If
not, why is this approach being considered?
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-24 22:00 UTC (permalink / raw)
To: Paul Moore
Cc: Yeoreum Yun, roberto.sassu, Jonathan McDowell,
linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, jmorris, serge, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <CAHC9VhTW3=RJ8L91RWXYYA9tFjfSXGN-DMEEwdiD6big9H57Ew@mail.gmail.com>
On Fri, 2026-04-24 at 17:08 -0400, Paul Moore wrote:
> On Fri, Apr 24, 2026 at 4:58 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Fri, 2026-04-24 at 16:15 -0400, Paul Moore wrote:
> > > On Fri, Apr 24, 2026 at 1:57 AM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > > On Thu, Apr 23, 2026 at 2:13 PM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > > >
> > > > > > Sounds good. Once the patch is posted, I’ll review it as well.
> > > > > > Sorry again for the noise, and thanks for your patience ;)
> > > > >
> > > > > My apologies for not getting a chance to look at this patchset sooner.
> > > > >
> > > > > This seems like an obvious, perhaps even stupid, question, but I have
> > > > > to ask: if IMA can be properly initialized via late_initcall_sync(),
> > > > > why not simply do the initialization in late_initcall_sync() and drop
> > > > > the late_initcall() initialization?
> > > > >
> > > > > Does any IMA functionality suffer if initialization waits until
> > > > > late_initcall_sync()? If so, it seems non-critical if waiting until
> > > > > _sync() is acceptable, as it appears in these patches/comments.
> > > >
> > > > This is the way first patch did, and here is some discussion for this
> > > > (Might you have seen, but in case of you missed):
> > > > - https://lore.kernel.org/all/a6a0e15286c983d720de227c6827adbe976c5b9b.camel@linux.ibm.com/
> > >
> > > Thanks for the pointer.
> > >
> > > Unfortunately, my concern remains the same: it's either "safe" to
> > > initialize IMA at late_initcall_sync() or it isn't. Attempting to
> > > initialize IMA twice seems both odd and wrong.
> >
> > Agreed. However, IMA should be initialized as soon as the TPM becomes
> > available, not delayed.
> >
> > In patch 2/4 patch description, Jonathan describes the reasoning:
> >
> > Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM
> > devices) are not reliably available during the initcall_late stage,
> > resulting in a log error:
> >
> > ima: No TPM chip found, activating TPM-bypass!
> >
> > and no measurements into the TPM by IMA. We can avoid this by doing IMA
> > init in the initcall_late_sync stage, after the drivers have completed
> > their init + registration.
> >
> > Rather than do this everywhere, and needlessly delay the initialisation
> > of IMA when there is no need to do so, we continue to try to initialise
> > at the earlier stage, only deferring to the later point if the TPM is
> > not available yet.
>
> Once again, that heavily implies that it is safe to initialize IMA in late-sync.
>
> Put another way, what breaks if IMA's initialization is delayed to
> late-sync? If the answer is nothing, just move the initialization to
> late-sync. However, if something *is* broken and we are just doing
> this because of TPM delays at boot, this patchset just creates
> additional problems and we need a different solution. I can't
> envision a scenario where it makes sense to attempt initialization
> twice.
>
> > > I understand the need to ensure that the TPM is available, but if it
> > > isn't safe to wait to initialize IMA at late_initcall_sync() then it
> > > would seem like this is a bad option and we need another mechanism to
> > > synchronize IMA with TPM devices. If it is safe to initalize IMA in
> > > late_initcall_sync(), just do that and be done with it.
> >
> > Within the same initcall level there is no way of ordering the initialization.
> > Yeorum attempted to address the ordering issue in commit 0e0546eabcd6
> > ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"),
> > which is being reverted in this patch set.
> >
> > Ordering within an initcall level needs to be fixed, but for now retrying at
> > late_initcall_sync works for some, hopefully most, cases.
>
> That's not a good answer. Ignoring the TPM issue for a moment, can
> you confirm that moving IMA's initialization to late-sync is safe? If
> not, why is this approach being considered?
I'm not seeing any measurements between late_initcall and late_initcall_sync.
Based on this very limited testing, I don't feel comfortable to actually move
the syscall, but can see adding support to allow IMA initialization to be
deferred.
Mimi
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Paul Moore @ 2026-04-24 22:10 UTC (permalink / raw)
To: Mimi Zohar
Cc: Yeoreum Yun, roberto.sassu, Jonathan McDowell,
linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, jmorris, serge, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <1f78fc75b2e95239973612a4b6c4cc782960b7ac.camel@linux.ibm.com>
On Fri, Apr 24, 2026 at 6:01 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Fri, 2026-04-24 at 17:08 -0400, Paul Moore wrote:
> > On Fri, Apr 24, 2026 at 4:58 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Fri, 2026-04-24 at 16:15 -0400, Paul Moore wrote:
> > > > On Fri, Apr 24, 2026 at 1:57 AM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > > > On Thu, Apr 23, 2026 at 2:13 PM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > > > >
> > > > > > > Sounds good. Once the patch is posted, I’ll review it as well.
> > > > > > > Sorry again for the noise, and thanks for your patience ;)
> > > > > >
> > > > > > My apologies for not getting a chance to look at this patchset sooner.
> > > > > >
> > > > > > This seems like an obvious, perhaps even stupid, question, but I have
> > > > > > to ask: if IMA can be properly initialized via late_initcall_sync(),
> > > > > > why not simply do the initialization in late_initcall_sync() and drop
> > > > > > the late_initcall() initialization?
> > > > > >
> > > > > > Does any IMA functionality suffer if initialization waits until
> > > > > > late_initcall_sync()? If so, it seems non-critical if waiting until
> > > > > > _sync() is acceptable, as it appears in these patches/comments.
> > > > >
> > > > > This is the way first patch did, and here is some discussion for this
> > > > > (Might you have seen, but in case of you missed):
> > > > > - https://lore.kernel.org/all/a6a0e15286c983d720de227c6827adbe976c5b9b.camel@linux.ibm.com/
> > > >
> > > > Thanks for the pointer.
> > > >
> > > > Unfortunately, my concern remains the same: it's either "safe" to
> > > > initialize IMA at late_initcall_sync() or it isn't. Attempting to
> > > > initialize IMA twice seems both odd and wrong.
> > >
> > > Agreed. However, IMA should be initialized as soon as the TPM becomes
> > > available, not delayed.
> > >
> > > In patch 2/4 patch description, Jonathan describes the reasoning:
> > >
> > > Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM
> > > devices) are not reliably available during the initcall_late stage,
> > > resulting in a log error:
> > >
> > > ima: No TPM chip found, activating TPM-bypass!
> > >
> > > and no measurements into the TPM by IMA. We can avoid this by doing IMA
> > > init in the initcall_late_sync stage, after the drivers have completed
> > > their init + registration.
> > >
> > > Rather than do this everywhere, and needlessly delay the initialisation
> > > of IMA when there is no need to do so, we continue to try to initialise
> > > at the earlier stage, only deferring to the later point if the TPM is
> > > not available yet.
> >
> > Once again, that heavily implies that it is safe to initialize IMA in late-sync.
> >
> > Put another way, what breaks if IMA's initialization is delayed to
> > late-sync? If the answer is nothing, just move the initialization to
> > late-sync. However, if something *is* broken and we are just doing
> > this because of TPM delays at boot, this patchset just creates
> > additional problems and we need a different solution. I can't
> > envision a scenario where it makes sense to attempt initialization
> > twice.
> >
> > > > I understand the need to ensure that the TPM is available, but if it
> > > > isn't safe to wait to initialize IMA at late_initcall_sync() then it
> > > > would seem like this is a bad option and we need another mechanism to
> > > > synchronize IMA with TPM devices. If it is safe to initalize IMA in
> > > > late_initcall_sync(), just do that and be done with it.
> > >
> > > Within the same initcall level there is no way of ordering the initialization.
> > > Yeorum attempted to address the ordering issue in commit 0e0546eabcd6
> > > ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"),
> > > which is being reverted in this patch set.
> > >
> > > Ordering within an initcall level needs to be fixed, but for now retrying at
> > > late_initcall_sync works for some, hopefully most, cases.
> >
> > That's not a good answer. Ignoring the TPM issue for a moment, can
> > you confirm that moving IMA's initialization to late-sync is safe? If
> > not, why is this approach being considered?
>
> I'm not seeing any measurements between late_initcall and late_initcall_sync.
> Based on this very limited testing, I don't feel comfortable to actually move
> the syscall, but can see adding support to allow IMA initialization to be
> deferred.
(I'm assuming you meant initcall and not syscall above, but if you're
talking about something else, please let me know.)
Saying that you aren't comfortable moving IMA initialization to
late-sync is inconsistent with allowing IMA initialization to be
deferred to late-sync. Either it is okay to initialize IMA in
late-sync or it isn't. You must pick one.
--
paul-moore.com
^ permalink raw reply
* [RFC PATCH net-next 0/3] net: macb: candidate fixes for silent TX stall on BCM2712/RP1
From: Lukasz Raczylo @ 2026-04-24 22:38 UTC (permalink / raw)
To: netdev
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
Hi netdev, Nicolas, Claudiu, linux-rpi,
This series proposes three candidate fixes for the silent TX stall
observed on Raspberry Pi 5 (BCM2712 SoC, Cadence GEM via RP1 PCIe
south bridge). The bug has been reported, with reproducers, at:
* https://github.com/cilium/cilium/issues/43198
* https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Cilium #43198 reports reproduction on linux-raspi 6.17.0-1004, and
explicitly notes reproduction with both Cilium/eBPF and
Calico/nftables dataplanes (i.e. not CNI-specific). We observe the
same failure mode on kernel 6.18.24 built from raspberrypi/linux
rpi-6.18.y @ f2f68e79f16f, across a 24-node Raspberry Pi 5 fleet.
The 6.17/6.18 commonality and the two-CNI reproduction together
put the root cause below the packet-scheduling layer, in the macb
driver or the RP1 PCIe path.
Observed symptoms (our side, 6.18.24; consistent with the linked
reports):
* queue->tx_tail stops advancing at a single second;
* /sys/class/net/<iface>/statistics/tx_packets stops incrementing;
* qdisc backlog grows past zero; netif_stop_subqueue() is called;
* RX counters continue advancing; the MAC IRQ line continues to
fire (RX completions are handled);
* no kernel log line is produced for the duration of the stall;
* dev_watchdog does not fire: macb_netdev_ops has no
.ndo_tx_timeout, and our reading is that trans_start is kept
fresh by successful xmit prior to the ring filling;
* recovery on our side has required `ip link set <iface> down/up`
via an out-of-band watchdog DaemonSet.
Reading the current driver we identified three plausible races
between driver and hardware, each of which could independently
produce the observed behaviour. We did not determine which is the
actual root cause -- that likely requires either BCM2712/RP1
documentation we do not have, or dynamic tracing of the driver
during an in-situ stall. The series therefore attempts to close
all three, with each commit message stating which specific race
that patch is targeting.
Patch 1/3 -- flush PCIe posted write after TSTART doorbell.
Writes to NCR are posted PCIe writes and may not reach the MAC
before the driver returns. If the TSTART doorbell is lost, no
TX starts, no TCOMP arrives, and the ring goes quiescent. A
read-back of NCR after the write is a standard read-after-write
PCIe flush.
Patch 2/3 -- re-check ISR after IER re-enable in macb_tx_poll().
An existing comment in macb_tx_poll() notes that completions
raised while TCOMP is masked do not re-fire when IER is
re-enabled, and mitigates the window with macb_tx_complete_pending(),
which inspects driver-visible ring state only (after rmb()). On
PCIe-attached parts the descriptor DMA write that sets TX_USED
can remain in flight when that check runs; the rmb() orders CPU
writes but does not retire peripheral DMA. Reading ISR directly
after IER re-enable addresses this in two ways: (a) the MMIO read
is an architected PCIe read barrier for prior DMA writes, so a
subsequent macb_tx_complete_pending() sees up-to-date TX_USED
state; (b) it directly observes a pending TCOMP bit if the
hardware has one set. Either signal reschedules NAPI.
Patch 3/3 -- TX stall watchdog. Defence-in-depth. If patches
1 and 2 close the races we identified, this patch performs a
single spin_lock_irqsave/unlock and a branch per queue per
second with no other effect. If a further race remains that we
have not identified, it invokes the driver's own existing
macb_tx_restart(), which already verifies that TBQP is behind
tx_head before re-asserting TSTART. We include this patch
because we have empirically observed multi-minute stalls on this
hardware; we are willing to drop it if the preference is for
1 and 2 to stand alone.
Status and testing:
* Apply-tested against Linux net-next HEAD (this series is
generated from it) and against raspberrypi/linux rpi-6.18.y @
f2f68e79f16f (the fork our fleet runs): all three apply
cleanly on net-next; the rpi fork carries an additional local
`bool tx_pending` field on `struct macb_queue` that is not in
mainline, so we maintain a small rebased patch 3 hunk for it.
* Build-tested: the series compiles cleanly as part of our Talos
image build pipeline on arm64.
* Runtime-tested, early signal: ~4 h 20 min of post-patch uptime
on the canary node, ~3 h 15 min on the slowest (last master to
upgrade), ~95 node-hours cumulative across the 24-node fleet at
the time this cover letter was written. During that window the
fleet-wide counts are zero RECOVER events, zero `[tx-stall]`
partial markers (an out-of-band userspace detector that records
even transient one-second freezes that recover before the
3-second threshold), and zero ping-failure markers. Pre-patch
reference window (2026-04-24 14:00-18:10 UTC, when proper
monitoring was in place) observed multiple stalls per hour at
fleet level; at that rate we would expect on the order of 50
stalls in 95 node-hours, actual is zero. We will follow up
with a 24 h and a 1-week data point as the same observability
runs forward; the direction so far is consistent with patches
1 and 2 closing the underlying race(s) and patch 3 correctly
being a no-op on healthy hardware.
The series does not depend on any other in-flight work we are
aware of. Happy to split, rebase, or drop individual patches on
feedback. All three are independently revertable.
Lukasz Raczylo (3):
net: macb: flush PCIe posted write after TSTART doorbell
net: macb: re-check ISR after IER re-enable in macb_tx_poll
net: macb: add TX stall watchdog as defence-in-depth safety net
drivers/net/ethernet/cadence/macb.h | 5 ++
drivers/net/ethernet/cadence/macb_main.c | 99 +++++++++++++++++++++---
2 files changed, 94 insertions(+), 10 deletions(-)
--
2.53.0
^ permalink raw reply
* [RFC PATCH net-next 1/3] net: macb: flush PCIe posted write after TSTART doorbell
From: Lukasz Raczylo @ 2026-04-24 22:38 UTC (permalink / raw)
To: netdev
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
macb_start_xmit() and macb_tx_restart() kick transmission by
OR-ing MACB_BIT(TSTART) into NCR. On PCIe-attached macb instances
(BCM2712 + RP1 PCIe south bridge on Raspberry Pi 5 is the setup we
have in front of us), writes to NCR are posted PCIe writes: they
are not guaranteed to reach the device before the issuing CPU
returns. If the TSTART doorbell does not reach the MAC, no TX
begins, no TCOMP completion arrives, and the ring remains
quiescent without any kernel-visible indication.
Note that the raspberrypi/linux vendor fork carries a local patch
around the TSTART site (a queue->tx_pending breadcrumb that is
promoted to queue->txubr_pending by the next TCOMP interrupt,
triggering macb_tx_restart()). That workaround makes the loss
recoverable under traffic, but it cannot help if TCOMP itself is
not raised because no TX started -- which is exactly the case we
are targeting here. The handshake is not present in mainline.
Add a read-back of NCR after each TSTART write in macb_start_xmit()
and macb_tx_restart(). The read is an architected PCIe read
barrier for earlier posted writes on the same path; it ensures the
doorbell has reached the MAC before the functions return.
We do not yet have direct hardware evidence that TSTART is being
lost on the RP1 path (that would require a PCIe protocol analyser,
or at minimum a before/after counter on queue->tx_stall_last_tail
with and without this patch applied in isolation). This patch is
one of a three-patch series ("candidate fixes for silent TX stall
on BCM2712/RP1"); see the cover letter for context. We have
verified the series compiles and applies cleanly against mainline
HEAD and against raspberrypi/linux rpi-6.18.y @ f2f68e79f16f;
runtime verification is pending.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb_main.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a12aa2124..b6cca55ad 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1922,6 +1922,13 @@ static void macb_tx_restart(struct macb_queue *queue)
spin_lock(&bp->lock);
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
+ /*
+ * Flush the PCIe posted-write queue so the TSTART doorbell
+ * reliably reaches the MAC. Without this, the write can sit
+ * in the fabric and the MAC never advances, causing a silent
+ * TX stall.
+ */
+ (void)macb_readl(bp, NCR);
spin_unlock(&bp->lock);
out_tx_ptr_unlock:
@@ -2560,6 +2567,11 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
spin_lock(&bp->lock);
macb_tx_lpi_wake(bp);
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
+ /*
+ * Flush the PCIe posted-write queue; see the comment in
+ * macb_tx_restart() for the reasoning.
+ */
+ (void)macb_readl(bp, NCR);
spin_unlock(&bp->lock);
if (CIRC_SPACE(queue->tx_head, queue->tx_tail, bp->tx_ring_size) < 1)
--
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