* 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 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Thierry Reding @ 2026-05-07 13:39 UTC (permalink / raw)
To: Boris Brezillon
Cc: Maxime Ripard, Ketil Johnsen, David Airlie, Simona Vetter,
Maarten Lankhorst, 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
In-Reply-To: <20260506170515.2d8511c3@fedora>
[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]
On Wed, May 06, 2026 at 05:05:15PM +0200, Boris Brezillon wrote:
> On Wed, 6 May 2026 15:12:37 +0200
> Maxime Ripard <mripard@kernel.org> wrote:
>
> > On Wed, May 06, 2026 at 12:50:15PM +0200, Boris Brezillon wrote:
> > > On Wed, 6 May 2026 12:08:24 +0200
> > > Maxime Ripard <mripard@kernel.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > On Tue, May 05, 2026 at 04:05:10PM +0200, Ketil Johnsen wrote:
> > > > > From: Florent Tomasin <florent.tomasin@arm.com>
> > > > >
> > > > > This patch allows Panthor to allocate buffer objects from a
> > > > > protected heap. The Panthor driver should be seen as a consumer
> > > > > of the heap and not an exporter.
> > > > >
> > > > > Protected memory buffers needed by the Panthor driver:
> > > > > - On CSF FW load, the Panthor driver must allocate a protected
> > > > > buffer object to hold data to use by the FW when in protected
> > > > > mode. This protected buffer object is owned by the device
> > > > > and does not belong to a process.
> > > > > - On CSG creation, the Panthor driver must allocate a protected
> > > > > suspend buffer object for the FW to store data when suspending
> > > > > the CSG while in protected mode. The kernel owns this allocation
> > > > > and does not allow user space mapping. The format of the data
> > > > > in this buffer is only known by the FW and does not need to be
> > > > > shared with other entities.
> > > > >
> > > > > The driver will retrieve the protected heap using the name of the
> > > > > heap provided to the driver as module parameter.
> > > >
> > > > I know it's what dma_heap_find asks for, but I wonder if it wouldn't be
> > > > better in the device tree and lookup through the device node? heaps are
> > > > going to have a node anyway, right?
> > >
> > > I'm not too sure. Take the PROTMEM (name="protected,xxxx") dma_heaps
> > > instantiated by optee for instance, I don't think the originating
> > > tee_device comes from a device node, nor is the underlying heap
> > > described as a device node. The reserved memory pool this protected heap
> > > comes from is most likely defined somewhere as reserved memory in the
> > > DT, but there's nothing to correlate this range of reserved mem to some
> > > sub-range that the TEE implementation is carving out to provide
> > > protected memory.
> >
> > Maybe we should be working on a dt bindings for heaps then? Something
> > simple like we have for clocks with a phandle and an ID would probably
> > be enough. In optee's case, it looks like it would map nicely with
> > TEE_DMA_HEAP_* flags too.
>
> Sure.
>
> >
> > The only two that wouldn't be covered would be the system and default
> > CMA heap if not setup in the DT, which shouldn't be too bad for this
> > particular use-case.
>
> I'm not opposed to the idea of describing the association through the
> DT (with a <phandle, ID> pair). My main fear is that it drags us into
> endless discussions around what's considered HW description and what's
> not (PTSD of all those DT-bindings discussions I suppose :-)), which
> ends up delaying the merging of Panthor's protected memory support.
FWIW, I plan on doing exactly that for Tegra. The way we wire things up
there is by referencing the protected memory by phandle via the memory-
region property (and a memory-region-names = "protected" for context).
It doesn't support passing a specifier along with the phandle, but maybe
that can be added (using something like a #memory-region-cells property
to mirror other similar bindings).
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-07 13:40 UTC (permalink / raw)
To: Greg KH; +Cc: corbet, akpm, skhan, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <2026050739-football-dreamy-351f@gregkh>
On Thu, May 07, 2026 at 12:47:43PM +0200, Greg KH wrote:
>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.
I figure that even if the new kernel does go out in a timely manner, there are
still days (weeks? months?) between when a new kernel is available and when the
user reboots.
Might as well try and improve their chances of survival during that period :)
>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?
The return register is `long` on every arch.
While testing this, I added the ability to modify the return value after we
create a killswitch, and figured that it could be a useful thing to keep in the
code.
But then I got worried about a race between a user changing the return value of
the killswitch and some program trying to execute the code, and getting some
combination of the old and the new return value.
Is that a real concern? I'm not sure - but making this atomic was cheap enough.
>> + /* 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?
Ugh... no good reason, I can switch to a kref.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH] Documentation: core-api/cpu_hotplug: Remove stale cpu0_hotplug docs
From: Chao Gao @ 2026-05-07 13:47 UTC (permalink / raw)
To: linux-doc, linux-kernel
Cc: Chao Gao, Dave Hansen, Jonathan Corbet, Shuah Khan
Commit e59e74dc48a3 ("x86/topology: Remove CPU0 hotplug option")
removed the 'cpu0_hotplug' option, but its documentation remained in
cpu_hotplug.rst. Remove the stale entry.
Reported-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
---
Documentation/core-api/cpu_hotplug.rst | 5 -----
1 file changed, 5 deletions(-)
diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
index 9b4afca9fd09..6de26d1c6a9a 100644
--- a/Documentation/core-api/cpu_hotplug.rst
+++ b/Documentation/core-api/cpu_hotplug.rst
@@ -45,11 +45,6 @@ Command Line Switches
This option is limited to the X86 and S390 architecture.
-``cpu0_hotplug``
- Allow to shutdown CPU0.
-
- This option is limited to the X86 architecture.
-
CPU maps
========
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v9 00/22] Enable FRED with KVM VMX
From: Maciej Wieczor-Retman @ 2026-05-07 13:53 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: <1146015e19d441f135d81f376c158c938a7ba340.camel@infradead.org>
On 2026-05-07 at 14:35:41 +0100, David Woodhouse wrote:
>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.
My theory is that after 'int3' call the FRED event is handled elsewhere and %rdi
is not preserved. So the original version of the assembly looks okay but I was
thinking that int3 has side effects.
Below is the test output of the RIPs not matching when running the original,
does that help in any way?
Random seed: 0x6b8b4567
Testing FRED event types with EPT fault on stack
==== Test Assertion Failure ====
x86/int1_fred_test.c:114: fred_saved_rip == expected_rip
pid=193114 tid=193114 errno=4 - Interrupted system call
1 0x0000000000413319: assert_on_unhandled_exception at processor.c:659
2 0x0000000000407d06: _vcpu_run at kvm_util.c:1703
3 (inlined by) vcpu_run at kvm_util.c:1714
4 0x0000000000403104: main at int1_fred_test.c:209
5 0x00007f90b3c2a1c9: ?? ??:0
6 0x00007f90b3c2a28a: ?? ??:0
7 0x0000000000403314: _start at ??:?
0x40446b != 0xabaf80 (fred_saved_rip != expected_rip)
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply
* Re: [PATCH v9 00/22] Enable FRED with KVM VMX
From: David Woodhouse @ 2026-05-07 14:01 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: <afyXgQdzdTr_JNXf@wieczorr-mobl1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
On Thu, 2026-05-07 at 15:53 +0200, Maciej Wieczor-Retman wrote:
>
> My theory is that after 'int3' call the FRED event is handled elsewhere and %rdi
> is not preserved. So the original version of the assembly looks okay but I was
> thinking that int3 has side effects.
>
> Below is the test output of the RIPs not matching when running the original,
> does that help in any way?
Ah right, of course!
+"fred_entrypoint_kernel:\n"
+ "movq %rsp, %rdi\n"
+ "call fred_handler\n"
+ ".byte 0xf2, 0x0f, 0x01, 0xca\n" /* ERETS */
+ ".popsection\n"
That needs to save the %rdi it's scribbling on, plus all the callee-
clobbered registers that fred_handler() might use.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v9 1/9] revocable: Revocable resource management
From: Tzung-Bi Shih @ 2026-05-07 14:03 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Benson Leung, linux-kernel, chrome-platform, driver-core,
linux-doc, linux-gpio, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Shuah Khan, Laurent Pinchart, Wolfram Sang,
Jason Gunthorpe, Johan Hovold, Paul E . McKenney, Dan Williams,
Arnd Bergmann, Greg Kroah-Hartman, Linus Walleij
In-Reply-To: <CAMRc=McG41iHWfY+3U4Xp6YNFCwbt_zAUE-2417LrQVrTfdWjA@mail.gmail.com>
On Tue, May 05, 2026 at 05:55:40AM -0700, Bartosz Golaszewski wrote:
> On Mon, 27 Apr 2026 15:58:33 +0200, Tzung-Bi Shih <tzungbi@kernel.org> said:
> > diff --git a/include/linux/revocable.h b/include/linux/revocable.h
> > new file mode 100644
> > index 000000000000..2bcf23f01ace
> > --- /dev/null
> > +++ b/include/linux/revocable.h
> > @@ -0,0 +1,214 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2026 Google LLC
> > + */
> > +
> > +#ifndef __LINUX_REVOCABLE_H
> > +#define __LINUX_REVOCABLE_H
> > +
> > +#include <linux/cleanup.h>
> > +#include <linux/compiler.h>
>
> I don't think you need this header.
Ack, will remove it in the next version.
>
> > +#include <linux/kref.h>
> > +#include <linux/srcu.h>
> > +
> > +/**
> > + * enum revocable_alloc_type - The allocation method for a revocable provider.
> > + * @REVOCABLE_DYNAMIC: The struct revocable was dynamically allocated using
> > + * revocable_alloc() and its lifetime is managed by
> > + * reference counting.
> > + * @REVOCABLE_EMBEDDED: The struct revocable is embedded within another
> > + * structure. Its lifetime is tied to the parent
> > + * structure and is not reference counted.
> > + */
> > +enum revocable_alloc_type {
> > + REVOCABLE_DYNAMIC,
> > + REVOCABLE_EMBEDDED,
> > +};
>
> Maybe we don't need this public enum at all, we could just use a different
> release callback for kref_put() depending on how the revocable was allocated?
>
> The enum is not used elsewhere so it doesn't make sense to document it as if it
> was part of the revocable API.
>
> > +
> > +/**
> > + * struct revocable - A handle for resource provider.
> > + * @srcu: The SRCU to protect the resource.
> > + * @res: The pointer of resource. It can point to anything.
> > + * @kref: The refcount for this handle.
> > + * @alloc_type: The memory allocation type.
> > + */
> > +struct revocable {
> > + struct srcu_struct srcu;
> > + void __rcu *res;
> > + struct kref kref;
> > + enum revocable_alloc_type alloc_type;
>
> This could be replaced with the pointer to the release callback, assigned
> by revocable_alloc()/revocable_init() respectively.
>
Ack, will remove the enum. A boolean is sufficient given that the
allocation type is binary.
> > +};
> > +
> > +/**
> > + * struct revocable_consumer - A handle for resource consumer.
> > + * @rev: The pointer of resource provider.
> > + * @idx: The index for the SRCU critical section.
>
> Should any of these be accessed directly by the user? Maybe document them
> as __private?
I don't think that is necessary. All members in both struct revocable and
struct revocable_consumer are intended to be opaque and should not be
accessed directly by users. However, I made them public structures
because:
- The try_access_* macros need to allocate a struct revocable_consumer
locally.
- KUnit tests require access to these members for verification.
I can add a comment to the structure definitions noting that they should
be treated as private. Does it make sense?
>
> > + */
> > +struct revocable_consumer {
> > + struct revocable *rev;
> > + int idx;
> > +};
>
> I'd rename it to struct revocable_handle which indicates better what it is:
> it's a handle *owned* by the consumer.
Ack, will rename it.
>
> > +
> > +void revocable_get(struct revocable *rev);
> > +void revocable_put(struct revocable *rev);
> > +
> > +struct revocable *revocable_alloc(void *res);
> > +void revocable_revoke(struct revocable *rev);
> > +int revocable_embed_init(struct revocable *rev, void *res);
> > +void revocable_embed_destroy(struct revocable *rev);
> > +
> > +void revocable_init(struct revocable *rev, struct revocable_consumer *rc);
> > +void revocable_deinit(struct revocable_consumer *rc);
>
> If we hid the release logic, we could drop revocable_embed_destroy() and use
> the same refcounting functions for both variants. I'd suggest the following:
>
> For refcounting (same for both variants):
>
> void revocable_get(struct revocable *rev);
> void revocable_put(struct revocable *rev);
>
> For dynamic variant:
>
> struct revocable *revocable_alloc(void *res);
>
> For embedded:
>
> int revocable_init(struct revocable *rev, void *res);
>
> For handles:
>
> void revocable_handle_init(struct revocable *rev, struct
> revocable_consumer *rc);
> void revocable_handle_deinit(struct revocable_consumer *rc);
>
> Does it make sense?
That makes sense. I'll fix this in the next version.
^ permalink raw reply
* Re: [PATCH v9 2/6] iio: adc: ad4691: add initial driver for AD4691 family
From: Jonathan Cameron @ 2026-05-07 14:15 UTC (permalink / raw)
To: Sabau, Radu bogdan
Cc: Lars-Peter Clausen, Hennerich, Michael, 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,
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: <LV9PR03MB841460307B0CF4C6F267A631F73C2@LV9PR03MB8414.namprd03.prod.outlook.com>
On Thu, 7 May 2026 09:26:00 +0000
"Sabau, Radu bogdan" <Radu.Sabau@analog.com> wrote:
> Addressing Sashiko's review for initial driver's patch.
>
> > -----Original Message-----
> > From: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org>
> > Sent: Thursday, April 30, 2026 1:17 PM
>
> ...
>
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 60038ae8dfc4..3685a03aa8dc 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -139,6 +139,17 @@ config AD4170_4
> > To compile this driver as a module, choose M here: the module will be
> > called ad4170-4.
> >
> > +config AD4691
> > + tristate "Analog Devices AD4691 Family ADC Driver"
> > + depends on SPI
>
> "Should this driver also depend on REGULATOR? In ad4691_regulator_setup(),
> it relies on devm_regulator_get_enable_read_voltage() to obtain its reference
> voltage. If the kernel is compiled without CONFIG_REGULATOR, this function
> is stubbed to return -ENODEV, causing probe to fail unconditionally."
>
> Will add "depends on REGULATOR". Without it,
> devm_regulator_get_enable_read_voltage() can be stubbed and
> return -ENODEV, making the driver unusable regardless of hardware.
If you really want to also add || COMPILE_TEST because
I want maximum build coverage and for that I don't mind if the driver
can actually probe or not.
>
> > + select REGMAP
> > + help
> > + Say yes here to build support for Analog Devices AD4691 Family
>
> ...
>
> > +};
> > +
> > +#define AD4691_CHANNEL(ch)
> > \
> > + { \
> > + .type = IIO_VOLTAGE, \
> > + .indexed = 1, \
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW)
> > \
> > + | BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > + .info_mask_separate_available =
> > \
> > + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> > \
>
> "Since ad4691_set_sampling_freq() modifies the AD4691_OSC_FREQ_REG register
> which controls the global internal oscillator frequency for the entire ADC,
> should IIO_CHAN_INFO_SAMP_FREQ be exposed as info_mask_shared_by_all
> instead of info_mask_separate? Changing the frequency for one channel
> currently seems to silently alter it for all channels."
>
> Agreed for this commit. With no per-channel OSR in the base driver
> all channels share a single oscillator register, so info_mask_shared_by_all
> is the correct annotation. Changing accordingly. The OSR commit switches it
> back to info_mask_separate because at that point the effective rate is
> genuinely per-channel (osc_freq / osr[N]).
Don't. That would mean an ABI change mid way through the series which we
don't want. Just add a note to the patch description.
...
>
> > +
> > +static int ad4691_reset(struct ad4691_state *st)
> > +{
> > + struct device *dev = regmap_get_device(st->regmap);
> > + struct reset_control *rst;
> > +
> > + rst = devm_reset_control_get_optional_exclusive(dev, NULL);
> > + if (IS_ERR(rst))
> > + return dev_err_probe(dev, PTR_ERR(rst), "Failed to get
> > reset\n");
> > +
> > + if (rst) {
> > + /*
> > + * reset_gpio_probe() already drives the pin asserted, so the
> > + * device is held in reset before we get here.
> > + * devm_reset_control_get_optional_exclusive_deasserted()
> > cannot
> > + * be used because it deasserts immediately without delay; the
> > + * datasheet (Table 5) requires a ≥300 µs reset pulse width
> > + * before deassertion.
> > + */
> > + fsleep(300);
> > + return reset_control_deassert(rst);
>
> "Could this sequence break on driver reload?
> When the driver is unloaded, the reset line remains in its deasserted state
> because there is no cleanup action to re-assert it. Upon reloading, the 300
> microsecond sleep will occur while the pin is already deasserted, meaning
> the hardware might not receive the required reset pulse.
> Should reset_control_assert() be called explicitly prior to the delay?"
>
> Valid. reset_control_put() does not re-assert the line at unload, so
> on reload the pin is already deasserted when we enter the 300 µs sleep.
> Adding reset_control_assert(rst) before fsleep(300) to guarantee a proper
> reset pulse on every probe including reloads.
I'm not that fussed about driver reload bugs like this one but why
not fix it I guess. Lots of cases of this in upstream code though.
>
> > + }
> > +
>
> ...
>
> > +
> > + st = iio_priv(indio_dev);
> > + st->info = spi_get_device_match_data(spi);
>
> "Is it possible for st->info to be NULL here?
> If the driver is manually bound to a device with a non-matching name using
> the sysfs bind interface in combination with driver_override,
> spi_get_device_match_data() could return NULL, which would cause a NULL
> pointer dereference later in the probe sequence."
>
> Agreed, will add the NULL check with -ENODEV immediately after
> spi_get_device_match_data().
Andy, you seeing this one? Looks like we are putting these checks back in again.
Whilst anyone forcing a bind like this is onto a looser anyway we shouldn't
crash due to a null dereference.
>
> > +
> > + ret = devm_mutex_init(dev, &st->lock);
> > + if (ret)
> > + return ret;
>
^ permalink raw reply
* Re: [PATCH v9 3/6] iio: adc: ad4691: add triggered buffer support
From: Jonathan Cameron @ 2026-05-07 14:25 UTC (permalink / raw)
To: Sabau, Radu bogdan
Cc: Lars-Peter Clausen, Hennerich, Michael, 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,
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: <LV9PR03MB8414E0FFAD9C9423189117B2F73C2@LV9PR03MB8414.namprd03.prod.outlook.com>
On Thu, 7 May 2026 11:37:25 +0000
"Sabau, Radu bogdan" <Radu.Sabau@analog.com> wrote:
> 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.
This looks wrong to me.
What holes? If available_scan_masks is set we will do a bunch of
demux work - but then this code would see the mask picked from that
list. If it's not then typically we won't (subject to multiple consumers
forcing it - but that still won't close up holes here).
If the active_scan_mask == the one requested, there is no demux at all
and I think that's the case here - the code pushes the data passed in
directly to the kfifo.
Perhaps given an illustration of what the layout of resulting data
is if only even numbered channels are enabled.
>
> > + 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++;
> > + }
> > +
>
>
> > + 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.
Make sure to add a comment on why that is there.
Otherwise makes sense.
>
Rest look fine to me.
^ permalink raw reply
* Re: [PATCH] Documentation/firmware: clean up other_interfaces.rst
From: Frank Li @ 2026-05-07 14:39 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap
Cc: Frank Li, Pankaj Gupta, imx, Jonathan Corbet, Shuah Khan,
linux-doc
In-Reply-To: <20260507020446.370101-1-rdunlap@infradead.org>
On Wed, 06 May 2026 19:04:46 -0700, Randy Dunlap wrote:
> Fix bullet lists, grammar, punctuation, spelling, and literal block
> formatting. These changes eliminate several documentation build warnings
> make the documentation more readable, and render it cleanly.
>
> Documentation/driver-api/firmware/other_interfaces.rst:60: ERROR: Unexpected indentation. [docutils]
> Documentation/driver-api/firmware/other_interfaces.rst:103: ERROR: Unexpected indentation. [docutils]
> Documentation/driver-api/firmware/other_interfaces.rst:115: ERROR: Unexpected indentation. [docutils]
> Documentation/driver-api/firmware/other_interfaces.rst:116: WARNING: Blank line required after table. [docutils]
> Documentation/driver-api/firmware/other_interfaces.rst:140: WARNING: Bullet list ends without a blank line; unexpected unindent. [docutils]
>
> [...]
Applied, thanks!
[1/1] Documentation/firmware: clean up other_interfaces.rst
squash to 3b4531c6e0f4 ("Documentation/firmware: add imx/se to other_interfaces")
any concern let me known.
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dpll: add fractional frequency offset to pin-parent-device
From: Jakub Kicinski @ 2026-05-07 14:47 UTC (permalink / raw)
To: Ivan Vecera
Cc: Jiri Pirko, 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: <541f767d-222b-4dfa-a95a-19a5ed7a46bf@redhat.com>
On Thu, 7 May 2026 08:12:01 +0200 Ivan Vecera wrote:
> >> @@ -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.
>
> Regarding the fail-close concern — I agree that relying on drivers
> to check dpll==NULL is fragile. A capability bit alone wouldn't help
> though, since the driver still needs to distinguish which FFO context
> is being requested.
>
> I can think of two approaches:
> 1. An explicit bool parameter (e.g. `bool per_parent`) instead of
> overloading the dpll pointer for context distinction.
> 2. Separate callbacks for each FFO context (e.g. ffo_get for the
> top-level and ffo_parent_get for the per-parent).
>
> Do you have a preference, or something else in mind?
TAL at the fields at the beginning of struct ethtool_ops
If we had two bits in the ops struct for driver to declare / opt-in
to each context the core can avoid calling the driver if it doesn't
support a context.
^ permalink raw reply
* Re: [PATCH 6/8] drm/panthor: Explicit expansion of locked VM region
From: Nicolas Frattaroli @ 2026-05-07 14:54 UTC (permalink / raw)
To: 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, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, Ketil Johnsen, Ketil Johnsen
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek
In-Reply-To: <kC1hpRBAS8uGaw7vVFyW2g@collabora.com>
On Wednesday, 6 May 2026 17:14:45 Central European Summer Time Nicolas Frattaroli wrote:
> On Tuesday, 5 May 2026 16:05:12 Central European Summer Time Ketil Johnsen wrote:
> > Currently the panthor_vm_lock_region() function will implicitly expand
> > an already locked VM region. This can be problematic because the caller
> > do not reliably know if it needs to call panthor_vm_unlock_region()
> > or not.
> >
> > Worth noting, there is currently no known issues with this as the code
> > is written today.
> >
> > This change introduces panthor_vm_expand_region() which will only work
> > if there is already a locked VM region. This again means that the
> > original lock and unlock functions can work as a pair. This pairing is
> > needed for subsequent protected memory changes.
> >
> > Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
> > ---
> > drivers/gpu/drm/panthor/panthor_mmu.c | 69 +++++++++++++++++++--------
> > 1 file changed, 50 insertions(+), 19 deletions(-)
> >
>
> While trying this series, I attempted my usual
> `modprobe -r panthor && modprobe panthor protected_heap_name=default_cma_region`.
>
> Unfortunately, it oopses when attempting to unmap the sg for a bo labeled
> "FW section" on panthor module unload, and I bisected it to this patch.
Okay, so this one is due to the iomem access rework having landed
in drm-misc-next already, but this series being based on something
before that, so now all the new gpu_read(_.*)? and gpu_write.* calls
pass a panthor_device to something that expects the iomem. Since the
iomem uses void pointers, this wasn't caught by the compiler.
So, no "real" bug here, just an incredible dice roll for luck from my side.
Kind regards
Nicolas Frattaroli
>
> The oops:
>
> [ 598.515550] Unable to handle kernel paging request at virtual address 0000000000400267
> [ 598.516864] Mem abort info:
> [ 598.517676] ESR = 0x0000000096000004
> [ 598.518560] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 598.520414] SET = 0, FnV = 0
> [ 598.521275] EA = 0, S1PTW = 0
> [ 598.522099] FSC = 0x04: level 0 translation fault
> [ 598.523069] Data abort info:
> [ 598.524311] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 598.525566] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 598.526850] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 598.527905] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104056000
> [ 598.529019] [0000000000400267] pgd=0000000000000000, p4d=0000000000000000
> [ 598.530170] Internal error: Oops: 0000000096000004 [#1] SMP
> [ 598.531158] Modules linked in: btusb btrtl btmtk btintel btbcm bluetooth ecdh_generic ecc kpp snd_soc_hdmi_codec cfg80211 r8169 rfkill_gpio pwm_fan rfkill snd_soc_es8316 rtc_hym8563 rk805_pwrkey at24 fusb302 tcpm aux_hpd_bridge display_connector snd_soc_simple_card phy_rockchip_samsung_hdptx phy_rockchip_usbdp rockchip_thermal typec phy_rockchip_naneng_combphy rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchipdrm inno_hdmi dw_dp hantro_vpu rockchip_vdec dw_mipi_dsi2 v4l2_jpeg v4l2_vp9 rockchip_rga dw_mipi_dsi v4l2_h264 synopsys_hdmirx v4l2_dv_timings spi_rockchip_sfc videobuf2_dma_contig videobuf2_dma_sg v4l2_mem2mem videobuf2_memops dw_hdmi_qp onboard_usb_dev analogix_dp videobuf2_v4l2 videobuf2_common snd_soc_rockchip_i2s_tdm dw_hdmi videodev mc drm_display_helper nvme cec panthor(-) drm_gpuvm drm_exec gpu_sched drm_dp_aux_bus drm_dma_helper drm_client_lib nvme_core drm_kms_helper drm pci_endpoint_test backlight snd_soc_audio_graph_card snd_soc_simple_card_utils fuse dm_mod
> [ 598.541237] CPU: 6 UID: 0 PID: 806 Comm: modprobe Not tainted 7.1.0-rc2-00726-g8ab0a3092b56-dirty #2 PREEMPT
> [ 598.542733] Hardware name: Radxa ROCK 5T (DT)
> [ 598.543746] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 598.544991] pc : dma_unmap_sg_attrs (kernel/dma/mapping.c:0)
> [ 598.546021] lr : panthor_gem_free_object (include/linux/dma-mapping.h:565 drivers/gpu/drm/panthor/panthor_gem.c:308 drivers/gpu/drm/panthor/panthor_gem.c:469) panthor
> [ 598.547180] sp : ffff80008835bb90
> [ 598.548123] x29: ffff80008835bb90 x28: ffff00012610bf00 x27: 0000000000000000
> [ 598.549412] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
> [ 598.550696] x23: ffff000127194600 x22: ffff0001271943d0 x21: ffff000118671000
> [ 598.551984] x20: ffff000127194200 x19: ffff000127194600 x18: 00000000002ab980
> [ 598.553273] x17: 00000000002ab980 x16: ffffa39a6b372a04 x15: 0000000000000000
> [ 598.554568] x14: 0000000000000010 x13: 0000000000000000 x12: 000000000000003c
> [ 598.555864] x11: 0000000000000002 x10: ffff000100a5d000 x9 : ffff000118671000
> [ 598.557164] x8 : ffff000102f8b490 x7 : ffff000149569000 x6 : ffff000149569000
> [ 598.558461] x5 : ffff000100faa7e8 x4 : 0000000000000000 x3 : 0000000000000000
> [ 598.559763] x2 : 0000000000000010 x1 : ffff000127194000 x0 : 000000000040000f
> [ 598.561069] Call trace:
> [ 598.561961] dma_unmap_sg_attrs (kernel/dma/mapping.c:0) (P)
> [ 598.563038] panthor_gem_free_object (include/linux/dma-mapping.h:565 drivers/gpu/drm/panthor/panthor_gem.c:308 drivers/gpu/drm/panthor/panthor_gem.c:469) panthor
> [ 598.564218] drm_gem_object_free (drivers/gpu/drm/drm_gem.c:1148) drm
> [ 598.565386] panthor_kernel_bo_destroy (include/linux/kref.h:65 include/drm/drm_gem.h:565 include/drm/drm_gem.h:578 drivers/gpu/drm/panthor/panthor_gem.c:1317) panthor
> [ 598.566575] panthor_fw_unplug (drivers/gpu/drm/panthor/panthor_fw.c:1306) panthor
> [ 598.567705] panthor_device_unplug (drivers/gpu/drm/panthor/panthor_device.c:103) panthor
> [ 598.568878] panthor_remove (drivers/gpu/drm/panthor/panthor_drv.c:1846) panthor
> [ 598.569991] platform_remove (drivers/base/platform.c:1435)
> [ 598.571029] device_release_driver_internal (drivers/base/dd.c:619 drivers/base/dd.c:1352 drivers/base/dd.c:1375)
> [ 598.572209] driver_detach (drivers/base/dd.c:1438)
> [ 598.573237] bus_remove_driver (drivers/base/bus.c:825)
> [ 598.574304] driver_unregister (drivers/base/driver.c:277)
> [ 598.575363] platform_driver_unregister (drivers/base/platform.c:920)
> [ 598.576494] cleanup_module (drivers/gpu/drm/panthor/panthor_devfreq.c:134) panthor
> [ 598.577617] __arm64_sys_delete_module (kernel/module/main.c:863 kernel/module/main.c:804 kernel/module/main.c:804)
> [ 598.578751] invoke_syscall (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49)
> [ 598.579794] el0_svc_common (arch/arm64/kernel/syscall.c:121)
> [ 598.580842] do_el0_svc (arch/arm64/kernel/syscall.c:140)
> [ 598.581862] el0_svc (arch/arm64/kernel/entry-common.c:723)
> [ 598.582853] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:742)
> [ 598.583949] el0t_64_sync (arch/arm64/kernel/entry.S:594)
>
> Kind regards,
> Nicolas Frattaroli
>
>
>
^ permalink raw reply
* Re: [PATCH v9 4/6] iio: adc: ad4691: add SPI offload support
From: Jonathan Cameron @ 2026-05-07 15:11 UTC (permalink / raw)
To: Sabau, Radu bogdan
Cc: Lars-Peter Clausen, Hennerich, Michael, 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,
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: <LV9PR03MB8414E7E034F79900A6595750F73C2@LV9PR03MB8414.namprd03.prod.outlook.com>
> > + /* 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.
This confuses me a bit because the SPI controller should work with
native endian and from that generate the expected big endian on the wire.
So on a little endian host byte order in address space is LH but it will
write top bit of H first thus the ADC channel address needs to be in the
second byte.
On a big endian host despite the ordering in memory being HL, the top
bit of H is still written first thus in needs to be in the first byte.
If you using cpu_to_be16() to assign a 16 bit value swapping only on little endian
and start with the cmd in L on little endian you'll end up with LH swapped to
HL and on big endian HL but the little endian SPI controller should then swap
it again sending what it thinks is the high byte first (L) whereas the big endian
system will send H.
Upshot. I think the field should be native endian. If a byte swap is needed
it should be unconditional and not rely on endianness of the host.
>
> > +
> > + /* 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.
>
^ permalink raw reply
* Re: [PATCH 6/6] KVM: PPC: Document KVM_PPC_GET_COMPAT_CAPS ioctl
From: Amit Machhiwal @ 2026-05-07 15:20 UTC (permalink / raw)
To: Harsh Prateek Bora
Cc: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan, Vaibhav Jain,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, kvm, linux-kernel,
linux-doc
In-Reply-To: <81b9d00f-7568-4bcd-9b77-2f6de3162d65@linux.ibm.com>
On 2026/05/05 03:25 PM, Harsh Prateek Bora wrote:
>
>
> On 30/04/26 11:19 am, Amit Machhiwal wrote:
> > Add documentation for the KVM_PPC_GET_COMPAT_CAPS ioctl to the KVM API
> > documentation.
> >
> > The ioctl exposes host processor compatibility modes supported for
> > nested KVM guests on PowerPC systems.
> >
> > Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> > ---
> > Documentation/virt/kvm/api.rst | 35 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index 52bbbb553ce1..7a10c3c6cbf1 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -6555,6 +6555,41 @@ KVM_S390_KEYOP_SSKE
> > .. _kvm_run:
> > +4.145 KVM_PPC_GET_COMPAT_CAPS
> > +-----------------------------
> > +:Capability: KVM_CAP_PPC_COMPAT_CAPS
> > +:Architectures: powerpc
> > +:Type: vm ioctl
> > +:Parameters: struct kvm_ppc_compat_caps (out)
> > +:Returns:
> > + 0 on successful completion,
> > + -EFAULT if ``struct kvm_ppc_compat_caps`` cannot be written
>
> -EINVAL also needs to be documented?
We do not currently return -EINVAL for this ioctl, so I did not document it. As
implemented, the only explicit error documented here is -EFAULT when struct
kvm_ppc_compat_caps cannot be written. Please let me know if I am missing a case
where -EINVAL should be returned.
>
> > +
> > +IBM POWER system server-based processors provide a compatibility mode feature
> > +where an Nth generation processor can operate in modes consistent with earlier
> > +generations such as (N-1) and (N-2).
> > +
> > +This ioctl provides userspace with information about the CPU compatibility modes
> > +supported by the current host processor for booting the nested KVM guests on
> > +PowerNV (KVM nested APIv1) and PowerVM (KVM nested APIv2) platforms.
> > +
> > +::
> > +
> > + struct kvm_ppc_compat_caps {
> > + __u32 flags;
> > + __u64 compat_capabilities; /* Capabilities supported by the host */
> > + };
> > +
> > +The ``compat_capabilities`` bit field describes the processor compatibility
> > +modes supported by the host. For example, the following bits indicate support
> > +for specific processor modes.
> > +
> > +::
> > +
> > + bit 1: KVM guests can run in Power9 processor mode
> > + bit 2: KVM guests can run in Power10 processor mode
> > + bit 3: KVM guests can run in Power11 processor mode
>
> May be use H_GUEST_CAP_POWER9 and friends ?
I used the bit descriptions directly since this is documenting the uAPI bitmap
layout, which felt clearer for userspace than using only H_GUEST_CAP_POWER9 and
friends. But I’m happy to mention those macros as well if you think that
improves clarity.
Thanks again for reviewing the series. I will wait a little longer for any
further feedback before posting v2.
Thanks,
Amit
>
> > +
> > 5. The kvm_run structure
> > ========================
>
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Jonathan Corbet @ 2026-05-07 15:21 UTC (permalink / raw)
To: Sasha Levin, akpm
Cc: skhan, linux-doc, linux-kernel, linux-kselftest, gregkh,
Sasha Levin
In-Reply-To: <20260507070547.2268452-1-sashal@kernel.org>
Sasha Levin <sashal@kernel.org> writes:
> 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 quick look suggests that you're not checking lockdown status. I don't
doubt for a second that this thing could be used to bypass lockdown - by
shorting out security_locked_down() if nothing else. I'm guessing that
might not prove entirely popular.
jon
^ permalink raw reply
* Re: [PATCH v9 5/6] iio: adc: ad4691: add oversampling support
From: Jonathan Cameron @ 2026-05-07 15:26 UTC (permalink / raw)
To: Sabau, Radu bogdan
Cc: Lars-Peter Clausen, Hennerich, Michael, 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,
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: <LV9PR03MB8414B9A4A4D48BDF8E60398FF73C2@LV9PR03MB8414.namprd03.prod.outlook.com>
On Thu, 7 May 2026 11:56:53 +0000
"Sabau, Radu bogdan" <Radu.Sabau@analog.com> wrote:
> Addressing Sashiko's review for the oversampling support patch.
>
One thing inline. I think Sashiko got it wrong..
> > @@ -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.
I saw this one and think it's wrong.
It is sort of true and sort of not. active_scan_mask never has the timestamp
channel set. There is special handling for that channel.
https://elixir.bootlin.com/linux/v7.0.1/source/drivers/iio/industrialio-buffer.c#L613
IIRC the bitmap is technically one bit too large given that quirk
(I've not checked that today so I'm relying on memory of when this last came up).
Jonathan
> 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 1/8] dma-heap: Add proper kref handling on dma-buf heaps
From: Maxime Ripard @ 2026-05-07 15:33 UTC (permalink / raw)
To: Boris Brezillon
Cc: Ketil Johnsen, David Airlie, Simona Vetter, Maarten Lankhorst,
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, Yong Wu, Yunfei Dong,
Florent Tomasin
In-Reply-To: <20260505184021.3676f9af@fedora>
[-- Attachment #1: Type: text/plain, Size: 5859 bytes --]
On Tue, May 05, 2026 at 06:40:21PM +0200, Boris Brezillon wrote:
> On Tue, 5 May 2026 17:39:13 +0200
> Maxime Ripard <mripard@kernel.org> wrote:
>
> > Hi Boris,
> >
> > On Tue, May 05, 2026 at 05:20:48PM +0200, Boris Brezillon wrote:
> > > Hi Ketil,
> > >
> > > On Tue, 5 May 2026 16:05:07 +0200
> > > Ketil Johnsen <ketil.johnsen@arm.com> wrote:
> > >
> > > > From: John Stultz <jstultz@google.com>
> > > >
> > > > Add proper reference counting on the dma_heap structure. While
> > > > existing heaps are built-in, we may eventually have heaps loaded
> > > > from modules, and we'll need to be able to properly handle the
> > > > references to the heaps
> > >
> > > It's weird that this "heap as module" thing is mentioned here, but
> > > actual robustness to make this safe is not added in the commit or any
> > > of the following ones.
> > >
> > > >
> > > > Signed-off-by: John Stultz <jstultz@google.com>
> > > > Signed-off-by: T.J. Mercier <tjmercier@google.com>
> > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > [Yong: Just add comment for "minor" and "refcount"]
> > > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > > [Yunfei: Change reviewer's comments]
> > > > Signed-off-by: Florent Tomasin <florent.tomasin@arm.com>
> > > > [Florent: Rebase]
> > > > Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
> > > > [Ketil: Rebase]
> > > > ---
> > > > drivers/dma-buf/dma-heap.c | 29 +++++++++++++++++++++++++++++
> > > > include/linux/dma-heap.h | 2 ++
> > > > 2 files changed, 31 insertions(+)
> > > >
> > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> > > > index ac5f8685a6494..9fd365ddbd517 100644
> > > > --- a/drivers/dma-buf/dma-heap.c
> > > > +++ b/drivers/dma-buf/dma-heap.c
> > > > @@ -12,6 +12,7 @@
> > > > #include <linux/dma-heap.h>
> > > > #include <linux/err.h>
> > > > #include <linux/export.h>
> > > > +#include <linux/kref.h>
> > > > #include <linux/list.h>
> > > > #include <linux/nospec.h>
> > > > #include <linux/syscalls.h>
> > > > @@ -31,6 +32,7 @@
> > > > * @heap_devt: heap device node
> > > > * @list: list head connecting to list of heaps
> > > > * @heap_cdev: heap char device
> > > > + * @refcount: reference counter for this heap device
> > > > *
> > > > * Represents a heap of memory from which buffers can be made.
> > > > */
> > > > @@ -41,6 +43,7 @@ struct dma_heap {
> > > > dev_t heap_devt;
> > > > struct list_head list;
> > > > struct cdev heap_cdev;
> > > > + struct kref refcount;
> > > > };
> > > >
> > > > static LIST_HEAD(heap_list);
> > > > @@ -248,6 +251,7 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> > > > if (!heap)
> > > > return ERR_PTR(-ENOMEM);
> > > >
> > > > + kref_init(&heap->refcount);
> > > > heap->name = exp_info->name;
> > > > heap->ops = exp_info->ops;
> > > > heap->priv = exp_info->priv;
> > > > @@ -313,6 +317,31 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> > > > }
> > > > EXPORT_SYMBOL_NS_GPL(dma_heap_add, "DMA_BUF_HEAP");
> > > >
> > > > +static void dma_heap_release(struct kref *ref)
> > > > +{
> > > > + struct dma_heap *heap = container_of(ref, struct dma_heap, refcount);
> > > > + unsigned int minor = MINOR(heap->heap_devt);
> > > > +
> > > > + mutex_lock(&heap_list_lock);
> > > > + list_del(&heap->list);
> > > > + mutex_unlock(&heap_list_lock);
> > > > +
> > > > + device_destroy(dma_heap_class, heap->heap_devt);
> > > > + cdev_del(&heap->heap_cdev);
> > > > + xa_erase(&dma_heap_minors, minor);
> > > > +
> > > > + kfree(heap);
> > >
> > > That's actually problematic, because cdev_del() doesn't guarantee that
> > > all opened FDs have been closed [1], it just guarantees that no new ones
> > > can materialize. In order to make that safe, we'd need a
> > >
> > > 1. kref_get_unless_zero() in dma_heap_open(), with proper locking around
> > > the xa_load() to protect against the heap removal that's happening
> > > here
> > > 2. a dma_heap_put() in a new dma_heap_close() implementation
> > > 3. a guarantee that heap implementations won't go away until the last
> > > ref is dropped, which means ops and all the data needed for this heap
> > > to satisfy ioctl()s (and more generally every passed at
> > > dma_heap_add() time) have to stay valid until the last ref is
> > > dropped. Alternatively, we could restrict this only to in-flight
> > > ioctl()s, and have the ops replaced by some dummy ops using RCU or a
> > > rwlock. But I guess live dmabufs allocated on this heap have to
> > > retain the heap and its implementation anyway.
> > >
> > > For record, #3 is already not satisfied by the current tee_heap
> > > implementation (tee_dma_heap objects can vanish before the dma_heap
> > > object is gone). The other implementations seem to be fine because they
> > > are statically linked, and they either have exp_info.priv set to NULL,
> > > or something that's never released.
> >
> > That statement won't hold for long, see:
> > https://lore.kernel.org/r/20260427-dma-buf-heaps-as-modules-v5-0-b6f5678feefc@kernel.org
> >
> > However, all upstream heaps can be loaded as module, but not unloaded.
> > So once you get a reference to it, you can assume it will live forever.
> > That's why we didn't merge that patch before, even though it was discussed:
> >
> > https://lore.kernel.org/all/CANDhNCqk9Uk4aXHhUsL4hR1GHNmWZnH3C9Np-A02wdi+J3D7tA@mail.gmail.com/
>
> Hm, not too sure that makes the tee_heap implementation sane WRT
> tee_heap removal though, unless we have a guarantee that
> tee_device_unregister() will never be called...
I missed that part. You're totally right then :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Linus Torvalds @ 2026-05-07 15:37 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Willy Tarreau, greg, leon, security, Jonathan Corbet, skhan,
workflows, linux-doc, linux-kernel, Greg KH
In-Reply-To: <20260507070720.GG3126523@noisy.programming.kicks-ass.net>
On Thu, 7 May 2026 at 00:07, Peter Zijlstra <peterz@infradead.org> wrote:
>
> Perhaps also note that including a reproducer for a crash in public is
> fine, including a full blown exploit is not.
>
> So perhaps that can serve as a guide
That would be a good rule, I think - and I like how it has the
advantage of being very explicit and black-and-white, rather than some
"I think my bug is so important that it should be sent to the speshul
super-sikret list".
Because we all think we are special. Our mothers told us so, and even
the AI bots are typically explicitly told to act as experts. So they
think they are special too.
Linus
^ permalink raw reply
* Re: [PATCH net-next v2 2/6] net: devmem: support TX over NETMEM_TX_NO_DMA devices
From: Bobby Eshleman @ 2026-05-07 15:38 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi, Yanteng Si,
Dongliang Mu, Michael Chan, Pavan Chebbi, Joshua Washington,
Harshitha Ramamurthy, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Leon Romanovsky, Alexander Duyck, kernel-team, Daniel Borkmann,
Nikolay Aleksandrov, Shuah Khan, netdev, linux-doc, linux-kernel,
linux-rdma, bpf, linux-kselftest, Stanislav Fomichev,
Mina Almasry, Bobby Eshleman
In-Reply-To: <20260506193420.575e1806@kernel.org>
On Wed, May 06, 2026 at 07:34:20PM -0700, Jakub Kicinski wrote:
> On Mon, 04 May 2026 17:27:49 -0700 Bobby Eshleman wrote:
> > + if (bind_dev != netdev)
> > + netdev_lock(bind_dev);
> > + dma_dev = netdev_queue_get_dma_dev(bind_dev, 0, NETDEV_QUEUE_TYPE_TX);
> > + if (bind_dev != netdev)
> > + netdev_unlock(bind_dev);
> > + binding = net_devmem_bind_dmabuf(bind_dev,
> > + bind_dev != netdev ? netdev : NULL,
> > + dma_dev, DMA_TO_DEVICE, dmabuf_fd,
> > + priv, info->extack);
>
> Not sure if it matters but are we intentionally releasing the bind_dev
> lock before calling net_devmem_bind_dmabuf() ? Previously more code here
> was covered by the physical netdev's lock.
True, lock needs to be held at least until after binding. I have this
fixed in the next rev.
Best,
Bobby
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-07 15:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: Peter Zijlstra, greg, leon, security, Jonathan Corbet, skhan,
workflows, linux-doc, linux-kernel, Greg KH
In-Reply-To: <CAHk-=whE=rLLbBRsFuQKVX49NgN2UUdUE=Druf3fiSZ9Ou8c3Q@mail.gmail.com>
On Thu, May 07, 2026 at 08:37:29AM -0700, Linus Torvalds wrote:
> On Thu, 7 May 2026 at 00:07, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > Perhaps also note that including a reproducer for a crash in public is
> > fine, including a full blown exploit is not.
> >
> > So perhaps that can serve as a guide
>
> That would be a good rule, I think - and I like how it has the
> advantage of being very explicit and black-and-white, rather than some
> "I think my bug is so important that it should be sent to the speshul
> super-sikret list".
>
> Because we all think we are special. Our mothers told us so, and even
> the AI bots are typically explicitly told to act as experts. So they
> think they are special too.
These points correspond to what I mentioned in my second message a few
hours ago, but I want to protect maintainers against the flood of crap
they're not necessarily used to. I think that the balance I proposed
could work as it more or less covers this. When you have a time to look
at it I'd be glad to have your opinion/criticism (sorry if it's a bit
long but the topic is far from being trivial).
willy
^ permalink raw reply
* Re: [PATCH v3 2/2] hwmon: add AMD Promontory 21 xHCI temperature sensor support
From: Guenter Roeck @ 2026-05-07 15:53 UTC (permalink / raw)
To: Jihong Min
Cc: Greg Kroah-Hartman, Mathias Nyman, Jonathan Corbet, Shuah Khan,
Mario Limonciello, Basavaraj Natikar, linux-usb, linux-hwmon,
linux-doc, linux-pci, linux-kernel
In-Reply-To: <0c35058bb088213397b42fca8d51e9ad0bba5169.1778123510.git.hurryman2212@gmail.com>
On Thu, May 07, 2026 at 12:31:59PM +0900, Jihong Min wrote:
> PROM21 xHCI controllers expose an 8-bit temperature value through a
> vendor-specific index/data register pair in the xHCI PCI MMIO BAR
> region. Add an auxiliary hwmon driver for PROM21 controllers with PCI
> ID 1022:43fd.
>
> PROM21 is an AMD chipset IP used in single-chip or daisy-chained
> configurations to build AMD 6xx/8xx series chipsets.
>
> The vendor index register is at byte offset 0x3000 from the xHCI MMIO
> BAR base and the vendor data register is at byte offset 0x3008. The
> driver writes register selector 0x0001e520 to the index register, reads
> the raw temperature value from the low 8 bits of the data register, and
> restores the previous index before returning. Expose temp1_input and an
> xHCI label through hwmon.
>
> Register the hwmon device under the parent PCI function so userspace
> reports it as a PCI adapter, while the auxiliary driver still owns the
> hwmon lifetime and unregisters it from the auxiliary remove path.
>
> No public AMD reference is available for this value. The conversion
> formula is derived from observed temperature readings:
>
> temp[C] = raw * 0.9066 - 78.624
>
> Testing showed that the temperature register does not return a valid
> value while the xHCI PCI function is runtime suspended. By default, the
> driver does not wake the parent PCI device from hwmon reads and returns
> -EPERM while the device is suspended.
Seriously ? Why would this be a permission issue ? Make it -ENODATA.
>
> Document the supported device, register access, conversion formula,
> module parameter, sysfs attributes, and sysfs lookup method.
>
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
> ---
> Documentation/hwmon/index.rst | 1 +
> Documentation/hwmon/prom21-hwmon.rst | 86 ++++++++
> drivers/hwmon/Kconfig | 11 +
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/prom21-hwmon.c | 293 +++++++++++++++++++++++++++
> 5 files changed, 392 insertions(+)
> create mode 100644 Documentation/hwmon/prom21-hwmon.rst
> create mode 100644 drivers/hwmon/prom21-hwmon.c
>
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index 8b655e5d6b68..41072977f0ef 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -216,6 +216,7 @@ Hardware Monitoring Kernel Drivers
> pmbus
> powerz
> powr1220
> + prom21-hwmon
> pt5161l
> pxe1610
> pwm-fan
> diff --git a/Documentation/hwmon/prom21-hwmon.rst b/Documentation/hwmon/prom21-hwmon.rst
> new file mode 100644
> index 000000000000..0ba763e68ae9
> --- /dev/null
> +++ b/Documentation/hwmon/prom21-hwmon.rst
> @@ -0,0 +1,86 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Kernel driver prom21-hwmon
> +==========================
> +
> +Supported chips:
> +
> + * AMD Promontory 21 (PROM21) xHCI
> +
> + Prefix: 'prom21_hwmon'
The "hwmon" in this name is redundant. Yes, I know, others like it too,
but it is still redundant. I won't comment on it further, though.
> +
> + PCI ID: 1022:43fd
> +
> +Author:
> +
> + - Jihong Min <hurryman2212@gmail.com>
> +
> +Description
> +-----------
> +
> +This driver exposes the temperature sensor in AMD PROM21 xHCI controllers.
> +
> +The driver binds to an auxiliary device created by the xHCI PCI driver for
> +supported controllers. The sensor value is accessed through a vendor-specific
> +index/data register pair in the controller's PCI MMIO BAR.
> +
> +PROM21 is an AMD chipset IP used in single-chip or daisy-chained configurations
> +to build AMD 6xx/8xx series chipsets. Since the xHCI controllers are
> +integrated in PROM21, this temperature can also be used as a monitor for a
> +temperature close to the AMD chipset temperature.
> +
> +Register access
> +---------------
> +
> +The temperature value is read through a vendor-specific index/data register
> +pair in the xHCI PCI MMIO BAR. The driver uses the following byte offsets from
> +the MMIO BAR base:
> +
> +======================= =====================================================
> +0x3000 Vendor index register
> +0x3008 Vendor data register
> +======================= =====================================================
> +
> +The driver saves the current vendor index register value, writes the
> +temperature selector ``0x0001e520`` to the vendor index register, reads the
> +vendor data register, and restores the previous vendor index value before
> +returning. The raw temperature value is the low 8 bits of the vendor data
> +register value.
> +
> +No public AMD reference is available for the raw value. The temperature
> +conversion formula is derived from observed PROM21 xHCI temperature readings:
> +
> + temp[C] = raw * 0.9066 - 78.624
> +
> +Module parameters
> +-----------------
> +
> +pm: bool
> + Allow runtime PM state changes for device memory access. This is disabled
> + by default. If disabled, the driver does not wake the xHCI PCI device from
> + a temperature read. It reads the temperature only when the device is active.
> + A read from a suspended device returns ``-EPERM``.
> +
> +Sysfs entries
> +-------------
> +
> +======================= =====================================================
> +temp1_input Temperature in millidegrees Celsius
> +temp1_label "xHCI"
This is pointless and not the idea behind having a "label" attribute.
The driver name itself already associates the sensor with xhci.
Please drop.
> +======================= =====================================================
> +
> +The hwmon device name is ``prom21_hwmon``. The sysfs path depends on the hwmon
> +device number assigned by the kernel. Userspace can locate the device by
> +matching the ``name`` attribute:
> +
> +.. code-block:: sh
> +
> + for hwmon in /sys/class/hwmon/hwmon*; do
> + [ "$(cat "$hwmon/name")" = "prom21_hwmon" ] || continue
> + cat "$hwmon/temp1_label"
> + cat "$hwmon/temp1_input"
> + done
> +
> +``temp1_input`` reports millidegrees Celsius, so a value of ``50113`` means
> +50.113 degrees Celsius. If the raw register value is invalid, ``temp1_input``
> +returns ``-ENODATA``.
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 14e4cea48acc..06d81cc29fec 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -940,6 +940,17 @@ config SENSORS_POWERZ
> This driver can also be built as a module. If so, the module
> will be called powerz.
>
> +config SENSORS_PROM21
> + tristate "AMD Promontory 21 xHCI temperature sensor"
> + depends on USB_XHCI_PCI
> + select USB_XHCI_PCI_AUXDEV
> + help
> + If you say yes here you get support for the AMD Promontory 21
> + (PROM21) xHCI temperature sensor.
> +
> + This driver can also be built as a module. If so, the module
> + will be called prom21-hwmon.
> +
> config SENSORS_POWR1220
> tristate "Lattice POWR1220 Power Monitoring"
> depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 4788996aa137..7693ed3b3f72 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -196,6 +196,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> obj-$(CONFIG_SENSORS_POWERZ) += powerz.o
> obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> +obj-$(CONFIG_SENSORS_PROM21) += prom21-hwmon.o
> obj-$(CONFIG_SENSORS_PT5161L) += pt5161l.o
> obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
> obj-$(CONFIG_SENSORS_QNAP_MCU_HWMON) += qnap-mcu-hwmon.o
> diff --git a/drivers/hwmon/prom21-hwmon.c b/drivers/hwmon/prom21-hwmon.c
> new file mode 100644
> index 000000000000..1c137304d65d
> --- /dev/null
> +++ b/drivers/hwmon/prom21-hwmon.c
> @@ -0,0 +1,293 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * AMD PROM21 xHCI Hwmon Implementation
> + * (only temperature monitoring is supported)
> + *
> + * This can be effectively used as the alternative chipset temperature monitor.
> + *
> + * Copyright (C) 2026 Jihong Min <hurryman2212@gmail.com>
> + */
> +
> +#include <linux/auxiliary_bus.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/hwmon.h>
> +#include <linux/io.h>
> +#include <linux/math.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/pci.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/slab.h>
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +
> +#define PROM21_INDEX 0x3000
> +#define PROM21_DATA 0x3008
> +#define PROM21_TEMP_REG 0x0001e520
> +
> +#define PROM21_HWMON_NAME "prom21_hwmon"
> +#define PROM21_TEMP_LABEL "xHCI"
> +
> +struct prom21_hwmon {
> + struct pci_dev *pdev;
> + struct device *hwmon_dev;
> + void __iomem *regs;
> + bool removing;
> + struct mutex lock; /* protects removing and the index/data registers */
It is difficult to believe that auxiliary device management is so unstable
that it needs all that complexity. This will require confirmation from
someone who knows how this is supposed to work, and a detailed explanation
in the driver explaining why it is necessary.
> +};
> +
> +static bool pm;
> +module_param(pm, bool, 0444);
> +MODULE_PARM_DESC(pm, "Allow runtime PM state changes for device memory access");
No. Either enable it or don't, but please don't add such module parameters.
The pm complexity in the driver, as written, makes it all but impossible
to determine what is going on.
> +
> +static void prom21_hwmon_invalidate(struct prom21_hwmon *hwmon)
> +{
> + mutex_lock(&hwmon->lock);
> + hwmon->removing = true;
> + mutex_unlock(&hwmon->lock);
> +}
> +
> +static int prom21_hwmon_pm_get(struct prom21_hwmon *hwmon, bool *pm_ref)
> +{
> + struct device *dev = &hwmon->pdev->dev;
> + int ret;
> +
> + *pm_ref = false;
> +
> + /*
> + * PROM21 temperature register access does not return a valid value while
> + * the parent xHCI PCI function is suspended. By default, only read when
> + * runtime PM reports the device as active, or when runtime PM is disabled
> + * and the device is not marked as suspended. If pm=Y, allow runtime PM
> + * state changes while accessing the temperature register.
> + */
> + if (pm) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret < 0)
> + return ret;
> +
> + *pm_ref = true;
> + return 0;
> + }
> +
> + ret = pm_runtime_get_if_active(dev);
> + if (ret > 0) {
> + *pm_ref = true;
> + return 0;
> + }
> +
> + if (ret == -EINVAL && !pm_runtime_status_suspended(dev))
> + return 0;
> +
> + if (!ret || pm_runtime_status_suspended(dev))
> + return -EPERM;
> +
> + return ret;
> +}
> +
> +/*
> + * This is not a pure MMIO read. The PROM21 vendor data register is selected
> + * by temporarily writing PROM21_TEMP_REG to the vendor index register. Keep
> + * the sequence short and restore the previous index before returning.
> + */
> +static int prom21_hwmon_read_temp_raw_restore_index(struct prom21_hwmon *hwmon,
> + u8 *raw)
> +{
> + struct device *dev = &hwmon->pdev->dev;
> + bool pm_ref;
> + u32 index;
> + u32 data;
> + int ret;
> +
> + /*
> + * The xHCI PCI remove path destroys the auxiliary device before HCD
> + * teardown. Keep runtime PM and MMIO inside the critical section so a
> + * sysfs read cannot use the vendor register pair after remove starts.
> + */
> + mutex_lock(&hwmon->lock);
> + if (hwmon->removing) {
> + mutex_unlock(&hwmon->lock);
> + return -ENODEV;
> + }
> +
> + ret = prom21_hwmon_pm_get(hwmon, &pm_ref);
> + if (ret) {
> + mutex_unlock(&hwmon->lock);
> + return ret;
> + }
> +
> + index = readl(hwmon->regs + PROM21_INDEX);
> + /* Select the PROM21 temperature register through the vendor index. */
> + writel(PROM21_TEMP_REG, hwmon->regs + PROM21_INDEX);
> + data = readl(hwmon->regs + PROM21_DATA);
> + /* Restore the previous vendor index register value. */
> + writel(index, hwmon->regs + PROM21_INDEX);
> + readl(hwmon->regs + PROM21_INDEX);
> +
> + if (pm_ref) {
> + /*
> + * Use autosuspend so repeated sysfs reads do not suspend the
> + * controller immediately after each successful register access.
> + */
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> + }
> + mutex_unlock(&hwmon->lock);
> +
> + *raw = data & 0xff;
> + if (!*raw || *raw == 0xff)
> + return -ENODATA;
> +
> + return 0;
> +}
> +
> +static long prom21_hwmon_raw_to_millicelsius(u8 raw)
> +{
> + /*
> + * No public AMD reference is available for this value.
> + * The scale was derived from observed PROM21 xHCI temperature readings:
> + * temp[C] = raw * 0.9066 - 78.624
> + */
> + return DIV_ROUND_CLOSEST(raw * 9066, 10) - 78624;
> +}
> +
> +static umode_t prom21_hwmon_is_visible(const void *drvdata,
> + enum hwmon_sensor_types type, u32 attr,
> + int channel)
> +{
> + if (type != hwmon_temp || channel)
> + return 0;
> +
> + switch (attr) {
> + case hwmon_temp_input:
> + case hwmon_temp_label:
> + return 0444;
> + default:
> + return 0;
> + }
> +}
> +
> +static int prom21_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct prom21_hwmon *hwmon = dev_get_drvdata(dev);
> + u8 raw;
> + int ret;
> +
> + if (type != hwmon_temp || attr != hwmon_temp_input || channel)
> + return -EOPNOTSUPP;
> +
> + ret = prom21_hwmon_read_temp_raw_restore_index(hwmon, &raw);
> + if (ret)
> + return ret;
> +
> + *val = prom21_hwmon_raw_to_millicelsius(raw);
> + return 0;
> +}
> +
> +static int prom21_hwmon_read_string(struct device *dev,
> + enum hwmon_sensor_types type, u32 attr,
> + int channel, const char **str)
> +{
> + if (type != hwmon_temp || attr != hwmon_temp_label || channel)
> + return -EOPNOTSUPP;
> +
> + *str = PROM21_TEMP_LABEL;
> + return 0;
> +}
> +
> +static const struct hwmon_ops prom21_hwmon_ops = {
> + .is_visible = prom21_hwmon_is_visible,
> + .read = prom21_hwmon_read,
> + .read_string = prom21_hwmon_read_string,
> +};
> +
> +static const struct hwmon_channel_info *const prom21_hwmon_info[] = {
> + HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
> + NULL,
> +};
> +
> +static const struct hwmon_chip_info prom21_hwmon_chip_info = {
> + .ops = &prom21_hwmon_ops,
> + .info = prom21_hwmon_info,
> +};
> +
> +static int prom21_hwmon_probe(struct auxiliary_device *auxdev,
> + const struct auxiliary_device_id *id)
> +{
> + struct device *dev = &auxdev->dev;
> + struct device *parent = dev->parent;
> + struct prom21_hwmon *hwmon;
> + struct pci_dev *pdev;
> + struct usb_hcd *hcd;
> + int ret;
> +
> + if (!parent || !dev_is_pci(parent))
> + return -ENODEV;
> +
> + pdev = to_pci_dev(parent);
> + hcd = pci_get_drvdata(pdev);
> + if (!hcd)
> + return dev_err_probe(dev, -ENODEV,
> + "xHCI HCD data unavailable\n");
> +
> + if (!hcd->regs || hcd->rsrc_len < PROM21_DATA + sizeof(u32))
> + return dev_err_probe(dev, -ENODEV, "invalid MMIO resource\n");
> +
> + hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
> + if (!hwmon)
> + return -ENOMEM;
> +
> + ret = devm_mutex_init(dev, &hwmon->lock);
> + if (ret)
> + return ret;
> +
> + hwmon->pdev = pdev;
> + hwmon->regs = hcd->regs;
> + auxiliary_set_drvdata(auxdev, hwmon);
> +
> + /*
> + * Use the PCI function as the hwmon parent so user space reports it as
> + * a PCI adapter. Lifetime is still owned by this auxiliary driver;
> + * remove() unregisters the hwmon device before xhci-pci tears down the
> + * HCD.
> + */
> + hwmon->hwmon_dev =
> + hwmon_device_register_with_info(&pdev->dev, PROM21_HWMON_NAME,
> + hwmon, &prom21_hwmon_chip_info,
> + NULL);
> + if (IS_ERR(hwmon->hwmon_dev))
> + return PTR_ERR(hwmon->hwmon_dev);
> +
> + return 0;
> +}
> +
> +static void prom21_hwmon_remove(struct auxiliary_device *auxdev)
> +{
> + struct prom21_hwmon *hwmon = auxiliary_get_drvdata(auxdev);
> +
> + if (hwmon) {
> + prom21_hwmon_invalidate(hwmon);
> + hwmon_device_unregister(hwmon->hwmon_dev);
> + }
> +}
> +
> +static const struct auxiliary_device_id prom21_hwmon_id_table[] = {
> + { .name = "xhci_pci." PROM21_HWMON_NAME },
> + {}
> +};
> +MODULE_DEVICE_TABLE(auxiliary, prom21_hwmon_id_table);
> +
> +static struct auxiliary_driver prom21_hwmon_driver = {
> + .name = "prom21-hwmon",
> + .probe = prom21_hwmon_probe,
> + .remove = prom21_hwmon_remove,
> + .id_table = prom21_hwmon_id_table,
> +};
> +module_auxiliary_driver(prom21_hwmon_driver);
> +
> +MODULE_AUTHOR("Jihong Min <hurryman2212@gmail.com>");
> +MODULE_DESCRIPTION("AMD PROM21 xHCI hwmon driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH v11 07/11] iio: frequency: adf41513: driver implementation
From: Jonathan Cameron @ 2026-05-07 15:56 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
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: <5rzmlzst6m2ewcheblimqbv5c64umfhb4mlx34ak65sxpotqgy@jzzmw6cb2vyc>
> > +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?
Sadly I think this is correct. Nothing stops suspend racing with an ongoing sysfs access.
>
> ...
>
> > +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 we do have a documented time it would be better to sleep just to be sure.
>
> > + 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.
>
^ permalink raw reply
* Re: [PATCH v11 05/11] iio: core: add decimal value formatting into 64-bit value
From: Jonathan Cameron @ 2026-05-07 16:01 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
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-5-2b7e99cfe8f2@analog.com>
On Wed, 06 May 2026 15:08:49 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Create new format types for iio values (IIO_VAL_DECIMAL64_*), which
> defines the representation of fixed decimal point values into a single
> 64-bit number. This new format increases the range of represented values,
> allowing for integer parts greater than 2^32, as bits are not "wasted"
> in the fractional part, which can be seen in IIO_VAL_INT_PLUS_MICRO and
> IIO_VAL_INT_PLUS_NANO. Helpers are created to compose and decompose 64-bit
> decimals into integer values used in IIO formatting interfaces, which
> creates consistency and avoid error-prone manual assignments when using
> wordpart macros. When doing the parsing, kstrtodec64() is used with the
> scale defined by the specific decimal format type.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Looks good to me now. I'll probably take one final look before applying
but for now looks like you've still got some Sashiko reported stuff to
sort and I don't have any other feedback.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Greg KH @ 2026-05-07 16:23 UTC (permalink / raw)
To: Sasha Levin; +Cc: corbet, akpm, skhan, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <afyWXIsqqgMpxVIb@laps>
On Thu, May 07, 2026 at 09:40:44AM -0400, Sasha Levin wrote:
> On Thu, May 07, 2026 at 12:47:43PM +0200, Greg KH wrote:
> > > + atomic_long_t retval;
> >
> > Why is this an atomic value? Shouldn't it be whatever the userspace
> > return type is?
>
> The return register is `long` on every arch.
>
> While testing this, I added the ability to modify the return value after we
> create a killswitch, and figured that it could be a useful thing to keep in the
> code.
>
> But then I got worried about a race between a user changing the return value of
> the killswitch and some program trying to execute the code, and getting some
> combination of the old and the new return value.
>
> Is that a real concern? I'm not sure - but making this atomic was cheap enough.
I don't think that a combination should matter all that much here, but
at least it makes sense now. You might want to document that somewhere
here.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 0/3] iio: dac: Add support for AD5529R DAC
From: Janani Sunil @ 2026-05-07 16:28 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
Janani Sunil
This patch series adds support for Analog Devices AD5529R, a 16 channel
16 and 12 bit voltage Digital-to-Analog Converter (DAC) with integrated
precision reference. The AD5529R operates from both unipolar and
bipolar supplies. The device communicates via SPI interface.
**Device Overview:**
The AD5529R features 16 independent DAC channels, with 16 or 12 bit
resolution, allowing independently programmable output ranges. The
internal 4.096V precision reference sets the accuracy of the output
voltage.
**Features Implemented:**
- Automatic detection of 12/16 bit generic with product ID read.
- Reset support via GPIO.
- Dual regmap configuration to handle 8 and 16 bit registers.
**Patch Summary:**
1. **dt-bindings**: Binding documentation with channel configuration.
2. **driver**: Implement IIO DAC Driver with regmap support.
3. **documentation**: Add driver documentation with usage examples.
**Testing:**
The driver was compiled and tested on the EVAL-AD5529R-ARDZ using a
coraZ7 with a mainline v7.0 kernel.
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
Janani Sunil (3):
dt-bindings: iio: dac: Add AD5529R
iio: dac: Add AD5529R DAC driver support
Documentation: iio: Add AD5529R Documentation
.../devicetree/bindings/iio/dac/adi,ad5529r.yaml | 99 ++++
Documentation/iio/ad5529r.rst | 214 ++++++++
Documentation/iio/index.rst | 1 +
MAINTAINERS | 9 +
drivers/iio/dac/Kconfig | 17 +
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ad5529r.c | 564 +++++++++++++++++++++
7 files changed, 905 insertions(+)
---
base-commit: 93df88612859e8e19dec93c69d563b4b73e9bd4b
change-id: 20260507-ad5529r-driver-866bbdd864de
Best regards,
--
Janani Sunil <janani.sunil@analog.com>
^ 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