* [PATCH 2/2] docs: iio: triggered-buffers: use new helpers in example
From: David Lechner @ 2026-05-17 17:00 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Jonathan Cameron, Nuno Sá,
Andy Shevchenko
Cc: linux-doc, linux-kernel, linux-iio, David Lechner
In-Reply-To: <20260517-iio-doc-triggered-buffer-update-helpers-v1-0-7f00d4188f6f@baylibre.com>
Update the "typical" triggered buffer example to use various new helpers
that have been added in the last year or so. This reflects current
expectations of how similar code should be written.
Also zero-initialize the buffer so we don't leak stack data. And fix a
missing semicolon while we're at it.
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
Documentation/driver-api/iio/triggered-buffers.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 23b82357eba6..23762b06fdc6 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -29,14 +29,14 @@ A typical triggered buffer setup looks like this::
irqreturn_t sensor_trigger_handler(int irq, void *p)
{
- u16 buf[8];
+ IIO_DECLARE_BUFFER_WITH_TS(u16, buf, 3) = { };
int i = 0;
/* read data for each active channel */
- for_each_set_bit(bit, active_scan_mask, masklength)
- buf[i++] = sensor_get_data(bit)
+ iio_for_each_active_channel(indio_dev, bit)
+ buf[i++] = sensor_get_data(bit);
- iio_push_to_buffers_with_timestamp(indio_dev, buf, timestamp);
+ iio_push_to_buffers_with_ts(indio_dev, buf, sizeof(buf), timestamp);
iio_trigger_notify_done(trigger);
return IRQ_HANDLED;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 01/10] liveupdate: centralize state management into struct luo_ser
From: Mike Rapoport @ 2026-05-17 17:20 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-2-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:19PM +0000, Pasha Tatashin wrote:
> Transition the LUO to ABI v2, which centralizes state management into a
> single struct luo_ser header.
>
> Previously, LUO state was spread across multiple FDT properties and
> subnodes. ABI v2 simplifies this by placing all core state, including
> the liveupdate number and physical addresses for sessions and FLB
> headers into a centralized struct luo_ser.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> include/linux/kho/abi/luo.h | 91 +++++++++++---------------------
> kernel/liveupdate/luo_core.c | 59 ++++++++++++++-------
> kernel/liveupdate/luo_flb.c | 65 ++++-------------------
> kernel/liveupdate/luo_internal.h | 8 +--
> kernel/liveupdate/luo_session.c | 57 +++-----------------
> 5 files changed, 93 insertions(+), 187 deletions(-)
This looks lovely :)
> @@ -115,27 +117,29 @@ static int __init luo_early_startup(void)
> return -EINVAL;
> }
>
> - ln_size = 0;
> - ptr = fdt_getprop(luo_global.fdt_in, 0, LUO_FDT_LIVEUPDATE_NUM,
> - &ln_size);
> - if (!ptr || ln_size != sizeof(luo_global.liveupdate_num)) {
> - pr_err("Unable to get live update number '%s' [%d]\n",
> - LUO_FDT_LIVEUPDATE_NUM, ln_size);
> + header_size = 0;
> + ptr = fdt_getprop(luo_global.fdt_in, 0, LUO_FDT_ABI_HEADER, &header_size);
> + if (!ptr || header_size != sizeof(u64)) {
> + pr_err("Unable to get ABI header '%s' [%d]\n",
> + LUO_FDT_ABI_HEADER, header_size);
>
> return -EINVAL;
> }
>
> - luo_global.liveupdate_num = get_unaligned((u64 *)ptr);
> + luo_ser_pa = get_unaligned((u64 *)ptr);
> + luo_ser = phys_to_virt(luo_ser_pa);
> +
> + luo_global.liveupdate_num = luo_ser->liveupdate_num;
> pr_info("Retrieved live update data, liveupdate number: %lld\n",
> luo_global.liveupdate_num);
>
> - err = luo_session_setup_incoming(luo_global.fdt_in);
> + err = luo_session_setup_incoming(luo_ser->sessions_pa);
> if (err)
> return err;
>
> - err = luo_flb_setup_incoming(luo_global.fdt_in);
> + luo_flb_setup_incoming(luo_ser->flbs_pa);
Sashiko asks:
Is there a leak of the preserved luo_ser memory here?
The outgoing kernel allocates the header using kho_alloc_preserve(), but
luo_early_startup() returns without calling kho_restore_free() on the
luo_ser pointer once the fields have been processed. This results in an
unreleased memory reservation on every successful live update.
This seems preexisting, and we probably don't care enough, but still...
There were more comments by sashiko, didn't check them yet.
> - return err;
> + return 0;
> }
>
> static int __init liveupdate_early_init(void)
> @@ -156,7 +160,8 @@ early_initcall(liveupdate_early_init);
> /* Called during boot to create outgoing LUO fdt tree */
> static int __init luo_fdt_setup(void)
> {
> - const u64 ln = luo_global.liveupdate_num + 1;
> + struct luo_ser *luo_ser;
> + u64 luo_ser_pa;
> void *fdt_out;
> int err;
>
> @@ -166,27 +171,45 @@ static int __init luo_fdt_setup(void)
> return PTR_ERR(fdt_out);
> }
>
> + luo_ser = kho_alloc_preserve(sizeof(*luo_ser));
> + if (IS_ERR(luo_ser)) {
> + err = PTR_ERR(luo_ser);
> + goto exit_free_fdt;
> + }
> + luo_ser_pa = virt_to_phys(luo_ser);
> +
> err = fdt_create(fdt_out, LUO_FDT_SIZE);
> err |= fdt_finish_reservemap(fdt_out);
> err |= fdt_begin_node(fdt_out, "");
> err |= fdt_property_string(fdt_out, "compatible", LUO_FDT_COMPATIBLE);
> - err |= fdt_property(fdt_out, LUO_FDT_LIVEUPDATE_NUM, &ln, sizeof(ln));
> - err |= luo_session_setup_outgoing(fdt_out);
> - err |= luo_flb_setup_outgoing(fdt_out);
> + err |= fdt_property(fdt_out, LUO_FDT_ABI_HEADER, &luo_ser_pa,
> + sizeof(luo_ser_pa));
> err |= fdt_end_node(fdt_out);
> err |= fdt_finish(fdt_out);
> if (err)
> - goto exit_free;
> + goto exit_free_luo_ser;
> +
> + err = luo_session_setup_outgoing(&luo_ser->sessions_pa);
> + if (err)
> + goto exit_free_luo_ser;
> +
> + err = luo_flb_setup_outgoing(&luo_ser->flbs_pa);
> + if (err)
> + goto exit_free_luo_ser;
> +
> + luo_ser->liveupdate_num = luo_global.liveupdate_num + 1;
>
> err = kho_add_subtree(LUO_FDT_KHO_ENTRY_NAME, fdt_out,
> fdt_totalsize(fdt_out));
> if (err)
> - goto exit_free;
> + goto exit_free_luo_ser;
And here we also seem to leak memory allocated by sesttion/flb setup.
> luo_global.fdt_out = fdt_out;
>
> return 0;
>
> -exit_free:
> +exit_free_luo_ser:
> + kho_unpreserve_free(luo_ser);
> +exit_free_fdt:
> kho_unpreserve_free(fdt_out);
> pr_err("failed to prepare LUO FDT: %d\n", err);
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 02/10] liveupdate: Extract luo_file_deserialize_one helper
From: Mike Rapoport @ 2026-05-17 17:24 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-3-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:20PM +0000, Pasha Tatashin wrote:
> Extract the logic for deserializing single entries for files into
> separate helper functions. In preparation to a linked-block
> serialization for files.
It would be nice to mention that this is a pure code movement without
indented changes.
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> kernel/liveupdate/luo_file.c | 77 ++++++++++++++++++++----------------
> 1 file changed, 44 insertions(+), 33 deletions(-)
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 03/10] liveupdate: Extract luo_session_deserialize_one helper
From: Mike Rapoport @ 2026-05-17 17:25 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-4-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:21PM +0000, Pasha Tatashin wrote:
> Extract the logic for deserializing single entries for sessions into
> separate helper functions. In preparation to a linked-block
> serialization for sessions.
It would be nice to mention that this is a pure code movement without
indented changes.
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> kernel/liveupdate/luo_session.c | 62 +++++++++++++++++++--------------
> 1 file changed, 36 insertions(+), 26 deletions(-)
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 04/10] liveupdate: add support for linked-block serialization
From: Mike Rapoport @ 2026-05-17 17:26 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-5-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:22PM +0000, Pasha Tatashin wrote:
> Introduce a linked-block serialization mechanism for LUO state.
>
> Previously, LUO used contiguous memory blocks for serializing sessions
> and files, which imposed limits on the total number of items that could
> be preserved across a live update.
>
> This commit adds the infrastructure for a more flexible, block-based
> approach where serialized data is stored in a chain of linked blocks.
> This is a preparatory step to allow an unlimited number of
> luo_sessions and luo_files to be preserved.
Shouldn't it be a part of KHO?
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> Documentation/core-api/liveupdate.rst | 8 +
> include/linux/kho/abi/luo.h | 22 ++
> kernel/liveupdate/Makefile | 1 +
> kernel/liveupdate/luo_block.c | 388 ++++++++++++++++++++++++++
> kernel/liveupdate/luo_internal.h | 57 ++++
> 5 files changed, 476 insertions(+)
> create mode 100644 kernel/liveupdate/luo_block.c
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH RFC v4 09/10] Documentation: ABI: testing: add docs for ad9910 sysfs entries
From: Rodrigo Alencar @ 2026-05-17 17:30 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260517155843.7f833658@jic23-huawei>
On 26/05/17 03:58PM, Jonathan Cameron wrote:
> On Fri, 08 May 2026 18:00:25 +0100
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
>
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
> > control Parallel Port, Digital Ramp Generator and OSK parameters.
> >
> > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> I'm fine with phase and frequency as defined, but for the scaling it made me wonder.
> For outvoltage0 channels the assumption the value is the peak voltage so if
> we know what input to be modulated by the ramp generator can we express them
> in volts (well milivolts) rather than as a scaling multiplier?
The DAC output is current-based and differential. Voltage conversion would happen
outside the device... using a resistor load or an op-amp transimpedance stage,
and I am no expert on that, but that often requires impedance matching so voltage
levels may depend on the frequency. Then, I suppose that voltage is not the right
unit to use.
The scale here controls the amplitude of the varying signal. Assuming the peak voltage
(amplitude) is constant means we have a constant envelope, but that should not mean
we can't control it or it should not mean that the hardware can have other ways to
control it. That said, scale behaves as a "gain multiplier".
>
> That seems to me like it fits better with the overall ABI.
>
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_offset
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows amplitude control through buffers, this
> > + represents the value for a base amplitude scale. The actual output
> > + amplitude scale is a result with the sum of this value.
> > +
>
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_roc
>
> Silly question perhaps but can work out how this related to millivolts/sec
> That might make a more intuitive interface than scaling multiplier per sec
> Perhaps the combination with offset makes this impossible though maybe that
> could be a expressed as a voltage offset? Afterall if the amplitude being
> scaled is 5V then 5 * (offset + scale) = 5 * offset + 5 * scale
>
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + Amplitude scale rate of change in 1/s for channels that ramp
> > + amplitude. This value may be influenced by the channel's
> > + sampling_frequency setting.
>
>
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH] docs: gpu: fix spelling errors and remove duplicate sentence
From: Randy Dunlap @ 2026-05-17 16:35 UTC (permalink / raw)
To: Elliot Tester, alexander.deucher, christian.koenig,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, corbet
Cc: skhan, amd-gfx, dri-devel, linux-doc, linux-kernel
In-Reply-To: <20260517134122.38389-1-elliotctester1@gmail.com>
On 5/17/26 6:41 AM, Elliot Tester wrote:
> Fix various spelling errors in GPU docs:
> - indicies -> indices (userq.rst)
> - umap -> unmap (userq.rst)
> - pre-empt -> preempt (drm-compute.rst)
> - buffer-leaks -> buffer leaks (drm-uapi.rst)
> - Additionally to -> In addition to (drm-uapi.rst)
> - unpriviledged -> unprivileged (drm-uapi.rst)
> - fucntions -> functions (todo.rst)
> - varios -> various (todo.rst)
> - implementions -> implementations (todo.rst)
> - complection -> completion (todo.rst)
>
> Ale remove a duplicated sentance and stray "uff." in the todo.rst, add
> missing period after drm_ioctl.c reference, and add missing newline at
> end of drm-uapi.rst. Fixing this would make reading the docs just a
> little bit easier.
>
> Signed-off-by: Elliot Tester <elliotctester1@gmail.com>
LGTM. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Documentation/gpu/amdgpu/userq.rst | 4 ++--
> Documentation/gpu/drm-compute.rst | 2 +-
> Documentation/gpu/drm-uapi.rst | 10 +++++-----
> Documentation/gpu/todo.rst | 11 +++++------
> 4 files changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/gpu/amdgpu/userq.rst b/Documentation/gpu/amdgpu/userq.rst
> index 88f54393b..94427e18a 100644
> --- a/Documentation/gpu/amdgpu/userq.rst
> +++ b/Documentation/gpu/amdgpu/userq.rst
> @@ -156,9 +156,9 @@ IOCTL Interfaces
> GPU virtual addresses used for queues and related data (rptrs, wptrs, context
> save areas, etc.) should be validated by the kernel mode driver to prevent the
> user from specifying invalid GPU virtual addresses. If the user provides
> -invalid GPU virtual addresses or doorbell indicies, the IOCTL should return an
> +invalid GPU virtual addresses or doorbell indices, the IOCTL should return an
> error message. These buffers should also be tracked in the kernel driver so
> -that if the user attempts to unmap the buffer(s) from the GPUVM, the umap call
> +that if the user attempts to unmap the buffer(s) from the GPUVM, the unmap call
> would return an error.
>
> INFO
> diff --git a/Documentation/gpu/drm-compute.rst b/Documentation/gpu/drm-compute.rst
> index f90c3e63a..35cc8d654 100644
> --- a/Documentation/gpu/drm-compute.rst
> +++ b/Documentation/gpu/drm-compute.rst
> @@ -7,7 +7,7 @@ seconds. (The time let the user wait before he reaches for the power button).
> This means that other techniques need to be used to manage those workloads,
> that cannot use fences.
>
> -Some hardware may schedule compute jobs, and have no way to pre-empt them, or
> +Some hardware may schedule compute jobs, and have no way to preempt them, or
> have their memory swapped out from them. Or they simply want their workload
> not to be preempted or swapped out at all.
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 579e87cb9..0ef498bff 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -150,10 +150,10 @@ separate render node called renderD<num>. There will be one render node
> per device. No ioctls except PRIME-related ioctls will be allowed on
> this node. Especially GEM_OPEN will be explicitly prohibited. For a
> complete list of driver-independent ioctls that can be used on render
> -nodes, see the ioctls marked DRM_RENDER_ALLOW in drm_ioctl.c Render
> -nodes are designed to avoid the buffer-leaks, which occur if clients
> +nodes, see the ioctls marked DRM_RENDER_ALLOW in drm_ioctl.c. Render
> +nodes are designed to avoid the buffer leaks, which occur if clients
> guess the flink names or mmap offsets on the legacy interface.
> -Additionally to this basic interface, drivers must mark their
> +In addition to this basic interface, drivers must mark their
> driver-dependent render-only ioctls as DRM_RENDER_ALLOW so render
> clients can use them. Driver authors must be careful not to allow any
> privileged ioctls on render nodes.
> @@ -568,7 +568,7 @@ ENOSPC:
> EPERM/EACCES:
> Returned for an operation that is valid, but needs more privileges.
> E.g. root-only or much more common, DRM master-only operations return
> - this when called by unpriviledged clients. There's no clear
> + this when called by unprivileged clients. There's no clear
> difference between EACCES and EPERM.
>
> ENODEV:
> @@ -761,4 +761,4 @@ Stable uAPI events
> From ``drivers/gpu/drm/scheduler/gpu_scheduler_trace.h``
>
> .. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> - :doc: uAPI trace events
> \ No newline at end of file
> + :doc: uAPI trace events
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index bc9f14c8a..b13cd4347 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -55,7 +55,7 @@ There are still drivers that use drm_simple_display_pipe. The task here is to
> convert them to use regular atomic helpers. Search for a driver that calls
> drm_simple_display_pipe_init() and inline all helpers from drm_simple_kms_helper.c
> into the driver, such that no simple-KMS interfaces are required. Please also
> -rename all inlined fucntions according to driver conventions.
> +rename all inlined functions according to driver conventions.
>
> Contact: Thomas Zimmermann, respective driver maintainer
>
> @@ -301,7 +301,7 @@ Various hold-ups:
> valid formats for atomic drivers.
>
> - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
> - version of the varios drm_gem_fb_create functions. Maybe called
> + version of the various drm_gem_fb_create functions. Maybe called
> drm_gem_fb_create/_with_dirty/_with_funcs as needed.
>
> Contact: Simona Vetter
> @@ -326,10 +326,9 @@ everything after it has done the write-protect/mkwrite trickery:
>
> vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
>
> -- Set the mkwrite and fsync callbacks with similar implementions to the core
> +- Set the mkwrite and fsync callbacks with similar implementations to the core
> fbdev defio stuff. These should all work on plain ptes, they don't actually
> - require a struct page. uff. These should all work on plain ptes, they don't
> - actually require a struct page.
> + require a struct page.
>
> - Track the dirty pages in a separate structure (bitfield with one bit per page
> should work) to avoid clobbering struct page.
> @@ -914,7 +913,7 @@ Querying errors from drm_syncobj
> ================================
>
> The drm_syncobj container can be used by driver independent code to signal
> -complection of submission.
> +completion of submission.
>
> One minor feature still missing is a generic DRM IOCTL to query the error
> status of binary and timeline drm_syncobj.
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 05/10] liveupdate: defer session block allocation and PA setting
From: Mike Rapoport @ 2026-05-17 17:31 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-6-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:23PM +0000, Pasha Tatashin wrote:
> Currently, luo_session_setup_outgoing() allocates the session block and
> sets its physical address in the header immediately. With upcoming
> dynamic block-based session management, this makes the first block
> different from the rest. Move the allocation to where it is first needed.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> @@ -77,15 +77,16 @@
>
> /**
> * struct luo_session_header - Header struct for managing LUO sessions.
> - * @count: The number of sessions currently tracked in the @list.
> - * @list: The head of the linked list of `struct luo_session` instances.
> - * @rwsem: A read-write semaphore providing synchronized access to the
> - * session list and other fields in this structure.
> - * @header_ser: The header data of serialization array.
> - * @ser: The serialized session data (an array of
> - * `struct luo_session_ser`).
> - * @active: Set to true when first initialized. If previous kernel did not
> - * send session data, active stays false for incoming.
> + * @count: The number of sessions currently tracked in the @list.
> + * @list: The head of the linked list of `struct luo_session` instances.
> + * @rwsem: A read-write semaphore providing synchronized access to the
> + * session list and other fields in this structure.
> + * @header_ser: The header data of serialization array.
> + * @ser: The serialized session data (an array of
> + * `struct luo_session_ser`).
> + * @sessions_pa: Points to the location of sessions_pa within struct luo_ser.
> + * @active: Set to true when first initialized. If previous kernel did not
> + * send session data, active stays false for incoming.
Hmm, why addition of a single field changed the entire block? :/
> */
> struct luo_session_header {
> long count;
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 06/10] liveupdate: Remove limit on the number of sessions
From: Mike Rapoport @ 2026-05-17 17:33 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-7-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:24PM +0000, Pasha Tatashin wrote:
> Currently, the number of LUO sessions is limited by a fixed number of
> pre-allocated pages for serialization (16 pages, allowing for ~819
> sessions).
>
> This limitation is problematic if LUO is used to support things such as
> systemd file descriptor store, and would be used not just as VM memory
> but to save other states on the machine.
>
> Remove this limit by transitioning to a linked-block approach for
> session metadata serialization. Instead of a single contiguous block,
> session metadata is now stored in a chain of 16-page blocks. Each block
> starts with a header containing the physical address of the next block
> and the number of session entries in the current block.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> include/linux/kho/abi/luo.h | 24 +-------
> kernel/liveupdate/luo_session.c | 105 +++++++++++++++-----------------
> 2 files changed, 50 insertions(+), 79 deletions(-)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 07/10] liveupdate: Remove limit on the number of files per session
From: Mike Rapoport @ 2026-05-17 17:33 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-8-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:25PM +0000, Pasha Tatashin wrote:
> To remove the fixed limit on the number of preserved files per session,
> transition the file metadata serialization from a single contiguous
> memory block to a chain of linked blocks.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> include/linux/kho/abi/luo.h | 13 +--
> kernel/liveupdate/luo_file.c | 142 +++++++++++++++----------------
> kernel/liveupdate/luo_internal.h | 5 +-
> 3 files changed, 77 insertions(+), 83 deletions(-)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 08/10] selftests/liveupdate: Test session and file limit removal
From: Mike Rapoport @ 2026-05-17 17:35 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-9-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:26PM +0000, Pasha Tatashin wrote:
> With the removal of static limits on the number of sessions and files per
> session, the orchestrator now uses dynamic allocation.
>
> Add new test cases to verify that the system can handle a large number of
> sessions and files. These tests ensure that the dynamic block allocation
> and reuse logic for session metadata and outgoing files work correctly
> beyond the previous static limits.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> .../testing/selftests/liveupdate/liveupdate.c | 75 +++++++++++++++++++
> .../selftests/liveupdate/luo_test_utils.c | 24 ++++++
> .../selftests/liveupdate/luo_test_utils.h | 2 +
> 3 files changed, 101 insertions(+)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 09/10] selftests/liveupdate: Add stress-sessions kexec test
From: Mike Rapoport @ 2026-05-17 17:37 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-10-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:27PM +0000, Pasha Tatashin wrote:
> Add a new test that creates 2000 LUO sessions before a kexec
> reboot and verifies their presence after the reboot. This ensures
> that the linked-block serialization mechanism works correctly for
> a large number of sessions.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> tools/testing/selftests/liveupdate/Makefile | 1 +
> .../liveupdate/luo_stress_sessions.c | 102 ++++++++++++++++++
> 2 files changed, 103 insertions(+)
> create mode 100644 tools/testing/selftests/liveupdate/luo_stress_sessions.c
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 10/10] selftests/liveupdate: Add stress-files kexec test
From: Mike Rapoport @ 2026-05-17 17:38 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, shuah, akpm, linux-mm, skhan, linux-doc,
linux-kernel, corbet, dmatlack, kexec, pratyush, skhawaja, graf
In-Reply-To: <20260514222628.931312-11-pasha.tatashin@soleen.com>
On Thu, May 14, 2026 at 10:26:28PM +0000, Pasha Tatashin wrote:
> Add a new luo_stress_files kexec test that verifies preserving and
> retrieving 500 files across a kexec reboot.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> tools/testing/selftests/liveupdate/Makefile | 1 +
> .../selftests/liveupdate/luo_stress_files.c | 101 ++++++++++++++++++
> 2 files changed, 102 insertions(+)
> create mode 100644 tools/testing/selftests/liveupdate/luo_stress_files.c
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 RESEND] design: fix typos in design.rst
From: SeongJae Park @ 2026-05-17 17:42 UTC (permalink / raw)
To: Sakurai Shun
Cc: SeongJae Park, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jonathan Corbet, Shuah Khan,
damon, linux-mm, linux-doc, linux-kernel
In-Reply-To: <20260517073433.3015-1-ssh1326@icloud.com>
Hello Sakurai,
Thank you for sending v2 of this patch!
As I commented [1] to the previous version, let's use 'Docs/mm/damon/design:'
as the prefix of the subject, e.g., "Docs/mm/damon/design: fix three typos"
On Sun, 17 May 2026 16:34:26 +0900 Sakurai Shun <ssh1326@icloud.com> wrote:
> L140: "unsinged" -> "unsigned"
> L371: "sampleing" -> "sampling"
> L387: "multipled" -> "multiplied"
>
> Signed-off-by: Sakurai Shun <ssh1326@icloud.com>
Assuming the subject prefix suggestion is accepted,
Reviewed-by: SeongJae Park <sj@kernel.org>
If you willing to, please send v3 with the change. But please do so after
giving time (say, one day?) for others to further comment.
Unless you object to the subject prefix change suggestion, Andrew might pick
this after making the subject line change on his own. I will also pick this
with my subject line change suggestion on my tree (damon/next), and repost it
for mm.git inclusion if it seems Andrew will not do so.
So, assuming you are ok with my subject line change suggestion, no more work
from your side is needed (unless you willing to do some). Thank you for your
contribution, Sakurai :)
> ---
Also, from the next time, please add patch changelog here [2].
[1] https://lore.kernel.org/20260516170847.146524-1-sj@kernel.org
[2] https://docs.kernel.org/process/submitting-patches.html#commentary
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH RFC v4 10/10] docs: iio: add documentation for ad9910 driver
From: Rodrigo Alencar @ 2026-05-17 17:54 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner
Cc: Rodrigo Alencar, rodrigo.alencar, linux-iio, devicetree,
linux-kernel, linux-doc, linux-hardening, Lars-Peter Clausen,
Michael Hennerich, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260517164418.37f13914@jic23-huawei>
On 26/05/17 04:44PM, Jonathan Cameron wrote:
> On Mon, 11 May 2026 10:23:35 -0500
> David Lechner <dlechner@baylibre.com> wrote:
>
> > On 5/11/26 10:02 AM, Rodrigo Alencar wrote:
> > > On 26/05/11 09:46AM, David Lechner wrote:
> > >> On 5/10/26 4:30 AM, Rodrigo Alencar wrote:
> > >>> On 26/05/09 06:42PM, David Lechner wrote:
> > >>>> On 5/8/26 12:00 PM, Rodrigo Alencar via B4 Relay wrote:
> > >>>>> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > >>>>>
> > >>>>> Add documentation for the AD9910 DDS IIO driver, which describes channels,
> > >>>>> DDS modes, attributes and ABI usage examples.
> > >>>
> > >>> ...
> > >>>
> > >>>>> + must be a power of 2.
> > >>>>> +
> > >>>>> + * - ``frequency_offset``
> > >>>>> + - Hz
> > >>>>> + - Base FTW to which scaled parallel data is added. Range :math:`[0, f_{SYSCLK}/2)`.
> > >>>>> +
> > >>>>> + * - ``phase_offset``
> > >>>>> + - rad
> > >>>>> + - Base phase for polar modulation. Lower 8 bits of POW register.
> > >>>>> + Range :math:`[0, 2\pi/256)`.
> > >>>>> +
> > >>>>> + * - ``scale_offset``
> > >>>>> + - fractional
> > >>>>> + - Base amplitude for polar modulation. Lower 6 bits of ASF register.
> > >>>>> + Range :math:`[0, 1/256)`.
> > >>>>> +
> > >>>>
> > >>>> I guess there was some discussion on these attributes. I see some of these in the
> > >>>> ad9832 driver in staging, but I'm guessing they are new ABI. It isn't clear to
> > >>>> me from the documentation here what they actually do though. I guess they are
> > >>>> just basic transformations on the input signal?
> > >>>
> > >>> Not sure how the ABI is not clear:
> > >>>
> > >>> For a channel that allows amplitude control through buffers, this
> > >>> represents the value for a base amplitude scale. The actual output
> > >>> amplitude scale is a result with the sum of this value.
> > >>>
> > >>> So yes, it is a basic transformation.
> > >>
> > >> I didn't have time to read the ABI docs yet. For scale_offset though,
> > >> how is that different from the existing offset attribute?
> > >
> > > I suppose that existing offset ABI is applied to (raw * scale), mostly for
> > > voltage channels, here the scale_offset is an offset to the scale itself.
> >
> >
> > Ah, so a very general case would be (raw * (scale + scale_offset)) + offset
> >
> > when the scale can change as a function of time and comes from an external
> > source.
> Ah. Similar question to what I was commenting on. Though maths is currently wrong
> for normal offset application as it is pre scale.
>
>
> (raw + offset) * scale is normal case.
> This is proposing (I think)
>
> (raw + offset) * (scale_offset + scale)
>
> Altvoltages are a little odd though in that we are really always kind of dealing
> in scales as it's the peak voltage that is the base unit. So they are kind
> of always about scale - hence for such a single offset would be shifting the
> mid voltage point which I guess is different form scale_offset.
As mentioned in the previous patch, I'd say we don't handle voltages in altvoltage
channels because voltage values depends on external circuitry and they vary with
frequency. Scale control is often achieved with hardware_gain in dB, but the
dB scale would not be good to achive the 32 bit control of the "raw" values.
Then, here it is implemented from 0 to 1.0, where 1.0 is the full scale.
>
> Hmm. Not sure I can draw this but i'll give it a go...
>
> So with no modulation going on and scale = 2.0, Raw 1000.
> (imagine these are sign waves)
>
> _ _ _ 2V
> / \ / \
> /___\_____/___\___ _ 0V
> \ / \
> \_/ \__ _ -2V
>
> That is sine wave -2/2V swing.
>
> Now if scale or voltage double it get twice as big.
>
> If offset + 100
>
> _ _ _ 3V
> / \ / \
> / \ / \
> _____\___/_____\___ _ 0v
> \_/ \__ _ -1V
>
> Scale offset at this point seems straight forward.. Gets more fun when it's modulated.
>
> For now apply a scale offset of -1 and scale becomes 2 - 1 == 1.
> _ _ _ 1.5V
> / \ / \
> / \ / \
> _____\___/_____\___ _ 0v
> \_/ \__ _ -0.5V
>
> So for simple case we could just role it into scale. However the fun here
> I believe is that _scale is controlled by say a ramp generator..
>
> Ok. I can't really draw this.. Lets try with xs
The ramp pattern would be the envelope of the actual varying signal.
>
> Initial scale 1, ramping to 2 over a couple 1ish cycles, offset 1. That is
> computed sale is going from 2 to 3.
> Peak 3
> ____________________________ 3V
> Peak 2.33 xx
> ______x_______________xx____ 2V
> xxx x x
> xx x x
> xx x x
> x_________x_________x_______ 0V
> x x
> x x
> x x
> ______________x__x__________ -2V
> _______________xx___________ -2.5
> Peak 2.67
>
> Key being really where this starts which is scale_offset = 1 rather than starting
> ramp from scale of 0.
yeah... that makes sense. Note that scale_offset ABI is defined generically, but
it is proposed for the parallel port mode with polar as destination. That is needed
because the amplitude is defined by the 6-bit offset (LSB) plus 8-bit input (MSB) that
would come from the buffer.
> Having drawn these I'm even less clear in my head on whether we can move from
> expressing that scale_offset and scale_roc in volts - i.e. not as scales
> or not.
Yes, I'd say volts is not the right unit to use here. We may have the options:
- raw values
- fractional or proportional values from 0 to 1.0 (the one I am using here)
- dBFS
> Given need for separate control for overall mid point of waveform and the
> starting point of scaling I think not. Ah well. The challenge will be
> how to makes sure folk looking at the ABI can understand the complex
> interactions of all these parameters. We may need some extra docs with
> better diagrams than above.
>
> Jonathan
>
>
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: add match for IIO API docs
From: Stepan Ionichev @ 2026-05-17 17:55 UTC (permalink / raw)
To: dlechner
Cc: corbet, skhan, jic23, nuno.sa, andy, linux-doc, linux-kernel,
linux-iio, Stepan Ionichev
In-Reply-To: <20260517-iio-doc-triggered-buffer-update-helpers-v1-1-7f00d4188f6f@baylibre.com>
On Sun, May 17, 2026, David Lechner wrote:
> Add a match for Documentation/driver-api/iio/ to the IIO subsystem in
> MAINTAINERS. Any changes to the IIO API documentation should be reviewed
> IIO folks.
Reviewed-by: Stepan Ionichev <sozdayvek@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/2] docs: iio: triggered-buffers: use new helpers in example
From: Stepan Ionichev @ 2026-05-17 17:56 UTC (permalink / raw)
To: dlechner
Cc: corbet, skhan, jic23, nuno.sa, andy, linux-doc, linux-kernel,
linux-iio, Stepan Ionichev
In-Reply-To: <20260517-iio-doc-triggered-buffer-update-helpers-v1-2-7f00d4188f6f@baylibre.com>
On Sun, May 17, 2026, David Lechner wrote:
> Update the "typical" triggered buffer example to use various new helpers
> that have been added in the last year or so. This reflects current
> expectations of how similar code should be written.
Reviewed-by: Stepan Ionichev <sozdayvek@gmail.com>
^ permalink raw reply
* Re: [PATCH RFC v4 03/10] iio: frequency: ad9910: initial driver implementation
From: Rodrigo Alencar @ 2026-05-17 18:07 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260517154745.5fbfcabf@jic23-huawei>
On 26/05/17 03:47PM, Jonathan Cameron wrote:
> On Fri, 08 May 2026 18:00:19 +0100
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
>
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add the core AD9910 DDS driver infrastructure with single tone mode
> > support. This includes SPI register access, profile management via GPIO
> > pins, PLL/DAC configuration from firmware properties, and single tone
> > frequency/phase/amplitude control through IIO attributes.
> >
> > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> Hi Rodrigo
>
> A few really minor things from a fresh look through.
>
> Jonathan
>
> > diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> > new file mode 100644
> > index 000000000000..c75f2ef178c2
> > --- /dev/null
> > +++ b/drivers/iio/frequency/ad9910.c
>
> > +
> > +static int ad9910_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + int *val, int *val2, long info)
> > +{
> > + struct ad9910_state *st = iio_priv(indio_dev);
> > + u64 tmp64;
> > + u32 tmp32;
> > +
> > + guard(mutex)(&st->lock);
> > +
> > + switch (info) {
> > + case IIO_CHAN_INFO_ENABLE:
> > + switch (chan->channel) {
> > + case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
> > + if (ad9910_sw_powerdown_get(st)) {
> > + *val = 0;
> > + } else {
> > + tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
> > + *val = (tmp32 == st->profile);
> > + }
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > + return IIO_VAL_INT;
> > + case IIO_CHAN_INFO_FREQUENCY:
> > + switch (chan->channel) {
> > + case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
> > + tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
> > + tmp64 = FIELD_GET(AD9910_PROFILE_ST_FTW_MSK,
> > + st->reg[AD9910_REG_PROFILE(tmp32)].val64);
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > + tmp64 *= st->data.sysclk_freq_hz;
> > + *val = tmp64 >> 32;
> > + *val2 = ((tmp64 & GENMASK_ULL(31, 0)) * MICRO) >> 32;
>
> Why in this particular case have this outside the switch / case whereas in others
> you do the full maths and set inside? I'd put it inside and not worry about slightly
> long lines.
for frequency, those calculations are going to be common for the other channels that are
going to be populated by other patches...
DRG up/down and RAM will have tmp64 populated with a FTW value.
>
> > + return IIO_VAL_INT_PLUS_MICRO;
> > + case IIO_CHAN_INFO_PHASE:
> > + switch (chan->channel) {
> > + case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
> > + tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
> > + tmp64 = FIELD_GET(AD9910_PROFILE_ST_POW_MSK,
> > + st->reg[AD9910_REG_PROFILE(tmp32)].val64);
> > + tmp32 = (tmp64 * AD9910_MAX_PHASE_MICRORAD) >> 16;
> > + *val = tmp32 / MICRO;
> > + *val2 = tmp32 % MICRO;
> > + return IIO_VAL_INT_PLUS_MICRO;
> > + default:
> > + return -EINVAL;
> > + }
> > + case IIO_CHAN_INFO_SCALE:
> > + switch (chan->channel) {
> > + case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
> > + tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
> > + tmp64 = FIELD_GET(AD9910_PROFILE_ST_ASF_MSK,
> > + st->reg[AD9910_REG_PROFILE(tmp32)].val64);
> > + *val = 0;
> > + *val2 = tmp64 * MICRO >> 14;
> > + return IIO_VAL_INT_PLUS_MICRO;
> > + default:
> > + return -EINVAL;
> > + }
> > + case IIO_CHAN_INFO_SAMP_FREQ:
> > + switch (chan->channel) {
> > + case AD9910_CHANNEL_PHY:
> > + *val = st->data.sysclk_freq_hz;
> > + return IIO_VAL_INT;
> > + default:
> > + return -EINVAL;
> > + }
> > + default:
> > + return -EINVAL;
> > + }
> > +}
>
>
>
> > +
> > +static int ad9910_setup(struct device *dev, struct ad9910_state *st,
> > + struct reset_control *dev_rst)
> > +{
> > + int ret;
> > +
> > + ret = reset_control_deassert(dev_rst);
> > + if (ret)
> > + return ret;
> No need to sleep at all after bringing device out of reset?
>
> Sashiko has reasonably been asking about this in other drivers. If there
> is no period needed or it is so quick as to be irrelevant add a comment here.
I do not see any requirement on that in the datasheet.
> > +
> > + ret = ad9910_reg32_write(st, AD9910_REG_CFR1,
> > + AD9910_CFR1_SDIO_INPUT_ONLY_MSK, false);
> > + if (ret)
> > + return ret;
> > +
> > + ret = devm_add_action_or_reset(dev, ad9910_sw_powerdown_action, st);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ad9910_reg32_write(st, AD9910_REG_CFR2,
> > + AD9910_CFR2_AMP_SCALE_SINGLE_TONE_MSK |
> > + AD9910_CFR2_SYNC_TIMING_VAL_DISABLE_MSK |
> > + AD9910_CFR2_DRG_NO_DWELL_MSK |
> > + AD9910_CFR2_DATA_ASM_HOLD_LAST_MSK |
> > + AD9910_CFR2_SYNC_CLK_EN_MSK |
> > + AD9910_CFR2_PDCLK_ENABLE_MSK, false);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ad9910_cfg_sysclk(st, false);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ad9910_set_dac_current(st, false);
> > + if (ret)
> > + return ret;
> > +
> > + return ad9910_io_update(st);
> > +}
>
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [RFC PATCH 1/5] mm/damon/core: fix nr_accesses_bp underflow in damon_moving_sum
From: SeongJae Park @ 2026-05-17 18:16 UTC (permalink / raw)
To: Ravi Jonnalagadda
Cc: SeongJae Park, damon, linux-mm, linux-kernel, linux-doc, akpm,
corbet, bijan311, ajayjoshi, honggyu.kim, yunjeong.mun
In-Reply-To: <20260516210357.2247-2-ravis.opensrc@gmail.com>
Hello Ravi,
On Sat, 16 May 2026 14:03:53 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> Guard against unsigned integer underflow when nomvsum/len_window
> exceeds mvsum.
How could this happen? mvsum is assumed to be same to nomvsum at the beginning
of the window. Hence, even if there is only zero new_value, at the end of the
window, mvsum should be exactly zero. Of course there could be a bug that
breaks the assumption.
> When that subtraction wraps, the moving sum returns a
> near-ULONG_MAX value and corrupts nr_accesses_bp.
>
> If subtrahend > mvsum, return new_value: this clamps the moving-sum
> estimate to the current observation rather than wrapping.
I guess you saw this issue in real, and this change should fix the issue. But
I think we should know why and how mvsum < nomvum / len_window can unexpectedly
happen, and fix that.
Could you share more details about when and how the situation happens?
Thanks,
SJ
[...]
^ permalink raw reply
* [PATCH] Docs/{ABI,admin-guide}/damon: fix various typoes
From: Zenghui Yu @ 2026-05-17 18:26 UTC (permalink / raw)
To: damon, linux-mm, linux-kernel, linux-doc
Cc: sj, akpm, david, ljs, liam, vbabka, rppt, surenb, mhocko, corbet,
skhan, Zenghui Yu
``damon_target_idx`` was wrongly written as ``target_idx`` in the docs. Fix
it all over the place, as well as the wrong directory count, grammar, etc.
Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
---
.../ABI/testing/sysfs-kernel-mm-damon | 2 +-
Documentation/admin-guide/mm/damon/usage.rst | 18 +++++++++---------
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon
index 2424237ebb10..40c8843a82a4 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-damon
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon
@@ -428,7 +428,7 @@ Description: If 'hugepage_size' is written to the 'type' file, writing to
or reading from this file sets or gets the maximum size of the
hugepage for the filter.
-What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/target_idx
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/damon_target_idx
Date: Dec 2022
Contact: SeongJae Park <sj@kernel.org>
Description: If 'target' is written to the 'type' file, writing to or
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 534e1199cf09..cae622b959db 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -89,7 +89,7 @@ comma (",").
│ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path
│ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks>`/metric,interval_us,high,mid,low
│ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters
- │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max
+ │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,damon_target_idx,min,max
│ │ │ │ │ │ │ :ref:`dests <damon_sysfs_dests>`/nr_dests
│ │ │ │ │ │ │ │ 0/id,weight
│ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds,nr_snapshots,max_nr_snapshots
@@ -337,7 +337,7 @@ to ``N-1``. Each directory represents each DAMON-based operation scheme.
schemes/<N>/
------------
-In each scheme directory, eight directories (``access_pattern``, ``quotas``,
+In each scheme directory, nine directories (``access_pattern``, ``quotas``,
``watermarks``, ``core_filters``, ``ops_filters``, ``filters``, ``dests``,
``stats``, and ``tried_regions``) and three files (``action``, ``target_nid``
and ``apply_interval``) exist.
@@ -447,7 +447,7 @@ given DAMON-based operation scheme.
Under the watermarks directory, five files (``metric``, ``interval_us``,
``high``, ``mid``, and ``low``) for setting the metric, the time interval
between check of the metric, and the three watermarks exist. You can set and
-get the five values by writing to the files, respectively.
+get the five values by writing to and reading from the files, respectively.
Keywords and meanings of those that can be written to the ``metric`` file are
as below.
@@ -455,7 +455,7 @@ as below.
- none: Ignore the watermarks
- free_mem_rate: System's free memory rate (per thousand)
-The ``interval`` should written in microseconds unit.
+The ``interval_us`` should be written in microseconds unit.
.. _sysfs_filters:
@@ -483,9 +483,9 @@ in the numeric order.
Each filter directory contains nine files, namely ``type``, ``matching``,
``allow``, ``memcg_path``, ``addr_start``, ``addr_end``, ``min``, ``max``
-and ``target_idx``. To ``type`` file, you can write the type of the filter.
-Refer to :ref:`the design doc <damon_design_damos_filters>` for available type
-names, their meaning and on what layer those are handled.
+and ``damon_target_idx``. To ``type`` file, you can write the type of the
+filter. Refer to :ref:`the design doc <damon_design_damos_filters>` for
+available type names, their meaning and on what layer those are handled.
For ``memcg`` type, you can specify the memory cgroup of the interest by
writing the path of the memory cgroup from the cgroups mount point to
@@ -495,7 +495,7 @@ files, respectively. For ``hugepage_size`` type, you can specify the minimum
and maximum size of the range (closed interval) to ``min`` and ``max`` files,
respectively. For ``target`` type, you can specify the index of the target
between the list of the DAMON context's monitoring targets list to
-``target_idx`` file.
+``damon_target_idx`` file.
You can write ``Y`` or ``N`` to ``matching`` file to specify whether the filter
is for memory that matches the ``type``. You can write ``Y`` or ``N`` to
@@ -677,7 +677,7 @@ show results using tracepoint supporting tools like ``perf``. For example::
Each line of the perf script output represents each monitoring region. The
first five fields are as usual other tracepoint outputs. The sixth field
-(``target_id=X``) shows the ide of the monitoring target of the region. The
+(``target_id=X``) shows the id of the monitoring target of the region. The
seventh field (``nr_regions=X``) shows the total number of monitoring regions
for the target. The eighth field (``X-Y:``) shows the start (``X``) and end
(``Y``) addresses of the region in bytes. The ninth field (``X``) shows the
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 01/10] liveupdate: centralize state management into struct luo_ser
From: Pasha Tatashin @ 2026-05-17 18:36 UTC (permalink / raw)
To: Mike Rapoport
Cc: Pasha Tatashin, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, linux-kernel, corbet, dmatlack, kexec, pratyush,
skhawaja, graf
In-Reply-To: <agn4z5ZrFBi9AIGw@kernel.org>
On 05-17 20:20, Mike Rapoport wrote:
> On Thu, May 14, 2026 at 10:26:19PM +0000, Pasha Tatashin wrote:
> > Transition the LUO to ABI v2, which centralizes state management into a
> > single struct luo_ser header.
> >
> > Previously, LUO state was spread across multiple FDT properties and
> > subnodes. ABI v2 simplifies this by placing all core state, including
> > the liveupdate number and physical addresses for sessions and FLB
> > headers into a centralized struct luo_ser.
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > ---
> > include/linux/kho/abi/luo.h | 91 +++++++++++---------------------
> > kernel/liveupdate/luo_core.c | 59 ++++++++++++++-------
> > kernel/liveupdate/luo_flb.c | 65 ++++-------------------
> > kernel/liveupdate/luo_internal.h | 8 +--
> > kernel/liveupdate/luo_session.c | 57 +++-----------------
> > 5 files changed, 93 insertions(+), 187 deletions(-)
>
> This looks lovely :)
>
> > @@ -115,27 +117,29 @@ static int __init luo_early_startup(void)
> > return -EINVAL;
> > }
> >
> > - ln_size = 0;
> > - ptr = fdt_getprop(luo_global.fdt_in, 0, LUO_FDT_LIVEUPDATE_NUM,
> > - &ln_size);
> > - if (!ptr || ln_size != sizeof(luo_global.liveupdate_num)) {
> > - pr_err("Unable to get live update number '%s' [%d]\n",
> > - LUO_FDT_LIVEUPDATE_NUM, ln_size);
> > + header_size = 0;
> > + ptr = fdt_getprop(luo_global.fdt_in, 0, LUO_FDT_ABI_HEADER, &header_size);
> > + if (!ptr || header_size != sizeof(u64)) {
> > + pr_err("Unable to get ABI header '%s' [%d]\n",
> > + LUO_FDT_ABI_HEADER, header_size);
> >
> > return -EINVAL;
> > }
> >
> > - luo_global.liveupdate_num = get_unaligned((u64 *)ptr);
> > + luo_ser_pa = get_unaligned((u64 *)ptr);
> > + luo_ser = phys_to_virt(luo_ser_pa);
> > +
> > + luo_global.liveupdate_num = luo_ser->liveupdate_num;
> > pr_info("Retrieved live update data, liveupdate number: %lld\n",
> > luo_global.liveupdate_num);
> >
> > - err = luo_session_setup_incoming(luo_global.fdt_in);
> > + err = luo_session_setup_incoming(luo_ser->sessions_pa);
> > if (err)
> > return err;
> >
> > - err = luo_flb_setup_incoming(luo_global.fdt_in);
> > + luo_flb_setup_incoming(luo_ser->flbs_pa);
>
> Sashiko asks:
>
> Is there a leak of the preserved luo_ser memory here?
>
> The outgoing kernel allocates the header using kho_alloc_preserve(), but
> luo_early_startup() returns without calling kho_restore_free() on the
> luo_ser pointer once the fields have been processed. This results in an
> unreleased memory reservation on every successful live update.
>
> This seems preexisting, and we probably don't care enough, but still...
The freeing happen during finish, that was by design.
>
> There were more comments by sashiko, didn't check them yet.
The other comment is stupid: yes, changing ABI prevents updating from
older kernel.
>
> > - return err;
> > + return 0;
> > }
> >
> > static int __init liveupdate_early_init(void)
> > @@ -156,7 +160,8 @@ early_initcall(liveupdate_early_init);
> > /* Called during boot to create outgoing LUO fdt tree */
> > static int __init luo_fdt_setup(void)
> > {
> > - const u64 ln = luo_global.liveupdate_num + 1;
> > + struct luo_ser *luo_ser;
> > + u64 luo_ser_pa;
> > void *fdt_out;
> > int err;
> >
> > @@ -166,27 +171,45 @@ static int __init luo_fdt_setup(void)
> > return PTR_ERR(fdt_out);
> > }
> >
> > + luo_ser = kho_alloc_preserve(sizeof(*luo_ser));
> > + if (IS_ERR(luo_ser)) {
> > + err = PTR_ERR(luo_ser);
> > + goto exit_free_fdt;
> > + }
> > + luo_ser_pa = virt_to_phys(luo_ser);
> > +
> > err = fdt_create(fdt_out, LUO_FDT_SIZE);
> > err |= fdt_finish_reservemap(fdt_out);
> > err |= fdt_begin_node(fdt_out, "");
> > err |= fdt_property_string(fdt_out, "compatible", LUO_FDT_COMPATIBLE);
> > - err |= fdt_property(fdt_out, LUO_FDT_LIVEUPDATE_NUM, &ln, sizeof(ln));
> > - err |= luo_session_setup_outgoing(fdt_out);
> > - err |= luo_flb_setup_outgoing(fdt_out);
> > + err |= fdt_property(fdt_out, LUO_FDT_ABI_HEADER, &luo_ser_pa,
> > + sizeof(luo_ser_pa));
> > err |= fdt_end_node(fdt_out);
> > err |= fdt_finish(fdt_out);
> > if (err)
> > - goto exit_free;
> > + goto exit_free_luo_ser;
> > +
> > + err = luo_session_setup_outgoing(&luo_ser->sessions_pa);
> > + if (err)
> > + goto exit_free_luo_ser;
> > +
> > + err = luo_flb_setup_outgoing(&luo_ser->flbs_pa);
> > + if (err)
> > + goto exit_free_luo_ser;
> > +
> > + luo_ser->liveupdate_num = luo_global.liveupdate_num + 1;
> >
> > err = kho_add_subtree(LUO_FDT_KHO_ENTRY_NAME, fdt_out,
> > fdt_totalsize(fdt_out));
> > if (err)
> > - goto exit_free;
> > + goto exit_free_luo_ser;
>
> And here we also seem to leak memory allocated by sesttion/flb setup.
>
> > luo_global.fdt_out = fdt_out;
> >
> > return 0;
> >
> > -exit_free:
> > +exit_free_luo_ser:
> > + kho_unpreserve_free(luo_ser);
> > +exit_free_fdt:
> > kho_unpreserve_free(fdt_out);
> > pr_err("failed to prepare LUO FDT: %d\n", err);
>
> --
> Sincerely yours,
> Mike.
^ permalink raw reply
* Re: [RFC PATCH 2/5] mm/damon/core: cap effective quota size to total monitored memory
From: SeongJae Park @ 2026-05-17 18:36 UTC (permalink / raw)
To: Ravi Jonnalagadda
Cc: SeongJae Park, damon, linux-mm, linux-kernel, linux-doc, akpm,
corbet, bijan311, ajayjoshi, honggyu.kim, yunjeong.mun
In-Reply-To: <20260516210357.2247-3-ravis.opensrc@gmail.com>
Hello Ravi,
On Sat, 16 May 2026 14:03:54 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> The DAMOS quota goal tuner can compute an effective size (esz) larger
> than the total monitored memory because it integrates over cumulative
> deltas without bounding by the actual workload size. Once esz exceeds
> total monitored memory, the per-tick "remaining quota" arithmetic
> stops being meaningful: any scheme can apply to the entire monitored
> space and "remaining" stays positive indefinitely.
Nice finding!
>
> Cap esz to the total size of all currently monitored regions as a
> final bound after all other quota calculations. Add
> damon_ctx_total_monitored_sz() helper that sums region sizes across
> all targets.
You could also make an arbitrary cap by setting the static size quota. That
is, if there are not only quota goal but also the size quota and/or time quota,
and the different types of quotas disagree about the real quota, DAMOS uses
smallest quota. You could read damos_set_effective_quota() code and kernel-doc
comment of 'struct damos_quota' for more details.
So you could apply the total monitoring region size cap by setting the size
quota of the total monitoring region size. Could that work for you?
Adding the total monitoring region size cap makes sense to me, and I think that
will make user experience better. But, if the size quota based cap works, that
could also be handled on user space in an easier and even a betetr way. If so,
I'd prefer the direction, to reduce kernel code complexity. What do you think?
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH v2 02/10] liveupdate: Extract luo_file_deserialize_one helper
From: Pasha Tatashin @ 2026-05-17 18:37 UTC (permalink / raw)
To: Mike Rapoport
Cc: Pasha Tatashin, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, linux-kernel, corbet, dmatlack, kexec, pratyush,
skhawaja, graf
In-Reply-To: <agn50TRvhDpGm_9v@kernel.org>
On 05-17 20:24, Mike Rapoport wrote:
> On Thu, May 14, 2026 at 10:26:20PM +0000, Pasha Tatashin wrote:
> > Extract the logic for deserializing single entries for files into
> > separate helper functions. In preparation to a linked-block
> > serialization for files.
>
> It would be nice to mention that this is a pure code movement without
> indented changes.
OK, will do that if there is another spin.
>
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > ---
> > kernel/liveupdate/luo_file.c | 77 ++++++++++++++++++++----------------
> > 1 file changed, 44 insertions(+), 33 deletions(-)
>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>
> --
> Sincerely yours,
> Mike.
^ permalink raw reply
* [PATCH v5 00/13] AD9910 Direct Digital Synthesizer
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar, sashiko-bot
This patch series adds support for the Analog Devices AD9910 DDS.
This is a follow-up of the V3/V4 discussion. For V1, we reached into
this channel composition agreement where physical channels may have
sub-channels. That adds the flexibility necessary for this design.
During V2, some feedback indicated that the ABI is too device-specific,
so DRG/RAM destination and operating modes are configured through
alternate paths and profile channels are created. In V3, there was
further discussion on the ABI and on mode priority debug.
The AD9910 DDS core can be driven through several independent mechanisms:
single tone profiles, a digital ramp generator, an internal RAM playback
engine, a parallel data port, and output shift keying. Each of these
represents a distinct signal path into the DDS accumulator, so the driver
models them as separate IIO output channels (all IIO_ALTVOLTAGE type).
This per-channel separation allows userspace to configure each mode
independently through its own set of sysfs attributes, and to
enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on
the hardware's own mode selection architecture.
The AD9910 register map is not suited for the regmap framework: register
widths vary across the map (16, 32, and 64 bits). The driver instead
implements direct SPI access helpers with a software register cache, using
type-specific read/write/update functions (ad9910_reg{16,32,64}_{read,
write,update}) that handle endianness conversion and cache coherency.
Registers are cached for several reasons. The control/function registers
(CFR1, CFR2) are frequently queried to determine the current operating
mode (e.g., checking RAM_ENABLE before every profile register access),
and caching avoids repeated SPI read transactions for what are
essentially state checks. The cache also enables efficient
read-modify-write updates on multi-byte registers: the update functions
merge new field values with the cached register content without issuing
a SPI read, and skip the write entirely when the value is unchanged.
Finally, the profile registers serve dual purposes depending on whether
RAM mode is active -- they hold single tone parameters (FTW, POW, ASF)
in normal operation but are repurposed for RAM playback configuration
(start/end address, step rate, operating mode) when RAM is enabled. A
shadow register array (reg_profile[]) preserves the inactive mode's
settings across transitions, so no state is lost when switching between
single tone and RAM operation.
RAM data is loaded through firmware upload infrastructure. Userspace
writes the waveform data as a raw binary buffer (up to 4096 bytes for
the full 1024x32-bit RAM), and the driver reverses the byte array and
transfers it to the device in a single SPI transaction. Per-profile
start/end addresses and playback parameters (operating mode, step rate,
no-dwell control) are also configured through firmware update, using
metadata in the header.
Streaming data to the DDS core through the parallel data port at the
PD_CLK rate is not covered by this series. That functionality would
be added in a separate patch series, building on top of the IIO backend
infrastructure to provide a proper buffered data path.
Kind regards,
Rodrigo Alencar
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
Changes in v5:
- Drop RFC tag to the patch series.
- Address sashiko's comments.
- Add parent-child relationship between iio channels.
- List vs Table changes in documentation.
- Add crc and version check to RAM mode firmware update.
- Link to v4: https://lore.kernel.org/r/20260508-ad9910-iio-driver-v4-0-d26bfd20ee3d@analog.com
Changes in v4:
- Digital Ramp step exposed as a rate of change.
- Dwell modes of Digital Ramp are controlled with dwell_en attribute.
- Disable of active profile behaves as a software powerdown.
- Expose debugfs attributes to show mode priority.
- Add 64-bit debugfs reg access support into iio core.
- Link to v3: https://lore.kernel.org/r/20260417-ad9910-iio-driver-v3-0-29b93712a228@analog.com
Changes in v3:
- RAM custom configs (address range, destination, modes) loaded during firmware write.
- DRG destination defined when attrs are written.
- DRG modes broken down into enable attrs for ramp up/down channels.
- Add separate profile channels, switching done through enable attr
- Link to v2: https://lore.kernel.org/r/20260318-ad9910-iio-driver-v2-0-e79f93becf11@analog.com
Changes in v2:
- Device-tree bindings changes.
- RAM loading to use firmware update interface.
- Rearrange of channels into a hierarchy.
- Link to v1: https://lore.kernel.org/r/20260220-ad9910-iio-driver-v1-0-3b264aa48a10@analog.com
---
Rodrigo Alencar (13):
iio: core: validate file offset in iio_debugfs_write_reg()
iio: core: support 64-bit register through debugfs
iio: core: add hierarchical channel relationships
Documentation: ABI: testing: add parent entry for iio channels
dt-bindings: iio: frequency: add ad9910
iio: frequency: ad9910: initial driver implementation
iio: frequency: ad9910: add basic parallel port support
iio: frequency: ad9910: add digital ramp generator support
iio: frequency: ad9910: add RAM mode support
iio: frequency: ad9910: add output shift keying support
iio: frequency: ad9910: show channel priority in debugfs
Documentation: ABI: testing: add docs for ad9910 sysfs entries
docs: iio: add documentation for ad9910 driver
Documentation/ABI/testing/sysfs-bus-iio | 13 +
.../ABI/testing/sysfs-bus-iio-frequency-ad9910 | 76 +
.../bindings/iio/frequency/adi,ad9910.yaml | 200 ++
Documentation/iio/ad9910.rst | 666 ++++++
Documentation/iio/index.rst | 1 +
MAINTAINERS | 10 +
drivers/iio/frequency/Kconfig | 21 +
drivers/iio/frequency/Makefile | 1 +
drivers/iio/frequency/ad9910.c | 2413 ++++++++++++++++++++
drivers/iio/industrialio-core.c | 73 +-
include/linux/iio/iio-opaque.h | 2 +-
include/linux/iio/iio.h | 9 +
12 files changed, 3474 insertions(+), 11 deletions(-)
---
base-commit: 1548c54e9adc32a719499216f63fba14b2fc07c3
change-id: 20260218-ad9910-iio-driver-9b3d214c251f
Best regards,
--
Rodrigo Alencar <rodrigo.alencar@analog.com>
^ permalink raw reply
* [PATCH v5 01/13] iio: core: validate file offset in iio_debugfs_write_reg()
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar, sashiko-bot
In-Reply-To: <20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com>
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Check that a file offset is zero so that simple_write_to_buffer() can be
used safely, i.e., buf array is not left with uninitialized memory at its
start. It is not a big concern as it is a debug interface, but it is still
a hardening measure. The issue was introduced when direct call to
copy_from_user() was replaced by simple_write_to_buffer().
Fixes: 6d5dd486c715 ("iio: core: make use of simple_write_to_buffer()")
Reported-by: sashiko-bot@kernel.org
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/industrialio-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index bd6f4f9f4533..e587aca79b8e 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -419,7 +419,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
char buf[80];
int ret;
- if (count >= sizeof(buf))
+ if (count >= sizeof(buf) || *ppos != 0)
return -EINVAL;
ret = simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, userbuf,
--
2.43.0
^ permalink raw reply related
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