* [PATCH v4 4/8] riscv/runtime-const: Replace open-coded placeholder with RUNTIME_MAGIC
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, Alexandre Ghiti, Charlie Jenkins, Jisheng Zhang,
Charles Mirabile
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
Define the placeholder used for lui + addi[w] patching sequence as
RUNTIME_MAGIC and use that instead of open coding the constants in the
inline assembly.
No functional changes intended.
Suggested-by: Guo Ren <guoren@kernel.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o New patch based on suggestions from Guo. (Thank you!)
---
arch/riscv/include/asm/runtime-const.h | 38 ++++++++++++++------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/arch/riscv/include/asm/runtime-const.h b/arch/riscv/include/asm/runtime-const.h
index 900db0a103d05..1ce02605d2e43 100644
--- a/arch/riscv/include/asm/runtime-const.h
+++ b/arch/riscv/include/asm/runtime-const.h
@@ -15,21 +15,23 @@
#include <linux/uaccess.h>
+#define RUNTIME_MAGIC __ASM_STR(0x89ABCDEF)
+
#ifdef CONFIG_32BIT
-#define runtime_const_ptr(sym) \
-({ \
- typeof(sym) __ret; \
- asm_inline(".option push\n\t" \
- ".option norvc\n\t" \
- "1:\t" \
- "lui %[__ret],0x89abd\n\t" \
- "addi %[__ret],%[__ret],-0x211\n\t" \
- ".option pop\n\t" \
- ".pushsection runtime_ptr_" #sym ",\"a\"\n\t" \
- ".long 1b - .\n\t" \
- ".popsection" \
- : [__ret] "=r" (__ret)); \
- __ret; \
+#define runtime_const_ptr(sym) \
+({ \
+ typeof(sym) __ret; \
+ asm_inline(".option push\n\t" \
+ ".option norvc\n\t" \
+ "1:\t" \
+ "lui %[__ret], %%hi(" RUNTIME_MAGIC ")\n\t" \
+ "addi %[__ret],%[__ret], %%lo(" RUNTIME_MAGIC ")\n\t" \
+ ".option pop\n\t" \
+ ".pushsection runtime_ptr_" #sym ",\"a\"\n\t" \
+ ".long 1b - .\n\t" \
+ ".popsection" \
+ : [__ret] "=r" (__ret)); \
+ __ret; \
})
#else
/*
@@ -46,10 +48,10 @@
".option push\n\t" \
".option norvc\n\t" \
"1:\t" \
- "lui %[__ret],0x89abd\n\t" \
- "lui %[__tmp],0x1234\n\t" \
- "addiw %[__ret],%[__ret],-0x211\n\t" \
- "addiw %[__tmp],%[__tmp],0x567\n\t" \
+ "lui %[__ret], %%hi(" RUNTIME_MAGIC ")\n\t" \
+ "lui %[__tmp], %%hi(" RUNTIME_MAGIC ")\n\t" \
+ "addiw %[__ret],%[__ret], %%lo(" RUNTIME_MAGIC ")\n\t" \
+ "addiw %[__tmp],%[__tmp], %%lo(" RUNTIME_MAGIC ")\n\t" \
#define RISCV_RUNTIME_CONST_64_BASE \
"slli %[__tmp],%[__tmp],32\n\t" \
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/8] riscv/runtime-const: Introduce runtime_const_mask_32()
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, Alexandre Ghiti, Charlie Jenkins, Jisheng Zhang,
Charles Mirabile
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
Futex hash computation requires a mask operation with read-only after
init data that will be converted to a runtime constant in the subsequent
commit.
Introduce runtime_const_mask_32 to further optimize the mask operation
in the futex hash computation hot path. GCC generates a:
lui a0, 0x12346 # upper; +0x800 then >>12 for correct rounding
addi a0, a0, 0x678 # lower 12 bits
and a1, a1, a0 # a1 = a1 & a0
pattern to tackle arbitrary 32-bit masks and the same was also suggested
by Claude which is implemented here. The final (__ret & val) operation
is intentionally placed outside of asm block to allow compilers to
further optimize it if possible.
__runtime_fixup_ptr() already patches a "lui + addi" sequence which has
been reused to patch the same sequence for __runtime_fixup_mask().
Assisted-by: Claude:claude-sonnet-4-5
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o Reverted back to using __ret as the macro variable to prevent
collision with local varaibles at callsite. (Sashiko)
o Separated out the & operation to prevent any confusion with operator
precedence id "val" is an expression. (Sashiko)
---
arch/riscv/include/asm/runtime-const.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/riscv/include/asm/runtime-const.h b/arch/riscv/include/asm/runtime-const.h
index 1ce02605d2e43..684641cb0fe82 100644
--- a/arch/riscv/include/asm/runtime-const.h
+++ b/arch/riscv/include/asm/runtime-const.h
@@ -159,6 +159,23 @@
__ret; \
})
+#define runtime_const_mask_32(val, sym) \
+({ \
+ u32 __ret; \
+ asm_inline(".option push\n\t" \
+ ".option norvc\n\t" \
+ "1:\t" \
+ "lui %[__ret], %%hi(" RUNTIME_MAGIC ")\n\t" \
+ "addi %[__ret],%[__ret], %%lo(" RUNTIME_MAGIC ")\n\t" \
+ ".option pop\n\t" \
+ ".pushsection runtime_mask_" #sym ",\"a\"\n\t" \
+ ".long 1b - .\n\t" \
+ ".popsection" \
+ : [__ret] "=r" (__ret)); \
+ __ret &= val; /* Allow compiler to optimize & operation. */ \
+ __ret; \
+})
+
#define runtime_const_init(type, sym) do { \
extern s32 __start_runtime_##type##_##sym[]; \
extern s32 __stop_runtime_##type##_##sym[]; \
@@ -262,6 +279,12 @@ static inline void __runtime_fixup_shift(void *where, unsigned long val)
mutex_unlock(&text_mutex);
}
+static inline void __runtime_fixup_mask(void *where, unsigned long val)
+{
+ __runtime_fixup_32(where, where + 4, val);
+ __runtime_fixup_caches(where, 2);
+}
+
static inline void runtime_const_fixup(void (*fn)(void *, unsigned long),
unsigned long val, s32 *start, s32 *end)
{
--
2.34.1
^ permalink raw reply related
* [PATCH v4 6/8] s390/runtime-const: Introduce runtime_const_mask_32()
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
Futex hash computation requires a mask operation with read-only after
init data that will be converted to a runtime constant in the subsequent
commit.
Introduce runtime_const_mask_32 to further optimize the mask operation
in the futex hash computation hot path.
GCC generates a:
nilf %r1,<imm32>
to tackle arbitrary 32-bit masks and the same is implemented here.
Immediate patching pattern for __runtime_fixup_mask() has been adopted
from __runtime_fixup_ptr().
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o No changes.
---
arch/s390/include/asm/runtime-const.h | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/runtime-const.h b/arch/s390/include/asm/runtime-const.h
index 17878b1d048cf..7b71156031ecb 100644
--- a/arch/s390/include/asm/runtime-const.h
+++ b/arch/s390/include/asm/runtime-const.h
@@ -33,6 +33,20 @@
__ret; \
})
+#define runtime_const_mask_32(val, sym) \
+({ \
+ unsigned int __ret = (val); \
+ \
+ asm_inline( \
+ "0: nilf %[__ret],12\n" \
+ ".pushsection runtime_mask_" #sym ",\"a\"\n" \
+ ".long 0b - .\n" \
+ ".popsection" \
+ : [__ret] "+d" (__ret) \
+ : : "cc"); \
+ __ret; \
+})
+
#define runtime_const_init(type, sym) do { \
extern s32 __start_runtime_##type##_##sym[]; \
extern s32 __stop_runtime_##type##_##sym[]; \
@@ -43,12 +57,12 @@
__stop_runtime_##type##_##sym); \
} while (0)
-/* 32-bit immediate for iihf and iilf in bits in I2 field */
static inline void __runtime_fixup_32(u32 *p, unsigned int val)
{
s390_kernel_write(p, &val, sizeof(val));
}
+/* 32-bit immediate for iihf and iilf in bits in I2 field */
static inline void __runtime_fixup_ptr(void *where, unsigned long val)
{
__runtime_fixup_32(where + 2, val >> 32);
@@ -65,6 +79,12 @@ static inline void __runtime_fixup_shift(void *where, unsigned long val)
s390_kernel_write(where, &insn, sizeof(insn));
}
+/* 32-bit immediate for nilf in bits in I2 field */
+static inline void __runtime_fixup_mask(void *where, unsigned long val)
+{
+ __runtime_fixup_32(where + 2, val);
+}
+
static inline void runtime_const_fixup(void (*fn)(void *, unsigned long),
unsigned long val, s32 *start, s32 *end)
{
--
2.34.1
^ permalink raw reply related
* [PATCH v4 7/8] asm-generic/runtime-const: Add dummy runtime_const_mask_32()
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Arnd Bergmann
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
From: Peter Zijlstra <peterz@infradead.org>
Add a dummy runtime_const_mask_32() for all the architectures that do
not support runtime-const.
Link: https://patch.msgid.link/20260227161841.GH606826@noisy.programming.kicks-ass.net
Not-yet-signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o No changes.
---
include/asm-generic/runtime-const.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/asm-generic/runtime-const.h b/include/asm-generic/runtime-const.h
index 6704994595145..03e6e3e02401e 100644
--- a/include/asm-generic/runtime-const.h
+++ b/include/asm-generic/runtime-const.h
@@ -10,6 +10,7 @@
*/
#define runtime_const_ptr(sym) (sym)
#define runtime_const_shift_right_32(val, sym) ((u32)(val)>>(sym))
+#define runtime_const_mask_32(val, sym) ((u32)(val)&(sym))
#define runtime_const_init(type,sym) do { } while (0)
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v4 8/8] futex: Use runtime constants for __futex_hash() hot path
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Borislav Petkov, Dave Hansen, x86,
Catalin Marinas, Will Deacon, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Arnd Bergmann, Guo Ren
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, H. Peter Anvin, Thomas Huth, Sean Christopherson,
Jisheng Zhang, Alexandre Ghiti, Charlie Jenkins, Charles Mirabile,
Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
From: Peter Zijlstra <peterz@infradead.org>
Runtime constify the read-only after init data __futex_shift(shift_32),
__futex_mask(mask_32), and __futex_queues(ptr) used in __futex_hash()
hot path to avoid referencing global variable.
This also allows __futex_queues to be allocated dynamically to
"nr_node_ids" slots instead of reserving config dependent MAX_NUMNODES
(1 << CONFIG_NODES_SHIFT) worth of slots upfront.
Runtime constants are initialized before their first access and
runtime_const_init() provides necessary barrier to ensure subsequent
accesses are not reordered against their initialization.
No functional changes intended.
[ prateek: Dynamically allocate __futex_queues, mark the global data
__ro_after_init since they are constified after futex_init(). ]
Link: https://patch.msgid.link/20260227161841.GH606826@noisy.programming.kicks-ass.net
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> # MAX_NUMNODES bloat
Not-yet-signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o Added a small note on runtime_const_init() in the commit log based on
the concerns highlighted by Sashiko. No changes to the diff.
---
include/asm-generic/vmlinux.lds.h | 5 +++-
kernel/futex/core.c | 42 +++++++++++++++++--------------
2 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 60c8c22fd3e44..e80987d8016cc 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -970,7 +970,10 @@
RUNTIME_CONST(ptr, __dentry_cache) \
RUNTIME_CONST(ptr, __names_cache) \
RUNTIME_CONST(ptr, __filp_cache) \
- RUNTIME_CONST(ptr, __bfilp_cache)
+ RUNTIME_CONST(ptr, __bfilp_cache) \
+ RUNTIME_CONST(shift, __futex_shift) \
+ RUNTIME_CONST(mask, __futex_mask) \
+ RUNTIME_CONST(ptr, __futex_queues)
/* Alignment must be consistent with (kunit_suite *) in include/kunit/test.h */
#define KUNIT_TABLE() \
diff --git a/kernel/futex/core.c b/kernel/futex/core.c
index ff2a4fb2993f0..73eade7184dc2 100644
--- a/kernel/futex/core.c
+++ b/kernel/futex/core.c
@@ -45,23 +45,19 @@
#include <linux/mempolicy.h>
#include <linux/mmap_lock.h>
+#include <asm/runtime-const.h>
+
#include "futex.h"
#include "../locking/rtmutex_common.h"
-/*
- * The base of the bucket array and its size are always used together
- * (after initialization only in futex_hash()), so ensure that they
- * reside in the same cacheline.
- */
-static struct {
- unsigned long hashmask;
- unsigned int hashshift;
- struct futex_hash_bucket *queues[MAX_NUMNODES];
-} __futex_data __read_mostly __aligned(2*sizeof(long));
+static u32 __futex_mask __ro_after_init;
+static u32 __futex_shift __ro_after_init;
+static struct futex_hash_bucket **__futex_queues __ro_after_init;
-#define futex_hashmask (__futex_data.hashmask)
-#define futex_hashshift (__futex_data.hashshift)
-#define futex_queues (__futex_data.queues)
+static __always_inline struct futex_hash_bucket **futex_queues(void)
+{
+ return runtime_const_ptr(__futex_queues);
+}
struct futex_private_hash {
int state;
@@ -439,14 +435,14 @@ __futex_hash(union futex_key *key, struct futex_private_hash *fph)
* NOTE: this isn't perfectly uniform, but it is fast and
* handles sparse node masks.
*/
- node = (hash >> futex_hashshift) % nr_node_ids;
+ node = runtime_const_shift_right_32(hash, __futex_shift) % nr_node_ids;
if (!node_possible(node)) {
node = find_next_bit_wrap(node_possible_map.bits,
nr_node_ids, node);
}
}
- return &futex_queues[node][hash & futex_hashmask];
+ return &futex_queues()[node][runtime_const_mask_32(hash, __futex_mask)];
}
/**
@@ -1916,7 +1912,7 @@ int futex_hash_allocate_default(void)
* 16 <= threads * 4 <= global hash size
*/
buckets = roundup_pow_of_two(4 * threads);
- buckets = clamp(buckets, 16, futex_hashmask + 1);
+ buckets = clamp(buckets, 16, __futex_mask + 1);
if (current_buckets >= buckets)
return 0;
@@ -1986,10 +1982,19 @@ static int __init futex_init(void)
hashsize = max(4, hashsize);
hashsize = roundup_pow_of_two(hashsize);
#endif
- futex_hashshift = ilog2(hashsize);
+ __futex_mask = hashsize - 1;
+ __futex_shift = ilog2(hashsize);
size = sizeof(struct futex_hash_bucket) * hashsize;
order = get_order(size);
+ __futex_queues = kcalloc(nr_node_ids, sizeof(*__futex_queues), GFP_KERNEL);
+
+ runtime_const_init(shift, __futex_shift);
+ runtime_const_init(mask, __futex_mask);
+ runtime_const_init(ptr, __futex_queues);
+
+ BUG_ON(!futex_queues());
+
for_each_node(n) {
struct futex_hash_bucket *table;
@@ -2003,10 +2008,9 @@ static int __init futex_init(void)
for (i = 0; i < hashsize; i++)
futex_hash_bucket_init(&table[i], NULL);
- futex_queues[n] = table;
+ futex_queues()[n] = table;
}
- futex_hashmask = hashsize - 1;
pr_info("futex hash table entries: %lu (%lu bytes on %d NUMA nodes, total %lu KiB, %s).\n",
hashsize, size, num_possible_nodes(), size * num_possible_nodes() / 1024,
order > MAX_PAGE_ORDER ? "vmalloc" : "linear");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] arm64: smp: Do not mark secondary CPUs possible under nosmp
From: zhangpengjie (A) @ 2026-04-30 9:54 UTC (permalink / raw)
To: Catalin Marinas
Cc: will, maz, timothy.hayes, lpieralisi, mrigendra.chaubey, arnd,
linux-arm-kernel, linux-kernel, zhanjie9, zhenglifeng1, lihuisong,
yubowen8, linhongye, linuxarm, wangzhi12
In-Reply-To: <49f96032-6027-4c79-8d08-9545261e553f@huawei.com>
On 4/30/2026 5:34 PM, zhangpengjie (A) wrote:
>
> On 4/27/2026 9:20 PM, Catalin Marinas wrote:
>> On Thu, Apr 23, 2026 at 09:46:54PM +0800, Pengjie Zhang wrote:
>>> Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
>>>
>>> However, arm64 still enumerates firmware-described CPUs during SMP
>>> initialization, which can leave secondary CPUs visible to
>>> for_each_possible_cpu() users even though they never reach the
>>> bringup path in this configuration.
>>>
>>> This is not just a cosmetic mask mismatch: code iterating over
>>> possible CPUs may observe secondary CPU per-CPU state that is never
>>> fully initialized under nosmp.
>> I'm fine with the patch in principle but I fail to see why it is not
>> mostly cosmetic. If we have possible & !present CPUs (there's another
>> thread around cpuhp_smt_enable() to allow this combination on arm64),
>> get_cpu_device() would return NULL and the core code is supposed to
>> handle this. What other per-CPU state should be initialised for a
>> possible CPU but it is not without this patch?
> Yes, possible-but-not-present CPUs are valid in the general hotplug
> model. The nosmp/maxcpus=0 case is different though: on arm64,
> smp_prepare_cpus() treats this as a UP-mandated boot and returns
> before marking secondary CPUs present, so these CPUs are deliberately
> kept out of the bringup path for this boot. The kind of issue I had in
> mind was subsystem-owned per-CPU state where iteration follows
> cpu_possible_mask but the state is populated only from CPU
> online/probe paths. The CPPC nosmp issue fixed by commit 15eece6c5b05
> ("ACPI: CPPC: Fix NULL pointer dereference when nosmp is used") was
> the kind of mismatch I was thinking of, although CPPC itself has
> already been fixed to use online CPUs where appropriate. I agree the
> changelog overstates this. I can respin with a toned-down changelog if
> you prefer.
I'm very sorry, there was an issue with the format above.
I'm reattaching the response below.
Yes, possible-but-not-present CPUs are valid in the general hotplug
model. The nosmp/maxcpus=0 case is different though: on arm64,
smp_prepare_cpus() treats this as a UP-mandated boot and returns before
marking secondary CPUs present, so these CPUs are deliberately kept out of
the bringup path for this boot.
The kind of issue I had in mind was subsystem-owned per-CPU state where
iteration follows cpu_possible_mask but the state is populated only from
CPU online/probe paths. The CPPC nosmp issue fixed by commit 15eece6c5b05
("ACPI: CPPC: Fix NULL pointer dereference when nosmp is used") was the
kind of mismatch I was thinking of, although CPPC itself has already been
fixed to use online CPUs where appropriate.
I agree the changelog overstates this. I can respin with a toned-down
changelog if you prefer.
^ permalink raw reply
* Re: [PATCH v4 1/3 net-next] dt-bindings: net: add st,stlc4560/p54spi binding
From: Arnd Bergmann @ 2026-04-30 9:58 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann
Cc: Christian Lamparter, Andreas Kemnade, Benoît Cousson,
Eric Dumazet, Bartosz Golaszewski, Krzysztof Kozlowski,
Johannes Berg, Jakub Kicinski, Kevin Hilman, linux-kernel,
linux-wireless, Linux-OMAP, Felipe Balbi, Rob Herring,
open list:GPIO SUBSYSTEM, Paolo Abeni, devicetree, Netdev,
David S . Miller, Roger Quadros, linux-arm-kernel,
Dmitry Torokhov, Aaro Koskinen, Tony Lindgren, Linus Walleij
In-Reply-To: <177754112702.3678889.4847926893667561974.robh@kernel.org>
On Thu, Apr 30, 2026, at 11:25, Rob Herring (Arm) wrote:
> On Thu, 30 Apr 2026 10:12:40 +0200, Arnd Bergmann wrote:
>> .../bindings/net/wireless/st,stlc4560.yaml | 61 +++++++++++++++++++
>> MAINTAINERS | 1 +
>> 2 files changed, 62 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
>>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> $id: Cannot determine base path from $id, relative path/filename
> doesn't match actual path or filename
> $id: http://devicetree.org/schemas/net/wireless/st,stlc45xx.yaml
> file:
Thanks for the report, I've fixed it now for v5, to adjust for the
renamed file.
Arnd
^ permalink raw reply
* RE: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin [林祐君] @ 2026-04-30 9:58 UTC (permalink / raw)
To: Michael Walle, Linus Walleij
Cc: Bartosz Golaszewski, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸]
In-Reply-To: <DHXSUW3NJU22.1RUYUHQZSZ53S@kernel.org>
Hi Linus and Michael,
> Hi,
>
> On Sun Apr 19, 2026 at 11:19 PM CEST, Linus Walleij wrote:
> > Hi Yu-Chun,
> >
> > On Fri, Apr 10, 2026 at 11:39 AM Yu-Chun Lin [林祐君]
> > <eleanor.lin@realtek.com> wrote:
> >
> >> We did look into gpio-mmio and gpio-regmap, but they are not quite suitable for
> >> our platform due to the specific hardware design:
> >>
> >> 1. Per-GPIO Dedicated Registers: Unlike typical GPIO controllers that pack 32 pins
> >> into a single 32-bit register (1 bit per pin), our hardware uses a dedicated 32-bit
> >> register for each individual GPIO. This single register controls the
> >> input/output state, direction, and interrupt trigger type for that specific pin.
> >
> > Isn't that attainable by:
> >
> > - setting .ngpio_per_reg to 1 in struct gpio_regmap_config
>
> Which is just used by the gpio_regmap_simple_xlate() anyway. So it
> doesn't really matter. But yeah, 1 would be the correct value here,
> assuming that the registers are consecutive.
>
> > - extend .reg_mask_xlate callback with an enum for each operation
> > (need to change all users of the .reg_mask_xlate callback but
> > who cares, they are not many):
> >
> > e.g.
> >
> > enum gpio_regmap_operation {
> > GPIO_REGMAP_GET_OP,
> > GPIO_REGMAP_SET_OP,
> > GPIO_REGMAP_SET_WITH_CLEAR_OP,
> > GPIO_REGMAP_GET_DIR_OP,
> > GPIO_REGMAP_SET_DIR_OP,
> > };
> >
> > int (*reg_mask_xlate)(struct gpio_regmap *gpio,
> > enum_gpio_regmap_operation op,
> > unsigned int base,
> > unsigned int offset, unsigned int *reg,
> > unsigned int *mask);
> >
> > This way .reg_mask_xlate() can hit different bits in the returned
> > *mask depending on operation and it will be find to pack all of
> > the bits into one 32bit register.
> >
> > Added Michael Walle to the the thread, he will know if this is a
> > good idea.
>
> Nice idea, though the information is then redundant in the usual
> case, i.e. drivers which need to translate specific registers
> will do a "switch (base)" at the moment. These should be converted
> to "switch (op)" just to keep all the drivers aligned and prevent
> new drivers from using the old method. You'd need to touch them
> anyway.
>
> I was briefly thinking about making it somewhat possible to embed
> the op into the base, if it would otherwise be all the same. That
> way, you could gpio-regmap as is. A special case like
> GPIO_REGMAP_ADDR_ZERO, that could be used by these kind of drivers,
> but that is probably too hacky.
>
> I'm fine with either way.
>
> >> 2. Write-Enable (WREN) Mask Mechanism: Our hardware requires a specific Write-Enable
> >> mask to be written simultaneously when updating the register values.
> >
> > Which is to just set bit 31.
> >
> > With the above scheme your .reg_mask_xlate callback can just set bit 31
> > no matter what operating you're doing. Piece of cake.
>
> Keep in mind, that this will make reading and writing somewhat
> different. reading assumes there is only one bit set in mask,
> because of the "!!(val & mask)" op, which is hardcoded. I'm not
> against using the write like that though.
>
> -michael
>
I understand the proposed approach for extending '.reg_mask_xlate' with
'enum gpio_regmap_operation', and I have started implementing it.
> >> 3. Hardware Debounce: We also need to support hardware debounce settings per pin,
> >> which requires custom configuration via set_config mapped to these specific per-pin
> >> registers.
> >
> > Just add a version of an optional .set_config() call to gpio-regmap.c
> > to handle this using .reg_mask_xlate() per above and add a new
> > GPIO_REGMAP_CONFIG_OP to the above enum, problem solved.
> >
> > If it seems too hard I can write patch 1 & 2 adding this infrastructure
> > but I bet you can easily see what can be done with gpio-regmap.c
> > here provided Michael W approves the idea.
> >
Our .set_config requires mapping specific debounce time values to
hardware-specific enums and applying a Write-Enable bit.
Would it be better to allow drivers to assign a custom '.set_config' callback
directly within 'struct gpio_regmap_config'?
Additionally, I didn't mention this in my previous email. we also need to
implement GPIO interrupts. Our hardware design does not fit well with
'regmap_irq_chip'. Therefore, I am planning to create our own 'irqdomain' and
'irqchip' ops to handle our cascaded interrupts.
Because of this custom IRQ implementation, I would need to use 'readl()/writel()'
for the IRQ callbacks in the rtd1625 GPIO driver instead of the regmap APIs.
Do you have any suggestions on how to handle this gracefully while keeping it
aligned with the regmap infrastructure?
Best Regards,
Yu-Chun
> > Yours,
> > Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: zhangpengjie (A) @ 2026-04-30 10:00 UTC (permalink / raw)
To: catalin.marinas, will, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, sumitg, cuiyunhui
Cc: linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, wangzhi12
In-Reply-To: <20260410094145.4132082-1-zhangpengjie2@huawei.com>
Hi all,
Gentle ping on this thread. It has been a while since I posted it.
Could someone please take a look when you have time? If there is anything
I should revise or any additional information needed, I'd be happy to
update it.
Thanks!
On 4/10/2026 5:41 PM, Pengjie Zhang wrote:
> The legacy CPPC feedback-counter path reads the delivered and reference
> performance counters separately.
>
> On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
> served through a cross-CPU counter read helper. Reading the counters
> separately therefore widens the sampling window between them and can
> skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
> load, the skew is observable as transient values that may exceed the
> platform maximum, as discussed in [1] and [2].
>
> This series adds a small generic hook for architectures that can obtain
> both FFH feedback counters in one operation, while preserving the
> existing per-register read path as the fallback.
>
> Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
> Patch 2 implements the hook on arm64 by sampling both AMU counters in a
> single operation on the target CPU.
>
> [1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
> [2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>
> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>
> Pengjie Zhang (2):
> ACPI: CPPC: add paired FFH feedback-counter read hook
> arm64: topology: read CPPC FFH feedback counters in one operation
>
> arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
> drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
> include/acpi/cppc_acpi.h | 7 ++++
> 3 files changed, 127 insertions(+), 13 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v5 5/8] sframe: Allow unsorted FDEs
From: Jens Remus @ 2026-04-30 10:04 UTC (permalink / raw)
To: Dylan Hatch, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina
Cc: Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel, Randy Dunlap, Heiko Carstens
In-Reply-To: <20260428183643.3796063-6-dylanbhatch@google.com>
On 4/28/2026 8:36 PM, Dylan Hatch wrote:
> The .sframe in kernel modules is built without SFRAME_F_FDE_SORTED set.
> In order to allow sframe PC lookup in modules, add a code path to handle
> unsorted FDE tables by doing a simple linear search.
>
> Reviewed-by: Jens Remus <jremus@linux.ibm.com>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
Indu suggested that it would be preferable if a module's .sframe FDE
index table could be sorted during loading of the module to enable
binary search instead of having to resort to linear search. I propose
to drop everything from this patch except for the following, squash
it into the following patch that adds sframe support for modules, and
extend that to sort the .sframe FDE index table. See my separate
feedback to that patch.
> diff --git a/include/linux/sframe.h b/include/linux/sframe.h
> @@ -28,6 +28,7 @@ struct sframe_section {
> unsigned long fres_start;
> unsigned long fres_end;
> unsigned int num_fdes;
> + bool fdes_sorted;
>
> signed char ra_off;
> signed char fp_off;
> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> @@ -736,7 +771,6 @@ static int sframe_read_header(struct sframe_section *sec)
>
> if (shdr.preamble.magic != SFRAME_MAGIC ||
> shdr.preamble.version != SFRAME_VERSION_3 ||
> - !(shdr.preamble.flags & SFRAME_F_FDE_SORTED) ||
> !(shdr.preamble.flags & SFRAME_F_FDE_FUNC_START_PCREL) ||
> shdr.auxhdr_len) {
> dbg_sec("bad/unsupported sframe header\n");
> @@ -766,6 +800,7 @@ static int sframe_read_header(struct sframe_section *sec)
> return -EINVAL;
> }
>
> + sec->fdes_sorted = shdr.preamble.flags & SFRAME_F_FDE_SORTED;
> sec->num_fdes = num_fdes;
> sec->fdes_start = fdes_start;
> sec->fres_start = fres_start;
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH v5 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION
From: Jens Remus @ 2026-04-30 10:04 UTC (permalink / raw)
To: Dylan Hatch, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina
Cc: Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel, Randy Dunlap, Heiko Carstens
In-Reply-To: <20260428183643.3796063-8-dylanbhatch@google.com>
On 4/28/2026 8:36 PM, Dylan Hatch wrote:
> Generalize the __safe* helpers to support a non-user-access code path.
>
> This requires arch-specific function address validation. This is because
> arm64 vmlinux keeps .exit.text (normally discarded), and .rodata.text
> sections both of which lie outside the bounds of the normal .text.
> .rodata.text contains code that is never executed by the kernel mapping,
> but for which the toolchain nonetheless generates sframe data, and needs
> to be considered valid for a PC lookup.
>
> Additionally .init.text lies outside .text for all arches and must be
> accounted for as well.
> diff --git a/arch/arm64/include/asm/unwind_sframe.h b/arch/arm64/include/asm/unwind_sframe.h
> @@ -2,7 +2,54 @@
> #ifndef _ASM_ARM64_UNWIND_SFRAME_H
> #define _ASM_ARM64_UNWIND_SFRAME_H
>
> +#include <linux/module.h>
> +#include <linux/sframe.h>
> +#include <asm/sections.h>
> +
> #define SFRAME_REG_SP 31
> #define SFRAME_REG_FP 29
>
> +static inline bool sframe_func_start_addr_valid(struct sframe_section *sec,
> + unsigned long func_addr)
> +{
> + /* Common case for unwinding */
> + if (sec->text_start <= func_addr && func_addr < sec->text_end)
> + return true;
> +
> + if (sec->sec_type != SFRAME_KERNEL)
> + return false;
> +
> + /*
> + * Account for vmlinux and module code outside the normal .text section.
> + * The toolchain still generates sframe data for these functions, so
> + * sframe lookups on them should be allowed.
> + */
> + if (sec == &kernel_sfsec) {
> + if (is_kernel_inittext(func_addr))
> + return true;
> +
> + /* .exit.text is retained in vmlinux on arm64. */
> + if (func_addr >= (unsigned long)__exittext_begin &&
> + func_addr < (unsigned long)__exittext_end)
> + return true;
> +
> +
Nit: Superfluous empty line (2 instead of 1).
> + /*
> + * .rodata.text is never executed from the kernel mapping, but
> + * still has sframe data
> + */
> + if (func_addr >= (unsigned long)_srodatatext &&
> + func_addr < (unsigned long)_erodatatext)
> + return true;
> + } else {
> + struct module *mod = container_of(sec, struct module,
> + arch.sframe_sec);
This currently does not work properly when sframe_validate_section() is
called from sframe_module_init(), which operates on a temporary struct
sframe_section section, that is not (yet) the one in struct module. See
my feedback to the respective patch for how to resolve.
> + if (within_module_mem_type(func_addr, mod, MOD_INIT_TEXT))
> + return true;
> + }
> +
> + return false;
> +}
> +#define sframe_func_start_addr_valid sframe_func_start_addr_valid
> +
> #endif /* _ASM_ARM64_UNWIND_SFRAME_H */
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH v5 6/8] arm64/module, sframe: Add sframe support for modules
From: Jens Remus @ 2026-04-30 10:04 UTC (permalink / raw)
To: Dylan Hatch, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina
Cc: Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel, Randy Dunlap, Heiko Carstens
In-Reply-To: <20260428183643.3796063-7-dylanbhatch@google.com>
On 4/28/2026 8:36 PM, Dylan Hatch wrote:
> Add sframe table to mod_arch_specific and support sframe PC lookups when
> an .sframe section can be found on incoming modules.
One small fix and a proposal to sort the module's SFrame FDE index.
> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
A subsequent patch adds a call to sframe_validate_section(), which would
operate on the temporary struct sframe_section instance and thus fail
to use container_of() to access the struct module instance. To resolve
change as follows:
> +void sframe_module_init(struct module *mod, void *sframe, size_t sframe_size,
> + void *text, size_t text_size)
> +{
> + struct sframe_section sec;
struct sframe_section *sec = &mod->arch.sframe_sec;
It is fine to initialize the module's struct sframe_section instance as
use of the information is guarded by mod->arch.sframe_init, which is
only set if the instance has been full initialized.
> +
> + memset(&sec, 0, sizeof(sec));
Can be dropped if struct module instance got zero-initialized.
> + sec.sec_type = SFRAME_KERNEL;
> + sec.sframe_start = (unsigned long)sframe;
> + sec.sframe_end = (unsigned long)sframe + sframe_size;
> + sec.text_start = (unsigned long)text;
> + sec.text_end = (unsigned long)text + text_size;
Adjust all lines above to pointer access.
> +
> + if (WARN_ON(sframe_read_header(&sec)))
Ditto.
> + return;
> +
> + mod->arch.sframe_sec = sec;
Drop.
> + mod->arch.sframe_init = true;
> +}
Indu suggested that it would be preferable if a module's .sframe FDE
index table could be sorted during loading of the module to enable
binary search instead of having to resort to linear search. I propose
to change this patch as follows to sort the module .sframe FDE index
table in sframe_module_init(). Note that the patch assumes above
changes have been implemented. The sorting is very similar to sorting
of ORC tables in arch/x86/kernel/unwind_orc.c in unwind_module_init().
diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
--- a/kernel/unwind/sframe.c
+++ b/kernel/unwind/sframe.c
@@ -12,6 +12,7 @@
#include <linux/mm.h>
#include <linux/string_helpers.h>
#include <linux/sframe.h>
+#include <linux/sort.h>
#include <linux/unwind_types.h>
#include <asm/unwind_sframe.h>
#ifdef CONFIG_HAVE_UNWIND_KERNEL_SFRAME
@@ -1038,6 +1039,50 @@ void __init init_sframe_table(void)
sframe_init = true;
}
+static int sframe_sort_cmp_fde(const void *a, const void *b)
+{
+ const struct sframe_fde_v3 *fde_a = a, *fde_b = b;
+ unsigned long func_start_a, func_start_b;
+
+ func_start_a = (unsigned long)fde_a + fde_a->func_start_off;
+ func_start_b = (unsigned long)fde_b + fde_b->func_start_off;
+
+ return cmp_int(func_start_a, func_start_b);
+}
+
+static void sframe_sort_swap_fde(void *a, void *b, int size)
+{
+ struct sframe_fde_v3 *fde_a = a, *fde_b = b;
+ struct sframe_fde_v3 temp;
+ long delta;
+
+ /* Swap potentially unaligned FDE */
+ memcpy(&temp, fde_a, sizeof(struct sframe_fde_v3));
+ memcpy(fde_a, fde_b, sizeof(struct sframe_fde_v3));
+ memcpy(fde_b, &temp, sizeof(struct sframe_fde_v3));
+
+ /* Adjust FDE function start offset from FDE */
+ delta = (long)((unsigned long)fde_b - (unsigned long)fde_a);
+ fde_a->func_start_off += delta;
+ fde_b->func_start_off -= delta;
+}
+
+static int sframe_sort_fdes(struct sframe_section *sec)
+{
+ void *fdes = (void *)sec->fdes_start;
+ size_t num_fdes = sec->num_fdes;
+
+ if (sec->sec_type != SFRAME_KERNEL)
+ return -EINVAL;
+ if (sec->fdes_sorted)
+ return 0;
+
+ sort(fdes, num_fdes, sizeof(struct sframe_fde_v3),
+ sframe_sort_cmp_fde, sframe_sort_swap_fde);
+ sec->fdes_sorted = true;
+ return 0;
+}
+
void sframe_module_init(struct module *mod, void *sframe, size_t sframe_size,
void *text, size_t text_size)
{
@@ -1053,6 +1098,8 @@ void sframe_module_init(struct module *mod, void *sframe, size_t sframe_size,
if (WARN_ON(sframe_read_header(sec)))
return;
+ if (WARN_ON(sframe_sort_fdes(sec)))
+ return;
if (WARN_ON(sframe_validate_section(sec)))
return;
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel
From: Jens Remus @ 2026-04-30 10:11 UTC (permalink / raw)
To: Dylan Hatch, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina
Cc: Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel, Randy Dunlap, Heiko Carstens
In-Reply-To: <20260428183643.3796063-1-dylanbhatch@google.com>
On 4/28/2026 8:36 PM, Dylan Hatch wrote:
> Implement a generic kernel sframe-based [1] unwinder. The main goal is
> to improve reliable stacktrace on arm64 by unwinding across exception
> boundaries.
Please add support to initialize the optional sframe unwinder debug
information. Either in the appropriate patches in this series or as a
separate patch.
Note that for the module case I wonder whether it would be preferable
to somehow indicate that it is a module name in the string, e.g.
"(<module-name>)" or "<module-name> (module)"?
diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
--- a/kernel/unwind/sframe.c
+++ b/kernel/unwind/sframe.c
@@ -1028,6 +1028,8 @@ void __init init_sframe_table(void)
kernel_sfsec.text_start = (unsigned long)_stext;
kernel_sfsec.text_end = (unsigned long)_etext;
+ dbg_init(&kernel_sfsec);
+
if (WARN_ON(sframe_read_header(&kernel_sfsec)))
return;
if (WARN_ON(sframe_validate_section(&kernel_sfsec)))
@@ -1047,6 +1049,8 @@ void sframe_module_init(struct module *mod, void *sframe, size_t sframe_size,
sec->text_start = (unsigned long)text;
sec->text_end = (unsigned long)text + text_size;
+ dbg_init(sec);
+
if (WARN_ON(sframe_read_header(sec)))
return;
if (WARN_ON(sframe_validate_section(sec)))
diff --git a/kernel/unwind/sframe_debug.h b/kernel/unwind/sframe_debug.h
--- a/kernel/unwind/sframe_debug.h
+++ b/kernel/unwind/sframe_debug.h
@@ -32,6 +32,18 @@ static inline void dbg_init(struct sframe_section *sec)
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
+ if (sec->sec_type == SFRAME_KERNEL) {
+ if (sec == &kernel_sfsec) {
+ sec->filename = kstrdup("(vmlinux)", GFP_KERNEL);
+ } else {
+ struct module *mod = container_of(sec, struct module,
+ arch.sframe_sec);
+ sec->filename = kstrdup(mod->name, GFP_KERNEL);
+ }
+
+ return;
+ }
+
guard(mmap_read_lock)(mm);
vma = vma_lookup(mm, sec->sframe_start);
if (!vma)
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH 1/3] firmware: arm_scmi: quirk: Improve quirk range parsing
From: Sudeep Holla @ 2026-04-30 10:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, Marek Vasut, arm-scmi, Sudeep Holla,
linux-arm-kernel, linux-renesas-soc
In-Reply-To: <fe257b3b7b7b5c17fd0e5727bb9746c731bd7e3c.1775205358.git.geert+renesas@glider.be>
On Fri, Apr 03, 2026 at 10:41:29AM +0200, Geert Uytterhoeven wrote:
> When a range contains only an end ("-X"), the number string is parsed
> twice, as both "sep == first" and "sep != last" are true. Fix this by
> dropping the superfluous number parsing for "sep == first".
>
> This does have a harmless functional impact for the unbounded range:
> "-" is now accepted, while it was rejected before.
>
Supporting "-" is good but I think the ret is uninitialised in that case
as sep, first and last are all equal. If you agree, I can patch up by
initialising ret to 0. Let me know if I am missing any other case where
it is not good to have ret initialised to 0.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
From: Sudeep Holla @ 2026-04-30 10:25 UTC (permalink / raw)
To: Andre Przywara
Cc: Lorenzo Pieralisi, Hanjun Guo, Catalin Marinas, Sudeep Holla,
Will Deacon, Rafael J . Wysocki, Len Brown, James Morse,
Ben Horgan, Reinette Chatre, Fenghua Yu, Jonathan Cameron,
linux-acpi, linux-arm-kernel, linux-kernel
In-Reply-To: <fc96c088-f767-4bf2-b58b-d4e91b0acde4@arm.com>
On Thu, Apr 30, 2026 at 11:20:42AM +0200, Andre Przywara wrote:
> Hi Sudeep,
>
> thanks for having a look!
>
> On 4/30/26 10:35, Sudeep Holla wrote:
> > On Wed, Apr 29, 2026 at 04:13:39PM +0200, Andre Przywara wrote:
> > > The Arm MPAM-Fb specification [1] describes a protocol to access MSC
> > > registers through a firmware interface. This requires a shared memory
> > > region to hold the message, and a mailbox to trigger the access.
> > > For ACPI this is wrapped as a PCC channel, described using existing
> > > ACPI abstractions.
> > >
> > > Add code to parse those PCC table descriptions associated with an MSC,
> > > and store the parsed information in the MSC struct.
> > > This will be used by the MPAM-Fb access wrapper code.
> > >
> > > [1] https://developer.arm.com/documentation/den0144/latest
> > >
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > > drivers/acpi/arm64/mpam.c | 2 ++
> > > drivers/resctrl/mpam_devices.c | 46 +++++++++++++++++++++++++++++++---
> > > 2 files changed, 45 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
> > > index 99c2bdbb3314..edb4d10e8dc3 100644
> > > --- a/drivers/acpi/arm64/mpam.c
> > > +++ b/drivers/acpi/arm64/mpam.c
> > > @@ -341,6 +341,8 @@ static struct platform_device * __init acpi_mpam_parse_msc(struct acpi_mpam_msc_
> > > } else if (iface == MPAM_IFACE_PCC) {
> > > props[next_prop++] = PROPERTY_ENTRY_U32("pcc-channel",
> > > tbl_msc->base_address);
> > > + props[next_prop++] = PROPERTY_ENTRY_U32("msc-id",
> > > + tbl_msc->identifier);
> >
> > I may be looking at the wrong documents, but neither DEN0065 nor DEN0144 carry
> > any definitions of pcc-channel and msc-id for the device with HID
> > "“ARMHAA5C". Since "pcc-channel" is already merged, I think I am looking at
> > wrong documents, please point me to the right one.
>
> Please excuse my ignorance, but I was under the assumption that the strings
> used here are just unique identifiers that need to match the property_get
> calls in the MPAM code. Is there any requirement to match those
> property_entry.name fields with the names given in some spec? And those
> strings are kernel-internal only, right? But for DT would match exactly the
> property names?
>
My bad, I missed to see that these are properties added to the software node
created for ACPI. I assumed the ACPI code is expecting this property in the
namespace device with HID 'ARMHAA5C'. Ignore my comment.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 13/43] KVM: arm64: gic-v5: Make VPEs (non-)resident in vgic_load/put
From: Marc Zyngier @ 2026-04-30 10:26 UTC (permalink / raw)
To: Sascha Bischoff
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, nd, oliver.upton@linux.dev, Joey Gouly,
Suzuki Poulose, yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes
In-Reply-To: <20260427160547.3129448-14-sascha.bischoff@arm.com>
On Mon, 27 Apr 2026 17:10:28 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> Extend vgic_v5_load and vgic_v5_put to make the VPEs resident and
> non-resident, respectively. This makes the IRS aware of which VPE is
> currently resident, and therefore allows it to perform HPPI selection
> for LPIs and SPIs, which would otherwise never be signalled to the
> VPE.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index 92bb63b6dd6bb..11a1a491b7e0a 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -1053,6 +1053,8 @@ void vgic_v5_flush_ppi_state(struct kvm_vcpu *vcpu)
> void vgic_v5_load(struct kvm_vcpu *vcpu)
> {
> struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
> + u16 vm = vgic_v5_vm_id(vcpu->kvm);
> + u16 vpe = vgic_v5_vpe_id(vcpu);
>
> /*
> * On the WFI path, vgic_load is called a second time. The first is when
> @@ -1065,7 +1067,11 @@ void vgic_v5_load(struct kvm_vcpu *vcpu)
>
> kvm_call_hyp(__vgic_v5_restore_vmcr_apr, cpu_if);
>
> - cpu_if->gicv5_vpe.resident = true;
> + cpu_if->vgic_contextr = FIELD_PREP(ICH_CONTEXTR_EL2_V, true) |
> + FIELD_PREP(ICH_CONTEXTR_EL2_VPE, vpe) |
> + FIELD_PREP(ICH_CONTEXTR_EL2_VM, vm);
> +
> + kvm_call_hyp(__vgic_v5_make_resident, cpu_if);
> }
>
> void vgic_v5_put(struct kvm_vcpu *vcpu)
> @@ -1083,7 +1089,9 @@ void vgic_v5_put(struct kvm_vcpu *vcpu)
>
> kvm_call_hyp(__vgic_v5_save_apr, cpu_if);
>
> - cpu_if->gicv5_vpe.resident = false;
> + cpu_if->vgic_contextr = 0;
> +
> + kvm_call_hyp(__vgic_v5_make_non_resident, cpu_if);
>
> /* The shadow priority is only updated on entering WFI */
> if (vcpu_get_flag(vcpu, IN_WFI))
Should this patch be folded in patch #3? They seem to overlap in major
ways.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 4/6] soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
From: Alexey Klimov @ 2026-04-30 10:27 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc,
Krzysztof Kozlowski, Peter Griffin, André Draszik,
Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260430-exynos850-cpuhotplug-v3-4-fd6251d02a17@linaro.org>
On Thu Apr 30, 2026 at 2:56 AM BST, Alexey Klimov wrote:
> Add cpuhotplug support for Exynos850 platforms. This SoC requires
> its own specific set of writes/updates to PMU and PMU interrupts
> generation block in order to put a CPU or a group of CPUs into
> a different sleep states or prepare these entities for a CPU_OFF
> or wake-up out of idle state or after CPU online.
> Without these writes/updates the CPU(s) wake-up or online fails.
> While at this, also add description of Exynos850 PMU registers.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> drivers/soc/samsung/Makefile | 2 +-
> drivers/soc/samsung/exynos-pmu.c | 1 +
> drivers/soc/samsung/exynos-pmu.h | 1 +
> drivers/soc/samsung/exynos850-pmu.c | 79 +++++++++++++++++++++++++++++
[..]
> +const struct exynos_pmu_data exynos850_pmu_data = {
> + .pmu_cpuhp = true,
> + .cpu_pmu_offline = exynos850_cpu_pmu_offline,
> + .cpu_pmu_online = exynos850_cpu_pmu_online,
> +};
> +
Ah, sorry, I forgot to remove blank line here. Will do in the next
update.
BR,
Alexey
^ permalink raw reply
* Re: [PATCH 1/3] firmware: arm_scmi: quirk: Improve quirk range parsing
From: Geert Uytterhoeven @ 2026-04-30 10:34 UTC (permalink / raw)
To: Sudeep Holla
Cc: Cristian Marussi, Marek Vasut, arm-scmi, linux-arm-kernel,
linux-renesas-soc
In-Reply-To: <20260430-heretic-mandrill-of-symmetry-1c9a5e@sudeepholla>
Hi Sudeep,
On Thu, 30 Apr 2026 at 12:17, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> On Fri, Apr 03, 2026 at 10:41:29AM +0200, Geert Uytterhoeven wrote:
> > When a range contains only an end ("-X"), the number string is parsed
> > twice, as both "sep == first" and "sep != last" are true. Fix this by
> > dropping the superfluous number parsing for "sep == first".
> >
> > This does have a harmless functional impact for the unbounded range:
> > "-" is now accepted, while it was rejected before.
>
> Supporting "-" is good but I think the ret is uninitialised in that case
> as sep, first and last are all equal. If you agree, I can patch up by
> initialising ret to 0. Let me know if I am missing any other case where
> it is not good to have ret initialised to 0.
My bad, ret should indeed be preinitialized to zero.
Thanks for fixing!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 14/43] KVM: arm64: gic-v5: Request VPE doorbells when going non-resident
From: Marc Zyngier @ 2026-04-30 10:37 UTC (permalink / raw)
To: Sascha Bischoff
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, nd, oliver.upton@linux.dev, Joey Gouly,
Suzuki Poulose, yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes
In-Reply-To: <20260427160547.3129448-15-sascha.bischoff@arm.com>
On Mon, 27 Apr 2026 17:10:49 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> When a VPE is made non-resident and is entering WFI, a doorbell should
> be requested for the VPE. This allows the VPE to be easily woken once
> an SPI/LPI interrupt is pending for it. This is tracked by the IRS,
> which will signal the specific VPE doorbell for the VPE once such an
> interrupt arrives.
>
> Requesting a doorbell involves calculating the DBPM - DoorBell
> Priority Mask - which ensures that the DB is only signalled by the
> hardware if the pending interrupt is of sufficient priority. This
> avoids waking a VPE that can't process the incoming interrupt.
>
> Doorbells are NOT requested if a VPE is not entering WFI as we expect
> to enter again imminently.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index 11a1a491b7e0a..2fc6fa4df034f 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -1077,6 +1077,9 @@ void vgic_v5_load(struct kvm_vcpu *vcpu)
> void vgic_v5_put(struct kvm_vcpu *vcpu)
> {
> struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
> + bool req_db = !!vcpu_get_flag(vcpu, IN_WFI);
Drop the spurious variable and move the check in the if () statement.
This is way more readable than declaring a variable.
> + u32 priority_mask;
> + int dbpm;
Move these in the inner block.
>
> /*
> * Do nothing if we're not resident. This can happen in the WFI path
> @@ -1090,6 +1093,31 @@ void vgic_v5_put(struct kvm_vcpu *vcpu)
> kvm_call_hyp(__vgic_v5_save_apr, cpu_if);
>
> cpu_if->vgic_contextr = 0;
> + if (req_db) {
> + /*
> + * Find the virtual running priority and use this to calculate
> + * the doorbell priority mask. We combine the highest active
> + * priority and the CPU's priority mask. The guest can't handle
> + * interrupts with priorities less than or equal to the virtual
> + * running priority, so there's literally no point in waking the
> + * guest for these.
> + *
> + * The priority needs to be higher than the mask to signal, so
> + * pick the next higher priority (subtract 1).
> + */
> + priority_mask = vgic_v5_get_effective_priority_mask(vcpu);
> +
> + /* Don't request a doorbell if the max priority is masked */
This comment reads badly. I'd suggest something like "Request a
doorbell *unless* the priority is 0, indicating that no interrupt can
wake the vcpu up".
> + if (priority_mask) {
> + dbpm = priority_mask - 1;
> + cpu_if->vgic_contextr = FIELD_PREP(ICH_CONTEXTR_EL2_DB, 1) |
> + FIELD_PREP(ICH_CONTEXTR_EL2_DBPM, dbpm);
> + }
> +
> + /* Make the doorbell affine to this CPU */
> + WARN_ON(irq_set_affinity(vgic_v5_vpe_db(vcpu),
> + cpumask_of(smp_processor_id())));
Repeatedly setting the affinity is likely to be costly. It may be
worth comparing with the current affinity somehow.
> + }
>
> kvm_call_hyp(__vgic_v5_make_non_resident, cpu_if);
>
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH] KVM: arm64: Harden clock for nvhe/pKVM
From: Mostafa Saleh @ 2026-04-30 10:37 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, kvmarm
Cc: catalin.marinas, will, maz, oliver.upton, joey.gouly,
suzuki.poulose, yuzenghui, vdonnefort, tabba, Mostafa Saleh
Sashiko(locally) reports possiblity of division by zero and
out-of-bounds bitwise shift in trace_clock_update().
Although the clock update is untrusted, we should at least have some
basic checks to avoid the clock value getting out of sync if the host
is buggy.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
arch/arm64/kvm/hyp/nvhe/clock.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/clock.c b/arch/arm64/kvm/hyp/nvhe/clock.c
index 32fc4313fe43..a7fc61976fd0 100644
--- a/arch/arm64/kvm/hyp/nvhe/clock.c
+++ b/arch/arm64/kvm/hyp/nvhe/clock.c
@@ -35,6 +35,9 @@ void trace_clock_update(u32 mult, u32 shift, u64 epoch_ns, u64 epoch_cyc)
struct clock_data *clock = &trace_clock_data;
u64 bank = clock->cur ^ 1;
+ if (!mult || shift >= 64)
+ return;
+
clock->data[bank].mult = mult;
clock->data[bank].shift = shift;
clock->data[bank].epoch_ns = epoch_ns;
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* Re: [PATCH v1] pmdomain: ti_sci: re-sync TIFS with genpd on resume
From: Sebin Francis @ 2026-04-30 10:47 UTC (permalink / raw)
To: Vitor Soares, Vignesh Raghavendra, Nishanth Menon, Tero Kristo,
Santosh Shilimkar, Ulf Hansson
Cc: Vitor Soares, linux-arm-kernel, linux-pm, linux-kernel,
Tomi Valkeinen, Kevin Hilman, vishalm, d-gole, Devarsh Thakkar,
stable, Kendall Willis
In-Reply-To: <c0fe43a2339c802e9ce5900092cd530a2ba17a6b.camel@gmail.com>
Hi Vitor,
On 29/04/26 21:56, Vitor Soares wrote:
> Hi Vignesh
>
> Thank you for the review.
>
> On Wed, 2026-04-29 at 10:03 +0530, Vignesh Raghavendra wrote:
>> Hi Vitor
>>
>> On 27/04/26 13:18, Vitor Soares wrote:
>>> From: Vitor Soares <vitor.soares@toradex.com>
>>>
>>> When a device in a TI SCI power domain is on the wakeup path of a
>>> wakeup-capable child, the suspend path skips genpd_sync_power_off().
>>> No put_device is sent to TIFS and the domain's genpd status remains
>>> ON.
>>
>> Correction of terminologies: TIFS is Root of trust component and is not
>> usually involved in power management, that would be DM (Device Manager)
>>
>
> Thank you for the clarification. I will address this on v2. Also, I was thinking
> to replace put_device/get_device with ti_sci_pd_power_off/ti_sci_pd_power_on if
> that makes more clear the content.
>
>> But to be really sure who is doing what, Could you provide an example
>> and the platform on which you see the issue / external abort?
>>
>
> This was reproduced on our Toradex Verdin AM62P WB and the driver for our Wi-Fi
> module on the SDIO bus calls device_init_wakeup() during the initialization.
>
> After enter in suspend, it show the following error resume path:
>
>
> [ 41.759341] Internal error: synchronous external abort: 0000000096000010 [#1]
> SMP
> [ 41.843286] CPU: 0 UID: 0 PID: 933 Comm: rtcwake Tainted: G M O
> 6.18.21-dirty #3 PREEMPT
> [ 41.852762] Tainted: [M]=MACHINE_CHECK, [O]=OOT_MODULE
> [ 41.857891] Hardware name: Toradex Verdin AM62P WB on Verdin Development
> Board (DT)
> [ 41.865537] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 41.872492] pc : regmap_mmio_read32le+0x8/0x20
> [ 41.876941] lr : regmap_mmio_read+0x44/0x70
> [ 41.881120] sp : ffff800081fdb8e0
> [ 41.884428] x29: ffff800081fdb8e0 x28: 0000000000000000 x27: ffffa95bb64aa9c8
> [ 41.891563] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
> [ 41.898697] x23: 0000000080000000 x22: ffff000002df5c00 x21: ffff800081fdb9b4
> [ 41.905831] x20: 0000000000000100 x19: ffff000001286400 x18: 0000000000000000
> [ 41.912965] x17: 2d69696d67722f79 x16: 687020726f662067 x15: ffff00007fb74f40
> [ 41.920100] x14: 00000000000002ea x13: 000000000000031f x12: 0000000000000000
> [ 41.927234] x11: 00000000000000c0 x10: 00000000000009e0 x9 : ffff800081fdb7a0
> [ 41.934368] x8 : ffff00007fb6ce00 x7 : 0000000000000000 x6 : 0000000000000000
> [ 41.941502] x5 : ffffa95bb57948d8 x4 : 0000000000000100 x3 : 0000000000000100
> [ 41.948636] x2 : ffffa95bb5795034 x1 : 0000000000000100 x0 : ffff80008025d100
> [ 41.955770] Call trace:
> [ 41.958211] regmap_mmio_read32le+0x8/0x20 (P)
> [ 41.962655] _regmap_bus_reg_read+0x70/0xb0
> [ 41.966839] _regmap_read+0x64/0xdc
> [ 41.970327] _regmap_update_bits+0xf4/0x140
> [ 41.974509] regmap_update_bits_base+0x64/0x98
> [ 41.978952] sdhci_am654_runtime_resume+0x138/0x208
> [ 41.983830] pm_generic_runtime_resume+0x2c/0x44
> [ 41.988445] __genpd_runtime_resume+0x30/0x7c
> [ 41.992804] genpd_runtime_resume+0xdc/0x2e8
> [ 41.997073] pm_runtime_force_resume+0x68/0xf4
> [ 42.001517] dpm_run_callback+0x8c/0x14c
> [ 42.005439] device_resume+0x11c/0x34c
> [ 42.009188] dpm_resume+0x178/0x1f0
> [ 42.012673] dpm_resume_end+0x18/0x34
> [ 42.016332] suspend_devices_and_enter+0x4a4/0x668
> [ 42.021123] pm_suspend+0x170/0x2dc
> [ 42.024610] state_store+0x80/0x104
> [ 42.028096] kobj_attr_store+0x18/0x2c
> [ 42.031845] sysfs_kf_write+0x7c/0x94
> [ 42.035508] kernfs_fop_write_iter+0x130/0x1fc
> [ 42.039949] vfs_write+0x200/0x370
> [ 42.043351] ksys_write+0x6c/0x100
> [ 42.046752] __arm64_sys_write+0x1c/0x28
> [ 42.050673] invoke_syscall.constprop.0+0x50/0xe4
> [ 42.055378] do_el0_svc+0x40/0xc4
> [ 42.058691] el0_svc+0x40/0x15c
> [ 42.061834] el0t_64_sync_handler+0xa0/0xe4
> [ 42.066015] el0t_64_sync+0x198/0x19c
> [ 42.069680] Code: aa0603e0 d65f03c0 f9400000 8b214000 (b9400000)
>
>>
>>>
>>> TIFS powers off the hardware during deep sleep regardless, since it
>>> was never informed to keep the domain active. On resume, because the
>>> domain's genpd status is ON, no get_device is issued. The driver
>>> then accesses registers of a powered-off domain, causing a
>>> synchronous external abort (AXI bus error, ESR 0x96000010).
>>
>> Hmm, if something is wakeup source, I would expect even TIFS/DM not to
>> turn if off, else module wakeup wouldn't work.
>>
>
> I tested UART as a wakeup source and I couldn't reproduce this issue. My
> understanding is that UART has its own TI SCI domain and device_may_wakeup() is
> true directly on that domain device, so the set_device_constraint fires
> correctly and DM keeps it powered.
>
> Here is my tracking of the issue:
>
> Wi-Fi driver registers as wakeup source:
> device_init_wakeup(mmc0:0001)
>
> During suspend/resume.
> dpm_suspend()
> ->genpd_suspend_dev(fa20000.mmc)
> ->ti_sci_pd_suspend(fa20000.mmc)
> ->ti_sci_pd_set_wkup_constraint(fa20000.mmc)
> device_may_wakeup(fa20000.mmc) = false
> set_device_constraint never sent to DM
>
>
> dpm_suspend_noirq()
> ->genpd_finish_suspend(fa20000.mmc)
> ->device_awake_path(fa20000.mmc) = true
> ->GENPD_FLAG_ACTIVE_WAKEUP = true
> genpd status = GENPD_STATE_ON
> skip power_off (ti_sci_pd_power_off)
>
> On deep sleep entry, DM powers off fa20000.mmc independently.
> It received no set_device_constraint nor ti_sci_pd_power_off.
In AM62P fa20000.mmc is part of main domain. During deepsleep the entire
main domain is turned off by the DM, that is why you see the failures.
In-order to debug this we need to check why pd off and pd on call is not
getting called for fa20000.mmc during suspend and resume.
>
> I attempted to fix this by calling set_device_constraint when
> device_wakeup_path() is true but it prevented the system from entering deep
> sleep entirely.
In AM62P the DM manager selects the low power mode to enter based on the
constrains set. The mode selection logic will ensure that if a
constraint is set on the device, it will select a low power mode in
which the device is kept on or can wake the system up. the MMC is part
of main domain and there is no low power mode in which the MMC can stay
alive or generate a wake up interrupt. so when a constraint is set of
MMC, we cannot enter any low power mode. that why you see a failure.
Regards
Sebin
>
> [...]
>
> Best regards,
> Vitor Soares
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme interrupts
From: Krzysztof Kozlowski @ 2026-04-30 10:48 UTC (permalink / raw)
To: Hongxing Zhu
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
bhelgaas@google.com, Frank Li, l.stach@pengutronix.de,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <AM0PR04MB52202A13D528B3AE16C3616A8C352@AM0PR04MB5220.eurprd04.prod.outlook.com>
On 30/04/2026 10:37, Hongxing Zhu wrote:
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Thursday, April 30, 2026 4:04 PM
>> To: Hongxing Zhu <hongxing.zhu@nxp.com>
>> Cc: robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
>> bhelgaas@google.com; Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
>> lpieralisi@kernel.org; kwilczynski@kernel.org; mani@kernel.org;
>> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com; linux-
>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>> devicetree@vger.kernel.org; imx@lists.linux.dev; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v3 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme
>> interrupts
>>
>> On Thu, Apr 30, 2026 at 01:09:52PM +0800, Richard Zhu wrote:
>>> Add 'intr', 'aer', and 'pme' interrupt entries to the i.MX6Q PCIe
>>> binding to support PCIe event-based interrupts for general controller
>>> events, Advanced Error Reporting, and Power Management Events respectively.
>>>
>>> These interrupts are optional for existing variants (imx6q, imx6sx,
>>> imx6qp, imx7d, imx8mq, imx8mm, imx8mp) to maintain backward
>>> compatibility with existing device trees.
>>>
>>> For fsl,imx95-pcie, all 5 interrupts (msi, dma, intr, aer, pme) are
>>> mandatory due to hardware requirements.
>>>
>>> This introduces an ABI requirement for fsl,imx95-pcie. The i.MX95
>>> hardware requires dedicated interrupt lines for AER, PME, and general
>>> controller events due to its redesigned interrupt architecture. i.MX95
>>> cannot function correctly without explicit interrupt routing for error
>>> handling, power management and link event detection.
>>
>> fsl,imx95-pcie was added more than two years ago, so how it cannot function
>> correctly? Are you saying that for two years you had here completely broken
>> code?
>>
>> If this wasn't tested for two years, how can we believe anything is tested now?
> The basic PCIe functionality has been working since the initial fsl,imx95-pcie
> support. However, AER (Advanced Error Reporting) and link up/down detection
> were not previously enabled. This patch-set adds and verifies support for
> these advanced features.
>
That is not what you said in the commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: imx95: Add dma, intr, aer and pme interrupters for pcie{0,1}
From: Krzysztof Kozlowski @ 2026-04-30 10:49 UTC (permalink / raw)
To: Hongxing Zhu
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
bhelgaas@google.com, Frank Li, l.stach@pengutronix.de,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <AM0PR04MB52208A6081E971A8BF05B2888C352@AM0PR04MB5220.eurprd04.prod.outlook.com>
On 30/04/2026 10:37, Hongxing Zhu wrote:
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Thursday, April 30, 2026 4:05 PM
>> To: Hongxing Zhu <hongxing.zhu@nxp.com>
>> Cc: robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
>> bhelgaas@google.com; Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
>> lpieralisi@kernel.org; kwilczynski@kernel.org; mani@kernel.org;
>> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com; linux-
>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>> devicetree@vger.kernel.org; imx@lists.linux.dev; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v3 2/3] arm64: dts: imx95: Add dma, intr, aer and pme
>> interrupters for pcie{0,1}
>>
>> On Thu, Apr 30, 2026 at 01:09:53PM +0800, Richard Zhu wrote:
>>> Add dma, intr, aer and pme interrupters for pcie{0,1}.
>>>
>>> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
>>> ---
>>> arch/arm64/boot/dts/freescale/imx95.dtsi | 16 ++++++++++++----
>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi
>>> b/arch/arm64/boot/dts/freescale/imx95.dtsi
>>> index 71394871d8dd0..6896d9c15bf53 100644
>>> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
>>> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
>>> @@ -1861,8 +1861,12 @@ pcie0: pcie@4c300000 {
>>> bus-range = <0x00 0xff>;
>>> num-lanes = <1>;
>>> num-viewport = <8>;
>>> - interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
>>> - interrupt-names = "msi";
>>
>> Why there is no fixes tag if this is here for two years and you claim that IT
>> CANNOT work without these interrupts?
> Regarding the Fixes tag: I think that it is not needed here because this is not
> a bug fix.
>
> The driver has been functional for two years using only the MSI interrupt. The
That's not what your binding said. Get your patchset straight including
proper ABI impact explanations.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] firmware: arm_scmi: quirk: Improve quirk range parsing
From: Sudeep Holla @ 2026-04-30 10:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, Marek Vasut, arm-scmi, Sudeep Holla,
linux-arm-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdWaF8buTuuMOPZLyEVF0vqPPdQxYP7LYJSj+vhdPJFc0w@mail.gmail.com>
On Thu, Apr 30, 2026 at 12:34:43PM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Thu, 30 Apr 2026 at 12:17, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> > On Fri, Apr 03, 2026 at 10:41:29AM +0200, Geert Uytterhoeven wrote:
> > > When a range contains only an end ("-X"), the number string is parsed
> > > twice, as both "sep == first" and "sep != last" are true. Fix this by
> > > dropping the superfluous number parsing for "sep == first".
> > >
> > > This does have a harmless functional impact for the unbounded range:
> > > "-" is now accepted, while it was rejected before.
> >
> > Supporting "-" is good but I think the ret is uninitialised in that case
> > as sep, first and last are all equal. If you agree, I can patch up by
> > initialising ret to 0. Let me know if I am missing any other case where
> > it is not good to have ret initialised to 0.
>
> My bad, ret should indeed be preinitialized to zero.
Thanks for confirming.
> Thanks for fixing!
>
Pushed now, will let the build/other bots take a spin and then I will
announce as applied if there are no other issues(which should be the case
as it has been in my -next for a while)
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 0/3] arm64: perf: Skip device memory during user callchain unwinding
From: Fredrik Markstrom @ 2026-04-30 10:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Shuah Khan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Santosh Shilimkar, Olof Johansson, Tony Lindgren
Cc: linux-arm-kernel, linux-kernel, linux-kselftest, linux-perf-users,
Nicolas Pitre, Fredrik Markstrom, Ivar Holmqvist, Malin Jonsson
Perf callchain unwinding follows userspace frame pointers via
copy_from_user. A corrupted or malicious frame pointer can point
into device I/O memory mapped into the process (e.g. via UIO or
/dev/mem), causing the kernel to read from MMIO regions in PMU
interrupt context. Such reads can have side effects on hardware
(clearing status registers, advancing FIFOs, triggering DMA) and
on arm64 can produce a synchronous external abort that panics the
kernel.
This series adds a guard that detects device memory before each
frame pointer read and skips the frame.
Patch 1: Lockless page table walk checking the MAIR attribute index
in the leaf PTE to identify device memory types
(MT_DEVICE_nGnRnE, MT_DEVICE_nGnRE). Follows the same
pattern as perf_get_pgtable_size() in kernel/events/core.c.
Patch 2: (DO NOT MERGE) Module parameter to disable the guard at
runtime for regression testing.
Patch 3: (DO NOT MERGE) kselftest that exercises the attack vector:
maps /dev/mem, points FP into it, and verifies the kernel
survives perf sampling.
Alternatives considered:
- VMA lookup (mmap_read_trylock + vma_lookup checking VM_IO):
requires the mmap lock on every frame.
- RCU maple tree lookup: lock-free but still a tree traversal
per frame.
- lock_vma_under_rcu: sleeping lock, unusable from IRQ context.
The page table walk requires no locks and costs only 4 pointer
dereferences per frame.
Limitations:
- The MAIR attribute check is arm64-specific. Other architectures
use different mechanisms to identify device memory and would need
their own PTE inspection logic.
- The walk only detects memory types visible in the PTE. If a page
is not present, the walk skips the frame. This has no additional
cost: copy_from_user_inatomic cannot fault in pages either, so
unwinding would stop at the same point regardless.
A QEMU-based reproducer is available at:
https://gitlab.com/frma71/qemu-kernel-tests/-/tree/vmio_perf_test?ref_type=tags
Signed-off-by: Fredrik Markstrom <fredrik.markstrom@est.tech>
---
Changes in v2:
- Added range_is_device_mem() to check both ends of the frame read
- Used module_param_unsafe with 0600 permissions
- Documented TOCTOU race in commit message
- Fixed selftest: O_CLOEXEC, mkdtemp, page size from sysconf
---
Fredrik Markstrom (3):
arm64: perf: Skip device memory during user callchain unwinding
DO NOT MERGE: arm64: perf: Add skip_vmio parameter to control device memory callchain guard
DO NOT MERGE: selftests: perf_events: Add device memory callchain unwinding test
MAINTAINERS | 1 +
arch/arm64/kernel/stacktrace.c | 116 ++++++++++++++++++
tools/testing/selftests/perf_events/Makefile | 2 +-
.../testing/selftests/perf_events/test_perf_vmio.c | 131 +++++++++++++++++++++
4 files changed, 249 insertions(+), 1 deletion(-)
---
base-commit: dca922e019dd758b4c1b4bec8f1d509efddeaab4
change-id: 20260427-master-with-pfix-v3-ae7173f538ca
Best regards,
--
Fredrik Markstrom <fredrik.markstrom@est.tech>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox