* Re: [PATCH] iio: adc: meson-saradc: fix calibration buffer leak on error
From: Felix Gu @ 2026-04-26 15:26 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Rosen Penev, David Lechner, Nuno Sá, Andy Shevchenko,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-iio, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260426114118.7ad8b130@jic23-huawei>
On Sun, Apr 26, 2026 at 6:41 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> That is the minimal fix, so we should probably do that first
> even if we then circle back to consider if __free() magic is worth using here.
>
> J
Hi Jonathan,
You prefer a minimal fix here?
Best regards,
Felix
^ permalink raw reply
* [PATCH v4 1/1] crypto: atmel-sha204a - fix non-blocking read logic
From: Lothar Rubusch @ 2026-04-26 15:49 UTC (permalink / raw)
To: herbert, thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260426154940.24375-1-l.rubusch@gmail.com>
The blocking and non-blocking paths were failing to provide valid entropy
due to improper buffer management. Read the buffer starting from bit 1,
only fetch the 32 bytes of random data of the return message.
Tested on a Atmel SHA204a device.
Before (here for blocking) tests showed repeadetly reading reduced bytes of
entropy:
$ head -c 32 /dev/hwrng | hexdump -C
00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
After, the result will be similar to the following:
$ head -c 32 /dev/hwrng | hexdump -C
00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
00000020
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-sha204a.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index dbb39ed0cea1..39a229086a84 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -48,8 +48,8 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
if (rng->priv) {
work_data = (struct atmel_i2c_work_data *)rng->priv;
- max = min(sizeof(work_data->cmd.data), max);
- memcpy(data, &work_data->cmd.data, max);
+ max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
+ memcpy(data, &work_data->cmd.data[1], max);
rng->priv = 0;
} else {
work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
@@ -87,8 +87,8 @@ static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
if (ret)
return ret;
- max = min(sizeof(cmd.data), max);
- memcpy(data, cmd.data, max);
+ max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
+ memcpy(data, &cmd.data[1], max);
return max;
}
--
2.39.5
^ permalink raw reply related
* [PATCH v4 0/1] crypto: atmel-sha204a - multiple RNG fixes
From: Lothar Rubusch @ 2026-04-26 15:49 UTC (permalink / raw)
To: herbert, thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
When testing the RNG functionality on the Atmel SHA204a hardware, rngtest
reported failures. Fix start of reading and size of fetched data.
I verified and applied Ard's solution (tagged it with sugtgested-by, pls
tell me if I used the wrong tag).
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
v3 -> v4: Reduce seet and set focus on RNG fix, blocking and nonblocking
v2 -> v3: Removal blank line, rebased
v1 -> v2: Removal of C++ style comment
---
Lothar Rubusch (1):
crypto: atmel-sha204a - fix non-blocking read logic
drivers/crypto/atmel-sha204a.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
base-commit: 5db6ef9847717329f12c5ea8aba7e9f588a980c0
--
2.39.5
^ permalink raw reply
* Re: [PATCH v3 1/3] crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
From: Lothar Rubusch @ 2026-04-26 16:16 UTC (permalink / raw)
To: Thorsten Blum
Cc: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <ae4UD-JGUarmSMiK@linux.dev>
Hi Thorsten and Ard & ML,
This is just two general questions on some details of this driver.
Perhaps you could
give me some insights here.
On Sun, Apr 26, 2026 at 3:33 PM Thorsten Blum <thorsten.blum@linux.dev> wrote:
>
> On Wed, Apr 22, 2026 at 09:09:34PM +0000, Lothar Rubusch wrote:
> > The driver allocated memory for work_data in the non-blocking read
> > path but never free'd it again.
>
> Yes, 'work_data' is allocated once on the first nonblocking RNG request
> and reused for subsequent requests, but the memory is eventually freed
> on device removal in atmel_sha204a_remove().
>
> The memory might be retained unnecessarily after use when the device is
> idle (probably negligible), but it's not a memory leak.
>
> Best,
> Thorsten
1. Actually, having `work_data` allocated once/rarely and usually re-used.
Stupid question: could it be allocated also with managed device memory? I
usually use devm_ allocs rather in probe for related general instances,
here I'm a bit in doubt. Could it be used here as well, or why not?
2. In `atmel_sha204a_rng_read()` there is the function variable
`struct atmel_i2c_cmd cmd;`.
AFAIR allocation on the heap is preferable to stack variables, particularly
for structs and any non-primitive types. So, wouldn't it be better to have
`*cmd` as a pointer, dynamically allocate memory at the beginning of this
function and free it at the end of this function again?
Best,
L
^ permalink raw reply
* Re: [PATCH v4 1/1] crypto: atmel-sha204a - fix non-blocking read logic
From: Thorsten Blum @ 2026-04-26 16:43 UTC (permalink / raw)
To: Lothar Rubusch
Cc: herbert, davem, nicolas.ferre, alexandre.belloni, claudiu.beznea,
ardb, linusw, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260426154940.24375-2-l.rubusch@gmail.com>
On Sun, Apr 26, 2026 at 03:49:40PM +0000, Lothar Rubusch wrote:
> The blocking and non-blocking paths were failing to provide valid entropy
> due to improper buffer management. Read the buffer starting from bit 1,
> only fetch the 32 bytes of random data of the return message.
>
> Tested on a Atmel SHA204a device.
>
> Before (here for blocking) tests showed repeadetly reading reduced bytes of
s/repeadetly/repeatedly/
> entropy:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020
>
> After, the result will be similar to the following:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> 00000020
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
> Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index dbb39ed0cea1..39a229086a84 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -48,8 +48,8 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
>
> if (rng->priv) {
> work_data = (struct atmel_i2c_work_data *)rng->priv;
> - max = min(sizeof(work_data->cmd.data), max);
> - memcpy(data, &work_data->cmd.data, max);
> + max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
> + memcpy(data, &work_data->cmd.data[1], max);
Please use RSP_DATA_IDX instead of 1 as the index.
> rng->priv = 0;
> } else {
> work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
> @@ -87,8 +87,8 @@ static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
> if (ret)
> return ret;
>
> - max = min(sizeof(cmd.data), max);
> - memcpy(data, cmd.data, max);
> + max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
> + memcpy(data, &cmd.data[1], max);
Same here.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH RFC v2 1/2] arm64: vdso: Prepare for robust futex unlock support
From: Thomas Weißschuh @ 2026-04-26 18:07 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, linux-arm-kernel, linux-kernel,
linux-arch, kernel-dev
In-Reply-To: <20260424-tonyk-robust_arm-v2-1-db4e46f752cf@igalia.com>
Hi André,
Some more comments, after doing an actual proper review.
On 2026-04-24 15:56:00-0300, André Almeida wrote:
> There will be a VDSO function to unlock non-contended robust futexes in
> user space. The unlock sequence is racy vs. clearing the list_pending_op
> pointer in the task's robust list head. To plug this race the kernel needs
> to know the critical section window so it can clear the pointer when the
> task is interrupted within that race window. The window is determined by
> labels in the inline assembly.
>
> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
> Changes from v1:
> - Fixed linker not finding VDSO symbols
> ---
> arch/arm64/kernel/vdso.c | 30 ++++++++++++++++++++++++++++++
> arch/arm64/kernel/vdso/vdso.lds.S | 7 +++++++
> 2 files changed, 37 insertions(+)
What is the reason for splitting the series into two patches?
To me it looks like it should be one patch.
> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index 592dd8668de4..f9c520a1c942 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -11,6 +11,7 @@
> #include <linux/clocksource.h>
> #include <linux/elf.h>
> #include <linux/err.h>
> +#include <linux/futex.h>
> #include <linux/errno.h>
> #include <linux/gfp.h>
> #include <linux/kernel.h>
> @@ -57,6 +58,33 @@ static struct vdso_abi_info vdso_info[] __ro_after_init = {
> #endif /* CONFIG_COMPAT_VDSO */
> };
>
> +#ifdef CONFIG_FUTEX_ROBUST_UNLOCK
> +static void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm)
> +{
> + unsigned long vdso = (unsigned long) mm->context.vdso;
> + struct futex_mm_data *fd = &mm->futex;
> + uintptr_t success, end;
> +
> + if (abi == VDSO_ABI_AA64) {
> + success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_success);
> + end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_end);
> +
> + futex_set_vdso_cs_range(fd, 0, vdso, success, end, false);
Both VDSO_SYMBOL() and futex_set_vdso_cs_range() add the vdso base
address to the symbol offsets. The value stored in .start_ip will be
wrong. The fact that futex_set_vdso_cs_range() does the addition looks
like an artifact of it being written for x86 first. IMO its interface
should be changed not to do the addition internally.
> + }
> +
> +#ifdef CONFIG_COMPAT_VDSO
> + if (abi == VDSO_ABI_AA32) {
> + success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_success);
> + end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_end);
> +
> + futex_set_vdso_cs_range(fd, 1, vdso, success, end, true);
> + }
> +#endif
> +}
> +#else
> +static inline void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm) { }
> +#endif /* CONFIG_FUTEX_ROBUST_UNLOCK */
> +
> static int vdso_mremap(const struct vm_special_mapping *sm,
> struct vm_area_struct *new_vma)
> {
(...)
^ permalink raw reply
* Re: [PATCH RFC v2 2/2] arm64: vdso: Implement __vdso_futex_robust_try_unlock()
From: Thomas Weißschuh @ 2026-04-26 18:30 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, linux-arm-kernel, linux-kernel,
linux-arch, kernel-dev
In-Reply-To: <20260424-tonyk-robust_arm-v2-2-db4e46f752cf@igalia.com>
On 2026-04-24 15:56:01-0300, André Almeida wrote:
(...)
> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
> RFC:
> - Should I duplicate the explanation found in the x86 commit or can I just
> point to it?
> - Only LL/SC for now but I can add LSE later if this looks good
> - It the objdump I see that op_pending is store at x2. But how stable is this,
> how can I write it in a way that's always x2?
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/futex_robust.h | 35 +++++++++++++
> arch/arm64/kernel/vdso/Makefile | 9 +++-
> arch/arm64/kernel/vdso/vdso.lds.S | 4 ++
> .../kernel/vdso/vfutex_robust_list_try_unlock.c | 59 ++++++++++++++++++++++
> 5 files changed, 107 insertions(+), 1 deletion(-)
What about the actual 32-bit vDSO in arch/arm64/kernel/vdso32/ ?
(...)
> diff --git a/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
> new file mode 100644
> index 000000000000..e8a8fb22a2fa
> --- /dev/null
> +++ b/arch/arm64/kernel/vdso/vfutex_robust_list_try_unlock.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +#include <vdso/futex.h>
> +#include <linux/stringify.h>
> +
> +#define LABEL(name, sz) __stringify(__futex_list##sz##_try_unlock_cs_##name)
We should have some defines for these symbols. While they are not
userspace ABI, they will be used by the selftests.
> +#define GLOBLS(sz) ".globl " LABEL(start, sz) ", " LABEL(success, sz) ", " LABEL(end, sz) "\n"
> +
> +__u32 __vdso_futex_robust_list64_try_unlock(__u32 *lock, __u32 tid, __u64 *pop)
> +{
> + __u32 val, result;
> +
> + asm volatile (
> + GLOBLS(64)
> + " prfm pstl1strm, %[lock] \n"
> + LABEL(start, 64)": \n"
> + " ldxr %[val], %[lock] \n"
> + " cmp %[tid], %[val] \n"
> + " bne " LABEL(end, 64)" \n"
> + " stlxr %w[result], xzr, %[lock] \n"
> + " cbnz %w[result], " LABEL(start, 64)" \n"
> + LABEL(success, 64)": \n"
> + " str xzr, %[pop] \n"
> + LABEL(end, 64)": \n"
> +
> + : [val] "=&r" (val), [result] "=r" (result)
> + : [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
> + : "memory"
> + );
My clang 22.1.3 chokes on the assembly in this patch.
> +
> + return val;
> +}
> +
> +#ifdef CONFIG_COMPAT_VDSO
I am wondering about the CONFIG_COMPAT{,_VDSO} dependency here.
As far as I know the list32 variant is meant to be used by code
emulators which run 32-bit code on a 64-bit kernel, for example FEX.
But these emulators don't actually seem to need CONFIG_COMPAT.
So the dependency does not look correct.
The space savings also should be irrelevant.
The x86 series from Thomas does the same, maybe he will read this
comment, otherwise I'll bring it up on his series, too.
> +__u32 __vdso_futex_robust_list32_try_unlock(__u32 *lock, __u32 tid, __u32 *pop)
> +{
> + __u32 val, result;
> +
> + asm volatile (
> + GLOBLS(32)
> + " prfm pstl1strm, %[lock] \n"
> + LABEL(start, 32)": \n"
> + " ldxr %w[val], %[lock] \n"
> + " cmp %w[tid], %w[val] \n"
> + " bne " LABEL(end, 32)" \n"
> + " stlxr %w[result], wzr, %w[lock] \n"
> + " cbnz %w[result], " LABEL(start, 32)" \n"
> + LABEL(success, 32)": \n"
> + " str wzr, %w[pop] \n"
> + LABEL(end, 32)": \n"
> +
> + : [val] "=&r" (val), [result] "=r" (result)
> + : [tid] "r" (tid), [lock] "Q" (*lock), [pop] "Q" (*pop)
> + : "memory"
> + );
> +
> + return val;
> +}
> +#endif
^ permalink raw reply
* Re: [PATCH RFC v2 1/2] arm64: vdso: Prepare for robust futex unlock support
From: Thomas Weißschuh @ 2026-04-26 19:04 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, linux-arm-kernel, linux-kernel,
linux-arch, kernel-dev
In-Reply-To: <20260424-tonyk-robust_arm-v2-1-db4e46f752cf@igalia.com>
One more thing, sorry for the spam.
On 2026-04-24 15:56:00-0300, André Almeida wrote:
(...)
> +#ifdef CONFIG_FUTEX_ROBUST_UNLOCK
> +static void vdso_futex_robust_unlock_update_ips(enum vdso_abi abi, struct mm_struct *mm)
> +{
> + unsigned long vdso = (unsigned long) mm->context.vdso;
> + struct futex_mm_data *fd = &mm->futex;
> + uintptr_t success, end;
> +
> + if (abi == VDSO_ABI_AA64) {
> + success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_success);
> + end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list64_try_unlock_cs_end);
> +
> + futex_set_vdso_cs_range(fd, 0, vdso, success, end, false);
> + }
> +
> +#ifdef CONFIG_COMPAT_VDSO
> + if (abi == VDSO_ABI_AA32) {
> + success = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_success);
> + end = (uintptr_t) VDSO_SYMBOL(vdso, futex_list32_try_unlock_cs_end);
The futex_list32_ symbols here are in the 64-bit vDSO. They are not
applicable for VDSO_ABI_AA32 processes.
> +
> + futex_set_vdso_cs_range(fd, 1, vdso, success, end, true);
> + }
> +#endif
> +}
(...)
^ permalink raw reply
* Re: [PATCH 3/3] spi: rockchip: Drop dead zero-check on fifo_len
From: Mark Brown @ 2026-04-26 20:36 UTC (permalink / raw)
To: John Madieu
Cc: heiko, jon.lin, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260425092936.2590132-4-john.madieu@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
On Sat, Apr 25, 2026 at 09:29:36AM +0000, John Madieu wrote:
> rs->fifo_len is assigned from get_fifo_len(), which returns 64 for the
> two known SPI controller versions and 32 for everything else - never 0.
> The subsequent
> if (!rs->fifo_len)
> return dev_err_probe(...);
> is therefore unreachable.
> Drop the check. If unknown controller versions ever need to fail probe
> explicitly, that should be expressed in get_fifo_len() itself, not
> through an impossible post-condition.
That looks like it's intended as a "you added a new hardware type and
forgot to fill in this field" type check intended to never fire in
production?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] firmware: samsung: fix stale response flag in acpm_prepare_xfer()
From: Titouan Ameline de Cadeville @ 2026-04-26 21:02 UTC (permalink / raw)
To: tudor.ambarus
Cc: krzk, alim.akhtar, linux-kernel, linux-samsung-soc,
linux-arm-kernel, Titouan Ameline de Cadeville
acpm_prepare_xfer() only ever set rx_data->response to true, never
false. A reused sequence number slot could therefore inherit a stale
true from a previous transfer that expected a response, causing
acpm_get_rx() to enter the response-copy path for a fire-and-forget
transfer whose rxd is NULL.
Unconditionally assign the correct boolean value so the slot is fully
reset on every reuse.
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Signed-off-by: Titouan Ameline de Cadeville <titouan.ameline@gmail.com>
---
drivers/firmware/samsung/exynos-acpm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index 16c46ed60837..2fee6bb60efc 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -380,8 +380,7 @@ static void acpm_prepare_xfer(struct acpm_chan *achan,
/* Clear data for upcoming responses */
rx_data = &achan->rx_data[achan->seqnum - 1];
memset(rx_data->cmd, 0, sizeof(*rx_data->cmd) * rx_data->n_cmd);
- if (xfer->rxd)
- rx_data->response = true;
+ rx_data->response = !!xfer->rxd;
/* Flag the index based on seqnum. (seqnum: 1~63, bitmap: 0~62) */
set_bit(achan->seqnum - 1, achan->bitmap_seqnum);
--
2.44.2
^ permalink raw reply related
* Re: [PATCH 3/3] spi: rockchip: Drop dead zero-check on fifo_len
From: Mark Brown @ 2026-04-26 21:03 UTC (permalink / raw)
To: john madieu
Cc: heiko, jon.lin, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <CAM9Qs9B8SSGXrR47toj9P+_EUHzrwKwHnu9askVhGxm9WFzQCQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
On Sun, Apr 26, 2026 at 10:57:31PM +0200, john madieu wrote:
> Le dim. 26 avr. 2026 à 22:36, Mark Brown <broonie@kernel.org> a écrit :
> > That looks like it's intended as a "you added a new hardware type and
> > forgot to fill in this field" type check intended to never fire in
> > production?
> Yes, that's a fair reading. I missed that angle.
> Should I drop this patch and resend the series (v2) with just 1/3 and 2/3 ?
No need to resend.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2 0/3]: fix unnecessary includes and add missing ones across multiple drivers
From: Caio Morais @ 2026-04-26 21:17 UTC (permalink / raw)
To: andy, dlechner, jic23, michal.simek, nuno.sa
Cc: Caio Morais, linux-arm-kernel, linux-iio
From: Caio Morais <caiomorais@usp.br>
This series removes unnecessary includes and adds missing ones as reported
by the include-what-you-use (IWYU) tool across different IIO drivers.
Caio Morais (3):
iio: adc: xilinx-xadc: remove unnecessary includes and add missing
ones
iio: buffer: industrialio-triggered-buffer: fix includes with IWYU
iio: common: st_sensors: fix includes with IWYU
drivers/iio/adc/xilinx-xadc-events.c | 6 +++++-
drivers/iio/buffer/industrialio-triggered-buffer.c | 6 ++++--
drivers/iio/common/st_sensors/st_sensors_i2c.c | 7 +++++--
drivers/iio/common/st_sensors/st_sensors_spi.c | 9 +++++++--
4 files changed, 21 insertions(+), 7 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH 1/3] iio: adc: xilinx-xadc: remove unnecessary includes and add missing ones
From: Caio Morais @ 2026-04-26 21:18 UTC (permalink / raw)
To: andy, dlechner, jic23, michal.simek, nuno.sa
Cc: Caio Morais, linux-arm-kernel, linux-iio
In-Reply-To: <20260426211834.3318306-1-caiomorais@usp.br>
From: Caio Morais <caiomorais@usp.br>
Signed-off-by: Caio Morais <caiomorais@usp.br>
---
drivers/iio/adc/xilinx-xadc-events.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/xilinx-xadc-events.c b/drivers/iio/adc/xilinx-xadc-events.c
index c188d3dca..31cda8e69 100644
--- a/drivers/iio/adc/xilinx-xadc-events.c
+++ b/drivers/iio/adc/xilinx-xadc-events.c
@@ -6,9 +6,13 @@
* Author: Lars-Peter Clausen <lars@metafoo.de>
*/
+#include <linux/bitmap.h>
+#include <linux/errno.h>
+#include <linux/mutex.h>
+#include <linux/types.h>
+
#include <linux/iio/events.h>
#include <linux/iio/iio.h>
-#include <linux/kernel.h>
#include "xilinx-xadc.h"
--
2.54.0
^ permalink raw reply related
* [PATCH 2/3] iio: buffer: industrialio-triggered-buffer: fix includes with IWYU
From: Caio Morais @ 2026-04-26 21:18 UTC (permalink / raw)
To: andy, dlechner, jic23, michal.simek, nuno.sa
Cc: Caio Morais, linux-arm-kernel, linux-iio
In-Reply-To: <20260426211834.3318306-1-caiomorais@usp.br>
From: Caio Morais <caiomorais@usp.br>
Signed-off-by: Caio Morais <caiomorais@usp.br>
---
drivers/iio/buffer/industrialio-triggered-buffer.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/buffer/industrialio-triggered-buffer.c b/drivers/iio/buffer/industrialio-triggered-buffer.c
index 9bf75dee7..a91d439d7 100644
--- a/drivers/iio/buffer/industrialio-triggered-buffer.c
+++ b/drivers/iio/buffer/industrialio-triggered-buffer.c
@@ -4,9 +4,11 @@
* Author: Lars-Peter Clausen <lars@metafoo.de>
*/
-#include <linux/kernel.h>
-#include <linux/export.h>
+#include <linux/errno.h>
+#include <linux/linkage.h>
#include <linux/module.h>
+#include <linux/stddef.h>
+
#include <linux/iio/iio.h>
#include <linux/iio/buffer.h>
#include <linux/iio/buffer_impl.h>
--
2.54.0
^ permalink raw reply related
* [PATCH 3/3] iio: common: st_sensors: fix includes with IWYU
From: Caio Morais @ 2026-04-26 21:18 UTC (permalink / raw)
To: andy, dlechner, jic23, michal.simek, nuno.sa
Cc: Caio Morais, linux-arm-kernel, linux-iio
In-Reply-To: <20260426211834.3318306-1-caiomorais@usp.br>
From: Caio Morais <caiomorais@usp.br>
Signed-off-by: Caio Morais <caiomorais@usp.br>
---
drivers/iio/common/st_sensors/st_sensors_i2c.c | 7 +++++--
drivers/iio/common/st_sensors/st_sensors_spi.c | 9 +++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/common/st_sensors/st_sensors_i2c.c b/drivers/iio/common/st_sensors/st_sensors_i2c.c
index 7156302fe..04d106def 100644
--- a/drivers/iio/common/st_sensors/st_sensors_i2c.c
+++ b/drivers/iio/common/st_sensors/st_sensors_i2c.c
@@ -7,12 +7,15 @@
* Denis Ciocca <denis.ciocca@st.com>
*/
+#include <linux/device.h>
+#include <linux/err.h>
#include <linux/i2c.h>
-#include <linux/kernel.h>
+#include <linux/linkage.h>
#include <linux/module.h>
-#include <linux/iio/iio.h>
#include <linux/regmap.h>
+#include <linux/iio/iio.h>
+
#include <linux/iio/common/st_sensors_i2c.h>
#define ST_SENSORS_I2C_MULTIREAD 0x80
diff --git a/drivers/iio/common/st_sensors/st_sensors_spi.c b/drivers/iio/common/st_sensors/st_sensors_spi.c
index 0da270139..884077d51 100644
--- a/drivers/iio/common/st_sensors/st_sensors_spi.c
+++ b/drivers/iio/common/st_sensors/st_sensors_spi.c
@@ -7,12 +7,17 @@
* Denis Ciocca <denis.ciocca@st.com>
*/
-#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/linkage.h>
#include <linux/module.h>
-#include <linux/iio/iio.h>
#include <linux/property.h>
#include <linux/regmap.h>
#include <linux/spi/spi.h>
+#include <linux/stddef.h>
+#include <linux/types.h>
+
+#include <linux/iio/iio.h>
#include <linux/iio/common/st_sensors_spi.h>
--
2.54.0
^ permalink raw reply related
* [PATCH v5 0/1] crypto: atmel-sha204a - multiple RNG fixes
From: Lothar Rubusch @ 2026-04-26 21:29 UTC (permalink / raw)
To: herbert, thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
When testing the RNG functionality on the Atmel SHA204a hardware, rngtest
reported failures. Fix start of reading and size of fetched data.
I verified and applied Ard's solution (tagged it with sugtgested-by, pls
tell me if I used the wrong tag).
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
v3 -> v4: rephrase commit title; fix typos in commit message;
replace index literal by `RSP_DATA_IDX`
v3 -> v4: Reduce seet and set focus on RNG fix, blocking and nonblocking
v2 -> v3: Removal blank line, rebased
v1 -> v2: Removal of C++ style comment
---
Lothar Rubusch (1):
crypto: atmel-sha204a - fix blocking and non-blocking rng logic
drivers/crypto/atmel-sha204a.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
base-commit: 5db6ef9847717329f12c5ea8aba7e9f588a980c0
--
2.53.0
^ permalink raw reply
* [PATCH v5 1/1] crypto: atmel-sha204a - fix blocking and non-blocking rng logic
From: Lothar Rubusch @ 2026-04-26 21:29 UTC (permalink / raw)
To: herbert, thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260426212947.24757-1-l.rubusch@gmail.com>
The blocking and non-blocking paths were failing to provide valid entropy
due to improper buffer management. Reading the buffer starting from byte 1,
only fetch the 32 bytes of random data from the return message.
Tested on an Atmel SHA204A device.
Before (here for blocking), tests showed repeatedly reading reduced bytes.
$ head -c 32 /dev/hwrng | hexdump -C
00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
After, the result will be similar to the following:
$ head -c 32 /dev/hwrng | hexdump -C
00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
00000020
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-sha204a.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index dbb39ed0cea1..5699bb532325 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -48,8 +48,8 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
if (rng->priv) {
work_data = (struct atmel_i2c_work_data *)rng->priv;
- max = min(sizeof(work_data->cmd.data), max);
- memcpy(data, &work_data->cmd.data, max);
+ max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
+ memcpy(data, &work_data->cmd.data[RSP_DATA_IDX], max);
rng->priv = 0;
} else {
work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
@@ -87,8 +87,8 @@ static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
if (ret)
return ret;
- max = min(sizeof(cmd.data), max);
- memcpy(data, cmd.data, max);
+ max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
+ memcpy(data, &cmd.data[RSP_DATA_IDX], max);
return max;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2] serial: mxs-auart: replace hardcoded 1 with predefined macro GPIO_LINE_DIRECTION_IN
From: Nikola Z. Ivanov @ 2026-04-26 21:42 UTC (permalink / raw)
To: gregkh, jirislaby, Frank.Li, s.hauer, kernel, festevam
Cc: linux-kernel, linux-serial, imx, linux-arm-kernel,
Nikola Z. Ivanov
The GPIO_LINE_DIRECTION_* definitions have just recently been exposed to
gpio consumers.h by breaking them out in a separate defs.h file.
Use this to validate the gpio direction instead of the hard-coded literal.
Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
---
Changes since v1:
- Commit title change
https://lore.kernel.org/all/26cd0656-ca76-4cb7-9f1e-b8c042a7e2cb@gmail.com/
drivers/tty/serial/mxs-auart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 693b491f1e75..697318dbb146 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1520,7 +1520,7 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, struct device *dev)
for (i = 0; i < UART_GPIO_MAX; i++) {
gpiod = mctrl_gpio_to_gpiod(s->gpios, i);
- if (gpiod && (gpiod_get_direction(gpiod) == 1))
+ if (gpiod && (gpiod_get_direction(gpiod) == GPIO_LINE_DIRECTION_IN))
s->gpio_irq[i] = gpiod_to_irq(gpiod);
else
s->gpio_irq[i] = -EINVAL;
--
2.53.0
^ permalink raw reply related
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-26 22:04 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Mathias Stearn, Dmitry Vyukov, Jinjie Ruan, linux-man,
Mark Rutland, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Blake Oler,
Dmitry Vyukov, Florian Weimer, Rich Felker, Matthew Wilcox,
Greg Kroah-Hartman, Linus Torvalds
In-Reply-To: <87se8kywhb.ffs@tglx>
On Fri, Apr 24 2026 at 21:44, Thomas Gleixner wrote:
> On Fri, Apr 24 2026 at 17:03, Peter Zijlstra wrote:
>> On Fri, Apr 24, 2026 at 04:16:08PM +0200, Thomas Gleixner wrote:
>>> > I was really hoping that we would only need to do the "redundant"
>>> > cpu_id_start writes would only be needed on membarrier_rseq IPIs where
>>> > it really is a pay-for-what-you-use functionality,
>>>
>>> That's fine and can be solved without adding this sequence overhead into
>>> the scheduler hotpath.
>>
>> Something like so? (probably needs help for !GENERIC bits)
>
> Yes and yes :)
>
> Let me stare at that !generic tif bits case.
I stared at it and finally gave up because all of this is in a
completely FUBAR'ed state and ends up in a horrible pile of hacks and
duct tape with a way larger than zero probability that we chase the
nasty corner cases for quite some time just to add more duct tape and
hacks.
Contrary to that it's rather trivial to cleanly separate the behavioral
cases and guarantees without a masssive runtime overhead and without a
pile of hard to maintain TCMalloc specific hacks.
All required code is already available to support the architectures
which do not utilize the generic entry code and therefore can't neither
use the optimized mode nor time slice extensions. So instead of letting
the compiler optimize that code out for the generic entry code users, we
can keep it around and utilize one or the other depending on the
requested mode. I managed to get the required run-time conditionals down
to a minimum so that they are in the noise when analysing it with perf.
The real question is how to differentiate between the legacy and the
optimized mode. I have two working variants to achieve that:
1) The fully safe option requires a new flag for RSEQ
registration. It obviously requires a glibc update. (Suggested by
PeterZ)
2) Determine the requirements of the registering task via the size of
the registered RSEQ area.
The original implementation, which TCMalloc depends on, registers
a 32 byte region (ORIG_RSEG_SIZE). This region has 32 byte
alignment requirement.
The extension safe newer variant exposes the kernel RSEQ feature
size via getauxval(AT_RSEQ_FEATURE_SIZE) and the alignment
requirement via getauxval(AT_RSEQ_ALIGN). The alignment
requirement is that the registered rseq region is aligned to the
next power of two of the feature size. The kernel currently has a
feature size of 33 bytes, which means the alignment requirement is
64 bytes.
The TCMalloc RSEQ region is embedded into a cache line aligned
data structure starting at offset 32 bytes so that bytes 28-31 and
the cpu_id_start field at bytes 32-35 form a 64-bit little endian
pointer with the top-most bit (63 set) to check whether the kernel
has overwritten cpu_id_start with an actual CPU id value, which is
guaranteed to not have the top most bit set.
As this is part of their performance tuned magic, it's a pretty
safe assumption, that TCMalloc won't use a larger RSEQ size, which
allows to select optimized mode for registrations with a size
greater than 32 bytes.
That does not require any changes to glibc and works out of the
box. (Suggested by Mathieu)
In both cases the legacy non-optimized mode exposes the original
behaviour up to the mm_cid field and does not provide support for time
slice extensions. Optimized mode restores the performance gains and
enables support for time slice extensions.
I have no strong preference either way and have working code for both
variants. Though obviously avoiding to update the libc world has a
charme. If that unexpectedly would turn out to be not sufficient, then
disabling that would be a trivial one-liner and as a consequence require
to add the flag and update the libc world.
Combo patch for the auto-detection based on the registered size below as
that allows to immediately test without glibc dependencies. It applies
cleanly on Linus tree and 7.0. 6.19 would need some fixups, but I
learned today that it's already EOL.
In the final version that's three separate patches plus a set of
selftest changes which validate legacy behaviour and run the full param
test suite in both legacy and optimized mode.
Thoughts, preferences?
Thanks,
tglx
---
Documentation/userspace-api/rseq.rst | 77 ++++++++++++++
include/linux/rseq.h | 20 +++
include/linux/rseq_entry.h | 110 ++++++++++-----------
include/linux/rseq_types.h | 3
kernel/rseq.c | 183 ++++++++++++++++++++++-------------
kernel/sched/membarrier.c | 11 +-
6 files changed, 280 insertions(+), 124 deletions(-)
---
--- a/include/linux/rseq.h
+++ b/include/linux/rseq.h
@@ -9,6 +9,11 @@
void __rseq_handle_slowpath(struct pt_regs *regs);
+static __always_inline bool rseq_optimized(struct task_struct *t)
+{
+ return IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY) && likely(t->rseq.event.optimized);
+}
+
/* Invoked from resume_user_mode_work() */
static inline void rseq_handle_slowpath(struct pt_regs *regs)
{
@@ -30,7 +35,7 @@ void __rseq_signal_deliver(int sig, stru
*/
static inline void rseq_signal_deliver(struct ksignal *ksig, struct pt_regs *regs)
{
- if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
+ if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY) && rseq_optimized(current)) {
/* '&' is intentional to spare one conditional branch */
if (current->rseq.event.has_rseq & current->rseq.event.user_irq)
__rseq_signal_deliver(ksig->sig, regs);
@@ -50,15 +55,21 @@ static __always_inline void rseq_sched_s
{
struct rseq_event *ev = &t->rseq.event;
- if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
+ /*
+ * Only apply the user_irq optimization for RSEQ ABI V2
+ * registrations. Legacy users like TCMalloc rely on the historical ABI
+ * V1 behaviour which updates IDs on every context swtich.
+ */
+ if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY) && rseq_optimized(t)) {
/*
* Avoid a boat load of conditionals by using simple logic
* to determine whether NOTIFY_RESUME needs to be raised.
*
* It's required when the CPU or MM CID has changed or
- * the entry was from user space.
+ * the entry was from user space. ev->has_rseq does not
+ * have to be evaluated because optimized implies has_rseq.
*/
- bool raise = (ev->user_irq | ev->ids_changed) & ev->has_rseq;
+ bool raise = ev->user_irq | ev->ids_changed;
if (raise) {
ev->sched_switch = true;
@@ -66,6 +77,7 @@ static __always_inline void rseq_sched_s
}
} else {
if (ev->has_rseq) {
+ t->rseq.event.ids_changed = true;
t->rseq.event.sched_switch = true;
rseq_raise_notify_resume(t);
}
--- a/include/linux/rseq_entry.h
+++ b/include/linux/rseq_entry.h
@@ -111,6 +111,20 @@ static __always_inline void rseq_slice_c
t->rseq.slice.state.granted = false;
}
+/*
+ * Open coded, so it can be invoked within a user access region.
+ *
+ * This clears the user space state of the time slice extensions field only when
+ * the task has registered the optimized RSEQ_ABI V2. Some legacy registrations,
+ * e.g. TCMalloc, have conflicting non-ABI fields in struct RSEQ, which would be
+ * overwritten by an unconditional write.
+ */
+#define rseq_slice_clear_user(rseq, efault) \
+do { \
+ if (rseq_slice_extension_enabled()) \
+ unsafe_put_user(0U, &rseq->slice_ctrl.all, efault); \
+} while (0)
+
static __always_inline bool __rseq_grant_slice_extension(bool work_pending)
{
struct task_struct *curr = current;
@@ -230,10 +244,10 @@ static __always_inline bool rseq_slice_e
static __always_inline bool rseq_arm_slice_extension_timer(void) { return false; }
static __always_inline void rseq_slice_clear_grant(struct task_struct *t) { }
static __always_inline bool rseq_grant_slice_extension(unsigned long ti_work, unsigned long mask) { return false; }
+#define rseq_slice_clear_user(rseq, efault) do { } while (0)
#endif /* !CONFIG_RSEQ_SLICE_EXTENSION */
bool rseq_debug_update_user_cs(struct task_struct *t, struct pt_regs *regs, unsigned long csaddr);
-bool rseq_debug_validate_ids(struct task_struct *t);
static __always_inline void rseq_note_user_irq_entry(void)
{
@@ -353,43 +367,6 @@ bool rseq_debug_update_user_cs(struct ta
return false;
}
-/*
- * On debug kernels validate that user space did not mess with it if the
- * debug branch is enabled.
- */
-bool rseq_debug_validate_ids(struct task_struct *t)
-{
- struct rseq __user *rseq = t->rseq.usrptr;
- u32 cpu_id, uval, node_id;
-
- /*
- * On the first exit after registering the rseq region CPU ID is
- * RSEQ_CPU_ID_UNINITIALIZED and node_id in user space is 0!
- */
- node_id = t->rseq.ids.cpu_id != RSEQ_CPU_ID_UNINITIALIZED ?
- cpu_to_node(t->rseq.ids.cpu_id) : 0;
-
- scoped_user_read_access(rseq, efault) {
- unsafe_get_user(cpu_id, &rseq->cpu_id_start, efault);
- if (cpu_id != t->rseq.ids.cpu_id)
- goto die;
- unsafe_get_user(uval, &rseq->cpu_id, efault);
- if (uval != cpu_id)
- goto die;
- unsafe_get_user(uval, &rseq->node_id, efault);
- if (uval != node_id)
- goto die;
- unsafe_get_user(uval, &rseq->mm_cid, efault);
- if (uval != t->rseq.ids.mm_cid)
- goto die;
- }
- return true;
-die:
- t->rseq.event.fatal = true;
-efault:
- return false;
-}
-
#endif /* RSEQ_BUILD_SLOW_PATH */
/*
@@ -504,12 +481,32 @@ bool rseq_set_ids_get_csaddr(struct task
{
struct rseq __user *rseq = t->rseq.usrptr;
- if (static_branch_unlikely(&rseq_debug_enabled)) {
- if (!rseq_debug_validate_ids(t))
- return false;
- }
-
scoped_user_rw_access(rseq, efault) {
+ /* Validate the R/O fields for debug and optimized mode */
+ if (static_branch_unlikely(&rseq_debug_enabled) || rseq_optimized(t)) {
+ u32 cpu_id, uval, node_id;
+
+ /*
+ * On the first exit after registering the rseq region CPU ID is
+ * RSEQ_CPU_ID_UNINITIALIZED and node_id in user space is 0!
+ */
+ node_id = t->rseq.ids.cpu_id != RSEQ_CPU_ID_UNINITIALIZED ?
+ cpu_to_node(t->rseq.ids.cpu_id) : 0;
+
+ unsafe_get_user(cpu_id, &rseq->cpu_id_start, efault);
+ if (cpu_id != t->rseq.ids.cpu_id)
+ goto die;
+ unsafe_get_user(uval, &rseq->cpu_id, efault);
+ if (uval != cpu_id)
+ goto die;
+ unsafe_get_user(uval, &rseq->node_id, efault);
+ if (uval != node_id)
+ goto die;
+ unsafe_get_user(uval, &rseq->mm_cid, efault);
+ if (uval != t->rseq.ids.mm_cid)
+ goto die;
+ }
+
unsafe_put_user(ids->cpu_id, &rseq->cpu_id_start, efault);
unsafe_put_user(ids->cpu_id, &rseq->cpu_id, efault);
unsafe_put_user(node_id, &rseq->node_id, efault);
@@ -517,11 +514,9 @@ bool rseq_set_ids_get_csaddr(struct task
if (csaddr)
unsafe_get_user(*csaddr, &rseq->rseq_cs, efault);
- /* Open coded, so it's in the same user access region */
- if (rseq_slice_extension_enabled()) {
- /* Unconditionally clear it, no point in conditionals */
- unsafe_put_user(0U, &rseq->slice_ctrl.all, efault);
- }
+ /* RSEQ ABI V2 only operations */
+ if (rseq_optimized(t))
+ rseq_slice_clear_user(rseq, efault);
}
rseq_slice_clear_grant(t);
@@ -530,6 +525,9 @@ bool rseq_set_ids_get_csaddr(struct task
rseq_stat_inc(rseq_stats.ids);
rseq_trace_update(t, ids);
return true;
+
+die:
+ t->rseq.event.fatal = true;
efault:
return false;
}
@@ -612,6 +610,14 @@ static __always_inline bool rseq_exit_us
* interrupts disabled
*/
guard(pagefault)();
+ /*
+ * This optimization is only valid when the task registered for the
+ * optimized RSEQ_ABI_V2 variant. Some legacy users rely on the original
+ * RSEQ implementation behaviour which unconditionally updated the IDs.
+ * rseq_sched_switch_event() ensures that legacy registrations always
+ * have both sched_switch and ids_changed set, which is compatible with
+ * the historical TIF_NOTIFY_RESUME behaviour.
+ */
if (likely(!t->rseq.event.ids_changed)) {
struct rseq __user *rseq = t->rseq.usrptr;
/*
@@ -623,11 +629,9 @@ static __always_inline bool rseq_exit_us
scoped_user_rw_access(rseq, efault) {
unsafe_get_user(csaddr, &rseq->rseq_cs, efault);
- /* Open coded, so it's in the same user access region */
- if (rseq_slice_extension_enabled()) {
- /* Unconditionally clear it, no point in conditionals */
- unsafe_put_user(0U, &rseq->slice_ctrl.all, efault);
- }
+ /* RSEQ ABI V2 only operations */
+ if (rseq_optimized(t))
+ rseq_slice_clear_user(rseq, efault);
}
rseq_slice_clear_grant(t);
--- a/include/linux/rseq_types.h
+++ b/include/linux/rseq_types.h
@@ -18,6 +18,7 @@ struct rseq;
* @ids_changed: Indicator that IDs need to be updated
* @user_irq: True on interrupt entry from user mode
* @has_rseq: True if the task has a rseq pointer installed
+ * @optimized: RSEQ ABI V2 optimized mode
* @error: Compound error code for the slow path to analyze
* @fatal: User space data corrupted or invalid
* @slowpath: Indicator that slow path processing via TIF_NOTIFY_RESUME
@@ -41,7 +42,7 @@ struct rseq_event {
};
u8 has_rseq;
- u8 __pad;
+ u8 optimized;
union {
u16 error;
struct {
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -258,11 +258,15 @@ static bool rseq_handle_cs(struct task_s
static void rseq_slowpath_update_usr(struct pt_regs *regs)
{
/*
- * Preserve rseq state and user_irq state. The generic entry code
- * clears user_irq on the way out, the non-generic entry
- * architectures are not having user_irq.
- */
- const struct rseq_event evt_mask = { .has_rseq = true, .user_irq = true, };
+ * Preserve has_rseq, optimized and user_irq state. The generic entry
+ * code clears user_irq on the way out, the non-generic entry
+ * architectures are not setting user_irq.
+ */
+ const struct rseq_event evt_mask = {
+ .has_rseq = true,
+ .user_irq = true,
+ .optimized = true,
+ };
struct task_struct *t = current;
struct rseq_ids ids;
u32 node_id;
@@ -335,8 +339,9 @@ void __rseq_handle_slowpath(struct pt_re
void __rseq_signal_deliver(int sig, struct pt_regs *regs)
{
rseq_stat_inc(rseq_stats.signal);
+
/*
- * Don't update IDs, they are handled on exit to user if
+ * Don't update IDs yet, they are handled on exit to user if
* necessary. The important thing is to abort a critical section of
* the interrupted context as after this point the instruction
* pointer in @regs points to the signal handler.
@@ -349,6 +354,13 @@ void __rseq_signal_deliver(int sig, stru
current->rseq.event.error = 0;
force_sigsegv(sig);
}
+
+ /*
+ * In legacy mode, force the update of IDs before returning to user
+ * space to stay compatible.
+ */
+ if (!rseq_optimized(current))
+ rseq_force_update();
}
/*
@@ -404,66 +416,19 @@ static bool rseq_reset_ids(void)
/* The original rseq structure size (including padding) is 32 bytes. */
#define ORIG_RSEQ_SIZE 32
-/*
- * sys_rseq - setup restartable sequences for caller thread.
- */
-SYSCALL_DEFINE4(rseq, struct rseq __user *, rseq, u32, rseq_len, int, flags, u32, sig)
+static long rseq_register(struct rseq __user * rseq, u32 rseq_len, int flags, u32 sig)
{
+ bool optimized = IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY) && rseq_len > ORIG_RSEQ_SIZE;
u32 rseqfl = 0;
- if (flags & RSEQ_FLAG_UNREGISTER) {
- if (flags & ~RSEQ_FLAG_UNREGISTER)
- return -EINVAL;
- /* Unregister rseq for current thread. */
- if (current->rseq.usrptr != rseq || !current->rseq.usrptr)
- return -EINVAL;
- if (rseq_len != current->rseq.len)
- return -EINVAL;
- if (current->rseq.sig != sig)
- return -EPERM;
- if (!rseq_reset_ids())
- return -EFAULT;
- rseq_reset(current);
- return 0;
- }
-
- if (unlikely(flags & ~(RSEQ_FLAG_SLICE_EXT_DEFAULT_ON)))
- return -EINVAL;
-
- if (current->rseq.usrptr) {
- /*
- * If rseq is already registered, check whether
- * the provided address differs from the prior
- * one.
- */
- if (current->rseq.usrptr != rseq || rseq_len != current->rseq.len)
- return -EINVAL;
- if (current->rseq.sig != sig)
- return -EPERM;
- /* Already registered. */
- return -EBUSY;
- }
-
- /*
- * If there was no rseq previously registered, ensure the provided rseq
- * is properly aligned, as communcated to user-space through the ELF
- * auxiliary vector AT_RSEQ_ALIGN. If rseq_len is the original rseq
- * size, the required alignment is the original struct rseq alignment.
- *
- * The rseq_len is required to be greater or equal to the original rseq
- * size. In order to be valid, rseq_len is either the original rseq size,
- * or large enough to contain all supported fields, as communicated to
- * user-space through the ELF auxiliary vector AT_RSEQ_FEATURE_SIZE.
- */
- if (rseq_len < ORIG_RSEQ_SIZE ||
- (rseq_len == ORIG_RSEQ_SIZE && !IS_ALIGNED((unsigned long)rseq, ORIG_RSEQ_SIZE)) ||
- (rseq_len != ORIG_RSEQ_SIZE && (!IS_ALIGNED((unsigned long)rseq, rseq_alloc_align()) ||
- rseq_len < offsetof(struct rseq, end))))
- return -EINVAL;
if (!access_ok(rseq, rseq_len))
return -EFAULT;
- if (IS_ENABLED(CONFIG_RSEQ_SLICE_EXTENSION)) {
+ /*
+ * The optimized check disables time slice extensions for legacy
+ * registrations.
+ */
+ if (IS_ENABLED(CONFIG_RSEQ_SLICE_EXTENSION) && optimized) {
rseqfl |= RSEQ_CS_FLAG_SLICE_EXT_AVAILABLE;
if (rseq_slice_extension_enabled() &&
(flags & RSEQ_FLAG_SLICE_EXT_DEFAULT_ON))
@@ -485,7 +450,15 @@ SYSCALL_DEFINE4(rseq, struct rseq __user
unsafe_put_user(RSEQ_CPU_ID_UNINITIALIZED, &rseq->cpu_id, efault);
unsafe_put_user(0U, &rseq->node_id, efault);
unsafe_put_user(0U, &rseq->mm_cid, efault);
- unsafe_put_user(0U, &rseq->slice_ctrl.all, efault);
+
+ /*
+ * All fields past mm_cid are only valid for non-legacy registrations
+ * which register with rseq_len > ORIG_RSEQ_SIZE.
+ */
+ if (optimized) {
+ if (IS_ENABLED(CONFIG_RSEQ_SLICE_EXTENSION))
+ unsafe_put_user(0U, &rseq->slice_ctrl.all, efault);
+ }
}
/*
@@ -501,11 +474,11 @@ SYSCALL_DEFINE4(rseq, struct rseq __user
#endif
/*
- * If rseq was previously inactive, and has just been
- * registered, ensure the cpu_id_start and cpu_id fields
- * are updated before returning to user-space.
+ * Ensure the cpu_id_start and cpu_id fields are updated before
+ * returning to user-space.
*/
current->rseq.event.has_rseq = true;
+ current->rseq.event.optimized = optimized;
rseq_force_update();
return 0;
@@ -513,6 +486,86 @@ SYSCALL_DEFINE4(rseq, struct rseq __user
return -EFAULT;
}
+static long rseq_unregister(struct rseq __user * rseq, u32 rseq_len, int flags, u32 sig)
+{
+ if (flags & ~RSEQ_FLAG_UNREGISTER)
+ return -EINVAL;
+ if (current->rseq.usrptr != rseq || !current->rseq.usrptr)
+ return -EINVAL;
+ if (rseq_len != current->rseq.len)
+ return -EINVAL;
+ if (current->rseq.sig != sig)
+ return -EPERM;
+ if (!rseq_reset_ids())
+ return -EFAULT;
+ rseq_reset(current);
+ return 0;
+}
+
+static long rseq_reregister(struct rseq __user * rseq, u32 rseq_len, u32 sig)
+{
+ /*
+ * If rseq is already registered, check whether the provided address
+ * differs from the prior one.
+ */
+ if (current->rseq.usrptr != rseq || rseq_len != current->rseq.len)
+ return -EINVAL;
+ if (current->rseq.sig != sig)
+ return -EPERM;
+ /* Already registered. */
+ return -EBUSY;
+}
+
+static bool rseq_length_valid(struct rseq __user *rseq, unsigned int rseq_len)
+{
+ if (rseq_len < ORIG_RSEQ_SIZE)
+ return false;
+
+ /*
+ * Ensure the provided rseq is properly aligned, as communicated to
+ * user-space through the ELF auxiliary vector AT_RSEQ_ALIGN. If
+ * rseq_len is the original rseq size, the required alignment is the
+ * original struct rseq alignment.
+ *
+ * The rseq_len is required to be greater or equal than the original
+ * rseq size.
+ *
+ * In order to be valid, rseq_len is either the original rseq size, or
+ * large enough to contain all supported fields, as communicated to
+ * user-space through the ELF auxiliary vector AT_RSEQ_FEATURE_SIZE.
+ */
+ if (rseq_len < ORIG_RSEQ_SIZE)
+ return false;
+
+ if (rseq_len == ORIG_RSEQ_SIZE)
+ return IS_ALIGNED((unsigned long)rseq, ORIG_RSEQ_SIZE);
+
+ return IS_ALIGNED((unsigned long)rseq, rseq_alloc_align()) &&
+ rseq_len >= offsetof(struct rseq, end);
+}
+
+#define RSEQ_FLAGS_SUPPORTED (RSEQ_FLAG_SLICE_EXT_DEFAULT_ON)
+
+/*
+ * sys_rseq - Register or unregister restartable sequences for the caller thread.
+ */
+SYSCALL_DEFINE4(rseq, struct rseq __user *, rseq, u32, rseq_len, int, flags, u32, sig)
+{
+ if (flags & RSEQ_FLAG_UNREGISTER)
+ return rseq_unregister(rseq, rseq_len, flags, sig);
+
+ if (unlikely(flags & ~RSEQ_FLAGS_SUPPORTED))
+ return -EINVAL;
+
+ if (current->rseq.usrptr)
+ return rseq_reregister(rseq, rseq_len, sig);
+
+ if (!rseq_length_valid(rseq, rseq_len))
+ return -EINVAL;
+
+ return rseq_register(rseq, rseq_len, flags, sig);
+}
+
#ifdef CONFIG_RSEQ_SLICE_EXTENSION
struct slice_timer {
struct hrtimer timer;
@@ -713,6 +766,8 @@ int rseq_slice_extension_prctl(unsigned
return -ENOTSUPP;
if (!current->rseq.usrptr)
return -ENXIO;
+ if (!current->rseq.event.optimized)
+ return -ENOTSUPP;
/* No change? */
if (enable == !!current->rseq.slice.state.enabled)
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -199,7 +199,16 @@ static void ipi_rseq(void *info)
* is negligible.
*/
smp_mb();
- rseq_sched_switch_event(current);
+ /*
+ * Legacy mode requires that IDs are written and the critical section is
+ * evaluated. Optimized mode handles the critical section and IDs are
+ * only updated if they change as a consequence of preemption after
+ * return from this IPI.
+ */
+ if (rseq_optimized(current))
+ rseq_sched_switch_event(current);
+ else
+ rseq_force_update();
}
static void ipi_sync_rq_state(void *info)
--- a/Documentation/userspace-api/rseq.rst
+++ b/Documentation/userspace-api/rseq.rst
@@ -24,6 +24,80 @@ Quick access to CPU number, node ID
Allows to implement per CPU data efficiently. Documentation is in code and
selftests. :(
+Optimized RSEQ V2
+-----------------
+
+On architectures which utilize the generic entry code and generic TIF bits
+the kernel supports runtime optimizations for RSEQ, which also enable
+enhanced features like scheduler time slice extensions.
+
+To enable them a task has to register the RSEQ region with at least the
+length advertised by getauxval(AT_RSEQ_FEATURE_SIZE).
+
+If existing binaries register with RSEQ_ORIG_SIZE (32 bytes), the kernel
+keeps the legacy low performance mode enabled to fulfil the expectations
+existing users regarding the original RSEQ implementation behaviour.
+
+The following table documents the ABI and behavioral guarantees of the
+legacy and the optimized V2 mode.
+
+.. list-table:: RSEQ modes
+ :header-rows: 1
+
+ * - Nr
+ - What
+ - Legacy
+ - Optimized V2
+ * - 1
+ - The cpu_id_start, cpu_id, node_id and mm_cid fields (User mode read
+ only)
+ - Updated by the kernel unconditionally after each context switch and
+ before signal delivery
+ - Updated by the kernel if and only if they change, i.e. if the task
+ is migrated or mm_cid changes
+ * - 2
+ - The rseq_cs critical section field
+ - Evaluated and handled unconditionally after each context switch and
+ before signal delivery
+ - Evaluated and handled conditionally only when user space was
+ interrupted. Either after being preempted or before signal delivery
+ in the interrupted context.
+ * - 3
+ - Read only fields
+ - No strict enforcement except in debug mode
+ - Strict enforcement
+ * - 4
+ - membarrier(...RSEQ)
+ - All running threads of the process are interrupted and the ID fields
+ are rewritten and eventually active critical sections are aborted
+ before they return to user space. All threads which are scheduled
+ out whether voluntary or not are covered by #1/#2 above.
+ - All running threads of the process are interrupted and eventually
+ active critical sections are aborted before these threads return to
+ user space. The ID fields are only updated if changed as a
+ consequence of the interrupt. All threads which are scheduled out
+ whether voluntary not are covered by #1/#2 above.
+ * - 5
+ - Time slice extensions
+ - Not supported
+ - Supported
+
+The legacy mode is obviously less performant as it does unconditional
+updates and critical section checks even if not strictly required by the
+ABI contract. That can't be changed anymore as some users depend on that
+observed behavior, which in turn enables them to violate the ABI and
+overwrite the cpu_id_start field for their own purposes. This is obviously
+discouraged as it renders RSEQ incompatible with the intended usage and
+breaks the expectation of other libraries in the same application.
+
+The ABI compliant optimized mode, which respects the read only fields, does
+not require unconditional updates and therefore is way more performant. The
+kernel validates the read only fields for compliance. If user space
+modifies them, the process is killed. Compliant usage allows multiple
+libraries in the same application to benefit from the RSEQ functionality
+without disturbing each other.
+
+
Scheduler time slice extensions
-------------------------------
@@ -37,7 +111,8 @@ scheduled out inside of the critical sec
* Enabled at boot time (default is enabled)
- * A rseq userspace pointer has been registered for the thread
+ * A rseq userspace pointer has been registered for the thread in
+ optimized V2 mode
The thread has to enable the functionality via prctl(2)::
^ permalink raw reply
* [GIT PULL] Mailbox changes for v7.1
From: Jassi Brar @ 2026-04-26 22:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-arm-kernel, Linux Kernel Mailing List
Hi Linus,
The following changes since commit 11439c4635edd669ae435eec308f4ab8a0804808:
Linux 7.0-rc2 (2026-03-01 15:39:31 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox.git
tags/mailbox-v7.1
for you to fetch changes up to 6e937f4e769e60947909e3525965f0137b9039e8:
mailbox: mailbox-test: make data_ready a per-instance variable
(2026-04-18 13:10:14 -0500)
----------------------------------------------------------------
mailbox: updates for v7.1
- core: fix NULL message handling and add API to query TX queue slots
- test: resolve concurrency bugs, dangling IRQs, and memory leaks
- dt-bindings: qcom: add Eliza IPCC
- mtk: fix address calculation and pointer handling bugs
- cix: resolve SCMI suspend timeouts
- misc memory allocation optimizations and cleanups
----------------------------------------------------------------
Abel Vesa (1):
dt-bindings: mailbox: qcom-ipcc: Document the Eliza
Inter-Processor Communication Controller
Dylan Wu (1):
mailbox: cix: Add IRQF_NO_SUSPEND to mailbox interrupt
Felix Gu (1):
mailbox: mtk-vcp-mailbox: Fix the return value in mtk_vcp_mbox_xlate()
Jason-JH Lin (1):
mailbox: mtk-cmdq: Fix CURR and END addr for task insert case
Jassi Brar (2):
mailbox: add API to query available TX queue slots
mailbox: Fix NULL message support in mbox_send_message()
Rosen Penev (2):
mailbox: rockchip: kzalloc + kcalloc to kzalloc
mailbox: hi6220: kzalloc + kcalloc to kzalloc
Wolfram Sang (12):
mailbox: exynos: drop superfluous mbox setting per channel
mailbox: test: really ignore optional memory resources
mailbox: correct kdoc title for mbox_bind_client
mailbox: remove superfluous internal header
mailbox: prefix new constants with MBOX_
mailbox: mailbox-test: free channels on probe error
mailbox: add sanity check for channel array
mailbox: update kdoc for struct mbox_controller
mailbox: mailbox-test: handle channel errors consistently
mailbox: mailbox-test: don't free the reused channel
mailbox: mailbox-test: initialize struct earlier
mailbox: mailbox-test: make data_ready a per-instance variable
.../devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
drivers/mailbox/cix-mailbox.c | 6 +-
drivers/mailbox/exynos-mailbox.c | 4 --
drivers/mailbox/hi3660-mailbox.c | 2 -
drivers/mailbox/hi6220-mailbox.c | 14 ++--
drivers/mailbox/imx-mailbox.c | 4 +-
drivers/mailbox/mailbox-sti.c | 2 -
drivers/mailbox/mailbox-test.c | 80 +++++++++++++---------
drivers/mailbox/mailbox.c | 67 +++++++++++-------
drivers/mailbox/mailbox.h | 12 ----
drivers/mailbox/mtk-cmdq-mailbox.c | 10 +--
drivers/mailbox/mtk-vcp-mailbox.c | 2 +-
drivers/mailbox/omap-mailbox.c | 4 +-
drivers/mailbox/pcc.c | 2 -
drivers/mailbox/rockchip-mailbox.c | 9 +--
drivers/mailbox/tegra-hsp.c | 6 +-
include/linux/mailbox_client.h | 1 +
include/linux/mailbox_controller.h | 17 +++--
18 files changed, 124 insertions(+), 119 deletions(-)
delete mode 100644 drivers/mailbox/mailbox.h
^ permalink raw reply
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Cristian Marussi @ 2026-04-26 23:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, Sudeep Holla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto, arm-scmi, linux-arm-kernel, linux-renesas-soc,
linux-clk, devicetree, linux-pm, linux-kernel
In-Reply-To: <CAMuHMdWJvMH+a1RqozbaCxxH_8M569JcruTFa8PW+87FysnjHw@mail.gmail.com>
On Fri, Apr 24, 2026 at 02:08:55PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,
Hi Geert,
>
> On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > On Tue, Apr 21, 2026 at 08:11:38PM +0200, Geert Uytterhoeven wrote:
> > > Currently non-SCMI drivers cannot find out what the specific versions of
> > > each SCMI provider implementation on the running system are.
> >
> > Thanks for your patches....this is not a proper full review of the series,
> > BUT this patch catched my eye..
> >
> > Indeed, yes, it is deliberate that the SCMI version information is NOT
> > exposed out of the SCMI world, since being the SCMI an attempt to
> > standardize a common FW interface (as in [1] of course), you should not
> > know what runs inside the black-box, it should be irrelevant...
> >
> > ...indeed the versioning is used inside the SCMI stack to deal properly
> > with different protocol versions implemented by the server OR to apply
> > proper quirks when needed, but all the rest should be standard....
> >
> > ...you should NOT really behave differently based on the underneath
> > protocol or firmare implementation version...it is the SCMI stack that
> > should behave properly, transparently...
>
> Oh well...
>
> > Having said that...I understand that at least it could be useful to be able
> > to query the SCMI stack to know, even from non-SCMI drivers, WHICH quirks
> > have been applied/activated at run time...but anything more than that it
>
> I see no need for that, but we can discover which quirks have been
> applied from the kernel log ;-)
Ok so I may have misunderstood...it seemed to me, glancing through the
series that you wanted sort of reconfigure other non-SCMI drivers based
on the SCMI FW version assuming that some quirks were applied BUT also
that some sort of corrective workaround was needed additionally...so
what I was saying was that: is not more straightforward to be possibly
able to check if a quirk has been applied instead of querying the
version from outside ?
>
> > seems to me dangerous and prone to a number of abuses of the SCMI stack
> > itself...
> >
> > (Also...exposing the versions itself means also tracking that bit of info
> > in more than one place: the quirk framework and your drivers.)
>
> I'll see if I can get everything handled as quirks instead...
>
> > > However, different versions may use different ABIs (e.g. different clock
> > > IDs), or behave different, requiring remapping or workarounds in other
> > > drivers.
> >
> > ...abuse like this indeed :P ... the SCMI server is supposed to be that
> > one entity remapping the IDs in the background if the same IDs happen to
> > be representing different physical resources across a number of distinct
> > platforms all supported by the same firmware blob...so as to present
> > a consistent set of contiguos IDs...
>
> In our case it is just a single platform, with different ID number
> spaces for different firmware versions.
Yes understood.
>
> > Also because this should be one of the selling point of the SCMI stack
> > in a virtualized environment: you can ship the same kernel drivers with
> > the same DT and you know that ID=<N> will always identify the specific
> > resource that is needed by your driver without worrying about the fact
> > that in reality in the backstage the effectively managed physical resource
> > could be different across different platforms, because that does not matter
>
> This sounds strange to me, do I understand it correctly?
> So the ID should (1) be tied to the use-case, and not to the underlying
> hardware, and (2) be the same for different platforms?
>
> For (1): Then we must not put these IDs in DT at all, as DT is supposed
> to describe the hardware (and firmware IDs in DT were IMHO already
> a stretch before).
> For (2): How can there be a contiguous list of IDs, as not all platforms
> may have the same underlying hardware?
>
I would NOT say that an SCMI FW must behave like this regarding IDs, but it
is a possible SCMI deployed setup that can be useful in virtualized setups
I mean, the DT describes the hardware of course BUT when you refer to
some of this hardware DT bits from some other subsystem by referencing a
phandle, even in the non-SCMI world, you are in fact selecting a specific
resource that fit you use case, right ? Can we say this ?
I mean you needed that specific clock or regulator that you described
previously so as to be able to enable some other piece of HW...
Now, the SCMI provides an abstraction on top of this, since you really
discover domain IDs of a specific class (clocks/regulators etc) you are
in fact describing an HW abstraction that you then refer with the usual
phandle...also because there is NOT so much SCMI hardware to describe,
given that the HW is handled transparently (opaquely really :P) by the
driver on the FW side...
...you basically obtain such domain ID, usable as phandles through dynamic
SCMI enumeration so that you can use it all over your DT to make use of such
resources...
...on top of this, consider that the SCMI server CAN provide to its agents
a per-agent-view of the world, IOW it can (and should) expose to a specific
agent ONLY the resources needed by that agent, i.e. it can expose the set
of resources 1-N to two distinct agents and that does NOT mean that the
underlying physical resource mapped by ID=3 in both agents has to be
effectively the same piece of hardware: it could be the case, and this
would be useful to exposed and managed properly a shared resource, or
it could also be that the same ID=3 could refer to completely distinct
pieces of the same class of hardware...(same protocol same class of
resource...)
In fact the SCMI server provides an abstraction, sometime a mere illusion
to the agents...
So in a virtualized ennvironment you could expose the same ID to a pair
of distinct agents on distinct VMs, so that you can use the same driver
and same DT despite the fact that maybe the underlying resources are
distinct pieces of hardware ...
...OR on the other side you could decide to share the same resource with
different agents (say a clock) and take care, as a server, of armonizing
conflicting requests from different agents (e.g. by refcounting enable/disable
across all agents), WITHOUT necessarily need to expose that same resource
with the same ID to both agents...
...and you can easily draw a parallel from this virtualization dynamic
scenario to a more static usecase where you have a FW shipped on
multiple boards and so capable of serving, in fact, multiple distinct
agents, but this time, just NOT all together like the VM, but one at time
depending on which board configuration is booted...
....all of this madness of course has a chance to work ONLY if the SCMI
server takes care to remap such resources properly at build-time or
run-time as a contiguos set of IDs, based on the expected agents that
it has to serve
I am, of course, disillusioned enough NOT to believe that many FW were
shipped around trying to fit this ideal SCMI deployment scenario BUT at
least we try, kernel side, NOT to ease these kind of design that goes
pretty much against the SCMI ideas of a system (and the spec to some
extent if you punch holes in the IDs sets), and even more we try NOT
to legalize/normalize out-of-spec FW behaviours by fixing the driver,
where required, and deploying needed quirks to let existing boards survive
(..and that becomes quickly much more a pain in the ass for us then for the
FW guys :P)
> > if the SCMI platform server had properly remapped (at build time/run-time ?)
> > the resources to your expected ID...alternatively of course you can ship
> > with different DTs to describe different hardware...BUT remmapping stuff
>
> That is a different issue: as SCMI covers the full platform, not just
> the SoC, the IDs can be board-specific, and thus should be specified
> in the board .dts, not in the SoC .dtsi?
> Then the SoC .dtsi should describe the hardware, and we end up with
> things like arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts?
>
> > in the drivers themselves guessing on the vendor/subvendor/impl_vers
> > seems a dangerous abuse...
>
> There is no guessing.
>
> > I watched a bit of the LPC discussions around this (from Marek I think)
> > but sincerely most of those problems had one (not necessarily simple)
> > solution: fix your firmwares AND/OR apply quirks in the meantime...
>
> Unfortunately (at this point) we have to work with the firmware that exists.
>
> From that LPC discussion, we learned that we are actually the lucky
> guys: some other vendors tend to change the IDs and/or behavior without
> bumping the version, so Linux cannot even act upon that...
>
Oh I know that :P ... the whole SCMI quirk framework has been introduced
to cope with FW issue from one vendor that afterwards fixed their FW
issue BUT did NOT take care to update properly their FW versions upon
each release...so their quirks will be like diamonds, forever !
... no matter how many fixed-FW they will deploy :P
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v2 08/13] firmware: arm_scmi: Harden clock protocol initialization
From: Cristian Marussi @ 2026-04-26 23:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, Nicolas Frattaroli, linux-kernel,
linux-arm-kernel, arm-scmi, linux-clk, linux-renesas-soc,
sudeep.holla, philip.radford, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, geert+renesas, kuninori.morimoto.gx,
marek.vasut+renesas
In-Reply-To: <CAMuHMdXYGRzq2j3z1io=kHj_QsWtJBirPhbZPa5bFBD7U9e0sw@mail.gmail.com>
On Fri, Apr 24, 2026 at 03:55:08PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,
Hi,
>
> On Fri, 24 Apr 2026 at 15:32, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > On Fri, Apr 24, 2026 at 02:07:59PM +0200, Nicolas Frattaroli wrote:
> > > On Tuesday, 10 March 2026 19:40:25 Central European Summer Time Cristian Marussi wrote:
> > > > Add proper error handling on failure to enumerate clocks features or
> > > > rates.
>
> > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > > > ---
> > > > drivers/firmware/arm_scmi/clock.c | 22 ++++++++++++++++------
> > > > 1 file changed, 16 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
> > > > index c9b62edce4fd..bf956305a8fe 100644
> > > > --- a/drivers/firmware/arm_scmi/clock.c
> > > > +++ b/drivers/firmware/arm_scmi/clock.c
> > > > @@ -402,10 +402,16 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
> > > > SUPPORTS_RATE_CHANGE_REQUESTED_NOTIF(attributes))
> > > > clk->rate_change_requested_notifications = true;
> > > > if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> > > > - if (SUPPORTS_PARENT_CLOCK(attributes))
> > > > - scmi_clock_possible_parents(ph, clk_id, cinfo);
> > > > - if (SUPPORTS_GET_PERMISSIONS(attributes))
> > > > - scmi_clock_get_permissions(ph, clk_id, clk);
> > > > + if (SUPPORTS_PARENT_CLOCK(attributes)) {
> > > > + ret = scmi_clock_possible_parents(ph, clk_id, cinfo);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > + if (SUPPORTS_GET_PERMISSIONS(attributes)) {
> > > > + ret = scmi_clock_get_permissions(ph, clk_id, clk);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > if (SUPPORTS_EXTENDED_CONFIG(attributes))
> > > > clk->extended_config = true;
> > > > }
> > > > @@ -1143,8 +1149,12 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
> > > > for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
> > > > cinfo->clkds[clkid].id = clkid;
> > > > ret = scmi_clock_attributes_get(ph, clkid, cinfo);
> > > > - if (!ret)
> > > > - scmi_clock_describe_rates_get(ph, clkid, cinfo);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
> > > > + if (ret)
> > > > + return ret;
> > > > }
> > > >
> > > > if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> > > >
> > >
> > > I see that a quirk is being added for this, but I thought I should chime
> > > in with my opinion for future approaches in this direction.
> > >
> > > I don't see how this hardens anything. All this does is break platforms
> > > that were previously working by returning early. At most, this should
> >
> > Certainly the naming in the subject was chosen badly (by me!)...indeed it
> > should be more something like "Enforce strict protocol compliance",
> > because at the end all of the broken platforms really run a slighly odd
> > out of spec SCMI firmware that does NOT implement one or more of the SCMI
> > mandatory command...
> >
> > > be a warning (as in not WARN but pr_warn/dev_warn/...). If firmware
> > > returns nonsense, a clock driver should imho try its best to work
> > > around the nonsense in a safe way, because the alternative is that
> > > a major part of the system (and thus likely the entire system) no
> >
> > ..well yes we definitely dont want to break deployed platforms BUT also
> > we dont want to legalize this kind of out of spec behaviour in future
> > firmwares...hence (a number ?) of quirks an FW_BUG warns probably to
> > let already broken deployed platforms survive while discouraging such
> > implementation in future fw implementations...
> >
> > These firmware most certainly wont pass the SCMI compliance test suite [1],
> > which indeed we do not mandate, but the reason these bugs happened is
> > exactly because the kernel SCMI stack was buggy and left that door open...
> >
> > More specifically these kind of out-of-spec behaviours are not really just
> > a matter being 'picky', the problem is that any resource set in any
> > SCMI protocol is defined by the spec such as to be described by a
> > contiguos set of IDs and the drivers are designed anyway under that
> > assumption from the allocation point of view, so allowing a clock ID to
> > just fail one of the mandatory commands and skip a domain would jeopardize
> > all of this and, even if clearly is NOT a problem here, seems a fragile
> > assumption.
>
> How can you have all of:
> 1. a contiguous list of IDs,
> 2. implement all mandatory commands,
> 2. restrict the use of some clocks to a subset of the agents in the system?
> Use a different list of IDs for each agent?
Yes, the SCMI server can provide a per-agent view of the world to each
agent, and ideally it should not even expose resources that are not
needed at all to an agent...and by that I mean that the server SHOULD
not enumerate that resources when queried, by dropping them from the
list of resources that return to that agent WHILE maintaining the set of
IDs contigous...
...the SCMI server provides an illusion ideally where the agent is in
control and can access whatever it wants, while the reality is that the
agent can only issue commands that are deemed safe and sensible by the server,
which is the ultimate arbiter on the system, to the extent that can hide
resources or simply silently ignore requests...
> What if a mistake was made, and a clock was exposed to an agent by
> accident?
Quirk !
More detail on all of this in my babbling on the other thread...sorry
for the flood of words :P
Thanks,
Cristian
^ permalink raw reply
* Re: (subset) [PATCH 0/3] Mediatek Genio 1200-EVK: MT6315/MT6360 PMIC regulator supply cleanup
From: Mark Brown @ 2026-04-26 22:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Gene Chen,
Louis-Alexis Eyraud
Cc: kernel, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260414-mtk-g1200-pmic-cleanup-v1-0-2a7193ed4e93@collabora.com>
On Tue, 14 Apr 2026 13:44:09 +0200, Louis-Alexis Eyraud wrote:
> Mediatek Genio 1200-EVK: MT6315/MT6360 PMIC regulator supply cleanup
>
> This series goal is to cleanup the power supplies of MT6315 and MT6360
> PMIC regulators, that are either missing or incorrect in the Mediatek
> Genio 1200-EVK board devicetree.
>
> Patch 1 completes the MT6360 dt-bindings by adding the missing power
> supply descriptions for its buck regulators, that already handled by
> the mt6360 regulator driver.
> Patch 2 adds for the board the MT6315 regulator supply properties, that
> were added in the dt-bindings by [1].
> Patch 3 adds for the board the MT6360 regulator supply properties and
> fixes the existing one.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.2
Thanks!
[1/3] regulator: dt-bindings: mt6360: add buck regulator supplies
https://git.kernel.org/broonie/regulator/c/a8fccc792f42
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] ASoC: mchp-spdifrx: Replace manual bitfield manipulations with macros and typo correction
From: Mark Brown @ 2026-04-26 21:51 UTC (permalink / raw)
To: claudiu.beznea, andrei.simion, lgirdwood, perex, tiwai,
nicolas.ferre, alexandre.belloni, Joao Marinho joao.bcc@usp.br
Cc: Micael Vinicius, linux-sound, linux-arm-kernel
In-Reply-To: <20260420203218.15060-1-joao.bcc@usp.br>
On Mon, 20 Apr 2026 17:32:03 -0300, Joao Marinho joao.bcc@usp.br wrote:
> ASoC: mchp-spdifrx: Replace manual bitfield manipulations with macros and typo correction
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] ASoC: mchp-spdifrx: Replace manual bitfield manipulations with macros and typo correction
https://git.kernel.org/broonie/asoc/c/0241d6192a11
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] Change manual bitfield manipulation to use FIELD_PREP()
From: Mark Brown @ 2026-04-26 21:53 UTC (permalink / raw)
To: claudiu.beznea, andrei.simion, lgirdwood, perex, tiwai,
nicolas.ferre, alexandre.belloni, Gabriel Jacob Perin
Cc: carlos.albmr, linux-sound, linux-arm-kernel
In-Reply-To: <20260421193113.1060213-1-gabrieljp@usp.br>
On Tue, 21 Apr 2026 16:31:13 -0300, Gabriel Jacob Perin wrote:
> Change manual bitfield manipulation to use FIELD_PREP()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] Change manual bitfield manipulation to use FIELD_PREP()
https://git.kernel.org/broonie/sound/c/ae93afff9818
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
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