* Re: [PATCH v9 00/22] Enable FRED with KVM VMX
From: David Woodhouse @ 2026-05-07 13:35 UTC (permalink / raw)
To: Maciej Wieczor-Retman
Cc: Andrew Cooper, Xin Li, linux-kernel, kvm, linux-doc,
Saenz Julienne, Nicolas, pbonzini, seanjc, corbet, tglx, mingo,
bp, dave.hansen, x86, hpa, luto, peterz, chao.gao, hch,
sohil.mehta
In-Reply-To: <afxm400MglHAjoje@wieczorr-mobl1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]
On Thu, 2026-05-07 at 14:59 +0200, Maciej Wieczor-Retman wrote:
> On 2026-05-07 at 08:49:27 +0100, David Woodhouse wrote:
> > On Tue, 2026-05-05 at 22:20 +0200, Maciej Wieczor-Retman wrote:
> > >
> > > I take it you mean dropping the ICEBP selftest test case and just checking INT3
> > > and INT $0x20? In that case the other two tests pass after a minor change -
> > > namely in guest_code() the expected_rip needs to be volatile as well. Otherwise
> > > there is a RIP mismatch.
> >
> > I don't understand the part about making expected_rip volatile. Are the
> > asm constraints there not correct? If not I'd rather *fix* them than
> > use 'volatile' to paper over it. I can't see the issue though.
> >
> > Can you show the generated asm both with and without it?
>
> ---------- not volatile ---------------- | -------------- volatile -----------------
> #APP #APP
> # 156 "x86/int1_fred_test.c" 1 # 156 "x86/int1_fred_test.c" 1
> lea 1f(%rip), %rdi | lea 1f(%rip), %rax
> int3 int3
> 1: 1:
> # 0 "" 2 # 0 "" 2
> .LVL42: <
> .loc 3 159 2 view .LVU146 <
> #NO_APP #NO_APP
> > movq %rax, 8(%rsp)
> > .loc 3 159 2 view .LVU146
> > movq 8(%rsp), %rdi
> movl $6, %edx movl $6, %edx
> movl $3, %esi movl $3, %esi
> call check_fred_event.isra.0 call check_fred_event.isra.0
>
> I think that when the FRED event happens it doesn't save RDI and overwrites it
> before going into check_fred_event. In the volatile case it is saved to the
> stack before check_fred_event() (.loc 159 is the check_fred_event() call).
That looks OK to me. When it calls check_fred_event(), expected_rip is
the first argument and thus lives in %rdi. On the right hand side where
it's volatile, it gets explicitly loaded again from 8(%rsp) for the
call to check_fred_event().
On the left hand side, the compiler doesn't mess with it at all; just
chooses %rdi as the register to use for the output %0 of the inline
assembly. So it's loaded *directly* into %rdi by our 'lea' and it goes
straight from there to the check_fred_event() function as it should.
Your version turns it into a memory operand and forces it to get
written out to the stack, after which the compiler has to load it
again, so yes it'll look a lot more like your right hand side.
But I don't see anything actually wrong with the original.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH ipsec-next v8 10/14] xfrm: move encap and xuo into struct xfrm_migrate
From: Sabrina Dubroca @ 2026-05-07 13:26 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-10-4578fb016965@secunet.com>
2026-05-05, 06:34:04 +0200, Antony Antony wrote:
> In preparation for an upcoming patch, move the xfrm_encap_tmpl and
> xfrm_user_offload pointers from separate parameters into struct
> xfrm_migrate, reducing the parameter count of
> xfrm_state_migrate_create(), xfrm_state_migrate_install(), and
> xfrm_state_migrate().
>
> The fields are placed after the four xfrm_address_t members where
> the struct is naturally 8-byte aligned, avoiding padding.
>
> No functional change.
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
>
> ---
> v5->v6: added this patch.
> ---
> include/net/xfrm.h | 7 ++-----
> net/xfrm/xfrm_policy.c | 4 +++-
> net/xfrm/xfrm_state.c | 20 +++++++-------------
> 3 files changed, 12 insertions(+), 19 deletions(-)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon: add initial support for AMD PROM21 xHCI temperature sensor
From: Mario Limonciello @ 2026-05-07 13:24 UTC (permalink / raw)
To: Michal Pecio
Cc: Jihong Min, Greg Kroah-Hartman, Mathias Nyman, Guenter Roeck,
Jonathan Corbet, Shuah Khan, Basavaraj Natikar, linux-usb,
linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <20260507110821.07480da8.michal.pecio@gmail.com>
On 5/7/26 04:08, Michal Pecio wrote:
> On Wed, 6 May 2026 16:36:49 -0500, Mario Limonciello wrote:
>>>> The temperature register did not return a valid value while the
>>>> xHCI PCI function was suspended in testing. Keep the existing
>>>> behavior by default and allow temperature reads to wake the xHCI
>>>> PCI device. Add an allow_pm_switch module parameter so users can
>>>> disable that behavior; when disabled, reads do not wake the
>>>> device and return -EAGAIN if it is suspended.
>>>
>>> Is such behavior useful?
>>>
>>> Maybe the driver could just disable runtime PM while it's loaded.
>>
>> I'd encourage what we do in amdgpu for dGPUs. The hwmon files will
>> return an error code (I forget which code) when the device is in
>> runtime PM when called. Don't explicitly wake it otherwise.
>>
>> This prevents someone installing a sensor monitoring application and
>> that application "being the only thing" keeping the dGPU awake. If
>> it's awake already for other reasons (like being used) then return
>> valid data to the applications
>
> Well, that's not a dGPU but an xHCI controller embedded in the chipset,
> which chipset is more or less active all the time (includes bridges to
> PCIe ports, some SATA controllers and mabe other things I forgot).
> Is the saving from disabling xHCI significant for a desktop system?
>
> Users may be interested in monitoring chipset temperature even while
> not actively using USB.
>
> I don't know what are the conditions to put GPUs into runtime suspend,
> but a USB HC will be going in and out quite randomly, depending on
> connected devices and their workload. You may end up needing to answer
> people why their sensor only works when they turn on a webcam :)
Heh. You have a good point here. The reason for this policy in dGPUs
came from a lot of people using them "headless" (for example plugging in
a display to the iGPU on the board) and wondering why randomly their
power shot up and fans spun up on the GPU. It took a while to narrow
down that it was specifically sensor software doing it.
For a sensor accessed through registers on XHCI this is a lot less of a
big deal for all the reasons you point out.
>
> Alternatively, would it be possible to bring a suspendend HC into D0,
> read the temperature register and then put it back into D3hot without
> bothering the USB layer to fully resume and suspend xHCI logic?
>
This sounds better to me if it's feasible.
^ permalink raw reply
* Re: [PATCH] docs: leds: uleds: Make the documentation match the code.
From: Lee Jones @ 2026-05-07 13:11 UTC (permalink / raw)
To: Björn Persson
Cc: Pavel Machek, Jonathan Corbet, Shuah Khan, linux-leds, linux-doc,
linux-kernel
In-Reply-To: <20260424194714.71de0ef6@tag.xn--rombobjrn-67a.se>
On Fri, 24 Apr 2026, Björn Persson wrote:
> Lee Jones wrote:
> > On Thu, 02 Apr 2026, Björn Persson wrote:
> >
> > > From: Björn Persson <Bjorn@Rombobjörn.se>
> > >
> > > · max_brightness must be set. Leaving it uninitialized or just omitting it
> > > won't work.
> >
> > What are these points? How do you even type one of those?
>
> The bullet point is the character U+00B7 middle dot. I type it with
> AltGr-period on a Swedish keyboard in Fedora. I don't know what keymap
> your distro uses for your keyboard. I hear some keyboards lack an AltGr
> key.
Please use ASCII or you'll freak out the Luddites (like me)!
- or * is fine.
> > Anyway, proper sentences / paragraphs is better.
>
> You mean you dislike bulleted lists?
>
> Or if you mean that the first sentence doesn't begin with a capital M,
> that's because identifiers are case-sensitive in C. There is no
> Max_brightness, and if it were defined, it would be different from
> max_brightness.
>
> Otherwise I don't understand what you mean with "proper sentences", as
> I don't see any grammatical errors.
By all means use bullet points for lists, but a slab list of changes in
place of sentences is a little odd. Simply describe your changes as you
would speak to another human.
> > > -A new LED class device will be created with the name given. The name can be
> > > -any valid sysfs device node name, but consider using the LED class naming
> > > -convention of "devicename:color:function".
> > > +A new LED class device will be created with the given name and maximum
> >
> > Did you mean to revers "name given"? A "given name" usually means
> > something else.
>
> I felt that "the name and maximum brightness given" would be
> grammatically awkward.
>
> To prevent misinterpretation, how about replacing "given" with a
> synonym? Perhaps "the specified name and maximum brightness"? Another
This is nice.
> option is "the given maximum brightness and name", but it feels a
> little odd to mention the brightness before the name.
>
> > > +Although max_brightness is a signed int, only positive values are valid:
> > > +1 to INT_MAX.
> >
> > What about 0?
>
> That will get you an EINVAL from uleds.c – presumably because a
> brightness interval from 0 to 0 would be pointless. That LED would never
> be lit.
Ah, this is MAX brightness.
Okay so it's impossible to set a LED to always off.
> > > +The current brightness is found by reading a whole int from the character
> >
> > Try not to shorten names in documentation "integer".
>
> The type is named "int" in C. There are many integer types, but it would
> be wrong to try to read a uint16_t or a size_t or any other integer
> type. The document needs to use the actual type name to make it clear to
> the reader that they must read sizeof(int) bytes.
Right, but you're not writing in C.
> > Why do we need to specify "whole"?
>
> Because you can't read it piecemeal. Usually when you read from a disk
> file, a pipe, a TCP socket or some other bytestream, the system call
> will let you read one byte at a time if you want. A reader might assume
> that /dev/uleds works the same way.
>
> From a datagram socket you can read the beginning of a datagram and
> discard the part that doesn't fit in your buffer. To a reader with a
> little-endian system and max_brightness ≤ 255, it might seem logical
> that they'd be able to read the first byte and discard the bits that
> will always be zero.
>
> I thought "whole" would communicate to the reader that they must read
> sizeof(int) bytes in a single system call.
>
> It seems this wording wasn't enough to get the point across that it's
> necessary to read an int, a whole int, and nothing but an int. Do you
> think the document needs to expound that point more?
I think it needs rephrasing a little.
"Current brightness is obtained from the character device. It is
read in as an integer and must be done so in one go.
Or words to that effect.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v9 00/22] Enable FRED with KVM VMX
From: Maciej Wieczor-Retman @ 2026-05-07 12:59 UTC (permalink / raw)
To: David Woodhouse
Cc: Andrew Cooper, Xin Li, linux-kernel, kvm, linux-doc,
Saenz Julienne, Nicolas, pbonzini, seanjc, corbet, tglx, mingo,
bp, dave.hansen, x86, hpa, luto, peterz, chao.gao, hch,
sohil.mehta
In-Reply-To: <f4650572ea8277dcde8d68e4fa5317e1abdb988c.camel@infradead.org>
On 2026-05-07 at 08:49:27 +0100, David Woodhouse wrote:
>On Tue, 2026-05-05 at 22:20 +0200, Maciej Wieczor-Retman wrote:
>>
>> I take it you mean dropping the ICEBP selftest test case and just checking INT3
>> and INT $0x20? In that case the other two tests pass after a minor change -
>> namely in guest_code() the expected_rip needs to be volatile as well. Otherwise
>> there is a RIP mismatch.
>
>I don't understand the part about making expected_rip volatile. Are the
>asm constraints there not correct? If not I'd rather *fix* them than
>use 'volatile' to paper over it. I can't see the issue though.
>
>Can you show the generated asm both with and without it?
---------- not volatile ---------------- | -------------- volatile -----------------
#APP #APP
# 156 "x86/int1_fred_test.c" 1 # 156 "x86/int1_fred_test.c" 1
lea 1f(%rip), %rdi | lea 1f(%rip), %rax
int3 int3
1: 1:
# 0 "" 2 # 0 "" 2
.LVL42: <
.loc 3 159 2 view .LVU146 <
#NO_APP #NO_APP
> movq %rax, 8(%rsp)
> .loc 3 159 2 view .LVU146
> movq 8(%rsp), %rdi
movl $6, %edx movl $6, %edx
movl $3, %esi movl $3, %esi
call check_fred_event.isra.0 call check_fred_event.isra.0
I think that when the FRED event happens it doesn't save RDI and overwrites it
before going into check_fred_event. In the volatile case it is saved to the
stack before check_fred_event() (.loc 159 is the check_fred_event() call).
The below does work, it generates pretty much the same assembly as the volatile
expected_rip. Do you like it? I'm not sure if it can be simplified better?
asm volatile("lea 1f(%%rip), %%rax\n\t"
"movq %%rax, %0\n\t"
"int3\n\t"
"1:" : "=m"(expected_rip) :: "memory", "rax");
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply
* Re: [PATCH ipsec-next v8 09/14] xfrm: add error messages to state migration
From: Sabrina Dubroca @ 2026-05-07 12:56 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-9-4578fb016965@secunet.com>
2026-05-05, 06:33:49 +0200, Antony Antony wrote:
> Add descriptive(extack) error messages for all error paths
> in state migration. This improves diagnostics by
> providing clear feedback when migration fails.
>
> After xfrm_init_state() use NL_SET_ERR_MSG_WEAK() as fallback for
> error paths not yet propagating extack e.g. mode_cbs->init_state()
>
> No functional change.
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
>
> ---
> v5->v6: - in case dev_state_add() extack already set
> - after xfrm_init_state() use NL_SET_ERR_MSG_WEAK() as fallback
> v4->v5: - added this patch
> ---
> net/xfrm/xfrm_state.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
^ permalink raw reply
* Re: [PATCH v2] cpufreq: elanfreq: Drop support for AMD Elan SC4*
From: Zhongqiu Han @ 2026-05-07 12:35 UTC (permalink / raw)
To: Sean Young, Jonathan Corbet, Shuah Khan, Rafael J. Wysocki,
Viresh Kumar
Cc: linux-doc, linux-kernel, linux-pm, zhongqiu.han
In-Reply-To: <20260507090107.10113-1-sean@mess.org>
On 5/7/2026 5:01 PM, Sean Young wrote:
> Since commit 8b793a92d862 ("x86/cpu: Remove M486/M486SX/ELAN support"),
> the AMD Elan SC4* is no longer supported, so the cpu frequency
> driver is no longer needed.
>
> Signed-off-by: Sean Young <sean@mess.org>
> ---
> Changes since v1:
> - Also removes elanfreq= entry from kernel-parameters.txt
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
>
> .../admin-guide/kernel-parameters.txt | 4 -
> drivers/cpufreq/Kconfig.x86 | 15 --
> drivers/cpufreq/Makefile | 1 -
> drivers/cpufreq/elanfreq.c | 226 ------------------
> 4 files changed, 246 deletions(-)
> delete mode 100644 drivers/cpufreq/elanfreq.c
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 4d0f545fb3ec..7ab0e58c4aa9 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1669,10 +1669,6 @@ Kernel parameters
> very early in the boot process. For early debugging
> via a serial port see kgdboc_earlycon instead.
>
> - elanfreq= [X86-32]
> - See comment before function elanfreq_setup() in
> - arch/x86/kernel/cpu/cpufreq/elanfreq.c.
> -
> elfcorehdr=[size[KMG]@]offset[KMG] [PPC,SH,X86,S390,EARLY]
> Specifies physical address of start of kernel core
> image elf header and optionally the size. Generally
> diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
> index 865b290b01ff..c42dd39e0b2a 100644
> --- a/drivers/cpufreq/Kconfig.x86
> +++ b/drivers/cpufreq/Kconfig.x86
> @@ -126,21 +126,6 @@ config X86_ACPI_CPUFREQ_CPB
> By enabling this option the acpi_cpufreq driver provides the old
> entry in addition to the new boost ones, for compatibility reasons.
>
> -config ELAN_CPUFREQ
> - tristate "AMD Elan SC400 and SC410"
> - depends on MELAN
> - help
> - This adds the CPUFreq driver for AMD Elan SC400 and SC410
> - processors.
> -
> - You need to specify the processor maximum speed as boot
> - parameter: elanfreq=maxspeed (in kHz) or as module
> - parameter "max_freq".
> -
> - For details, take a look at <file:Documentation/cpu-freq/>.
> -
> - If in doubt, say N.
> -
> config X86_POWERNOW_K6
> tristate "AMD Mobile K6-2/K6-3 PowerNow!"
> depends on X86_32
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 96196edf79d5..6c7a39b7f8d2 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -40,7 +40,6 @@ obj-$(CONFIG_X86_POWERNOW_K6) += powernow-k6.o
> obj-$(CONFIG_X86_POWERNOW_K7) += powernow-k7.o
> obj-$(CONFIG_X86_LONGHAUL) += longhaul.o
> obj-$(CONFIG_X86_E_POWERSAVER) += e_powersaver.o
> -obj-$(CONFIG_ELAN_CPUFREQ) += elanfreq.o
> obj-$(CONFIG_X86_LONGRUN) += longrun.o
> obj-$(CONFIG_X86_GX_SUSPMOD) += gx-suspmod.o
> obj-$(CONFIG_X86_SPEEDSTEP_ICH) += speedstep-ich.o
> diff --git a/drivers/cpufreq/elanfreq.c b/drivers/cpufreq/elanfreq.c
> deleted file mode 100644
> index fc5a58088b35..000000000000
> --- a/drivers/cpufreq/elanfreq.c
> +++ /dev/null
> @@ -1,226 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later
> -/*
> - * elanfreq: cpufreq driver for the AMD ELAN family
> - *
> - * (c) Copyright 2002 Robert Schwebel <r.schwebel@pengutronix.de>
> - *
> - * Parts of this code are (c) Sven Geggus <sven@geggus.net>
> - *
> - * All Rights Reserved.
> - *
> - * 2002-02-13: - initial revision for 2.4.18-pre9 by Robert Schwebel
> - */
> -
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> -#include <linux/kernel.h>
> -#include <linux/module.h>
> -#include <linux/init.h>
> -
> -#include <linux/delay.h>
> -#include <linux/cpufreq.h>
> -
> -#include <asm/cpu_device_id.h>
> -#include <linux/timex.h>
> -#include <linux/io.h>
> -
> -#define REG_CSCIR 0x22 /* Chip Setup and Control Index Register */
> -#define REG_CSCDR 0x23 /* Chip Setup and Control Data Register */
> -
> -/* Module parameter */
> -static int max_freq;
> -
> -struct s_elan_multiplier {
> - int clock; /* frequency in kHz */
> - int val40h; /* PMU Force Mode register */
> - int val80h; /* CPU Clock Speed Register */
> -};
> -
> -/*
> - * It is important that the frequencies
> - * are listed in ascending order here!
> - */
> -static struct s_elan_multiplier elan_multiplier[] = {
> - {1000, 0x02, 0x18},
> - {2000, 0x02, 0x10},
> - {4000, 0x02, 0x08},
> - {8000, 0x00, 0x00},
> - {16000, 0x00, 0x02},
> - {33000, 0x00, 0x04},
> - {66000, 0x01, 0x04},
> - {99000, 0x01, 0x05}
> -};
> -
> -static struct cpufreq_frequency_table elanfreq_table[] = {
> - {0, 0, 1000},
> - {0, 1, 2000},
> - {0, 2, 4000},
> - {0, 3, 8000},
> - {0, 4, 16000},
> - {0, 5, 33000},
> - {0, 6, 66000},
> - {0, 7, 99000},
> - {0, 0, CPUFREQ_TABLE_END},
> -};
> -
> -
> -/**
> - * elanfreq_get_cpu_frequency: determine current cpu speed
> - *
> - * Finds out at which frequency the CPU of the Elan SOC runs
> - * at the moment. Frequencies from 1 to 33 MHz are generated
> - * the normal way, 66 and 99 MHz are called "Hyperspeed Mode"
> - * and have the rest of the chip running with 33 MHz.
> - */
> -
> -static unsigned int elanfreq_get_cpu_frequency(unsigned int cpu)
> -{
> - u8 clockspeed_reg; /* Clock Speed Register */
> -
> - local_irq_disable();
> - outb_p(0x80, REG_CSCIR);
> - clockspeed_reg = inb_p(REG_CSCDR);
> - local_irq_enable();
> -
> - if ((clockspeed_reg & 0xE0) == 0xE0)
> - return 0;
> -
> - /* Are we in CPU clock multiplied mode (66/99 MHz)? */
> - if ((clockspeed_reg & 0xE0) == 0xC0) {
> - if ((clockspeed_reg & 0x01) == 0)
> - return 66000;
> - else
> - return 99000;
> - }
> -
> - /* 33 MHz is not 32 MHz... */
> - if ((clockspeed_reg & 0xE0) == 0xA0)
> - return 33000;
> -
> - return (1<<((clockspeed_reg & 0xE0) >> 5)) * 1000;
> -}
> -
> -
> -static int elanfreq_target(struct cpufreq_policy *policy,
> - unsigned int state)
> -{
> - /*
> - * Access to the Elan's internal registers is indexed via
> - * 0x22: Chip Setup & Control Register Index Register (CSCI)
> - * 0x23: Chip Setup & Control Register Data Register (CSCD)
> - *
> - */
> -
> - /*
> - * 0x40 is the Power Management Unit's Force Mode Register.
> - * Bit 6 enables Hyperspeed Mode (66/100 MHz core frequency)
> - */
> -
> - local_irq_disable();
> - outb_p(0x40, REG_CSCIR); /* Disable hyperspeed mode */
> - outb_p(0x00, REG_CSCDR);
> - local_irq_enable(); /* wait till internal pipelines and */
> - udelay(1000); /* buffers have cleaned up */
> -
> - local_irq_disable();
> -
> - /* now, set the CPU clock speed register (0x80) */
> - outb_p(0x80, REG_CSCIR);
> - outb_p(elan_multiplier[state].val80h, REG_CSCDR);
> -
> - /* now, the hyperspeed bit in PMU Force Mode Register (0x40) */
> - outb_p(0x40, REG_CSCIR);
> - outb_p(elan_multiplier[state].val40h, REG_CSCDR);
> - udelay(10000);
> - local_irq_enable();
> -
> - return 0;
> -}
> -/*
> - * Module init and exit code
> - */
> -
> -static int elanfreq_cpu_init(struct cpufreq_policy *policy)
> -{
> - struct cpuinfo_x86 *c = &cpu_data(0);
> - struct cpufreq_frequency_table *pos;
> -
> - /* capability check */
> - if ((c->x86_vendor != X86_VENDOR_AMD) ||
> - (c->x86 != 4) || (c->x86_model != 10))
> - return -ENODEV;
> -
> - /* max freq */
> - if (!max_freq)
> - max_freq = elanfreq_get_cpu_frequency(0);
> -
> - /* table init */
> - cpufreq_for_each_entry(pos, elanfreq_table)
> - if (pos->frequency > max_freq)
> - pos->frequency = CPUFREQ_ENTRY_INVALID;
> -
> - policy->freq_table = elanfreq_table;
> - return 0;
> -}
> -
> -
> -#ifndef MODULE
> -/**
> - * elanfreq_setup - elanfreq command line parameter parsing
> - *
> - * elanfreq command line parameter. Use:
> - * elanfreq=66000
> - * to set the maximum CPU frequency to 66 MHz. Note that in
> - * case you do not give this boot parameter, the maximum
> - * frequency will fall back to _current_ CPU frequency which
> - * might be lower. If you build this as a module, use the
> - * max_freq module parameter instead.
> - */
> -static int __init elanfreq_setup(char *str)
> -{
> - max_freq = simple_strtoul(str, &str, 0);
> - pr_warn("You're using the deprecated elanfreq command line option. Use elanfreq.max_freq instead, please!\n");
> - return 1;
> -}
> -__setup("elanfreq=", elanfreq_setup);
> -#endif
> -
> -
> -static struct cpufreq_driver elanfreq_driver = {
> - .get = elanfreq_get_cpu_frequency,
> - .flags = CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING,
> - .verify = cpufreq_generic_frequency_table_verify,
> - .target_index = elanfreq_target,
> - .init = elanfreq_cpu_init,
> - .name = "elanfreq",
> -};
> -
> -static const struct x86_cpu_id elan_id[] = {
> - X86_MATCH_VENDOR_FAM_MODEL(AMD, 4, 10, NULL),
> - {}
> -};
> -MODULE_DEVICE_TABLE(x86cpu, elan_id);
> -
> -static int __init elanfreq_init(void)
> -{
> - if (!x86_match_cpu(elan_id))
> - return -ENODEV;
> - return cpufreq_register_driver(&elanfreq_driver);
> -}
> -
> -
> -static void __exit elanfreq_exit(void)
> -{
> - cpufreq_unregister_driver(&elanfreq_driver);
> -}
> -
> -
> -module_param(max_freq, int, 0444);
> -
> -MODULE_LICENSE("GPL");
> -MODULE_AUTHOR("Robert Schwebel <r.schwebel@pengutronix.de>, "
> - "Sven Geggus <sven@geggus.net>");
> -MODULE_DESCRIPTION("cpufreq driver for AMD's Elan CPUs");
> -
> -module_init(elanfreq_init);
> -module_exit(elanfreq_exit);
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH v3 1/1] leds: Introduce the multi_max_intensity sysfs attribute
From: Lee Jones @ 2026-05-07 12:31 UTC (permalink / raw)
To: Armin Wolf
Cc: pavel, linux-kernel, corbet, skhan, linux-leds, linux-doc,
jacek.anaszewski, pobrn, m.tretter, wse
In-Reply-To: <20260409210629.9934-2-W_Armin@gmx.de>
On Thu, 09 Apr 2026, Armin Wolf wrote:
> Some multicolor LEDs support global brightness control in hardware,
> meaning that the maximum intensity of the color components is not
> connected to the maximum global brightness. Such LEDs cannot be
> described properly by the current multicolor LED class interface,
> because it assumes that the maximum intensity of each color component
> is described by the maximum global brightness of the LED.
>
> Fix this by introducing a new sysfs attribute called
> "multi_max_intensity" holding the maximum intensity values for the
> color components of a multicolor LED class device. Drivers can use
> the new max_intensity field inside struct mc_subled to tell the
> multicolor LED class code about those values. Intensity values written
> by userspace applications will be limited to this maximum value.
>
> Drivers for multicolor LEDs that do not support global brightness
> control in hardware might still want to use the maximum global LED
> brightness supplied via devicetree as the maximum intensity of each
> individual color component. Such drivers should set max_intensity
> to 0 so that the multicolor LED core can act accordingly.
>
> The lp50xx and ncp5623 LED drivers already use hardware-based control
> for the global LED brightness. Modify those drivers to correctly
> initalize .max_intensity to avoid being limited to the maximum global
> brightness supplied via devicetree.
>
> Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Pretty good overall.
Please fix these small nits and submit with my R-b.
> ---
> .../ABI/testing/sysfs-class-led-multicolor | 19 ++++++--
> Documentation/leds/leds-class-multicolor.rst | 21 ++++++++-
> drivers/leds/led-class-multicolor.c | 47 ++++++++++++++++++-
> drivers/leds/leds-lp50xx.c | 1 +
> drivers/leds/rgb/leds-ncp5623.c | 4 +-
> include/linux/led-class-multicolor.h | 30 +++++++++++-
> 6 files changed, 113 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor b/Documentation/ABI/testing/sysfs-class-led-multicolor
> index 16fc827b10cb..197da3e775b4 100644
> --- a/Documentation/ABI/testing/sysfs-class-led-multicolor
> +++ b/Documentation/ABI/testing/sysfs-class-led-multicolor
> @@ -16,9 +16,22 @@ Date: March 2020
> KernelVersion: 5.9
> Contact: Dan Murphy <dmurphy@ti.com>
> Description: read/write
> - This file contains array of integers. Order of components is
> - described by the multi_index array. The maximum intensity should
> - not exceed /sys/class/leds/<led>/max_brightness.
> + This file contains an array of integers. The order of components
> + is described by the multi_index array. The maximum intensity value
> + supported by each color component is described by the multi_max_intensity
> + file. Writing intensity values larger than the maximum value of a
> + given color component will result in those values being clamped.
> +
> + For additional details please refer to
> + Documentation/leds/leds-class-multicolor.rst.
> +
> +What: /sys/class/leds/<led>/multi_max_intensity
> +Date: March 2026
> +KernelVersion: 7.1
> +Contact: Armin Wolf <W_Armin@gmx.de>
> +Description: read
> + This file contains an array of integers describing the maximum
> + intensity value for each intensity component.
>
> For additional details please refer to
> Documentation/leds/leds-class-multicolor.rst.
> diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst
> index c6b47b4093c4..68340644f80b 100644
> --- a/Documentation/leds/leds-class-multicolor.rst
> +++ b/Documentation/leds/leds-class-multicolor.rst
> @@ -25,10 +25,14 @@ color name to indexed value.
> The ``multi_index`` file is an array that contains the string list of the colors as
> they are defined in each ``multi_*`` array file.
>
> -The ``multi_intensity`` is an array that can be read or written to for the
> +The ``multi_intensity`` file is an array that can be read or written to for the
> individual color intensities. All elements within this array must be written in
> order for the color LED intensities to be updated.
>
> +The ``multi_max_intensity`` file is an array that contains the maximum intensity
> +value supported by each color intensity. Intensity values above this will be
> +automatically clamped into the supported range.
> +
> Directory Layout Example
> ========================
> .. code-block:: console
> @@ -38,6 +42,7 @@ Directory Layout Example
> -r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness
> -r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index
> -rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity
> + -r--r--r-- 1 root root 4096 Oct 19 16:16 multi_max_intensity
>
> ..
>
> @@ -104,3 +109,17 @@ the color LED group.
> 128
>
> ..
> +
> +Writing intensity values larger than the maximum specified in ``multi_max_intensity``
> +will result in those values being clamped into the supported range.
> +
> +.. code-block:: console
> +
> + # cat /sys/class/leds/multicolor:status/multi_max_intensity
> + 255 255 255
> +
> + # echo 512 512 512 > /sys/class/leds/multicolor:status/multi_intensity
> + # cat /sys/class/leds/multicolor:status/multi_intensity
> + 255 255 255
> +
> +..
> diff --git a/drivers/leds/led-class-multicolor.c b/drivers/leds/led-class-multicolor.c
> index 6b671f3f9c61..8d763b1ae76f 100644
> --- a/drivers/leds/led-class-multicolor.c
> +++ b/drivers/leds/led-class-multicolor.c
> @@ -7,10 +7,28 @@
> #include <linux/init.h>
> #include <linux/led-class-multicolor.h>
> #include <linux/math.h>
> +#include <linux/minmax.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> #include <linux/uaccess.h>
>
> +static unsigned int led_mc_get_max_intensity(struct led_classdev_mc *mcled_cdev, size_t index)
> +{
> + unsigned int max_intensity;
> +
> + /* The maximum global brightness value might still be changed by
Nit: Please use proper multi-line comment formatting.
> + * led_classdev_register_ext() using devicetree properties. This
> + * prevents us from changing subled_info[X].max_intensity when
> + * registering a multicolor LED class device, so we have to do
> + * this during runtime.
> + */
> + max_intensity = mcled_cdev->subled_info[index].max_intensity;
> + if (max_intensity)
> + return max_intensity;
> +
> + return mcled_cdev->led_cdev.max_brightness;
> +}
> +
> int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
> enum led_brightness brightness)
> {
> @@ -27,6 +45,27 @@ int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
> }
> EXPORT_SYMBOL_GPL(led_mc_calc_color_components);
>
> +static ssize_t multi_max_intensity_show(struct device *dev,
> + struct device_attribute *intensity_attr, char *buf)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
> + unsigned int max_intensity;
> + int len = 0;
> + int i;
> +
> + for (i = 0; i < mcled_cdev->num_colors; i++) {
Nit: for (int i = 0; ...)
> + max_intensity = led_mc_get_max_intensity(mcled_cdev, i);
> + len += sysfs_emit_at(buf, len, "%u", max_intensity);
> + if (i < mcled_cdev->num_colors - 1)
> + len += sprintf(buf + len, " ");
> + }
> +
> + buf[len++] = '\n';
> + return len;
> +}
> +static DEVICE_ATTR_RO(multi_max_intensity);
> +
> static ssize_t multi_intensity_store(struct device *dev,
> struct device_attribute *intensity_attr,
> const char *buf, size_t size)
> @@ -35,6 +74,7 @@ static ssize_t multi_intensity_store(struct device *dev,
> struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
> int nrchars, offset = 0;
> unsigned int intensity_value[LED_COLOR_ID_MAX];
> + unsigned int max_intensity;
> int i;
> ssize_t ret;
>
> @@ -56,8 +96,10 @@ static ssize_t multi_intensity_store(struct device *dev,
> goto err_out;
> }
>
> - for (i = 0; i < mcled_cdev->num_colors; i++)
> - mcled_cdev->subled_info[i].intensity = intensity_value[i];
> + for (i = 0; i < mcled_cdev->num_colors; i++) {
As above.
> + max_intensity = led_mc_get_max_intensity(mcled_cdev, i);
> + mcled_cdev->subled_info[i].intensity = min(intensity_value[i], max_intensity);
> + }
>
> if (!test_bit(LED_BLINK_SW, &led_cdev->work_flags))
> led_set_brightness(led_cdev, led_cdev->brightness);
> @@ -111,6 +153,7 @@ static ssize_t multi_index_show(struct device *dev,
> static DEVICE_ATTR_RO(multi_index);
>
> static struct attribute *led_multicolor_attrs[] = {
> + &dev_attr_multi_max_intensity.attr,
> &dev_attr_multi_intensity.attr,
> &dev_attr_multi_index.attr,
> NULL,
> diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
> index e2a9c8592953..69c3550f1a31 100644
> --- a/drivers/leds/leds-lp50xx.c
> +++ b/drivers/leds/leds-lp50xx.c
> @@ -525,6 +525,7 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
> }
>
> mc_led_info[multi_index].color_index = color_id;
> + mc_led_info[multi_index].max_intensity = 255;
> num_colors++;
> }
>
> diff --git a/drivers/leds/rgb/leds-ncp5623.c b/drivers/leds/rgb/leds-ncp5623.c
> index 85d6be6fff2b..f2528f06507d 100644
> --- a/drivers/leds/rgb/leds-ncp5623.c
> +++ b/drivers/leds/rgb/leds-ncp5623.c
> @@ -56,8 +56,7 @@ static int ncp5623_brightness_set(struct led_classdev *cdev,
> for (int i = 0; i < mc_cdev->num_colors; i++) {
> ret = ncp5623_write(ncp->client,
> NCP5623_PWM_REG(mc_cdev->subled_info[i].channel),
> - min(mc_cdev->subled_info[i].intensity,
> - NCP5623_MAX_BRIGHTNESS));
> + mc_cdev->subled_info[i].intensity);
> if (ret)
> return ret;
> }
> @@ -190,6 +189,7 @@ static int ncp5623_probe(struct i2c_client *client)
> goto release_led_node;
>
> subled_info[ncp->mc_dev.num_colors].channel = reg;
> + subled_info[ncp->mc_dev.num_colors].max_intensity = NCP5623_MAX_BRIGHTNESS;
> subled_info[ncp->mc_dev.num_colors++].color_index = color_index;
> }
>
> diff --git a/include/linux/led-class-multicolor.h b/include/linux/led-class-multicolor.h
> index db9f34c6736e..45469388bb1a 100644
> --- a/include/linux/led-class-multicolor.h
> +++ b/include/linux/led-class-multicolor.h
> @@ -9,10 +9,31 @@
> #include <linux/leds.h>
> #include <dt-bindings/leds/common.h>
>
> +/**
> + * struct mc_subled - Color component description.
> + * @color_index: Color ID.
> + * @brightness: Scaled intensity.
> + * @intensity: Current intensity.
> + * @max_intensity: Maximum supported intensity value.
> + * @channel: Channel index.
> + *
> + * Describes a color component of a multicolor LED. Many multicolor LEDs
> + * do no support global brightness control in hardware, so they use
Nit: "not"
> + * the brightness field in connection with led_mc_calc_color_components()
> + * to perform the intensity scaling in software.
> + * Such drivers should set max_intensity to 0 to signal the multicolor LED core
> + * that the maximum global brightness of the LED class device should be used for
> + * limiting incoming intensity values.
> + *
> + * Multicolor LEDs that do support global brightness control in hardware
> + * should instead set max_intensity to the maximum intensity value supported
> + * by the hardware for a given color component.
> + */
> struct mc_subled {
> unsigned int color_index;
> unsigned int brightness;
> unsigned int intensity;
> + unsigned int max_intensity;
> unsigned int channel;
> };
>
> @@ -53,7 +74,14 @@ int led_classdev_multicolor_register_ext(struct device *parent,
> */
> void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev);
>
> -/* Calculate brightness for the monochrome LED cluster */
> +/**
> + * led_mc_calc_color_components() - Calculates component brightness values of a LED cluster.
> + * @mcled_cdev - Multicolor LED class device of the LED cluster.
> + * @brightness - Global brightness of the LED cluster.
> + *
> + * Calculates the brightness values for each color component of a monochrome LED cluster,
> + * see Documentation/leds/leds-class-multicolor.rst for details.
> + */
> int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
> enum led_brightness brightness);
>
> --
> 2.39.5
>
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v7 6/6] ARM: zte: defconfig: Add a zx29 defconfig file
From: Linus Walleij @ 2026-05-07 12:24 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, linux-serial
In-Reply-To: <5379905.31r3eYUQgx@strix>
Hi Stefan,
On Wed, May 6, 2026 at 7:39 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> I'll send a v8 with some of Sashiko's (very impressive)
> findings but keep the defconfig.
Maybe not send all patches to soc@kernel.org right now because they
end up in the patch tracker.
For a new platform that may be OK though...
Nominall it should be three pull requests:
1. Platform
2. DTS files
3. Defconfig
But in this case maybe it is better if we cherry-pick them to the
SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 1/2] rust: task: clarify comments on task UID accessors
From: Alice Ryhl @ 2026-05-07 12:03 UTC (permalink / raw)
To: Gary Guo
Cc: Paul Moore, Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman,
Shuah Khan, Alex Shi, Yanteng Si, Dongliang Mu, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Jann Horn, linux-security-module,
linux-doc, linux-kernel, rust-for-linux
In-Reply-To: <DICEBGUAU4OT.244JDJIKXRHBS@garyguo.net>
On Thu, May 07, 2026 at 12:08:35PM +0100, Gary Guo wrote:
> On Thu May 7, 2026 at 10:48 AM BST, Alice Ryhl wrote:
> > - /// Returns the UID of the given task.
> > + /// Returns the objective real UID of the given task.
> > #[inline]
> > pub fn uid(&self) -> Kuid {
> > // SAFETY: It's always safe to call `task_uid` on a valid task.
> > Kuid::from_raw(unsafe { bindings::task_uid(self.as_ptr()) })
> > }
> >
> > - /// Returns the effective UID of the given task.
> > + /// Returns the objective effective UID of the given task.
> > + ///
> > + /// You should probably not be using this; the effective UID is normally
> > + /// only relevant in subjective credentials.
> > #[inline]
> > pub fn euid(&self) -> Kuid {
> > // SAFETY: It's always safe to call `task_euid` on a valid task.
> > @@ -371,7 +374,7 @@ fn eq(&self, other: &Self) -> bool {
> > impl Eq for Task {}
> >
> > impl Kuid {
> > - /// Get the current euid.
> > + /// Get the current subjective euid.
>
> For consistency this should be "subjective effective UID".
I can update this for the next version.
Alice
^ permalink raw reply
* RE: [PATCH v9 5/6] iio: adc: ad4691: add oversampling support
From: Sabau, Radu bogdan @ 2026-05-07 11:56 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-5-33e439e4fb87@analog.com>
Addressing Sashiko's review for the oversampling support patch.
> -----Original Message-----
> From: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org>
> Sent: Thursday, April 30, 2026 1:17 PM
...
> +/* CNV burst mode channel — exposes oversampling ratio. */
> #define AD4691_CHANNEL(ch)
> \
> + { \
> + .type = IIO_VOLTAGE, \
> + .indexed = 1, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> \
> +
> BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO) | \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .info_mask_separate_available =
> \
> +
> BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO) | \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
"The IIO_CHAN_INFO_SAMP_FREQ attribute is exported with info_mask_separate,
implying per-channel independence. However, writing to sampling_frequency
updates st->target_osc_freq_Hz, a global variable shared by all channels.
Does modifying this global variable on one channel silently alter the
effective sampling rate of all other channels? Should this use
info_mask_shared_by_all to comply with the IIO ABI?"
info_mask_separate is intentional here. The oscillator is shared, but
the effective output rate is genuinely per-channel: osc_freq / osr[N].
Writing in_voltageN_sampling_frequency sets the oscillator (which changes
the read-back for all channels), but reading it back for any channel always
returns osc_freq / osr[N] — a value specific to that channel's OSR. The
oscillator snaps to the largest table entry <= freq * osr[N] that is evenly
divisible by osr[N], so the read-back is always an integer for the channel
that drove the write. The same trade-off is present in ad4695.
info_mask_separate is the correct annotation for this per-channel view.
> + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> \
> + .channel = ch, \
> + .scan_index = ch, \
> + .scan_type = { \
> + .sign = 'u', \
> + .realbits = 16, \
> + .storagebits = 16, \
> + .endianness = IIO_BE, \
> + }, \
> + }
> +
...
> static int ad4691_read_avail(struct iio_dev *indio_dev,
> @@ -540,10 +655,30 @@ static int ad4691_read_avail(struct iio_dev
> *indio_dev,
> unsigned int start = ad4691_samp_freq_start(st->info);
>
> switch (mask) {
> - case IIO_CHAN_INFO_SAMP_FREQ:
> - *vals = &ad4691_osc_freqs_Hz[start];
> + case IIO_CHAN_INFO_SAMP_FREQ: {
> + unsigned int osr = st->osr[chan->channel];
> + int n = 0;
> +
> + /*
> + * Only oscillator frequencies evenly divisible by the channel's
> + * OSR yield an integer effective rate; expose those as effective
> + * rates (osc / osr) so the user works entirely in output-sample
> + * space.
> + */
> + for (unsigned int i = start; i <
> ARRAY_SIZE(ad4691_osc_freqs_Hz); i++) {
> + if (ad4691_osc_freqs_Hz[i] % osr != 0)
> + continue;
> + st->samp_freq_avail[n++] = ad4691_osc_freqs_Hz[i] /
> osr;
> + }
> + *vals = st->samp_freq_avail;
"The IIO core calls read_avail() without holding driver-level locks that
serialize sysfs reads. Can concurrent reads of
in_voltageN_sampling_frequency_available for channels with different OSR
values race and overwrite st->samp_freq_avail simultaneously?
This could result in interleaved or corrupted output being formatted by the
IIO core and sent to userspace. Is a per-channel array or synchronization
required here?"
Valid. Sysfs serializes reads to the same sysfs file but not across
different channel _available files. Concurrent reads of
in_voltage0_sampling_frequency_available and
in_voltage1_sampling_frequency_available (with different OSRs) raced on
the shared samp_freq_avail[] scratch array. Made it a 2D array
[16][N_OSC_ENTRIES] so each channel has its own sub-array; concurrent
reads for different channels no longer interfere.
> *type = IIO_VAL_INT;
> - *length = ARRAY_SIZE(ad4691_osc_freqs_Hz) - start;
> + *length = n;
> + return IIO_AVAIL_LIST;
...
> @@ -634,9 +780,29 @@ static int ad4691_write_raw(struct iio_dev
> *indio_dev,
> struct iio_chan_spec const *chan,
> int val, int val2, long mask)
> {
> + struct ad4691_state *st = iio_priv(indio_dev);
> +
> switch (mask) {
> case IIO_CHAN_INFO_SAMP_FREQ:
> - return ad4691_set_sampling_freq(indio_dev, val);
> + return ad4691_set_sampling_freq(indio_dev, chan, val);
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO: {
> + IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
> + if (IIO_DEV_ACQUIRE_FAILED(claim))
> + return -EBUSY;
> +
> + for (unsigned int i = 0; i <
> ARRAY_SIZE(ad4691_oversampling_ratios); i++) {
> + if (ad4691_oversampling_ratios[i] != val)
> + continue;
> + /*
> + * Store the new OSR; target_osc_freq_Hz is
> unchanged.
> + * The effective rate read back via
> in_voltageN_sampling_frequency
> + * becomes target_osc_freq_Hz / new_osr
> automatically.
> + */
> + st->osr[chan->channel] = val;
"Writing oversampling_ratio updates osr but leaves target_osc_freq_Hz
unchanged. Does this break the target_osc_freq_Hz % osr == 0 guarantee
enforced in ad4691_set_sampling_freq()?
Reading sampling_frequency after this could yield a truncated integer. If
that exact integer is written back, it might compute a smaller oscillator
requirement and snap the device to a different, lower oscillator frequency.
Does modifying oversampling_ratio need to recalculate target_osc_freq_Hz
to maintain state consistency?"
Valid. Storing a new OSR without updating target_osc_freq_Hz can
break the target_osc_freq_Hz % osr == 0 invariant. For example with
target_osc_freq_Hz = 250 kHz and new OSR = 32: read-back is
250000 / 32 = 7812 (truncated); writing that value back computes
needed_osc = 249984, snapping the oscillator to the next lower table
entry — a silent frequency change on what the user expected to be a
no-op write-back.
Fixed: the OVERSAMPLING_RATIO write path now calls ad4691_find_osc_freq()
with old_effective * new_osr as the ceiling, where
old_effective = target_osc_freq_Hz / old_osr. This preserves the
divisibility invariant and keeps the oscillator as close as possible to
the previous effective rate.
> + return 0;
> + }
> + return -EINVAL;
> + }
> default:
> return -EINVAL;
> }
> @@ -691,6 +857,10 @@ static int ad4691_enter_conversion_mode(struct
> ad4691_state *st)
> return regmap_update_bits(st->regmap,
> AD4691_DEVICE_SETUP,
> AD4691_MANUAL_MODE,
> AD4691_MANUAL_MODE);
>
> + ret = ad4691_write_osc_freq(st);
> + if (ret)
> + return ret;
> +
> ret = regmap_update_bits(st->regmap, AD4691_ADC_SETUP,
> AD4691_ADC_MODE_MASK,
> AD4691_CNV_BURST_MODE);
> if (ret)
> @@ -844,6 +1014,12 @@ static int
> ad4691_cnv_burst_buffer_preenable(struct iio_dev *indio_dev)
> if (ret)
> goto err_unoptimize;
>
> + iio_for_each_active_channel(indio_dev, i) {
> + ret = regmap_write(st->regmap, AD4691_ACC_DEPTH_IN(i),
> st->osr[i]);
> + if (ret)
> + goto err_unoptimize;
> + }
> +
"If the IIO soft timestamp channel is enabled, its scan_index is 16.
iio_for_each_active_channel() iterates over all active channels including
the timestamp channel.
Will this loop process i = 16 and access st->osr[16] out of bounds, since
st->osr is an array of size 16?
Additionally, since AD4691_ACC_DEPTH_IN(16) resolves to 0x196
(AD4691_GPIO_MODE1_REG), will this silently corrupt the GPIO configuration
and potentially break the DATA_READY interrupt?
Furthermore, does the presence of the timestamp channel cause the loop
iteration to advance k to 17, making the state-reset SPI transfers appended
after the loop write to st->scan_xfers[34] and [35]? This would overflow
the scan_xfers array which is sized 34 and could corrupt the surrounding
struct ad4691_state."
Valid for the osr[] out-of-bounds and GPIO corruption concerns. With
the soft timestamp enabled (scan_index = 16), the loop would access
st->osr[16] out-of-bounds and write to AD4691_ACC_DEPTH_IN(16) = 0x196,
which is AD4691_GPIO_MODE1_REG, silently corrupting the GPIO configuration
and potentially breaking the DATA_READY interrupt.
Added the same guard used by the scan_xfers loops in the triggered-buffer
commit: if (i >= indio_dev->num_channels - 1) break.
The scan_xfers k-overflow concern is already handled by that existing guard
in a separate loop — it is not affected by the ACC_DEPTH_IN loop added
here.
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Boris Brezillon @ 2026-05-07 11:53 UTC (permalink / raw)
To: Marcin Ślusarz
Cc: Ketil Johnsen, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jonathan Corbet, Shuah Khan,
Sumit Semwal, Benjamin Gaignard, Brian Starkey, John Stultz,
T.J. Mercier, Christian König, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek,
Florent Tomasin, nd
In-Reply-To: <afxVIuVVPisBQ9p_@e129842.arm.com>
On Thu, 7 May 2026 11:02:26 +0200
Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > return ret;
> > > }
> > >
> > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > + if (protected_heap_name && strlen(protected_heap_name)) {
> >
> > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > name is "" already?
>
> If dma_heap_find() will fail, then the whole probe with fail too.
> This check prevents that.
Yeah, that's also a questionable design choice. I mean, we can
currently probe and boot the FW even though we never setup the
protected FW sections, so why should we defer the probe here? Can't we
just retry the next time a group with the protected bit is created and
fail if we can find a protected heap?
> I'm not sure why it's needed at all, but if
> it is really needed, then s/strlen(protected_heap_name)/protected_heap_name[0]/
> would simplify this.
It's not so much about how you do the test, and more about the case
you're trying to protect against. I guess here you assume that
panthor.protected_heap_name="" means "I don't have a protected heap for
you". If it's deemed acceptable, this should most certainly be
described somewhere.
>
> > > + ptdev->protm.heap = dma_heap_find(protected_heap_name);
> > > + if (!ptdev->protm.heap) {
> > > + drm_warn(&ptdev->base,
> > > + "Protected heap \'%s\' not (yet) available - deferring probe",
> > > + protected_heap_name);
> > > + ret = -EPROBE_DEFER;
> > > + goto err_rpm_put;
> >
> > If you move the heap retrieval before the rpm enablement, you can get
> > rid of this goto err_rpm_put.
> >
> > > + }
> > > + }
> > > +
> > > ret = panthor_hw_init(ptdev);
> > > if (ret)
> > > - goto err_rpm_put;
> > > + goto err_dma_heap_put;
> > >
> > > ret = panthor_pwr_init(ptdev);
> > > if (ret)
^ permalink raw reply
* Re: Regression due to /sys/kernel/dmabuf/buffers removal
From: T.J. Mercier @ 2026-05-07 11:52 UTC (permalink / raw)
To: Christian König
Cc: Julian Orth, corbet, dri-devel, linaro-mm-sig, linux-doc,
linux-kernel, linux-media, Sumit Semwal
In-Reply-To: <b9c1b7a3-12a8-4104-b98f-a1e57b343046@amd.com>
On Thu, May 7, 2026 at 4:35 AM Christian König <christian.koenig@amd.com> wrote:
>
> On 5/5/26 16:32, T.J. Mercier wrote:
> > On Tue, May 5, 2026 at 6:00 AM Julian Orth <ju.orth@gmail.com> wrote:
> >>
> >> On Tue, May 5, 2026 at 2:41 PM Christian König <christian.koenig@amd.com> wrote:
> >>>
> >>> Hi Julian,
> >>>
> >>> On 5/5/26 14:25, Julian Orth wrote:
> >>>> In ab4c3dcf9a71582503b4fb25aeab884c696cab25 ("dma-buf: Remove DMA-BUF
> >>>> sysfs stats") the /sys/kernel/dmabuf/buffer directory was removed.
> >>>>
> >>>> I've been using this interface, specifically the exporter_name file,
> >>>> to detect dmabufs created via udmabuf. Such dmabufs show "udmabuf" in
> >>>> exporter_name. I've been doing this for two reasons: 1) to detect that
> >>>> mmap on such buffers will be fast and 2) to detect that GPU access to
> >>>> such buffers will be slow.
> >>>
> >>> Crap, I really hoped that Android was the only user of that sysfs interface since that approach turned out to be quite broken.
> >>>
> >>> It's number one rule on Linux that we don't break userspace. So I hope that you don't insist on bringing that interface back, but if you do I will just revert the removal until we found a better solution.
> >>
> >> Bringing it back shouldn't be necessary.
> >>
> >>>
> >>>> With the removal of that file, that detection mechanism no longer works.
> >>>>
> >>>> I'm not particularly fond of that mechanism but it was the only one
> >>>> providing that functionality that I could find at the time. If there
> >>>> is another one, ideally an ioctl on the dmabuf, please let me know.
> >>>
> >>> The virtual fdinfo file you can find under /proc/$pid/fdinfo/$fd also contains the exporter name for the DMA-buf.
> >>>
> >>> You can find the full documentation here: https://docs.kernel.org/filesystems/proc.html#dma-buffer-files
> >>>
> >>> Is that sufficient?
> >>
> >> I think that is sufficient. I probably didn't use fdinfo initially
> >> because 1) it's a lot more work to parse and 2) I wasn't sure if it
> >> was intended to be machine-readable or if there could sometimes be
> >> newlines in the values and such.
> >>
> >>>
> >>> Additional to that the debugfs for DMA-buf also contains that information and I'm open to the suggestion with the IOCTL.
> >>
> >> My application runs as a regular user so it cannot access /sys/kernel/debug.
> >>
> >> Having an IOCTL would be ideal if it is not too much work. I'll fall
> >> back to fdinfo for now.
> >>
> >> Thanks, Julian
> >
> > Phew, I'm glad fdinfo suits your needs.
>
> Yeah, exactly my thinking as well :)
>
> A college questioned me this week how to find DMA-buf stats for debugging and it turned out that Google points to the outdated DMA-buf sysfs documentation instead of the debugfs one.
>
> No idea why, maybe we need to improve the documentation here a bit.
Ah, this? https://source.android.com/docs/core/graphics/implement-dma-buf-gpu-mem
I will update it to mark it as deprecated, and only applicable to
kernels < 6.18 where CONFIG_DMABUF_SYSFS_STATS was first disabled.
source.android.com updates are usually released with the platform,
which is very soon for Android 17.
> > Adding an ioctl would introduce new UAPI so I think we'd want to avoid
> > that unless absolutely necessary.
>
> CRIU has some similar requirements, e.g. they need to know the exporting driver of a DMA-buf.
>
> Not sure if the fdinfo file will be sufficient for that case or not. But yeah I agree that we only need this if actually necessary.
>
> Regards,
> Christian.
>
> >
> > Thanks,
> > T.J.
> >
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>>>
> >>>> Shipping an entire BPF compiler in my application, which the original
> >>>> patch suggests as the replacement, is not an option when the removed
> >>>> alternative was simply reading a file.
> >>>>
> >>>> Thanks, Julian
> >>>
>
^ permalink raw reply
* RE: [PATCH v9 4/6] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-05-07 11:49 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-4-33e439e4fb87@analog.com>
Addressing Sashiko's review for the offload support patch.
> -----Original Message-----
> From: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org>
> Sent: Thursday, April 30, 2026 1:17 PM
...
> All offload transfers use 16-bit frames (bits_per_word=16, len=2).
> The channel scan_type (storagebits=16, shift=0, IIO_BE) is shared
> between the software triggered-buffer and offload paths; no separate
> scan_type or channel array is needed for the offload case. The
> ad4691_manual_channels[] array introduced in the triggered-buffer
> commit is reused here: it hides the IIO_CHAN_INFO_OVERSAMPLING_RATIO
> attribute, which is not applicable in Manual Mode.
"This isn't a bug, but ad4691_manual_channels and the oversampling attribute
don't appear to exist in this driver. Was this copied from another driver?"
Agreed on the commit message as per Jonathan's input as well.
Removed the two sentences referencing ad4691_manual_channels[] and
IIO_CHAN_INFO_OVERSAMPLING_RATIO — both were carried over from a
draft that included OSR support, which was split into the following commit.
The updated message now calls out explicitly that per-mode channel array
distinctions and oversampling support are introduced in the next commit.
>
> Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
> ---
> drivers/iio/adc/Kconfig | 2 +
> drivers/iio/adc/ad4691.c | 392
> ++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 389 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index d498f16c0816..fdc6565933c5 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -143,8 +143,10 @@ config AD4691
> tristate "Analog Devices AD4691 Family ADC Driver"
> depends on SPI
> select IIO_BUFFER
> + select IIO_BUFFER_DMAENGINE
> select IIO_TRIGGERED_BUFFER
> select REGMAP
> + select SPI_OFFLOAD
> help
> Say yes here to build support for Analog Devices AD4691 Family
> MuxSAR
> SPI analog to digital converters (ADC).
> diff --git a/drivers/iio/adc/ad4691.c b/drivers/iio/adc/ad4691.c
> index c1e3406fef18..50d81d87d4a0 100644
> --- a/drivers/iio/adc/ad4691.c
> +++ b/drivers/iio/adc/ad4691.c
> @@ -23,10 +23,14 @@
...
> +struct ad4691_offload_state {
> + struct spi_offload *offload;
> + struct spi_offload_trigger *trigger;
> + u64 trigger_hz;
> + u8 tx_cmd[17][2];
> + u8 tx_reset[4];
> };
"Could using these buffers for DMA transfers cause memory corruption on
architectures with non-coherent caches?
They are not marked with __aligned(IIO_DMA_MINALIGN), so they share cachelines
with each other and adjacent struct members like trigger_hz."
Valid. struct ad4691_offload_state is allocated with devm_kzalloc
which does not guarantee cache-line alignment, so tx_cmd and tx_reset
shared cache lines with trigger_hz and the pointer fields. Removed both
from ad4691_offload_state entirely. The existing scan_tx[17] field in
struct ad4691_state is large enough for all 17 AVG_IN addresses and is
already __aligned(IIO_DMA_MINALIGN); reused it for the offload TX
commands (the two paths are mutually exclusive at probe).
>
> struct ad4691_state {
> @@ -252,7 +286,10 @@ struct ad4691_state {
> * transfers in one go.
> */
> struct spi_message scan_msg;
...
> +
> +static int ad4691_cnv_burst_offload_buffer_postenable(struct iio_dev
> *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + struct ad4691_offload_state *offload = st->offload;
> + struct device *dev = regmap_get_device(st->regmap);
> + struct spi_device *spi = to_spi_device(dev);
...
> + /* TX: address phase, CS stays asserted into data phase */
> + st->scan_xfers[2 * k].tx_buf = offload->tx_cmd[k];
> + st->scan_xfers[2 * k].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k].bits_per_word = bpw;
"When bits_per_word is greater than 8 (like bpw = 16 here), the SPI framework
treats tx_buf as an array of native 16-bit words.
On little-endian architectures, the controller will byte-swap the data before
transmitting it. Will using a u8 array and put_unaligned_be16() result in the
command bytes being reversed on the wire?"
Switched to cpu_to_be16() assigned directly into __be16 scan_tx[],
matching the non-offload path. This makes the intended wire format
self-evident and sidesteps the byte-ordering question entirely.
> +
> + /* RX: data phase, CS toggles after to delimit the next register
> op */
> + st->scan_xfers[2 * k + 1].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k + 1].bits_per_word = bpw;
> + st->scan_xfers[2 * k + 1].offload_flags =
> SPI_OFFLOAD_XFER_RX_STREAM;
> + st->scan_xfers[2 * k + 1].cs_change = 1;
> + k++;
> + }
> +
> + /* State reset to re-arm DATA_READY for the next scan. */
> + put_unaligned_be16(AD4691_STATE_RESET_REG, offload->tx_reset);
> + offload->tx_reset[2] = AD4691_STATE_RESET_ALL;
> +
> + st->scan_xfers[2 * k].tx_buf = offload->tx_reset;
> + st->scan_xfers[2 * k].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k].bits_per_word = bpw;
> +
> + st->scan_xfers[2 * k + 1].tx_buf = &offload->tx_reset[2];
> + st->scan_xfers[2 * k + 1].len = sizeof(offload->tx_cmd[k]);
"Will passing &offload->tx_reset[2] directly as tx_buf cause DMA mapping
issues, since it is only 2-byte aligned?"
Addressed by the second concern's fix: no sub-aligned pointer into the middle
of a DMA buffer — the full 4-byte scan_tx_reset[] is passed as tx_buf
from its own cache-line-aligned start address.
> + st->scan_xfers[2 * k + 1].bits_per_word = bpw;
> + st->scan_xfers[2 * k + 1].cs_change = 1;
The ADI SPI Engine always deasserts CS at the end of its programmed
sequence regardless, though I will drop this in order to avoid confusion.
> +
> + spi_message_init_with_transfers(&st->scan_msg, st->scan_xfers, 2 * k
> + 2);
> + st->scan_msg.offload = offload->offload;
> +
> + ret = spi_optimize_message(spi, &st->scan_msg);
> + if (ret)
> + goto err_exit_conversion;
> +
> + ret = ad4691_sampling_enable(st, true);
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = spi_offload_trigger_enable(offload->offload, offload->trigger,
> &config);
"If the PWM starts generating DATA_READY trigger edges in ad4691_sampling_enable
before the SPI offload trigger is enabled, could the offload engine miss the
first trigger edge?
If that first edge is missed, wouldn't the DATA_READY line remain permanently
asserted (because the STATE_RESET command is never sent), deadlocking the
entire capture?"
Valid. Swapped the order: spi_offload_trigger_enable() first, then
ad4691_sampling_enable(), so the offload engine is armed before the first
CNV pulse fires. Without this, if DATA_READY asserts in the window between
sampling_enable() and trigger_enable(), the SPI Engine misses the rising
edge and the capture deadlocks.
> + if (ret)
> + goto err_sampling_disable;
> +
> + return 0;
> +
> +err_sampling_disable:
> + ad4691_sampling_enable(st, false);
> +err_unoptimize:
> + spi_unoptimize_message(&st->scan_msg);
> +err_exit_conversion:
> + ad4691_exit_conversion_mode(st);
> + return ret;
> +}
> +
> +static int ad4691_cnv_burst_offload_buffer_predisable(struct iio_dev
> *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + struct ad4691_offload_state *offload = st->offload;
> + int ret;
> +
> + spi_offload_trigger_disable(offload->offload, offload->trigger);
> +
> + ret = ad4691_sampling_enable(st, false);
> + if (ret)
> + return ret;
> +
> + spi_unoptimize_message(&st->scan_msg);
"If ad4691_sampling_enable() fails and returns early, won't this bypass
spi_unoptimize_message() and permanently leak the DMA mappings and memory
allocated during SPI message optimization?"
Valid. spi_unoptimize_message() is now always called before returning
from predisable, regardless of sampling_enable() result.
> +
> + return ad4691_exit_conversion_mode(st);
> +}
> +
> +static const struct iio_buffer_setup_ops
> ad4691_cnv_burst_offload_buffer_setup_ops = {
> + .postenable = &ad4691_cnv_burst_offload_buffer_postenable,
> + .predisable = &ad4691_cnv_burst_offload_buffer_predisable,
> +};
> +
> static ssize_t sampling_frequency_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -810,6 +1093,9 @@ static ssize_t sampling_frequency_show(struct
> device *dev,
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct ad4691_state *st = iio_priv(indio_dev);
>
> + if (st->manual_mode && st->offload)
> + return sysfs_emit(buf, "%llu\n", st->offload->trigger_hz);
Valid. Using READ_ONCE in show and WRITE_ONCE in store for trigger_hz;
on 32-bit architectures a bare u64 read/write is not atomic.
> +
> return sysfs_emit(buf, "%lu\n", NSEC_PER_SEC / st->cnv_period_ns);
> }
>
> @@ -829,6 +1115,19 @@ static ssize_t sampling_frequency_store(struct
> device *dev,
> if (IIO_DEV_ACQUIRE_FAILED(claim))
> return -EBUSY;
>
> + if (st->manual_mode && st->offload) {
> + struct spi_offload_trigger_config config = {
> + .type = SPI_OFFLOAD_TRIGGER_PERIODIC,
> + .periodic = { .frequency_hz = freq },
> + };
"Does this code safely handle zero or negative inputs?
kstrtoint parses freq as a signed int, and the existing validation
(if (!freq) return -EINVAL) is bypassed for the offload path.
A negative value would sign-extend to a massive u64 value when assigned to
frequency_hz."
Addressed per previous patch.
> +
> + ret = spi_offload_trigger_validate(st->offload->trigger,
> &config);
...
> - ret = ad4691_setup_triggered_buffer(indio_dev, st);
> + if (spi_offload) {
> + indio_dev->channels = st->info->offload_info->channels;
> + indio_dev->num_channels = st->info->offload_info-
> >num_channels;
> + ret = ad4691_setup_offload(indio_dev, st, spi_offload);
"The offload path reuses the existing channels array which defines
scan_type.endianness = IIO_BE.
Since the SPI offload DMA RX stream delivers data as native 16-bit words,
which are little-endian on LE platforms, will the IIO subsystem incorrectly
byte-swap the native data before passing it to userspace?"
Agreed. AD4691_CHANNEL no longer sets .endianness, matching the
ad4695 approach and defaulting to IIO_CPU.
^ permalink raw reply
* Re: (subset) [PATCH] docs: leds: fix sysfs ABI reference in lp5812.rst
From: Lee Jones @ 2026-05-07 11:46 UTC (permalink / raw)
To: linux-leds, Xinhong Hu
Cc: lee, linux-doc, skhan, linux-kernel-mentees, jkoolstra, me
In-Reply-To: <tencent_26F6155ED10CA20CC65F62FD659218853809@qq.com>
On Thu, 23 Apr 2026 18:39:10 +0800, Xinhong Hu wrote:
> Documentation/ABI/testing/sysfs-class-led-multicolor is a plain ABI
> description without a .rst suffix. The lp5812 documentation incorrectly
> referred to sysfs-class-led-multicolor.rst, which does not exist.
>
> This was reported by documentation-file-ref-check (make refcheckdocs).
>
>
> [...]
Applied, thanks!
[1/1] docs: leds: fix sysfs ABI reference in lp5812.rst
commit: 1f05106ff812466b491f2a8db752a06457878bf9
--
Lee Jones [李琼斯]
^ permalink raw reply
* RE: [PATCH v9 3/6] iio: adc: ad4691: add triggered buffer support
From: Sabau, Radu bogdan @ 2026-05-07 11:37 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-3-33e439e4fb87@analog.com>
Addressing Sashiko's review for triggered buffer patch.
> -----Original Message-----
> From: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org>
> Sent: Thursday, April 30, 2026 1:17 PM
...
> +static int ad4691_manual_buffer_preenable(struct iio_dev *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + unsigned int prev_i, k, i;
> + bool first;
> + int ret;
> +
> + memset(st->scan_xfers, 0, sizeof(st->scan_xfers));
> + memset(st->scan_tx, 0, sizeof(st->scan_tx));
> +
> + spi_message_init(&st->scan_msg);
> +
> + first = true;
> + prev_i = 0;
> + k = 0;
> + iio_for_each_active_channel(indio_dev, i) {
> + st->scan_tx[k] = cpu_to_be16(AD4691_ADC_CHAN(i));
> + st->scan_xfers[k].tx_buf = &st->scan_tx[k];
> + /*
> + * The pipeline means xfer[0] receives the residual from the
> + * previous sequence, not a valid sample for channel i. Point
> + * it at vals[i] anyway; xfer[1] (or the NOOP when only one
> + * channel is active) will overwrite that slot with the real
> + * result, so no separate dummy buffer is needed.
> + */
> + if (first) {
> + st->scan_xfers[k].rx_buf = &st->vals[i];
> + first = false;
> + } else {
> + st->scan_xfers[k].rx_buf = &st->vals[prev_i];
> + }
"The IIO subsystem expects data pushed to the buffer to be densely packed
according to the active channels in the scan mask.
If only a subset of channels are enabled, does assigning the rx_buf pointer
directly to absolute array indices at &st->vals[i] leave holes in the buffer?
When iio_push_to_buffers_with_ts() is called, this might cause it to read
uninitialized memory instead of the expected samples."
I would say there is no change needed. Writing to &st->vals[scan_index] and
passing the full array to iio_push_to_buffers_with_ts() is the standard IIO kfifo
pattern: the core demultiplexes by reading data[scan_index * storagebits/8]
for each active channel; holes at inactive indices are silently ignored.
The same pattern is used in ad4695, ad_sigma_delta, and others. The
pipeline residual in the first manual-mode transfer is overwritten by the
subsequent transfer before the scan is pushed, as the comment explains.
> + st->scan_xfers[k].len = sizeof(__be16);
> + st->scan_xfers[k].cs_change = 1;
> + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
> + prev_i = i;
> + k++;
> + }
> +
...
> +static int ad4691_cnv_burst_buffer_preenable(struct iio_dev *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + unsigned int k, i;
> + int ret;
> +
> + memset(st->scan_xfers, 0, sizeof(st->scan_xfers));
> + memset(st->scan_tx, 0, sizeof(st->scan_tx));
> +
> + spi_message_init(&st->scan_msg);
> +
> + /*
> + * Each AVG_IN read needs two transfers: a 2-byte address write phase
> + * followed by a 2-byte data read phase. CS toggles between channels
> + * (cs_change=1 on the read phase of all but the last channel).
> + */
> + k = 0;
> + iio_for_each_active_channel(indio_dev, i) {
> + st->scan_tx[k] = cpu_to_be16(0x8000 | AD4691_AVG_IN(i));
> + st->scan_xfers[2 * k].tx_buf = &st->scan_tx[k];
> + st->scan_xfers[2 * k].len = sizeof(__be16);
> + spi_message_add_tail(&st->scan_xfers[2 * k], &st-
> >scan_msg);
> + st->scan_xfers[2 * k + 1].rx_buf = &st->vals[i];
> + st->scan_xfers[2 * k + 1].len = sizeof(__be16);
> + st->scan_xfers[2 * k + 1].cs_change = 1;
> + spi_message_add_tail(&st->scan_xfers[2 * k + 1], &st-
> >scan_msg);
> + k++;
> + }
> +
> + st->scan_tx[k] = cpu_to_be16(AD4691_STATE_RESET_REG);
> + st->scan_xfers[2 * k].tx_buf = &st->scan_tx[k];
> + st->scan_xfers[2 * k].len = sizeof(__be16);
> + spi_message_add_tail(&st->scan_xfers[2 * k], &st->scan_msg);
> + st->scan_tx[k + 1] = cpu_to_be16(AD4691_STATE_RESET_ALL << 8);
"Does the iio_for_each_active_channel() loop iterate over the soft timestamp
channel if it is enabled?
If the soft timestamp channel is enabled, k would reach 17. Because
st->scan_tx is sized for 18 elements, does writing to st->scan_tx[k + 1] and
st->scan_xfers[2 * k + 1] overflow the bounds of these arrays?"
Valid defensive concern. With all data channels + timestamp enabled,
the loop iterates scan_index=16 (timestamp), pushing k to 17, and the
state-reset then accesses scan_xfers[34] which is out-of-bounds (array is
sized 34). Fixed by adding a guard to break out of the loop when
i >= num_channels - 1 (the timestamp scan_index), consistent with how
both ad4691_channels and ad4693_channels are laid out.
"Also, the AD4691 auto-decrements register addresses on multi-byte writes.
Could writing a 2-byte payload to the 1-byte AD4691_STATE_RESET_REG (0x181)
inadvertently write 0x00 to the adjacent lower register 0x180
(AD4691_OSC_EN_REG), disabling the internal oscillator?"
Real bug. The two back-to-back 2-byte transfers ([0x01,0x81] then
[0x01,0x00]) are sent with CS continuously asserted, so the chip sees a
4-byte write: 0x01 to STATE_RESET_REG and 0x00 to OSC_EN_REG, disabling
the oscillator mid-scan. Fixed by using a single 4-byte transfer
[addr_hi, addr_lo, STATE_RESET_ALL, OSC_EN=1] in a dedicated
u8 scan_tx_reset[4] field. The fourth byte deliberately re-enables
OSC_EN_REG (0x180) via ADDR_DESCENDING as a side-write, keeping the
oscillator enabled. This same buffer is reused by the offload path in
the following commit (the two paths are mutually exclusive at probe).
> + st->scan_xfers[2 * k + 1].tx_buf = &st->scan_tx[k + 1];
> + st->scan_xfers[2 * k + 1].len = sizeof(__be16);
> + st->scan_xfers[2 * k + 1].cs_change = 1;
> + spi_message_add_tail(&st->scan_xfers[2 * k + 1], &st->scan_msg);
> +
> + ret = spi_optimize_message(st->spi, &st->scan_msg);
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(st->regmap, AD4691_STD_SEQ_CONFIG,
> + bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)));
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG,
> + ~bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)) &
> GENMASK(15, 0));
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = ad4691_enter_conversion_mode(st);
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = ad4691_sampling_enable(st, true);
> + if (ret)
> + goto err_exit_conv;
> +
> + enable_irq(st->irq);
> + return 0;
"Is there a race condition introduced by enabling the PWM and unmasking the
IRQ here?
If a hardware interrupt fires before the IIO core attaches the trigger's poll
function, iio_trigger_poll() drops the event. Will the IRQ handler then call
disable_irq_nosync() without ever running the consumer thread to re-enable it?"
Valid. preenable is called before the IIO core attaches the trigger
poll function; if a DATA_READY IRQ fires in that window, iio_trigger_poll()
is dropped, disable_irq_nosync() disables the IRQ, and enable_irq() is
never called, leaving the IRQ stuck. Although the delay would need to be
very great for this to happen, I moved sampling_enable(true) and
enable_irq() to a new postenable callback which the IIO core calls only
after the trigger poll function is attached.
> +
> +err_exit_conv:
> + ad4691_exit_conversion_mode(st);
> +err_unoptimize:
> + spi_unoptimize_message(&st->scan_msg);
> + return ret;
> +}
> +
> +static int ad4691_cnv_burst_buffer_postdisable(struct iio_dev *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + int ret;
> +
> + disable_irq(st->irq);
"During buffer teardown, the IIO core detaches the trigger consumer before
invoking the postdisable callback.
If an interrupt fires while the PWM is still running before the call to
ad4691_sampling_enable(), could ad4691_irq() disable the IRQ without a
consumer to re-enable it? Does the subsequent disable_irq() call then increase
the disable depth to 2, permanently disabling the hardware IRQ?"
Valid, fixed as part of the previous concern rework. IRQ disabling and
sampling_enable(false) are now in a new predisable callback (called before
the consumer is detached); postdisable only handles SPI cleanup.
> +
> + ret = ad4691_sampling_enable(st, false);
> + if (ret)
> + return ret;
"If ad4691_sampling_enable() fails, does returning early bypass
spi_unoptimize_message() and leak the DMA mappings allocated by the SPI core
during preenable?"
Valid. If pwm_apply_might_sleep() inside sampling_enable(false) fails,
spi_unoptimize_message() was skipped. Always called now before returning
from postdisable regardless of sampling_enable() result.
> +
> + ret = ad4691_exit_conversion_mode(st);
...
> +static ssize_t sampling_frequency_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct ad4691_state *st = iio_priv(indio_dev);
> + int freq, ret;
> +
> + ret = kstrtoint(buf, 10, &freq);
> + if (ret)
> + return ret;
> +
> + IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
> + if (IIO_DEV_ACQUIRE_FAILED(claim))
> + return -EBUSY;
> +
> +
> + ret = ad4691_set_pwm_freq(st, freq);
"If a negative value is passed to kstrtoint(), does ad4691_set_pwm_freq()
calculate a cnv_period_ns of 0 due to signed integer arithmetic rules?
Could this lead to a division by zero regression in sampling_frequency_show()
when it calculates NSEC_PER_SEC / st->cnv_period_ns?"
Valid. Switching sampling_frequency_store to kstrtouint + unsigned int freq so
Negative strings are rejected at parse time before reaching set_pwm_freq.
> + if (ret)
> + return ret;
> +
> + return len;
> +}
> +
> +static IIO_DEVICE_ATTR_RW(sampling_frequency, 0);
> +
> +static const struct iio_dev_attr *ad4691_buffer_attrs[] = {
> + &iio_dev_attr_sampling_frequency,
> + NULL
> +};
> +
> +static irqreturn_t ad4691_irq(int irq, void *private)
> +{
> + struct iio_dev *indio_dev = private;
> + struct ad4691_state *st = iio_priv(indio_dev);
> +
> + iio_trigger_poll(indio_dev->trig);
> + /*
> + * Keep the DATA_READY IRQ disabled until the trigger handler has
> + * finished reading the scan, to prevent a new assertion mid-transfer.
> + * The PWM continues running uninterrupted; the IRQ is re-enabled in
> + * ad4691_trigger_handler once spi_sync completes.
> + *
> + * IRQF_ONESHOT already masks the hardware line during this
> threaded
> + * handler, so disable_irq_nosync here ensures the IRQ stays disabled
> + * even after IRQF_ONESHOT unmasks on return.
> + */
> + disable_irq_nosync(st->irq);
> +
> + return IRQ_HANDLED;
> +}
"Can a concurrency issue occur here between this threaded IRQ handler and the
trigger consumer thread?
Since iio_trigger_poll() wakes up the consumer thread, could the consumer
thread complete the SPI transfer and call enable_irq() before the provider
thread reaches disable_irq_nosync()? This might trigger an unbalanced enable
for IRQ warning and leave the hardware IRQ permanently disabled."
Valid. Moved disable_irq_nosync() before iio_trigger_poll() so the
IRQ is always disabled before the consumer thread gets a chance to call
enable_irq().
> +
> +static const struct iio_trigger_ops ad4691_trigger_ops = {
> + .validate_device = iio_trigger_validate_own_device,
...
> +
> static const struct iio_info ad4691_info = {
> .read_raw = &ad4691_read_raw,
> .write_raw = &ad4691_write_raw,
> @@ -514,6 +910,18 @@ static const struct iio_info ad4691_info = {
> .debugfs_reg_access = &ad4691_reg_access,
> };
"Without a .validate_trigger callback here, can external triggers be attached?
If an external trigger fires, the consumer thread might execute
enable_irq(st->irq) without a corresponding hardware interrupt calling
disable_irq_nosync() first, leading to an unbalanced IRQ enable warning."
Valid. Added .validate_trigger = iio_validate_own_trigger to
ad4691_info to prevent external triggers from causing unbalanced
enable_irq() calls.
^ permalink raw reply
* Re: Regression due to /sys/kernel/dmabuf/buffers removal
From: Christian König @ 2026-05-07 11:35 UTC (permalink / raw)
To: T.J. Mercier, Julian Orth
Cc: corbet, dri-devel, linaro-mm-sig, linux-doc, linux-kernel,
linux-media, Sumit Semwal
In-Reply-To: <CABdmKX1pDc7wpLVQzM0ihH6AfW+=KWdyaZuorMqWCbC80Y7-Bw@mail.gmail.com>
On 5/5/26 16:32, T.J. Mercier wrote:
> On Tue, May 5, 2026 at 6:00 AM Julian Orth <ju.orth@gmail.com> wrote:
>>
>> On Tue, May 5, 2026 at 2:41 PM Christian König <christian.koenig@amd.com> wrote:
>>>
>>> Hi Julian,
>>>
>>> On 5/5/26 14:25, Julian Orth wrote:
>>>> In ab4c3dcf9a71582503b4fb25aeab884c696cab25 ("dma-buf: Remove DMA-BUF
>>>> sysfs stats") the /sys/kernel/dmabuf/buffer directory was removed.
>>>>
>>>> I've been using this interface, specifically the exporter_name file,
>>>> to detect dmabufs created via udmabuf. Such dmabufs show "udmabuf" in
>>>> exporter_name. I've been doing this for two reasons: 1) to detect that
>>>> mmap on such buffers will be fast and 2) to detect that GPU access to
>>>> such buffers will be slow.
>>>
>>> Crap, I really hoped that Android was the only user of that sysfs interface since that approach turned out to be quite broken.
>>>
>>> It's number one rule on Linux that we don't break userspace. So I hope that you don't insist on bringing that interface back, but if you do I will just revert the removal until we found a better solution.
>>
>> Bringing it back shouldn't be necessary.
>>
>>>
>>>> With the removal of that file, that detection mechanism no longer works.
>>>>
>>>> I'm not particularly fond of that mechanism but it was the only one
>>>> providing that functionality that I could find at the time. If there
>>>> is another one, ideally an ioctl on the dmabuf, please let me know.
>>>
>>> The virtual fdinfo file you can find under /proc/$pid/fdinfo/$fd also contains the exporter name for the DMA-buf.
>>>
>>> You can find the full documentation here: https://docs.kernel.org/filesystems/proc.html#dma-buffer-files
>>>
>>> Is that sufficient?
>>
>> I think that is sufficient. I probably didn't use fdinfo initially
>> because 1) it's a lot more work to parse and 2) I wasn't sure if it
>> was intended to be machine-readable or if there could sometimes be
>> newlines in the values and such.
>>
>>>
>>> Additional to that the debugfs for DMA-buf also contains that information and I'm open to the suggestion with the IOCTL.
>>
>> My application runs as a regular user so it cannot access /sys/kernel/debug.
>>
>> Having an IOCTL would be ideal if it is not too much work. I'll fall
>> back to fdinfo for now.
>>
>> Thanks, Julian
>
> Phew, I'm glad fdinfo suits your needs.
Yeah, exactly my thinking as well :)
A college questioned me this week how to find DMA-buf stats for debugging and it turned out that Google points to the outdated DMA-buf sysfs documentation instead of the debugfs one.
No idea why, maybe we need to improve the documentation here a bit.
> Adding an ioctl would introduce new UAPI so I think we'd want to avoid
> that unless absolutely necessary.
CRIU has some similar requirements, e.g. they need to know the exporting driver of a DMA-buf.
Not sure if the fdinfo file will be sufficient for that case or not. But yeah I agree that we only need this if actually necessary.
Regards,
Christian.
>
> Thanks,
> T.J.
>
>>>
>>> Regards,
>>> Christian.
>>>
>>>>
>>>> Shipping an entire BPF compiler in my application, which the original
>>>> patch suggests as the replacement, is not an option when the removed
>>>> alternative was simply reading a file.
>>>>
>>>> Thanks, Julian
>>>
^ permalink raw reply
* Re: [PATCH v11 09/11] iio: frequency: adf41513: features on frequency change
From: Rodrigo Alencar @ 2026-05-07 11:19 UTC (permalink / raw)
To: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260506-adf41513-iio-driver-v11-9-2b7e99cfe8f2@analog.com>
On 26/05/06 03:08PM, Rodrigo Alencar via B4 Relay wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Set Bleed current when PFD frequency changes (bleed enabled when in
> fractional mode). Set lock detector window size, handling bias and
> precision. Add phase resync support, setting clock dividers when
> PFD frequency changes.
Sashiko's feedback:
https://sashiko.dev/#/patchset/20260506-adf41513-iio-driver-v11-0-2b7e99cfe8f2%40analog.com?part=9
...
> +static void adf41513_set_phase_resync(struct adf41513_state *st)
> +{
> + u32 total_div, clk1_div, clk2_div;
> +
> + if (!st->data.phase_resync_period_ns)
> + return;
> +
> + /* assuming both clock dividers hold similar values */
> + total_div = mul_u64_u64_div_u64(st->settings.pfd_frequency_uhz,
> + st->data.phase_resync_period_ns,
> + 1ULL * MICROHZ_PER_HZ * NSEC_PER_SEC);
> + clk1_div = clamp(int_sqrt(total_div), 1,
> + ADF41513_MAX_CLK_DIVIDER);
> + clk2_div = clamp(DIV_ROUND_CLOSEST(total_div, clk1_div), 1,
> + ADF41513_MAX_CLK_DIVIDER);
> +
> + FIELD_MODIFY(ADF41513_REG5_CLK1_DIV_MSK, &st->regs[ADF41513_REG5],
> + clk1_div);
> + FIELD_MODIFY(ADF41513_REG7_CLK2_DIV_MSK, &st->regs[ADF41513_REG7],
> + clk2_div);
> +
> + /* enable phase resync */
> + st->regs[ADF41513_REG7] |= ADF41513_REG7_CLK_DIV_MODE_MSK;
Does this accidentally write a reserved hardware state by forcing all bits
in the mask to 1?
If ADF41513_REG7_CLK_DIV_MODE_MSK is a multi-bit field, using the bitwise
OR operator will set all bits in the field to 1 (e.g., 0b11). Typically,
phase resync is 0b10, fast lock is 0b01, and 0b11 is reserved.
Should this use FIELD_MODIFY() with a specific phase resync mode value
instead of directly OR-ing the mask?
Indeed, it should be using FIELD_MODIFY() here:
FIELD_MODIFY(ADF41513_REG7_CLK_DIV_MODE_MSK, &st->regs[ADF41513_REG7], 2);
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 1/2] rust: task: clarify comments on task UID accessors
From: Gary Guo @ 2026-05-07 11:08 UTC (permalink / raw)
To: Alice Ryhl, Paul Moore, Serge Hallyn, Jonathan Corbet,
Greg Kroah-Hartman, Shuah Khan, Alex Shi, Yanteng Si,
Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux
In-Reply-To: <20260507-remove-task-euid-v3-1-27f22f335c2c@google.com>
On Thu May 7, 2026 at 10:48 AM BST, Alice Ryhl wrote:
> From: Jann Horn <jannh@google.com>
>
> Linux has separate subjective and objective task credentials, see the
> comment above `struct cred`. Clarify which accessor functions operate on
> which set of credentials.
>
> Also document that Task::euid() is a very weird operation. You can see how
> weird it is by grepping for task_euid() - binder is its only user.
> Task::euid() obtains the objective effective UID - it looks at the
> credentials of the task for purposes of acting on it as an object, but then
> accesses the effective UID (which the credentials.7 man page describes as
> "[...] used by the kernel to determine the permissions that the process
> will have when accessing shared resources [...]").
>
> For context:
> Arguably, binder's use of task_euid() is a theoretical security problem,
> which only has no impact on Android because Android has no setuid binaries
> executable by apps.
> commit 29bc22ac5e5b ("binder: use euid from cred instead of using task")
> fixed that by removing that only user of task_euid(), but the fix got
> reverted in commit c21a80ca0684 ("binder: fix test regression due to
> sender_euid change") because some Android test started failing.
>
> Signed-off-by: Jann Horn <jannh@google.com>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> Originally sent as:
> https://lore.kernel.org/r/20260212-rust-uid-v1-1-deff4214c766@google.com
> ---
> rust/kernel/task.rs | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
> index 38273f4eedb5..7950c3a3950d 100644
> --- a/rust/kernel/task.rs
> +++ b/rust/kernel/task.rs
> @@ -210,14 +210,17 @@ pub fn pid(&self) -> Pid {
> unsafe { *ptr::addr_of!((*self.as_ptr()).pid) }
> }
>
> - /// Returns the UID of the given task.
> + /// Returns the objective real UID of the given task.
> #[inline]
> pub fn uid(&self) -> Kuid {
> // SAFETY: It's always safe to call `task_uid` on a valid task.
> Kuid::from_raw(unsafe { bindings::task_uid(self.as_ptr()) })
> }
>
> - /// Returns the effective UID of the given task.
> + /// Returns the objective effective UID of the given task.
> + ///
> + /// You should probably not be using this; the effective UID is normally
> + /// only relevant in subjective credentials.
> #[inline]
> pub fn euid(&self) -> Kuid {
> // SAFETY: It's always safe to call `task_euid` on a valid task.
> @@ -371,7 +374,7 @@ fn eq(&self, other: &Self) -> bool {
> impl Eq for Task {}
>
> impl Kuid {
> - /// Get the current euid.
> + /// Get the current subjective euid.
For consistency this should be "subjective effective UID".
Best,
Gary
> #[inline]
> pub fn current_euid() -> Kuid {
> // SAFETY: Just an FFI call.
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dpll: add fractional frequency offset to pin-parent-device
From: Jiri Pirko @ 2026-05-07 11:08 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Ivan Vecera, netdev, Andrew Lunn, Arkadiusz Kubalewski,
David S. Miller, Donald Hunter, Eric Dumazet, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260506183342.767b5fbc@kernel.org>
Thu, May 07, 2026 at 03:33:42AM +0200, kuba@kernel.org wrote:
>On Mon, 4 May 2026 17:53:39 +0200 Ivan Vecera wrote:
>> + At top level this represents the RX vs TX symbol rate
>> + offset on the media associated with the pin.
>
>Isn't this a hacky hack? I'd think that pin is in or out.
>Having a freq offset between two pins or pin and parent's
>ref lock makes sense. This new interpretation sounds like
>we are trying to shove a difference between two pins into one?
The pin is in, but it is associated with SyncE port that has RX/TX
symbol rate offset. As the doc says, the "offset on the media associated
with the pin". Why is that hack?
>
>> @@ -299,6 +299,10 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
>> {
>> struct zl3073x_dpll_pin *pin = pin_priv;
>>
>> + /* Only rx vs tx symbol rate FFO is supported */
>> + if (dpll)
>> + return -ENODATA;
>> +
>> *ffo = pin->freq_offset;
>
>It's easy for driver authors to forget this sort of validation.
>We should fail close, so it's better to have some "capability"
>bits or something for the driver to opt into getting given format
>of the call.
^ permalink raw reply
* Re: [PATCH v11 07/11] iio: frequency: adf41513: driver implementation
From: Rodrigo Alencar @ 2026-05-07 11:05 UTC (permalink / raw)
To: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260506-adf41513-iio-driver-v11-7-2b7e99cfe8f2@analog.com>
On 26/05/06 03:08PM, Rodrigo Alencar via B4 Relay wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> The driver is based on existing PLL drivers in the IIO subsystem and
> implements the following key features:
>
> - Integer-N and fractional-N (fixed/variable modulus) synthesis modes
> - High-resolution frequency calculations using microhertz (µHz) precision
> to handle sub-Hz resolution across multi-GHz frequency ranges
> - IIO debugfs interface for direct register access
> - FW property parsing from devicetree including charge pump settings,
> reference path configuration and muxout options
> - Power management support with suspend/resume callbacks
> - Lock detect GPIO monitoring
Sashiko's feedback:
https://sashiko.dev/#/patchset/20260506-adf41513-iio-driver-v11-0-2b7e99cfe8f2%40analog.com?part=7
There is a lot of stuff here, most of things are good points, but maybe it
was not that bad. It could've been worse with those fractional mode calculations.
...
> +static u64 adf41513_pll_get_rate(struct adf41513_state *st)
> +{
> + struct adf41513_pll_settings *cfg = &st->settings;
> +
> + if (cfg->mode != ADF41513_MODE_INVALID)
> + return cfg->actual_frequency_uhz;
> +
> + /* get pll settings from regs_hw */
> + cfg->int_value = FIELD_GET(ADF41513_REG0_INT_MSK, st->regs_hw[ADF41513_REG0]);
> + cfg->frac1 = FIELD_GET(ADF41513_REG1_FRAC1_MSK, st->regs_hw[ADF41513_REG1]);
> + cfg->frac2 = FIELD_GET(ADF41513_REG3_FRAC2_MSK, st->regs_hw[ADF41513_REG3]);
> + cfg->mod2 = FIELD_GET(ADF41513_REG4_MOD2_MSK, st->regs_hw[ADF41513_REG4]);
> + cfg->r_counter = FIELD_GET(ADF41513_REG5_R_CNT_MSK, st->regs_hw[ADF41513_REG5]);
> + cfg->ref_doubler = FIELD_GET(ADF41513_REG5_REF_DOUBLER_MSK, st->regs_hw[ADF41513_REG5]);
> + cfg->ref_div2 = FIELD_GET(ADF41513_REG5_RDIV2_MSK, st->regs_hw[ADF41513_REG5]);
> + cfg->prescaler = FIELD_GET(ADF41513_REG5_PRESCALER_MSK, st->regs_hw[ADF41513_REG5]);
> +
> + /* calculate pfd frequency */
> + cfg->pfd_frequency_uhz = (u64)st->ref_freq_hz * MICRO;
> + if (cfg->ref_doubler)
> + cfg->pfd_frequency_uhz <<= 1;
> + if (cfg->ref_div2)
> + cfg->pfd_frequency_uhz >>= 1;
> + cfg->pfd_frequency_uhz = div_u64(cfg->pfd_frequency_uhz, cfg->r_counter);
If a user writes 0 to the R_CNT field via debugfs direct register access, won't
this cause a division by zero kernel panic?
The 0 value for R counter means 32, so this is a bug indeed.
> + cfg->actual_frequency_uhz = (u64)cfg->int_value * cfg->pfd_frequency_uhz;
> +
> + /* check if int mode is selected */
> + if (FIELD_GET(ADF41513_REG6_INT_MODE_MSK, st->regs_hw[ADF41513_REG6])) {
> + cfg->mode = ADF41513_MODE_INTEGER_N;
> + } else {
> + cfg->actual_frequency_uhz += mul_u64_u32_div(cfg->pfd_frequency_uhz,
> + cfg->frac1,
> + ADF41513_FIXED_MODULUS);
> +
> + /* check if variable modulus is selected */
> + if (FIELD_GET(ADF41513_REG0_VAR_MOD_MSK, st->regs_hw[ADF41513_REG0])) {
> + cfg->actual_frequency_uhz +=
> + mul_u64_u64_div_u64(cfg->frac2,
> + cfg->pfd_frequency_uhz,
> + (u64)cfg->mod2 * ADF41513_FIXED_MODULUS);
Similarly, if the MOD2 field is written as 0 via debugfs, will this result in
a division by zero panic?
I've just checked in hardware and it seems mod2 = 0 behave as mod2 = 1, so it does not fallback to
fixed modulus. Will adjust so that this is consistent.
...
> +static int adf41513_calc_integer_n(struct adf41513_state *st,
> + struct adf41513_pll_settings *result)
> +{
> + u16 max_int = st->chip_info->has_prescaler_8_9 ?
> + ADF41513_MAX_INT_8_9 : ADF41513_MAX_INT_4_5;
> + u64 freq_error_uhz;
> + u16 int_value = div64_u64_rem(result->target_frequency_uhz, result->pfd_frequency_uhz,
> + &freq_error_uhz);
If the target frequency is very high and the PFD frequency is very low, could
the 64-bit quotient overflow the u16 int_value and silently truncate?
This would bypass the subsequent bounds check on int_value and incorrectly
program the hardware instead of returning -ERANGE.
That would be unusual as max_int is way less than U16_MAX, but maybe possible with very low
ref frequency and very high dividers, so will make int_value as u32.
> +
> + /* check if freq error is within a tolerance of 1/2 resolution */
> + if (freq_error_uhz > (result->pfd_frequency_uhz >> 1) && int_value < max_int) {
> + int_value++;
> + freq_error_uhz = result->pfd_frequency_uhz - freq_error_uhz;
> + }
> +
> + if (freq_error_uhz > st->data.freq_resolution_uhz)
> + return -ERANGE;
> +
> + /* set prescaler */
> + if (st->chip_info->has_prescaler_8_9 && int_value >= ADF41513_MIN_INT_8_9 &&
> + int_value <= ADF41513_MAX_INT_8_9)
> + result->prescaler = 1;
> + else if (int_value >= ADF41513_MIN_INT_4_5 && int_value <= ADF41513_MAX_INT_4_5)
> + result->prescaler = 0;
> + else
> + return -ERANGE;
...
> +static int adf41513_set_frequency(struct adf41513_state *st, u64 freq_uhz, u16 sync_mask)
> +{
> + struct adf41513_pll_settings result;
> + int ret;
> +
> + ret = adf41513_calc_pll_settings(st, &result, freq_uhz);
> + if (ret < 0)
> + return ret;
> +
> + /* apply computed results to pll settings */
> + st->settings = result;
> +
> + dev_dbg(&st->spi->dev,
> + "%s mode: int=%u, frac1=%u, frac2=%u, mod2=%u, fpdf=%llu Hz, prescaler=%s\n",
> + (result.mode == ADF41513_MODE_INTEGER_N) ? "integer-n" :
> + (result.mode == ADF41513_MODE_FIXED_MODULUS) ? "fixed-modulus" : "variable-modulus",
> + result.int_value, result.frac1, result.frac2, result.mod2,
> + div64_u64(result.pfd_frequency_uhz, MICRO),
> + result.prescaler ? "8/9" : "4/5");
> +
> + st->regs[ADF41513_REG0] = FIELD_PREP(ADF41513_REG0_INT_MSK,
> + st->settings.int_value);
> + if (st->settings.mode == ADF41513_MODE_VARIABLE_MODULUS)
> + st->regs[ADF41513_REG0] |= ADF41513_REG0_VAR_MOD_MSK;
> +
> + st->regs[ADF41513_REG1] = FIELD_PREP(ADF41513_REG1_FRAC1_MSK,
> + st->settings.frac1);
> + if (st->settings.mode != ADF41513_MODE_INTEGER_N)
> + st->regs[ADF41513_REG1] |= ADF41513_REG1_DITHER2_MSK;
> +
> + st->regs[ADF41513_REG3] = FIELD_PREP(ADF41513_REG3_FRAC2_MSK,
> + st->settings.frac2);
> + FIELD_MODIFY(ADF41513_REG4_MOD2_MSK, &st->regs[ADF41513_REG4],
> + st->settings.mod2);
> + FIELD_MODIFY(ADF41513_REG5_R_CNT_MSK, &st->regs[ADF41513_REG5],
> + st->settings.r_counter);
The driver defines ADF41513_MAX_R_CNT as 32, but the ADF41513_REG5_R_CNT_MSK is
only 5 bits wide (GENMASK(20, 16)). If r_counter is 32, will this FIELD_MODIFY
silently truncate it to 0?
If this is truncated to 0, and the device state is invalidated, a subsequent
sysfs frequency read would call adf41513_pll_get_rate() and trigger a division
by zero panic.
The bitfield with zero value behaves as R_CNT = 32, so this should not be a problem,
but I suppose that should be explicit and as pointed out above, it is not being taken
care in adf41513_pll_get_rate().
...
> +static int adf41513_resume(struct adf41513_state *st)
> +{
> + st->regs[ADF41513_REG6] &= ~ADF41513_REG6_POWER_DOWN_MSK;
> + return adf41513_sync_config(st, ADF41513_SYNC_DIFF);
> +}
If regulators are turned off during system suspend, the hardware registers will
be wiped. However, since regs_hw isn't invalidated during suspend, won't
ADF41513_SYNC_DIFF falsely assume the hardware is still configured and skip
reprogramming it?
Indeed, I might need to use SYNC_ALL here when doing power management.
Also, doesn't the unconditional clearing of ADF41513_REG6_POWER_DOWN_MSK clobber
any prior explicit powerdown request made via sysfs?
Another good point, may need to have a powerdown field in the state struct to
track this.
...
> +static int adf41513_parse_fw(struct adf41513_state *st)
> +{
...
> + st->data.charge_pump_voltage_mv = ADF41513_DEFAULT_CP_VOLTAGE_mV;
> + ret = device_property_read_u32(dev, "adi,charge-pump-current-microamp", &cp_current);
> + if (!ret) {
> + tmp = DIV_ROUND_CLOSEST(cp_current * cp_resistance, MILLI); /* convert to mV */
Could cp_current * cp_resistance overflow the 32-bit boundary?
If an abnormally large current is provided via devicetree, the overflow could
pass the subsequent voltage range checks and configure the hardware with an
incorrect charge pump setting. Should this use mul_u32_u32() or a 64-bit cast?
I can add a bound/max check for cp_current first, as it needs to be between 81 and 7200 micro amps.
> + if (tmp < ADF41513_MIN_CP_VOLTAGE_mV || tmp > ADF41513_MAX_CP_VOLTAGE_mV)
> + return dev_err_probe(dev, -ERANGE, "I_CP %u uA (%u Ohms) out of range\n",
> + cp_current, cp_resistance);
> + st->data.charge_pump_voltage_mv = tmp;
> + }
...
> +static int adf41513_pm_suspend(struct device *dev)
> +{
> + return adf41513_suspend(dev_get_drvdata(dev));
> +}
Is it safe to call adf41513_suspend() without acquiring st->lock?
This function modifies the shared software register cache and executes SPI
writes. It seems this could race concurrently with sysfs reads/writes or
IIO core accesses.
Is this a real concern?
...
> +static int adf41513_probe(struct spi_device *spi)
> +{
...
> + st->chip_enable = devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_HIGH);
> + if (IS_ERR(st->chip_enable))
> + return dev_err_probe(dev, PTR_ERR(st->chip_enable),
> + "fail to request chip enable GPIO\n");
...
> + ret = adf41513_setup(st);
Is a delay needed between asserting the chip_enable GPIO and sending the first
SPI command in adf41513_setup()?
Hardware PLLs typically require a wake-up or stabilization time for internal
regulators. Without a usleep_range(), could the initial SPI commands be
dropped by the hardware?
I havent see the need for this, mostly because a lot seems to be happening before the
first SPI write and after the chip enable goes high, so I will ignore this.
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to setup device\n");
> +
> + ret = devm_add_action_or_reset(dev, adf41513_power_down, st);
If adf41513_setup() returns an error, the probe function aborts before
devm_add_action_or_reset() registers the adf41513_power_down action.
Since chip_enable is acquired with GPIOD_OUT_HIGH, devres will disable the
regulators but leave the GPIO high. Could this cause the host processor to
backpower the unpowered synthesizer IC through its ESD diodes?
Another good point, will separate the reset actions for sw powerdown and chip enable
gpio.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [RFC net-next 0/4] devlink: Add boot-time defaults
From: Jiri Pirko @ 2026-05-07 11:03 UTC (permalink / raw)
To: Mark Bloch
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Jonathan Corbet, Shuah Khan, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Morton,
Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Christian Brauner, Petr Mladek, Peter Zijlstra (Intel),
Thomas Gleixner, Pawan Gupta, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, linux-doc,
linux-kernel, netdev, linux-rdma
In-Reply-To: <3f9215c4-7c84-46d9-ba74-30dabe24db09@nvidia.com>
Wed, May 06, 2026 at 07:35:10PM +0200, mbloch@nvidia.com wrote:
>
>
>On 06/05/2026 18:22, Jiri Pirko wrote:
>> Wed, May 06, 2026 at 02:37:35PM +0200, mbloch@nvidia.com wrote:
>>> This series adds a devlink= kernel command line parameter for applying
>>> selected devlink settings during device initialization.
>>>
>>> Following a discussion with Jakub[1], I am sending this RFC to get the
>>> conversation moving. I started from Jakub's example/request and extended
>>> it to cover requirements from production systems and configurations that
>>> customers use.
>>>
>>> One important caveat is that the parsing logic in this RFC was written
>>> with AI assistance. I am also not sure whether the resulting syntax and
>>> parser are too complex for a kernel command line interface. This is part
>>> of why I am sending it as an RFC: to understand what direction and level
>>> of complexity would be acceptable to people.
>>>
>>> The implementation is intended to support the following properties:
>>>
>>> - A system may have multiple devlink devices that usually need the same
>>> configuration. For a configuration such as eswitch mode switchdev, a
>>> user should be able to specify multiple devices to which that
>>> configuration applies.
>>>
>>> - There may be ordering dependencies between options. For example, in
>>> mlx5, flow_steering_mode should be set before moving to switchdev.
>>> With this in mind, defaults are applied per device in the left-to-right
>>> order in which they appear on the command line.
>>>
>>> The intent is to let deployments set devlink defaults before normal
>>> userspace orchestration runs, while still using devlink concepts and
>>
>> "defaults before normal userspace orchestrarion". I read it as config
>> before config, which eventually could be skipped.
>>
>>
>>> driver callbacks rather than adding driver-specific module parameters.
>>> A default is scoped to one or more devlink handles, for example:
>>>
>>> devlink=[pci/0000:08:00.0]:esw:mode:switchdev
>>> devlink=[pci/0000:08:00.0]:param:flow_steering_mode:smfs
>>> devlink=[pci/0000:08:00.0,pci/0000:08:00.1]:param:flow_steering_mode:hmfs,[pci/0000:08:00.0,pci/0000:08:00.1]:esw:mode:switchdev
>>
>> I don't like this. What you do, you are basically introducing user
>> configuration tool on kernel cmdline.
>>
>> The same you would achieve with a proper userspace tool/daemon.
>> I did try to come up with it and push it here:
>> https://github.com/systemd/systemd/pull/37393
>> That didn't get merged for unknown reason, but the idea is sound. You
>> provide configuration files for devlink object and systemd-devlinkd
>> will apply when they appear. Wouldn't this help your case?
>
>I agree that systemd-devlinkd is the right shape for normal
>devlink configuration, and it could probably replace the udev/devlink
>plumbing we use today.
>
>The case I am trying to cover is earlier than that.
>
>On BlueField/ECPF/DPU systems, the host PF driver cannot always finish
>probing independently of the ECPF side. When the ECPF is the eswitch
>manager, the host PF is kept in initializing state until the ECPF eswitch
>side is set up and mlx5 enables the external host PF HCA. That happens as
>part of moving the ECPF to switchdev.
>
>Today userspace observes the ECPF instance and then switches the
>mode through devlink, usually via udev or similar plumbing. That still
>leaves a window where the ECPF has probed, userspace has not applied the
>mode yet, and the host PF is waiting. With many ECPFs this becomes visible
>in host PF probe/boot time. A daemon reacting to the devlink object
>appearing can make the userspace side cleaner, but it still runs after the
>device has appeared and after userspace scheduling/uevent handling.
>
>Long term, for these DPU deployments, we would like mlx5 to initialize
>directly in switchdev. I am hesitant to make that unconditional because it
>changes existing behavior and there is no early opt-out before probe. The
>cmdline parameter was meant as an explicit opt-in middle step: ask the
>driver to apply the same devlink operation during init, before this path
>depends on userspace.
>
>We previously tried to address this with an mlx5 module parameter. By
>design, that was too coarse: it applied to all mlx5 devices handled by the
>module. That makes it usable only for narrow DPU-only configurations. The
>devlink-handle based cmdline syntax was intended to keep the opt-in scoped
>to the specific devices that need this early switchdev transition.
The switchdev mode was introduced at roughly the time CX4 was out. What
stopped us from making it default for CX4+ ?
Introducing this horrible plumbing only bacause we were not able to
change the default sounds so absurd.
Can we write the default mode as a bit in ASIC NV memory perhaps? Simple
devlink cmode permanent param to write it, the driver can read this bit
during init to decide the init flow path?
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Greg KH @ 2026-05-07 10:47 UTC (permalink / raw)
To: Sasha Levin; +Cc: corbet, akpm, skhan, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <20260507070547.2268452-1-sashal@kernel.org>
On Thu, May 07, 2026 at 03:05:45AM -0400, Sasha Levin wrote:
> When a (security) issue goes public, fleets stay exposed until a patched kernel
> is built, distributed, and rebooted into.
>
> For many such issues the simplest mitigation is to stop calling the buggy
> function. Killswitch provides that. An admin writes:
>
> echo "engage af_alg_sendmsg -1" \
> > /sys/kernel/security/killswitch/control
>
> After this, af_alg_sendmsg() returns -EPERM on every call without
> running its body. The mitigation takes effect immediately, and is dropped on
> the next reboot.
>
> A lot of recent kernel issues sit in code paths most installs only have enabled
> to support a relative minority of users: AF_ALG, ksmbd, nf_tables, vsock, ax25,
> and friends.
>
> For most users, the cost of "this socket family stops working for the day" is
> much smaller than the cost of running a known vulnerable kernel until the fix
> land.
>
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Sasha Levin <sashal@kernel.org>
This is kind of funny, but understandable. Odds are a distro would want
to pick this up so that they can enable this for when their kernel
updates do not get out to users quick enough.
One question:
> +struct ks_attr {
> + struct list_head list;
> + struct kprobe kp;
> + atomic_long_t retval;
Why is this an atomic value? Shouldn't it be whatever the userspace
return type is?
> + /* false once disengaged; per-fn file ops then return -EIDRM. */
> + bool engaged;
> + unsigned long __percpu *hits;
> + struct dentry *dir;
> + /* engaged_list holds one ref; each open per-fn fd holds one. */
> + refcount_t refcnt;
Why is a refcnt needed? Why not use a kref instead?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH ipsec-next v8 02/14] xfrm: add extack to xfrm_init_state
From: Sabrina Dubroca @ 2026-05-07 10:37 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-2-4578fb016965@secunet.com>
2026-05-05, 06:32:19 +0200, Antony Antony wrote:
> Add a struct extack parameter to xfrm_init_state() and pass it
> through to __xfrm_init_state(). This allows validation errors detected
> during state initialization to propagate meaningful error messages back
> to userspace.
>
> xfrm_state_migrate_create() now passes extack so that errors from the
> XFRM_MSG_MIGRATE_STATE path are properly reported. Callers without an
> extack context (af_key, ipcomp4, ipcomp6) pass NULL, preserving their
> existing behaviour.
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
>
> ---
> v5->v6: added this patch
> ---
> include/net/xfrm.h | 2 +-
> net/ipv4/ipcomp.c | 2 +-
> net/ipv6/ipcomp6.c | 2 +-
> net/key/af_key.c | 2 +-
> net/xfrm/xfrm_state.c | 6 +++---
> 5 files changed, 7 insertions(+), 7 deletions(-)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
^ permalink raw reply
* Re: [PATCH ipsec-next v8 01/14] xfrm: remove redundant assignments
From: Sabrina Dubroca @ 2026-05-07 10:37 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-1-4578fb016965@secunet.com>
2026-05-05, 06:31:28 +0200, Antony Antony wrote:
> These assignments are overwritten within the same function further down
>
> commit e8961c50ee9cc ("xfrm: Refactor migration setup
> during the cloning process")
> x->props.family = m->new_family;
>
> Which actually moved it in the
> commit e03c3bba351f9 ("xfrm: Fix xfrm migrate issues when address family changes")
>
> And the initial
> commit 80c9abaabf428 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
>
> added x->props.saddr = orig->props.saddr; and
> memcpy(&xc->props.saddr, &m->new_saddr, sizeof(xc->props.saddr));
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
>
> ---
> v1->v2: remove extra saddr copy, previous line
> ---
> net/xfrm/xfrm_state.c | 2 --
> 1 file changed, 2 deletions(-)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
^ 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