* [PATCH v3 4/7] riscv/runtime-const: Introduce runtime_const_mask_32()
From: K Prateek Nayak @ 2026-04-02 11:22 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Samuel Holland, David Laight
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,
Charles Mirabile
In-Reply-To: <20260402112250.2138-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 (__mask & 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 v2..v3:
o Moved the "&" operation outside the inline asm block to allow for
compilers to further optimize it if possible. (Based on David's
comment on ARM64 bits).
---
arch/riscv/include/asm/runtime-const.h | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/riscv/include/asm/runtime-const.h b/arch/riscv/include/asm/runtime-const.h
index d766e2b9e6df..85efba8ecf12 100644
--- a/arch/riscv/include/asm/runtime-const.h
+++ b/arch/riscv/include/asm/runtime-const.h
@@ -153,6 +153,22 @@
__ret; \
})
+#define runtime_const_mask_32(val, sym) \
+({ \
+ u32 __mask; \
+ asm_inline(".option push\n\t" \
+ ".option norvc\n\t" \
+ "1:\t" \
+ "lui %[__mask],0x89abd\n\t" \
+ "addi %[__mask],%[__mask],-0x211\n\t" \
+ ".option pop\n\t" \
+ ".pushsection runtime_mask_" #sym ",\"a\"\n\t" \
+ ".long 1b - .\n\t" \
+ ".popsection" \
+ : [__mask] "=r" (__mask)); \
+ (__mask & val); \
+})
+
#define runtime_const_init(type, sym) do { \
extern s32 __start_runtime_##type##_##sym[]; \
extern s32 __stop_runtime_##type##_##sym[]; \
@@ -256,6 +272,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 v3 5/7] s390/runtime-const: Introduce runtime_const_mask_32()
From: K Prateek Nayak @ 2026-04-02 11:22 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, Sven Schnelle
In-Reply-To: <20260402112250.2138-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 v2..v3:
o Collected Ack from Heiko after folding in the suggested diff. (Thanks
a ton!)
---
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 17878b1d048c..7b71156031ec 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 v3 6/7] asm-generic/runtime-const: Add dummy runtime_const_mask_32()
From: K Prateek Nayak @ 2026-04-02 11:22 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: <20260402112250.2138-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 v2..v3:
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 670499459514..03e6e3e02401 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 v3 7/7] futex: Use runtime constants for __futex_hash() hot path
From: K Prateek Nayak @ 2026-04-02 11:22 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,
Christian Borntraeger, Arnd Bergmann, David Laight,
Samuel Holland
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak
In-Reply-To: <20260402112250.2138-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.
No functional chages 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 v2..v3:
o No changes.
---
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 1e1580febe4b..86f99fa6ae24 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -975,7 +975,10 @@
RUNTIME_CONST(shift, d_hash_shift) \
RUNTIME_CONST(ptr, dentry_hashtable) \
RUNTIME_CONST(ptr, __dentry_cache) \
- RUNTIME_CONST(ptr, __names_cache)
+ RUNTIME_CONST(ptr, __names_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 ff2a4fb2993f..73eade7184dc 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 v1 07/27] KVM: arm64: Provide arm64 KVM API for non-native architectures
From: Christian Borntraeger @ 2026-04-02 11:26 UTC (permalink / raw)
To: Marc Zyngier, Steffen Eiden
Cc: kvm, kvmarm, linux-arm-kernel, linux-kernel, linux-s390,
Andreas Grapentin, Arnd Bergmann, Catalin Marinas,
Claudio Imbrenda, David Hildenbrand, Gautam Gala,
Hendrik Brueckner, Janosch Frank, Joey Gouly,
Nina Schoetterl-Glausch, Oliver Upton, Paolo Bonzini,
Suzuki K Poulose, Ulrich Weigand, Will Deacon, Zenghui Yu
In-Reply-To: <86y0j53caf.wl-maz@kernel.org>
Am 02.04.26 um 12:08 schrieb Marc Zyngier:
>> +static inline bool kvm_supports_32bit_el0(void)
>> +{
>> + return false;
>> +}
>> +
>
> This looks wrong. The original file still has:
>
> #define kvm_supports_32bit_el0() \
> (system_supports_32bit_el0() && \
> !static_branch_unlikely(&arm64_mismatched_32bit_el0))
Thanks for spotting.
Yes, we will fix. Seems to be a leftover when sorting patches.
Christian
^ permalink raw reply
* [PATCH v2] firmware: arm_ffa: Use the correct buffer size during RXTX_MAP
From: Sebastian Ene @ 2026-04-02 11:39 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, android-kvm; +Cc: sudeep.holla, Sebastian Ene
Don't use the discovered buffer size from an FFA_FEATURES call directly
since we can run on a system that has the PAGE_SIZE larger than the
returned size which makes the alloc_pages_exact for the buffer to be
rounded up.
Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()")
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
v1 -> v2:
* use the correct macro PAGE_ALIGN when calculating the size of the buffer
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index f2f94d4d533e..eb2782848283 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2078,7 +2078,7 @@ static int __init ffa_init(void)
ret = ffa_rxtx_map(virt_to_phys(drv_info->tx_buffer),
virt_to_phys(drv_info->rx_buffer),
- rxtx_bufsz / FFA_PAGE_SIZE);
+ PAGE_ALIGN(rxtx_bufsz) / FFA_PAGE_SIZE);
if (ret) {
pr_err("failed to register FFA RxTx buffers\n");
goto free_pages;
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* Re: [DMARC error]Re: [PATCH 0/2] Add PWM support Amlogic S7 S7D S6
From: George Stark @ 2026-04-02 11:46 UTC (permalink / raw)
To: Xianwei Zhao, Martin Blumenstingl
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <78e05060-6f25-4d78-8b0d-35b8fca0cecb@amlogic.com>
Hello Xianwei Zhao
On 3/31/26 10:59, Xianwei Zhao wrote:
> Hi George,
>
> On 2026/3/31 15:33, George Stark wrote:
>> Hello Martin, Xianwei
>>
>>
>> On 3/31/26 10:10, Xianwei Zhao wrote:
>>> Hi Martin,
>>> I confirmed with Junyi Zhao that the current implementation counts
>>> from zero, so this submission is correct.
>>> We agree this should be fixed and will address it in a follow-up patch.
>>> Thanks for pointing it out.
>>>
>>> On 2026/3/31 05:54, Martin Blumenstingl wrote:
>>>> Hi Xianwei Zhao,
>>>>
>>>> thanks for your contribution!
>>>>
>>>> On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
>>>> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>>>>> Add bindings and driver support Amlogic S7/S7D/S6 SoCs.
>>>> There is an old report that got lost, stating that the current
>>
>> Xianwei Zhao thanks for the confirmation.
>> I am the author of the old report and the corresponding patch and it's
>> not lost. So if the patch is correct I'll be glad to add relevant
>> tested-by tags.
>>
>
> I will use your patch and won't send a separate one.
> Do you mean I should add a Tested-by tag to your patch?
Yes since you've confirmed the problem exists then your tested-by tag
would be appropriate. And I'm ok if you resend the patch. Thanks.
>>>> pwm-meson driver has an off-by-one error with the hi and lo fields:
>>>> [0]
>>>> Since you are working on bringing up a new platform: is this something
>>>> you can verify in your lab?
>>>> To be clear: I'm not expecting you to work on this ad-hoc or bring a
>>>> patch into this series. However, it would be great if you could verify
>>>> if the findings from [0] are correct and send an updated patch in
>>>> future.
>>>>
>>>> Thank you and best regards
>>>> Martin
--
Best regards
George
^ permalink raw reply
* Re: [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Thierry Reding @ 2026-04-02 12:00 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-1-thierry.reding@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]
On Sun, Mar 29, 2026 at 05:10:38PM +0200, Thierry Reding wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
>
> Hi ARM SoC maintainers,
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-dt-bindings
>
> for you to fetch changes up to bed2f5b4de6c6fd8f8928f6373ad92e8795c370f:
>
> dt-bindings: arm: tegra: Document Jetson AGX Thor DevKit (2026-03-28 01:05:24 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> dt-bindings: Changes for v7.1-rc1
>
> This contains a few conversions to DT schema along with various
> additions and fixes to reduce the amount of validation warnings.
>
> Included are also a new binding for the PCIe controller found on
> Tegra264 as well as compatible strings for the Jetson AGX Thor
> Developer Kit.
>
> ----------------------------------------------------------------
> Sumit Gupta (1):
> dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
>
> Svyatoslav Ryhel (1):
> dt-bindings: display: tegra: Document Tegra20 HDMI port
>
> Thierry Reding (9):
> dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
> dt-bindings: phy: tegra-xusb: Document Type C support
> dt-bindings: clock: tegra124-dfll: Convert to json-schema
> dt-bindings: interrupt-controller: tegra: Fix reg entries
> dt-bindings: arm: tegra: Add missing compatible strings
> dt-bindings: phy: tegra: Document Tegra210 USB PHY
> dt-bindings: memory: Add Tegra210 memory controller bindings
> dt-bindings: memory: tegra210: Mark EMC as cooling device
> dt-bindings: arm: tegra: Document Jetson AGX Thor DevKit
>
> Documentation/devicetree/bindings/arm/tegra.yaml | 56 +++-
> .../bindings/arm/tegra/nvidia,tegra234-cbb.yaml | 4 +
> .../bindings/clock/nvidia,tegra124-dfll.txt | 155 -----------
> .../bindings/clock/nvidia,tegra124-dfll.yaml | 290 +++++++++++++++++++++
> .../display/tegra/nvidia,tegra20-hdmi.yaml | 13 +-
> .../interrupt-controller/nvidia,tegra20-ictlr.yaml | 23 +-
> .../memory-controllers/nvidia,tegra210-emc.yaml | 6 +-
> .../memory-controllers/nvidia,tegra210-mc.yaml | 77 ++++++
> .../bindings/pci/nvidia,tegra264-pcie.yaml | 149 +++++++++++
> .../bindings/phy/nvidia,tegra194-xusb-padctl.yaml | 39 ++-
> .../bindings/phy/nvidia,tegra20-usb-phy.yaml | 1 +
> 11 files changed, 649 insertions(+), 164 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
> create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.yaml
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-mc.yaml
> create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
Hi ARM SoC maintainers,
Please ignore this for now. I'm dropping my set of patches from this
because they upset the DT maintainers. I'll send another version with
only Sumit and Svyatoslav's patches.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Thierry Reding @ 2026-04-02 12:02 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-6-thierry.reding@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]
On Sun, Mar 29, 2026 at 05:10:43PM +0200, Thierry Reding wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
>
> Hi ARM SoC maintainers,
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm64-dt
>
> for you to fetch changes up to c70e6bc11d2008fbb19695394b69fd941ab39030:
>
> arm64: tegra: Add Tegra264 GPIO controllers (2026-03-28 01:36:46 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> arm64: tegra: Device tree changes for v7.1-rc1
>
> Various fixes and new additions across a number of devices. GPIO and PCI
> are enabled on Tegra264 and the Jetson AGX Thor Developer Kit, allowing
> it to boot via network and mass storage.
>
> ----------------------------------------------------------------
> Diogo Ivo (1):
> arm64: tegra: smaug: Enable SPI-NOR flash
>
> Jon Hunter (1):
> arm64: tegra: Fix RTC aliases
>
> Prathamesh Shete (1):
> arm64: tegra: Add Tegra264 GPIO controllers
>
> Thierry Reding (6):
> dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
> Merge branch for-7.1/dt-bindings into for-7.1/pci
> arm64: tegra: Fix snps,blen properties
> arm64: tegra: Drop redundant clock and reset names for TSEC
> arm64: tegra: Add PCI controllers on Tegra264
> arm64: tegra: Add Jetson AGX Thor Developer Kit support
>
> .../bindings/pci/nvidia,tegra264-pcie.yaml | 149 +++++++++
> arch/arm64/boot/dts/nvidia/Makefile | 2 +
> arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 12 +
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 -
> arch/arm64/boot/dts/nvidia/tegra234-p3701.dtsi | 1 +
> arch/arm64/boot/dts/nvidia/tegra234-p3767.dtsi | 1 +
> arch/arm64/boot/dts/nvidia/tegra234.dtsi | 6 +-
> .../dts/nvidia/tegra264-p4071-0000+p3834-0008.dts | 11 +
> .../boot/dts/nvidia/tegra264-p4071-0000+p3834.dtsi | 12 +
> arch/arm64/boot/dts/nvidia/tegra264.dtsi | 336 +++++++++++++++++++--
> 10 files changed, 500 insertions(+), 32 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p4071-0000+p3834-0008.dts
> create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p4071-0000+p3834.dtsi
Hi ARM SoC maintainers,
DT maintainers objected to the way I wanted to handle the DT bindings
dependency here, so I'll drop the whole PCI stuff from this and redo the
PR.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v6 0/3] hwmon: emc2305: Support configurable fan PWM at shutdown
From: florin.leotescu @ 2026-04-02 12:25 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
From: Florin Leotescu <florin.leotescu@nxp.com>
This series adds support for configuring the fan PWM duty cycle applied
during system shutdown for the EMC2305 fan controller.
Some platforms require fans to transition to a predefined safe state
during shutdown or reboot handoff until firmware or the next boot stage
reconfigures the controller.
The new optional Device Tree property "fan-shutdown-percent" allows the
shutdown PWM duty cycle to be configured per fan output.
Changes in v6:
- Split fan channel index validation into a separate patch.
Validate fan channel index agains the number of available channels.
- Refine dt-binding commit message to refer to PWM duty cycle
instead of fan speed.
Changes in v5:
- Add fan channel index bound check after reg property read
to prevent out-of-bounds access.
- Refine fan-shutdown-percent description.
Changes in v4:
- Initialize pwm_shudown array to EMC2305_PWM_SHUTDOWN_UNSET in probe,
to avoid treating unconfigured channels as valid and written 0
during shutdown
Changes in v3:
- Rebased on current upstream
- Dropped already upstreamed of_node_put(child) fix
Changes in v2:
- Address feedback from Guenter Roeck
- Make shutdown behavior configurable via Device Tree
- Add optional fan-shutdown-percent property
- Apply shutdown PWM only for channels defining the property
Florin Leotescu (3):
hwmon: emc2305: Validate fan channel index
dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
hwmon: emc2305: Support configurable fan PWM at shutdown
.../bindings/hwmon/microchip,emc2305.yaml | 8 ++++
drivers/hwmon/emc2305.c | 41 +++++++++++++++++++
2 files changed, 49 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v6 1/3] hwmon: emc2305: Validate fan channel index
From: florin.leotescu @ 2026-04-02 12:25 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260402122514.1811737-1-florin.leotescu@oss.nxp.com>
From: Florin Leotescu <florin.leotescu@nxp.com>
The fan channel index is used to access per-channel data structures.
Validate the index agains the number of available channels
before use to prevent out-of-bounds access if an invalid
value is provided.
Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
---
drivers/hwmon/emc2305.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c
index 64b213e1451e..0b42b82c8e22 100644
--- a/drivers/hwmon/emc2305.c
+++ b/drivers/hwmon/emc2305.c
@@ -548,6 +548,12 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
return ret;
}
+ if (ch >= data->pwm_num) {
+ dev_err(dev, "invalid reg %u for node %pOF (valid range 0-%u)\n", ch, child,
+ data->pwm_num - 1);
+ return -EINVAL;
+ }
+
ret = of_parse_phandle_with_args(child, "pwms", "#pwm-cells", 0, &args);
if (ret)
--
2.34.1
^ permalink raw reply related
* [PATCH v6 2/3] dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
From: florin.leotescu @ 2026-04-02 12:25 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260402122514.1811737-1-florin.leotescu@oss.nxp.com>
From: Florin Leotescu <florin.leotescu@nxp.com>
The EMC2305 fan controller supports multiple independent PWM fan
outputs. Some systems require fans to enter a defined safe state
during system shutdown or reboot handoff, until firmware or the next
boot stage reconfigures the controller.
Add an optional "fan-shutdown-percent" property to fan child nodes
allowing the PWM duty cycle applied during shutdown to be configured
per fan output.
Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
---
.../devicetree/bindings/hwmon/microchip,emc2305.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
index d3f06ebc19fa..8c2548539d7f 100644
--- a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
+++ b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
@@ -54,6 +54,12 @@ patternProperties:
The fan number used to determine the associated PWM channel.
maxItems: 1
+ fan-shutdown-percent:
+ description:
+ PWM duty cycle in percent applied to the fan during shutdown.
+ minimum: 0
+ maximum: 100
+
required:
- reg
@@ -80,12 +86,14 @@ examples:
fan@0 {
reg = <0x0>;
pwms = <&fan_controller 26000 PWM_POLARITY_INVERTED 1>;
+ fan-shutdown-percent = <100>;
#cooling-cells = <2>;
};
fan@1 {
reg = <0x1>;
pwms = <&fan_controller 26000 0 1>;
+ fan-shutdown-percent = <50>;
#cooling-cells = <2>;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v6 3/3] hwmon: emc2305: Support configurable fan PWM at shutdown
From: florin.leotescu @ 2026-04-02 12:25 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260402122514.1811737-1-florin.leotescu@oss.nxp.com>
From: Florin Leotescu <florin.leotescu@nxp.com>
Some systems require fans to enter in a defined safe state during system
shutdown or reboot handoff.
Add support for the optional Device Tree property "fan-shutdown-percent"
to configure the shutdown PWM duty cycle per fan output.
If the property is present for a fan channel, the driver converts the
configured percentage value to the corresponding PWM duty cycle and
applies it during driver shutdown.
If the property is not present, the fan state remains unchanged.
Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
---
drivers/hwmon/emc2305.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c
index 0b42b82c8e22..dec3a79933c1 100644
--- a/drivers/hwmon/emc2305.c
+++ b/drivers/hwmon/emc2305.c
@@ -32,6 +32,7 @@
#define EMC2305_REG_DRIVE_PWM_OUT 0x2b
#define EMC2305_OPEN_DRAIN 0x0
#define EMC2305_PUSH_PULL 0x1
+#define EMC2305_PWM_SHUTDOWN_UNSET -1
#define EMC2305_PWM_DUTY2STATE(duty, max_state, pwm_max) \
DIV_ROUND_CLOSEST((duty) * (max_state), (pwm_max))
@@ -104,6 +105,7 @@ struct emc2305_cdev_data {
* @pwm_output_mask: PWM output mask
* @pwm_polarity_mask: PWM polarity mask
* @pwm_separate: separate PWM settings for every channel
+ * @pwm_shutdown: Set shutdown PWM.
* @pwm_min: array of minimum PWM per channel
* @pwm_freq: array of PWM frequency per channel
* @cdev_data: array of cooling devices data
@@ -116,6 +118,7 @@ struct emc2305_data {
u8 pwm_output_mask;
u8 pwm_polarity_mask;
bool pwm_separate;
+ s16 pwm_shutdown[EMC2305_PWM_MAX];
u8 pwm_min[EMC2305_PWM_MAX];
u16 pwm_freq[EMC2305_PWM_MAX];
struct emc2305_cdev_data cdev_data[EMC2305_PWM_MAX];
@@ -539,6 +542,7 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
struct device_node *child,
struct emc2305_data *data)
{ u32 ch;
+ u32 pwm_shutdown_percent;
int ret;
struct of_phandle_args args;
@@ -585,6 +589,16 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
}
of_node_put(args.np);
+
+ ret = of_property_read_u32(child, "fan-shutdown-percent",
+ &pwm_shutdown_percent);
+
+ if (!ret) {
+ pwm_shutdown_percent = clamp(pwm_shutdown_percent, 0, 100);
+ data->pwm_shutdown[ch] =
+ DIV_ROUND_CLOSEST(pwm_shutdown_percent * EMC2305_FAN_MAX, 100);
+ }
+
return 0;
}
@@ -637,6 +651,9 @@ static int emc2305_probe(struct i2c_client *client)
if (ret)
return ret;
+ for (i = 0; i < EMC2305_PWM_MAX; i++)
+ data->pwm_shutdown[i] = EMC2305_PWM_SHUTDOWN_UNSET;
+
pwm_childs = emc2305_probe_childs_from_dt(dev);
pdata = dev_get_platdata(&client->dev);
@@ -720,6 +737,23 @@ static int emc2305_probe(struct i2c_client *client)
return 0;
}
+static void emc2305_shutdown(struct i2c_client *client)
+{
+ int i;
+ int ret;
+ struct emc2305_data *data = i2c_get_clientdata(client);
+
+ for (i = 0; i < data->pwm_num; i++) {
+ if (data->pwm_shutdown[i] != EMC2305_PWM_SHUTDOWN_UNSET) {
+ ret = i2c_smbus_write_byte_data(client, EMC2305_REG_FAN_DRIVE(i),
+ data->pwm_shutdown[i]);
+ if (ret < 0)
+ dev_warn(&client->dev,
+ "Failed to set shutdown PWM for ch %d\n", i);
+ }
+ }
+}
+
static const struct of_device_id of_emc2305_match_table[] = {
{ .compatible = "microchip,emc2305", },
{},
@@ -732,6 +766,7 @@ static struct i2c_driver emc2305_driver = {
.of_match_table = of_emc2305_match_table,
},
.probe = emc2305_probe,
+ .shutdown = emc2305_shutdown,
.id_table = emc2305_ids,
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 6.1.y 5/8] nvme-apple: remove an extra queue reference
From: Heyne, Maximilian @ 2026-04-02 12:31 UTC (permalink / raw)
To: Fedor Pchelkin
Cc: Christoph Hellwig, Sagi Grimberg, stable@vger.kernel.org,
Sven Peter, Chaitanya Kulkarni, Keith Busch, Jens Axboe,
Hector Martin, Alyssa Rosenzweig, James E.J. Bottomley,
Martin K. Petersen, Alim Akhtar, Avri Altman, Bart Van Assche,
Sasha Levin, Peter Wang, Greg Kroah-Hartman, Seunghui Lee,
Sanjeev Yadav, Wonkon Kim, Brian Kao, Hannes Reinecke, Ming Lei,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <20260401232116-53765a086f3855a30962fb81-pchelkin@ispras>
On Wed, Apr 01, 2026 at 11:45:57PM +0300, Fedor Pchelkin wrote:
> Hello,
>
> "Heyne, Maximilian" <mheyne@amazon.de> wrote:
> > From: Christoph Hellwig <hch@lst.de>
> >
> > [ Upstream commit 941f7298c70c7668416e7845fa76eb72c07d966b ]
> >
> > Now that blk_mq_destroy_queue does not release the queue reference, there
> > is no need for a second admin queue reference to be held by the
> > apple_nvme structure.
>
> This patch is probably buggy in upstream. It removes extra reference
> ->get, but doesn't remove the corresponding ->put which is located
> inside apple_nvme_free_ctrl().
Now I'm seeing this as well. Has the same problem as the pci driver in
6.1 where blk_put_queue is called from nvme_free_ctrl() and again from
apple_nvme_free_ctrl(). Thank you for catching this. I don't have the
hardware to test this.
Are you going to send a fix upstream? It's looks to be broken on master,
too.
>
> I'm reporting here currently just for the heads up - was looking at the
> same nvme regression problem at 6.1.y, found this thread, and the
> nvme-apple changes appeared suspicious.
>
> nvme-apple patch is not required to fix the regression (this also holds
> true for [PATCH 6.1.y 3/8] scsi: remove an extra queue reference). Maybe
> they shouldn't go to stable.
I think, I'll send a v2 of the patch set without these 2 patches. It's
probably easier for Greg to apply.
>
> That said, the other part of the backport series FWIW looks good to me,
> and I've also verified it resolves the 6.1.y regression.
You may leave a Tested-by if you want ;-)
>
> Thanks.
>
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
> > Reviewed-by: Sven Peter <sven@svenpeter.dev>
> > Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
> > Reviewed-by: Keith Busch <kbusch@kernel.org>
> > Link: https://lore.kernel.org/r/20221018135720.670094-5-hch@lst.de
> > Signed-off-by: Jens Axboe <axboe@kernel.dk>
> > Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
> > ---
> > drivers/nvme/host/apple.c | 9 ---------
> > 1 file changed, 9 deletions(-)
> >
> > diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
> > index c5fc293c22123..c84ebfcfdeb88 100644
> > --- a/drivers/nvme/host/apple.c
> > +++ b/drivers/nvme/host/apple.c
> > @@ -1507,15 +1507,6 @@ static int apple_nvme_probe(struct platform_device *pdev)
> > goto put_dev;
> > }
> >
> > - if (!blk_get_queue(anv->ctrl.admin_q)) {
> > - nvme_start_admin_queue(&anv->ctrl);
> > - blk_mq_destroy_queue(anv->ctrl.admin_q);
> > - blk_put_queue(anv->ctrl.admin_q);
> > - anv->ctrl.admin_q = NULL;
> > - ret = -ENODEV;
> > - goto put_dev;
> > - }
> > -
> > nvme_reset_ctrl(&anv->ctrl);
> > async_schedule(apple_nvme_async_probe, anv);
> >
> > --
> > 2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply
* Re: [PATCH v3 0/5] Support the FEAT_HDBSS introduced in Armv9.5
From: Leonardo Bras @ 2026-04-02 12:42 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <730aaffa-9dfd-40c3-a372-c774d203b6e1@huawei.com>
On Thu, Apr 02, 2026 at 10:40:37AM +0800, Tian Zheng wrote:
>
> On 3/31/2026 10:13 PM, Leonardo Bras wrote:
> > On Wed, Feb 25, 2026 at 12:04:16PM +0800, Tian Zheng wrote:
> > > This series of patches add support to the Hardware Dirty state tracking
> > > Structure(HDBSS) feature, which is introduced by the ARM architecture
> > > in the DDI0601(ID121123) version.
> > >
> > > The HDBSS feature is an extension to the architecture that enhances
> > > tracking translation table descriptors' dirty state, identified as
> > > FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
> > > page tracking, aiming to significantly reduce the overhead of scanning
> > > for dirty pages.
> > >
> > > The purpose of this feature is to make the execution overhead of live
> > > migration lower to both the guest and the host, compared to existing
> > > approaches (write-protect or search stage 2 tables).
> > >
> > > After these patches, users(such as qemu) can use the
> > > KVM_CAP_ARM_HW_DIRTY_STATE_TRACK ioctl to enable or disable the HDBSS
> > > feature before and after the live migration.
> > >
> > > v2:
> > > https://lore.kernel.org/linux-arm-kernel/20251121092342.3393318-1-zhengtian10@huawei.com/
> > >
> > > v2->v3 changes:
> > > - Remove the ARM64_HDBSS configuration option and ensure this feature
> > > is only enabled in VHE mode.
> > > - Move HDBSS-related variables to the arch-independent portion of the
> > > kvm structure.
> > > - Remove error messages during HDBSS enable/disable operations
> > > - Change HDBSS buffer flushing from handle_exit to vcpu_put,
> > > check_vcpu_requests, and kvm_handle_guest_abort.
> > > - Add fault handling for HDBSS including buffer full, external abort,
> > > and general protection fault (GPF).
> > > - Add support for a 4KB HDBSS buffer size, mapped to the value 0b0000.
> > > - Add a second argument to the ioctl to turn HDBSS on or off.
> > >
> > > Tian Zheng (1):
> > > KVM: arm64: Document HDBSS ioctl
> > >
> > > eillon (4):
> > > arm64/sysreg: Add HDBSS related register information
> > > KVM: arm64: Add support to set the DBM attr during memory abort
> > > KVM: arm64: Add support for FEAT_HDBSS
> > > KVM: arm64: Enable HDBSS support and handle HDBSSF events
> > >
> > > Documentation/virt/kvm/api.rst | 16 +++++
> > > arch/arm64/include/asm/cpufeature.h | 5 ++
> > > arch/arm64/include/asm/esr.h | 7 ++
> > > arch/arm64/include/asm/kvm_host.h | 17 +++++
> > > arch/arm64/include/asm/kvm_mmu.h | 1 +
> > > arch/arm64/include/asm/kvm_pgtable.h | 4 ++
> > > arch/arm64/include/asm/sysreg.h | 11 +++
> > > arch/arm64/kernel/cpufeature.c | 12 ++++
> > > arch/arm64/kvm/arm.c | 102 +++++++++++++++++++++++++++
> > > arch/arm64/kvm/hyp/pgtable.c | 6 ++
> > > arch/arm64/kvm/hyp/vhe/switch.c | 19 +++++
> > > arch/arm64/kvm/mmu.c | 70 ++++++++++++++++++
> > > arch/arm64/kvm/reset.c | 3 +
> > > arch/arm64/tools/cpucaps | 1 +
> > > arch/arm64/tools/sysreg | 29 ++++++++
> > > include/uapi/linux/kvm.h | 1 +
> > > tools/include/uapi/linux/kvm.h | 1 +
> > > 17 files changed, 305 insertions(+)
> > >
> > > --
> > > 2.33.0
> > >
> >
> > Hi Tian,
> >
> > I was thinking: maybe instead of putting the HDBSS (and HACDBS) stuff
> > across a bunch of KVM files, we should try to focus them all on a single
> > arch/arm64/kvm/dirty_bit.c file (plus a header such as
> > arch/arm64/include/asm/kvm_dirty_bit.h).
> >
> > What is your opinion on that?
> >
> > Thanks!
> > Leo
>
>
> Sorry for the late reply. Yes, I had the same thought before. In the next
> version, I will
>
> move all the HDBSS-related content into the same file, such as
> arch/arm64/kvm/dirty_bit.c
>
> and arch/arm64/include/asm/kvm_dirty_bit.h.
>
>
> Tian
>
>
> >
> >
Awesome! Then I will work my HACDBS enablement that way as well.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-02 12:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260402-towering-transparent-malamute-1e44b8@quoll>
On Thu, Apr 02, 2026 at 09:57:59AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Apr 02, 2026 at 01:37:02AM +0100, Daniel Golle wrote:
> > Add compatible strings for MediaTek SoCs where the hardware random number
> > generator is accessed via a vendor-defined Secure Monitor Call (SMC)
> > rather than direct MMIO register access:
> >
> > - mediatek,mt7981-rng
> > - mediatek,mt7987-rng
> > - mediatek,mt7988-rng
> >
> > These variants require no reg, clocks, or clock-names properties since
> > the RNG hardware is managed by ARM Trusted Firmware-A.
> >
> > Relax the $nodename pattern to also allow 'rng' in addition to the
> > existing 'rng@...' pattern.
> >
> > Add a second example showing the minimal SMC variant binding.
> >
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> > ---
> > v2: express compatibilities with fallback
> >
> > .../devicetree/bindings/rng/mtk-rng.yaml | 28 ++++++++++++++++---
> > 1 file changed, 24 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> > index 7e8dc62e5d3a6..34648b53d14c6 100644
> > --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> > +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> > @@ -11,12 +11,13 @@ maintainers:
> >
> > properties:
> > $nodename:
> > - pattern: "^rng@[0-9a-f]+$"
> > + pattern: "^rng(@[0-9a-f]+)?$"
> >
> > compatible:
> > oneOf:
> > - enum:
> > - mediatek,mt7623-rng
> > + - mediatek,mt7981-rng
> > - items:
> > - enum:
> > - mediatek,mt7622-rng
> > @@ -25,6 +26,11 @@ properties:
> > - mediatek,mt8365-rng
> > - mediatek,mt8516-rng
> > - const: mediatek,mt7623-rng
> > + - items:
> > + - enum:
> > + - mediatek,mt7987-rng
> > + - mediatek,mt7988-rng
> > + - const: mediatek,mt7981-rng
> >
> > reg:
> > maxItems: 1
> > @@ -38,9 +44,19 @@ properties:
> >
> > required:
> > - compatible
> > - - reg
> > - - clocks
> > - - clock-names
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + not:
>
> As requested last time - drop
>
> > + contains:
> > + const: mediatek,mt7981-rng
> > + then:
>
> missing constraints for mediatek,mt7981-rng. So does it have IO space
> and clocks or not?
The firmware variant which has the RNG under the control of TF-A and
requires Linux to use SMC to access it implies that Linux should not
touch the clk and cannot access the IO space (which is accessible from
secure-land only in this case).
Do you think something like the hunk below would properly express that?
@@ -38,9 +44,23 @@ properties:
required:
- compatible
- - reg
- - clocks
- - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7981-rng
+ then:
+ properties:
+ reg: false
+ clocks: false
+ clock-names: false
+ else:
+ required:
+ - reg
+ - clocks
+ - clock-names
additionalProperties: false
>
> > + required:
> > + - reg
> > + - clocks
> > + - clock-names
> >
> > additionalProperties: false
> >
> > @@ -53,3 +69,7 @@ examples:
> > clocks = <&infracfg CLK_INFRA_TRNG>;
> > clock-names = "rng";
> > };
> > + - |
> > + rng {
> > + compatible = "mediatek,mt7981-rng";
>
> No improvements.
>
> Also, make the example complete since binding claims you have clocks and
> reg.
So clocks and reg have to be prohibited, not just allowed to be absent,
right?
>
> I am not sure it should be even same file, but if you are making it same
> file, then make it correct.
It's the same hardware. In case of the MT7986 SoC MediaTek has even switched
from requiring the mediatek,mt7623-rng driver implementation to have the TRNG
controlled by TF-A in newer firmware, see driver implementation
auto-detecting this as a work-around...
^ permalink raw reply
* [PATCH net] net: airoha: Fix memory leak in airoha_qdma_rx_process()
From: Lorenzo Bianconi @ 2026-04-02 12:57 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
If an error occurs on the subsequents buffers belonging to the
non-linear part of the skb (e.g. due to an error in the payload length
reported by the NIC or if we consumed all the available fragments for
the skb), the page_pool fragment will not be linked to the skb so it will
not return to the pool in the airoha_qdma_rx_process() error path. Fix the
memory leak partially reverting commit 'd6d2b0e1538d ("net: airoha: Fix
page recycling in airoha_qdma_rx_process()")' and always running
page_pool_put_full_page routine in the airoha_qdma_rx_process() error
path.
Fixes: d6d2b0e1538d ("net: airoha: Fix page recycling in airoha_qdma_rx_process()")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 95ba99b89428e4cafb91ff7813e43ffeb38e6d9b..91cb63a32d9904e0700bcce45b53624677d75c6c 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -697,9 +697,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
if (q->skb) {
dev_kfree_skb(q->skb);
q->skb = NULL;
- } else {
- page_pool_put_full_page(q->page_pool, page, true);
}
+ page_pool_put_full_page(q->page_pool, page, true);
}
airoha_qdma_fill_rx_queue(q);
---
base-commit: a1822cb524e89b4cd2cf0b82e484a2335496a6d9
change-id: 20260402-airoha_qdma_rx_process-mem-leak-fix-27b53dbaaa4f
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH 2/2] media: cedrus: Fix failure to clean up hardware on probe failure
From: Dan Carpenter @ 2026-04-02 13:00 UTC (permalink / raw)
To: Andrey Skvortsov
Cc: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans Verkuil, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260401191441.1217646-2-andrej.skvortzov@gmail.com>
On Wed, Apr 01, 2026 at 10:14:41PM +0300, Andrey Skvortsov wrote:
> From: Samuel Holland <samuel@sholland.org>
>
> From: Samuel Holland <samuel@sholland.org>
>
git am isn't set up to deal with two From: headers.
> cedrus_hw_remove undoes, that was done by cedrus_hw_probe previously,
> like disabling runtime power management, releasing claimed sram.
The first part of this sentence is missing.
Otherwise, the patch itself looks okay.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] crypto: atmel-ecc - fix potential use-after-free in remove path
From: Thorsten Blum @ 2026-04-02 13:05 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Tudor Ambarus
Cc: Thorsten Blum, stable, linux-crypto, linux-arm-kernel,
linux-kernel
Flush the Atmel I2C workqueue before teardown to prevent a potential
use-after-free if a queued callback runs while the device is being
removed.
Drop the early return to ensure the driver always unregisters the KPP
algorithm and removes the client from the global list instead of
aborting teardown when the device is busy.
Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index b6a77c8d439c..6dbd0f70dd84 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -346,21 +346,8 @@ static void atmel_ecc_remove(struct i2c_client *client)
{
struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
- /* Return EBUSY if i2c client already allocated. */
- if (atomic_read(&i2c_priv->tfm_count)) {
- /*
- * After we return here, the memory backing the device is freed.
- * That happens no matter what the return value of this function
- * is because in the Linux device model there is no error
- * handling for unbinding a driver.
- * If there is still some action pending, it probably involves
- * accessing the freed memory.
- */
- dev_emerg(&client->dev, "Device is busy, expect memory corruption.\n");
- return;
- }
-
crypto_unregister_kpp(&atmel_ecdh_nist_p256);
+ atmel_i2c_flush_queue();
spin_lock(&driver_data.i2c_list_lock);
list_del(&i2c_priv->i2c_client_list_node);
^ permalink raw reply related
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Arnd Bergmann @ 2026-04-02 13:08 UTC (permalink / raw)
To: Thomas Zimmermann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <20260402092305.208728-4-tzimmermann@suse.de>
On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
> Add a descriptive string and help text to CONFIG_SYSFB, so that users
> can modify it. Flip all implicit selects in the Kconfig options into
> dependencies. This avoids cyclic dependencies in the config.
>
> Enabling CONFIG_SYSFB makes the kernel provide a device for the firmware
> framebuffer. As this can (slightly) affect system behavior, having a
> user-facing option seems preferable. Some users might also want to set
> every detail of their kernel config.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
I don't really like this part of the series and would prefer
to keep CONFIG_SYSFB hidden as much as possible as an x86
(and EFI) specific implementation detail, with the hope
of eventually seperating out the x86 bits from the EFI ones.
In general, I am always in favor of properly using Kconfig
dependencies over 'select' statements, for the same reasons
you describe, but I don't want the the x86 logic for
the legacy VESA and VGA console handling to leak into more
architectures than necessary.
Do you think we could instead move the sysfb_init()
function into the same two places that contain the
sysfb_primary_display definition (arch/x86/kernel/setup.c,
drivers/firmware/efi/efi-init.c) and simplify the efi version
to take out the x86 bits? That would reduce the rest
of sysfb-primary.c to the logic to unregister the device,
and that could then be selected by both x86 and EFI.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] media: cedrus: Fix missing cleanup in error path
From: Dan Carpenter @ 2026-04-02 13:09 UTC (permalink / raw)
To: Andrey Skvortsov
Cc: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans Verkuil, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260401191441.1217646-1-andrej.skvortzov@gmail.com>
On Wed, Apr 01, 2026 at 10:14:40PM +0300, Andrey Skvortsov wrote:
> From: Samuel Holland <samuel@sholland.org>
>
> From: Samuel Holland <samuel@sholland.org>
>
> According to the documentation struct v4l2_fh has to be cleaned up with
> v4l2_fh_exit() before being freed. [1]
>
> 1. https://docs.kernel.org/driver-api/media/v4l2-fh.html
>
I wish the commit message would say what the use visible effect of the
bug is. I looked at it and I don't think this patch hurts but I also
didn't necessarily see a that the original code had a user visible bug.
I read the documentation but it wasn't as unambiguous as I'd prefer.
But I'm not a subsystem expert.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Set REG_RX_CPU_IDX() once in airoha_qdma_fill_rx_queue()
From: patchwork-bot+netdevbpf @ 2026-04-02 13:20 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260331-airoha-cpu-idx-out-off-loop-v1-1-75c66b428f50@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 31 Mar 2026 12:33:24 +0200 you wrote:
> It is not necessary to update REG_RX_CPU_IDX register for each iteration
> of the descriptor loop in airoha_qdma_fill_rx_queue routine.
> Move REG_RX_CPU_IDX configuration out of the descriptor loop and rely on
> the last queue head value updated in the descriptor loop.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net-next] net: airoha: Set REG_RX_CPU_IDX() once in airoha_qdma_fill_rx_queue()
https://git.kernel.org/netdev/net-next/c/269389ba5398
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: exynos850: Add ap2apm mailbox
From: Alexey Klimov @ 2026-04-02 13:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260402-free-foamy-gibbon-acad72@quoll>
On Thu Apr 2, 2026 at 9:01 AM BST, Krzysztof Kozlowski wrote:
> On Thu, Apr 02, 2026 at 03:20:16AM +0100, Alexey Klimov wrote:
>> Add mailbox node that describes AP-to-APM mailbox, that can be
>> used for communicating with APM co-processor on Exynos850 SoCs.
>>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++++++++
>
> What DTS is doing in the middle of the patchset? If there is going to be
> resend, then fix the order. If the order is intended, then most likely
> NAK but I need somewhere explanation (but I really do not see the need
> for it).
>
> Please read submitting patches (both documents).
The dts change goes last in this series, the commit 3 out of 3.
There is no DTS changes in the middle of the patchset as far as I can
trust my eyes.
If the order in this series is NACK, please explain why.
I suspect that potential confusion is because 2 clock patches from
prev series were accepted/merged, so dts change shifted from its 5th
place to 3-rd place.
BR,
Alexey.
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: exynos850: Add ap2apm mailbox
From: Krzysztof Kozlowski @ 2026-04-02 13:32 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <DHIPEQ4XDUI6.297HDXTP84FFP@linaro.org>
On 02/04/2026 15:30, Alexey Klimov wrote:
> On Thu Apr 2, 2026 at 9:01 AM BST, Krzysztof Kozlowski wrote:
>> On Thu, Apr 02, 2026 at 03:20:16AM +0100, Alexey Klimov wrote:
>>> Add mailbox node that describes AP-to-APM mailbox, that can be
>>> used for communicating with APM co-processor on Exynos850 SoCs.
>>>
>>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++++++++
>>
>> What DTS is doing in the middle of the patchset? If there is going to be
>> resend, then fix the order. If the order is intended, then most likely
>> NAK but I need somewhere explanation (but I really do not see the need
>> for it).
>>
>> Please read submitting patches (both documents).
>
> The dts change goes last in this series, the commit 3 out of 3.
> There is no DTS changes in the middle of the patchset as far as I can
> trust my eyes.
>
> If the order in this series is NACK, please explain why.
> I suspect that potential confusion is because 2 clock patches from
> prev series were accepted/merged, so dts change shifted from its 5th
> place to 3-rd place.
Oops, It is at the end! mutt does not order them by default when loaded
via b4, so it appeared in the middle and I did not pay attention enough.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Marc Zyngier @ 2026-04-02 13:35 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
Sebastian Ene
Cc: catalin.marinas, joey.gouly, mark.rutland, oupton, suzuki.poulose,
tabba, vdonnefort, will, yuzenghui
In-Reply-To: <20260330105441.3226904-1-sebastianene@google.com>
On Mon, 30 Mar 2026 10:54:41 +0000, Sebastian Ene wrote:
> The ARM Service Calling Convention (SMCCC) specifies that the function
> identifier and parameters should be passed in registers, leaving the
> 16-bit immediate field un-handled in pKVM when an SMC instruction is
> trapped.
> Since the HVC is a private interface between EL2 and the host,
> enforce the host kernel running under pKVM to use an immediate value
> of 0 only when using SMCs to make it clear for non-compliant software
> talking to Trustzone that we only use SMCCC.
>
> [...]
Applied to next, thanks!
[1/1] KVM: arm64: Prevent the host from using an smc with imm16 != 0
commit: cf6348af645bd8e38758114e6afcc406c5bb515f
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ 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