* Re: [PATCH v13 02/12] iio: kstrtox: add local _parse_integer_limit_init() helper
From: Jonathan Cameron @ 2026-05-17 13:53 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: <20260517-adf41513-iio-driver-v13-2-bb6e134a360f@analog.com>
On Sun, 17 May 2026 10:13:57 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add parsing helper that accepts an initial value for the accumulated
> result when parsing an 64-bit integer. It reuses current implementation
> for _parse_integer_limit(), which now consumes the new function with
> init = 0. The diff algorithm would have the documentation header and
> prototype of _parse_integer_limit() moved around so it is adjusted
> according to guidelines.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Sashiko makes a good point on this. It is not currently IIO specific
so the patch title should make that clear.
kstrox: add local_parse_integer_limit_init() helper.
> ---
> lib/kstrtox.c | 39 ++++++++++++++++++++++++++-------------
> 1 file changed, 26 insertions(+), 13 deletions(-)
>
> diff --git a/lib/kstrtox.c b/lib/kstrtox.c
> index 97be2a39f537..0705461f51c0 100644
> --- a/lib/kstrtox.c
> +++ b/lib/kstrtox.c
> @@ -39,23 +39,15 @@ const char *_parse_integer_fixup_radix(const char *s, unsigned int *base)
> return s;
> }
>
> -/*
> - * Convert non-negative integer string representation in explicitly given radix
> - * to an integer. A maximum of max_chars characters will be converted.
> - *
> - * Return number of characters consumed maybe or-ed with overflow bit.
> - * If overflow occurs, result integer (incorrect) is still returned.
> - *
> - * Don't you dare use this function.
> - */
> -noinline
> -unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *p,
> - size_t max_chars)
> +static unsigned int _parse_integer_limit_init(const char *s, unsigned int base,
> + unsigned long long init,
> + unsigned long long *p,
> + size_t max_chars)
> {
> unsigned long long res;
> unsigned int rv;
>
> - res = 0;
> + res = init;
> rv = 0;
> while (max_chars--) {
> unsigned int c = *s;
> @@ -87,6 +79,27 @@ unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned lon
> return rv;
> }
>
> +/**
> + * _parse_integer_limit() - Convert integer string representation to an integer
> + * limiting the number of characters parsed.
> + * @s: The start of the string.
> + * @base: The number base to use.
> + * @p: Where to write the result of the conversion.
> + * @max_chars: Maximum amount of characters to consume.
> + *
> + * Convert non-negative integer string representation in explicitly given radix
> + * to an integer. A maximum of max_chars characters will be converted.
> + *
> + * Return: Number of characters consumed maybe or-ed with overflow bit.
> + * If overflow occurs, result integer (incorrect) is still returned.
> + */
> +noinline
> +unsigned int _parse_integer_limit(const char *s, unsigned int base,
> + unsigned long long *p, size_t max_chars)
> +{
> + return _parse_integer_limit_init(s, base, 0, p, max_chars);
> +}
> +
> noinline
> unsigned int _parse_integer(const char *s, unsigned int base, unsigned long long *p)
> {
>
^ permalink raw reply
* Re: [PATCH v13 07/12] iio: test: iio-test-format: add test case for decimal format
From: Jonathan Cameron @ 2026-05-17 13:56 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: <20260517-adf41513-iio-driver-v13-7-bb6e134a360f@analog.com>
On Sun, 17 May 2026 10:14:02 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add iio_test_iio_format_value_decimal_64() kunit test case for decimal
> value formatting, exploring different scales types. Also, the same
> iio_val_s64_array_populate() macro used to populate local array is used in
> iio_test_iio_format_value_integer_64().
Sashiko calls out that this needs an update. Doesn't seem to use iio_val_s64_array_populate()
No other comment. Context left so anyone reading this can check for themselves
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> drivers/iio/test/iio-test-format.c | 97 +++++++++++++++++++++++++++++---------
> 1 file changed, 75 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/iio/test/iio-test-format.c b/drivers/iio/test/iio-test-format.c
> index 872dd8582003..1920dee3bfb0 100644
> --- a/drivers/iio/test/iio-test-format.c
> +++ b/drivers/iio/test/iio-test-format.c
> @@ -200,56 +200,108 @@ static void iio_test_iio_format_value_multiple(struct kunit *test)
> static void iio_test_iio_format_value_integer_64(struct kunit *test)
> {
> int values[2];
> - s64 value;
> char *buf;
> int ret;
>
> buf = kunit_kmalloc(test, PAGE_SIZE, GFP_KERNEL);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
>
> - value = 24;
> - values[0] = lower_32_bits(value);
> - values[1] = upper_32_bits(value);
> + iio_val_s64_to_s32s(24, values);
> ret = iio_format_value(buf, IIO_VAL_INT_64, ARRAY_SIZE(values), values);
> IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "24\n");
>
> - value = -24;
> - values[0] = lower_32_bits(value);
> - values[1] = upper_32_bits(value);
> + iio_val_s64_to_s32s(-24, values);
> ret = iio_format_value(buf, IIO_VAL_INT_64, ARRAY_SIZE(values), values);
> IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "-24\n");
>
> - value = 0;
> - values[0] = lower_32_bits(value);
> - values[1] = upper_32_bits(value);
> + iio_val_s64_to_s32s(0, values);
> ret = iio_format_value(buf, IIO_VAL_INT_64, ARRAY_SIZE(values), values);
> IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "0\n");
>
> - value = UINT_MAX;
> - values[0] = lower_32_bits(value);
> - values[1] = upper_32_bits(value);
> + iio_val_s64_to_s32s(UINT_MAX, values);
> ret = iio_format_value(buf, IIO_VAL_INT_64, ARRAY_SIZE(values), values);
> IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "4294967295\n");
>
> - value = -((s64)UINT_MAX);
> - values[0] = lower_32_bits(value);
> - values[1] = upper_32_bits(value);
> + iio_val_s64_to_s32s(-((s64)UINT_MAX), values);
> ret = iio_format_value(buf, IIO_VAL_INT_64, ARRAY_SIZE(values), values);
> IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "-4294967295\n");
>
> - value = LLONG_MAX;
> - values[0] = lower_32_bits(value);
> - values[1] = upper_32_bits(value);
> + iio_val_s64_to_s32s(LLONG_MAX, values);
> ret = iio_format_value(buf, IIO_VAL_INT_64, ARRAY_SIZE(values), values);
> IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "9223372036854775807\n");
>
> - value = LLONG_MIN;
> - values[0] = lower_32_bits(value);
> - values[1] = upper_32_bits(value);
> + iio_val_s64_to_s32s(LLONG_MIN, values);
> ret = iio_format_value(buf, IIO_VAL_INT_64, ARRAY_SIZE(values), values);
> IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "-9223372036854775808\n");
> }
>
> +static void iio_test_iio_format_value_decimal_64(struct kunit *test)
> +{
> + int values[2];
> + char *buf;
> + int ret;
> +
> + buf = kunit_kmalloc(test, PAGE_SIZE, GFP_KERNEL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
> +
> + /* DECIMAL64_MILLI: positive >= 1, value 1.234 */
> + iio_val_s64_to_s32s(1234, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MILLI, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "1.234\n");
> +
> + /* DECIMAL64_MICRO: positive >= 1, value 3.141592 */
> + iio_val_s64_to_s32s(3141592, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MICRO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "3.141592\n");
> +
> + /* DECIMAL64_MILLI: positive < 1, value 0.042 */
> + iio_val_s64_to_s32s(42, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MILLI, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "0.042\n");
> +
> + /* DECIMAL64_MILLI: negative <= -1, value -1.234 */
> + iio_val_s64_to_s32s(-1234, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MILLI, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "-1.234\n");
> +
> + /* DECIMAL64_MILLI: negative > -1, value -0.123 */
> + iio_val_s64_to_s32s(-123, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MILLI, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "-0.123\n");
> +
> + /* DECIMAL64_MILLI: zero */
> + iio_val_s64_to_s32s(0, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MILLI, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "0.000\n");
> +
> + /* DECIMAL64_NANO: value 1.000000001 */
> + iio_val_s64_to_s32s(1000000001, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_NANO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "1.000000001\n");
> +
> + /* DECIMAL64_MICRO: large value using upper 32 bits */
> + iio_val_s64_to_s32s(5000000000000042LL, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MICRO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "5000000000.000042\n");
> +
> + /* limits */
> + iio_val_s64_to_s32s(LLONG_MAX, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_PICO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "9223372.036854775807\n");
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_NANO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "9223372036.854775807\n");
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MICRO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "9223372036854.775807\n");
> +
> + iio_val_s64_to_s32s(LLONG_MIN, values);
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_PICO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "-9223372.036854775808\n");
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_NANO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "-9223372036.854775808\n");
> + ret = iio_format_value(buf, IIO_VAL_DECIMAL64_MICRO, ARRAY_SIZE(values), values);
> + IIO_TEST_FORMAT_EXPECT_EQ(test, buf, ret, "-9223372036854.775808\n");
> +}
> +
> static struct kunit_case iio_format_test_cases[] = {
> KUNIT_CASE(iio_test_iio_format_value_integer),
> KUNIT_CASE(iio_test_iio_format_value_fixedpoint),
> @@ -257,6 +309,7 @@ static struct kunit_case iio_format_test_cases[] = {
> KUNIT_CASE(iio_test_iio_format_value_fractional_log2),
> KUNIT_CASE(iio_test_iio_format_value_multiple),
> KUNIT_CASE(iio_test_iio_format_value_integer_64),
> + KUNIT_CASE(iio_test_iio_format_value_decimal_64),
> { }
> };
>
>
^ permalink raw reply
* Re: [PATCH v13 08/12] iio: frequency: adf41513: driver implementation
From: Jonathan Cameron @ 2026-05-17 14:05 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: <20260517-adf41513-iio-driver-v13-8-bb6e134a360f@analog.com>
On Sun, 17 May 2026 10:14:03 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> The driver is based on existing PLL drivers in the IIO subsystem and
> implements the following key features:
>
> - Integer-N and fractional-N (fixed/variable modulus) synthesis modes;
> - High-resolution frequency calculations using microhertz (µHz) precision
> to handle sub-Hz resolution across multi-GHz frequency ranges;
> - IIO debugfs interface for direct register access;
> - FW property parsing from devicetree including charge pump settings and
> reference path configuration;
> - Power management support with suspend/resume callbacks;
> - Lock detect GPIO monitoring.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Hi Rodrigo
Took another brief look. Seeing as you'll be doing a v14:
- check the headers don't need updates as I spotted one I think should be there.
- the named initializer for struct spi_device_id thing is just to preempt some
future cleanup.
> diff --git a/drivers/iio/frequency/Makefile b/drivers/iio/frequency/Makefile
> index 70d0e0b70e80..53b4d01414d8 100644
> --- a/drivers/iio/frequency/Makefile
> +++ b/drivers/iio/frequency/Makefile
> @@ -5,6 +5,7 @@
>
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_AD9523) += ad9523.o
> +obj-$(CONFIG_ADF41513) += adf41513.o
> obj-$(CONFIG_ADF4350) += adf4350.o
> obj-$(CONFIG_ADF4371) += adf4371.o
> obj-$(CONFIG_ADF4377) += adf4377.o
> diff --git a/drivers/iio/frequency/adf41513.c b/drivers/iio/frequency/adf41513.c
> new file mode 100644
> index 000000000000..20ea7e82818f
> --- /dev/null
> +++ b/drivers/iio/frequency/adf41513.c
> @@ -0,0 +1,1106 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * ADF41513 SPI PLL Frequency Synthesizer driver
> + *
> + * Copyright 2026 Analog Devices Inc.
> + */
> +
Give this another look.
array_size.h is missing for instance
That seems to be the most common one people miss so is my smoke
test for whether includes are probably correct.
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/log2.h>
> +#include <linux/math64.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/spi/spi.h>
> +#include <linux/types.h>
> +#include <linux/units.h>
> +
> +static const struct spi_device_id adf41513_id[] = {
> + {"adf41510", (kernel_ulong_t)&adf41510_chip_info},
{ "adf41510", (kernel_ulong_t)&adf41510_chip_info },
Though better still (and this is a recent thing given some of the work Uwe
is doing) - given you are respinning please use named initializers like
you do already for of_device_id.
It might save us a patch in the future.
Thanks,
Jonathan
> + {"adf41513", (kernel_ulong_t)&adf41513_chip_info},
> + { }
> +};
> +MODULE_DEVICE_TABLE(spi, adf41513_id);
^ permalink raw reply
* Re: [PATCH v13 00/12] ADF41513/ADF41510 PLL frequency synthesizers
From: Jonathan Cameron @ 2026-05-17 14:08 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,
Krzysztof Kozlowski
In-Reply-To: <20260517-adf41513-iio-driver-v13-0-bb6e134a360f@analog.com>
On Sun, 17 May 2026 10:13:55 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> This patch series adds support for the Analog Devices ADF41513 and ADF41510
> ultralow noise PLL frequency synthesizers. These devices are designed for
> implementing local oscillators (LOs) in high-frequency applications.
> The ADF41513 covers frequencies from 1 GHz to 26.5 GHz, while the ADF41510
> operates from 1 GHz to 10 GHz.
>
> Key features supported by this driver:
> - Integer-N and fractional-N operation modes
> - High maximum PFD frequency (250 MHz integer-N, 125 MHz fractional-N)
> - 25-bit fixed modulus or 49-bit variable modulus fractional modes
> - Digital lock detect functionality
> - Phase resync capability for consistent output phase
> - Load Enable vs Reference signal syncronization
>
> The series includes:
> 1. PLL driver implementation
> 2. Device tree bindings documentation
> 3. IIO ABI documentation
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
I took a brief look and other than the few things you've called out
already and trivial formatting stuff I'd ideally like tweaked, looks
good to me. Fingers crossed for v14 once others have had a chance
to look at v13.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH RFC v4 03/10] iio: frequency: ad9910: initial driver implementation
From: Jonathan Cameron @ 2026-05-17 14:47 UTC (permalink / raw)
To: 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: <20260508-ad9910-iio-driver-v4-3-d26bfd20ee3d@analog.com>
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.
> + 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.
> +
> + 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);
> +}
^ permalink raw reply
* Re: [PATCH RFC v4 09/10] Documentation: ABI: testing: add docs for ad9910 sysfs entries
From: Jonathan Cameron @ 2026-05-17 14:58 UTC (permalink / raw)
To: 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: <20260508-ad9910-iio-driver-v4-9-d26bfd20ee3d@analog.com>
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?
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.
^ permalink raw reply
* Re: [PATCH RFC v4 05/10] iio: frequency: ad9910: add digital ramp generator support
From: Jonathan Cameron @ 2026-05-17 15:01 UTC (permalink / raw)
To: 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: <20260508-ad9910-iio-driver-v4-5-d26bfd20ee3d@analog.com>
On Fri, 08 May 2026 18:00:21 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add Digital Ramp Generator channels with destination selection (frequency,
> phase, or amplitude) based on attribute writes, dwell mode control,
> configurable upper/lower limits, step size controlled with rate of change
> config, and step rate controlled as sampling frequency.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> drivers/iio/frequency/ad9910.c | 511 ++++++++++++++++++++++++++++++++++++++++-
> static const struct iio_chan_spec_ext_info ad9910_phy_ext_info[] = {
> AD9910_EXT_INFO("powerdown", AD9910_POWERDOWN, IIO_SEPARATE),
> { }
> @@ -677,6 +939,14 @@ static const struct iio_chan_spec_ext_info ad9910_pp_ext_info[] = {
> { }
> };
>
> +static const struct iio_chan_spec_ext_info ad9910_drg_ramp_ext_info[] = {
> + AD9910_EXT_INFO("dwell_en", AD9910_DRG_DWELL_EN, IIO_SEPARATE),
> + AD9910_DRG_EXT_INFO("frequency_roc", AD9910_DRG_FREQ_ROC),
> + AD9910_DRG_EXT_INFO("phase_roc", AD9910_DRG_PHASE_ROC),
> + AD9910_DRG_EXT_INFO("scale_roc", AD9910_DRG_AMP_ROC),
See abi docs reply. This scale made me wonder if we can make this just roc with it
scaled to be in the base units for altvoltage.
> + { }
> +};
^ permalink raw reply
* Re: [PATCH RFC v4 06/10] iio: frequency: ad9910: add RAM mode support
From: Jonathan Cameron @ 2026-05-17 15:06 UTC (permalink / raw)
To: 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: <20260508-ad9910-iio-driver-v4-6-d26bfd20ee3d@analog.com>
On Fri, 08 May 2026 18:00:22 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add RAM control channel, which includes:
> - RAM data loading via firmware upload interface;
> - Per-profile configuration and DDS core parameter destination as firmware
> metadata;
> - Profile switching relying on profile channels;
> - Sampling frequency control of the active profile;
> - ram-enable-aware read/write paths that redirect single tone
> frequency/phase/amplitude access through reg_profile cache when RAM is
> active;
>
> When RAM is enabled, the DDS profile parameters (frequency, phase,
> amplitude) for the single tone mode are sourced from a shadow register
> cache (reg_profile[]) since the profile registers are repurposed for RAM
> control.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Minor stuff inline.
> +
> +static enum fw_upload_err ad9910_ram_fwu_write(struct fw_upload *fw_upload,
> + const u8 *data, u32 offset,
> + u32 size, u32 *written)
> +{
> + const struct ad9910_ram_fw *fw_data = (const struct ad9910_ram_fw *)data;
> + struct ad9910_state *st = fw_upload->dd_handle;
> + int ret, ret2, idx, wcount;
> + u64 tmp64, backup;
> +
> + if (offset != 0)
> + return FW_UPLOAD_ERR_INVALID_SIZE;
> +
> + guard(mutex)(&st->lock);
> +
> + if (st->ram_fwu_cancel)
> + return FW_UPLOAD_ERR_CANCELED;
> +
> + if (AD9910_RAM_ENABLED(st))
> + return FW_UPLOAD_ERR_HW_ERROR;
> +
> + /* copy ram profiles */
> + for (idx = 0; idx < AD9910_NUM_PROFILES; idx++)
> + st->reg_profile[idx] = get_unaligned_be64(&fw_data->profiles[idx]) |
> + AD9910_PROFILE_RAM_OPEN_MSK;
> +
> + /* update CFR1 */
Comment is kind of obvious. Maybe say more or drop it.
> + ret = ad9910_reg32_update(st, AD9910_REG_CFR1,
> + AD9910_CFR1_RAM_PLAYBACK_DEST_MSK |
> + AD9910_CFR1_INT_PROFILE_CTL_MSK,
> + get_unaligned_be32(&fw_data->cfr1), true);
> + if (ret)
> + return FW_UPLOAD_ERR_RW_ERROR;
> +
> + wcount = get_unaligned_be32(&fw_data->wcount);
> + if (!wcount) {
> + *written = size;
> + return FW_UPLOAD_ERR_NONE; /* nothing else to write */
> + }
> +
> + /* ensure profile is selected */
Comment is not adding value unless there is more to say.
> + ret = ad9910_profile_set(st, st->profile);
> + if (ret)
> + return FW_UPLOAD_ERR_HW_ERROR;
> +
> + /* backup profile register and update it with required address range */
> + backup = st->reg[AD9910_REG_PROFILE(st->profile)].val64;
> + tmp64 = AD9910_PROFILE_RAM_STEP_RATE_MSK |
> + FIELD_PREP(AD9910_PROFILE_RAM_START_ADDR_MSK, 0) |
> + FIELD_PREP(AD9910_PROFILE_RAM_END_ADDR_MSK, wcount - 1);
> + ret = ad9910_reg64_write(st, AD9910_REG_PROFILE(st->profile), tmp64, true);
> + if (ret)
> + return FW_UPLOAD_ERR_RW_ERROR;
> +
> + /* populate words into tx_buf[1:] */
Another comment that doesn't add value given the code is obviously doing that.
If nothing else to say remove it.
> + memcpy(&st->tx_buf[1], fw_data->words, wcount * AD9910_RAM_WORD_SIZE);
> +
> + /* write ram data and restore profile register */
> + ret = ad9910_spi_write(st, AD9910_REG_RAM,
> + wcount * AD9910_RAM_WORD_SIZE, false);
> + ret2 = ad9910_reg64_write(st, AD9910_REG_PROFILE(st->profile), backup, true);
> + if (ret || ret2)
> + return FW_UPLOAD_ERR_RW_ERROR;
> +
> + *written = size;
> + return FW_UPLOAD_ERR_NONE;
> +}
> static int ad9910_probe(struct spi_device *spi)
> {
> static const char * const supplies[] = {
> @@ -1688,7 +1991,21 @@ static int ad9910_probe(struct spi_device *spi)
> if (ret)
> return dev_err_probe(dev, ret, "device setup failed\n");
>
> - return devm_iio_device_register(dev, indio_dev);
> + ret = devm_iio_device_register(dev, indio_dev);
> + if (ret)
> + return ret;
> +
> + snprintf(st->ram_fwu_name, sizeof(st->ram_fwu_name), "%s:ram",
> + dev_name(&indio_dev->dev));
> + st->ram_fwu = firmware_upload_register(THIS_MODULE, dev, st->ram_fwu_name,
> + &ad9910_ram_fwu_ops, st);
> + if (IS_ERR(st->ram_fwu))
> + return dev_err_probe(dev, PTR_ERR(st->ram_fwu),
> + "failed to register ram upload ops\n");
> +
> + ad9910_debugfs_init(st, indio_dev);
> +
> + return devm_add_action_or_reset(dev, ad9910_ram_fwu_unregister, st->ram_fwu);
Why is this only after we've registered the device? At that point userspace
stuff is exposed, so any risk of a race with this bit not having finished yet?
Perhaps a comment would be useful.
> }
>
> static const struct spi_device_id ad9910_id[] = {
>
^ permalink raw reply
* Re: [PATCH RFC v4 07/10] iio: frequency: ad9910: add output shift keying support
From: Jonathan Cameron @ 2026-05-17 15:08 UTC (permalink / raw)
To: 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: <20260508-ad9910-iio-driver-v4-7-d26bfd20ee3d@analog.com>
On Fri, 08 May 2026 18:00:23 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add OSK channel with amplitude envelope control capabilities:
> - OSK enable/disable via IIO_CHAN_INFO_ENABLE;
> - Amplitude ramp rate control via IIO_CHAN_INFO_SAMP_FREQ;
> - Amplitude scale readback via IIO_CHAN_INFO_SCALE (ASF register);
> - Automatic OSK step size configurable througth the scale_roc extended
> attribute, which allows for selectable step sizes in nano-units:
> - 0: no step, means manual mode (NOT pin controlled)
> - 61035: 1/2^14 step, automatic mode (pin controlled)
> - 122070: 2/2^14 step, automatic mode (pin controlled)
> - 244141: 4/2^14 step, automatic mode (pin controlled)
> - 488281: 8/2^14 step, automatic mode (pin controlled)
> - 1000000000: 1.0 step, manual mode (pin controlled)
>
> The ASF register is initialized with a default amplitude ramp rate during
> device setup to ensure valid readback.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> +#define AD9910_OSK_EXT_INFO(_name, _ident) \
> + AD9910_EXT_INFO_TMPL(_name, _ident, IIO_SEPARATE, osk_attrs)
> +
> static const struct iio_chan_spec_ext_info ad9910_phy_ext_info[] = {
> AD9910_EXT_INFO("powerdown", AD9910_POWERDOWN, IIO_SEPARATE),
> { }
> @@ -1018,6 +1154,12 @@ static const struct iio_chan_spec_ext_info ad9910_drg_ramp_ext_info[] = {
> { }
> };
>
> +static const struct iio_chan_spec_ext_info ad9910_osk_ext_info[] = {
> + AD9910_OSK_EXT_INFO("scale_roc", AD9910_OSK_AUTO_ROC),
> + AD9910_OSK_EXT_INFO("scale_roc_available", AD9910_OSK_AUTO_ROC_AVAIL),
same questions about whether we can transform these to voltages and hence
not scale (though arguably the main unit of an altvoltage channel is a scale
of a 1V peak amplitude sine wave but meh).
> + { }
> +};
^ permalink raw reply
* Re: [PATCH RFC v4 10/10] docs: iio: add documentation for ad9910 driver
From: Jonathan Cameron @ 2026-05-17 15:44 UTC (permalink / raw)
To: 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: <5bce7868-feca-4c54-a14d-ad4bf4072c29@baylibre.com>
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.
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
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.
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.
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
^ permalink raw reply
* Re: [PATCH RFC v4 09/10] Documentation: ABI: testing: add docs for ad9910 sysfs entries
From: Jonathan Cameron @ 2026-05-17 15:45 UTC (permalink / raw)
To: 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 Sun, 17 May 2026 15:58:43 +0100
Jonathan Cameron <jic23@kernel.org> 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?
>
> 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
>
See thread on next patch. I think I argued myself out of this.
> > +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.
>
>
>
^ permalink raw reply
* [PATCH] docs: threat-model: add missing closing parenthesis
From: Baruch Siach @ 2026-05-17 15:41 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan
Cc: workflows, linux-doc, Willy Tarreau, Baruch Siach
Fixes: a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug")
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Documentation/process/threat-model.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
index f177b8d3c1ca..9dd8011dde82 100644
--- a/Documentation/process/threat-model.rst
+++ b/Documentation/process/threat-model.rst
@@ -176,7 +176,7 @@ regular bug:
* problems seen only under development simulators, emulators, or combinations
that do not exist on real systems at the time of reporting (issues
involving tens of millions of threads, tens of thousands of CPUs,
- unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds.
+ unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds).
* issues whose reproduction requires hardware modification or emulation,
including fake USB devices that pretend to be another one.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] docs: fix typo in uniwill-laptop.rst
From: Armin Wolf @ 2026-05-17 16:01 UTC (permalink / raw)
To: Cheesecake, corbet; +Cc: skhan, platform-driver-x86, linux-doc, linux-kernel
In-Reply-To: <20260516070650.9454-1-cheesecake2960@icloud.com>
Am 16.05.26 um 09:06 schrieb Cheesecake:
> Replace "benifit" with "benefit".
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
> Signed-off-by: Cheesecake <cheesecake2960@icloud.com>
> ---
> Documentation/wmi/devices/uniwill-laptop.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/wmi/devices/uniwill-laptop.rst b/Documentation/wmi/devices/uniwill-laptop.rst
> index e246bf293..65583b239 100644
> --- a/Documentation/wmi/devices/uniwill-laptop.rst
> +++ b/Documentation/wmi/devices/uniwill-laptop.rst
> @@ -189,7 +189,7 @@ Indexed IO
>
> Indexed IO with IO ports with a granularity of a single byte can be performed using the ``RIOP``
> (read) and ``WIOP`` (write) ACPI control methods. Those ACPI methods are unused because they
> -provide no benifit when compared to the native IO port access functions provided by the kernel.
> +provide no benefit when compared to the native IO port access functions provided by the kernel.
>
> Special thanks go to github user `pobrn` which developed the
> `qc71_laptop <https://github.com/pobrn/qc71_laptop>`_ driver on which this driver is partly based.
^ permalink raw reply
* Re: [PATCH] docs: threat-model: add missing closing parenthesis
From: Willy Tarreau @ 2026-05-17 16:04 UTC (permalink / raw)
To: Baruch Siach; +Cc: Jonathan Corbet, Shuah Khan, workflows, linux-doc
In-Reply-To: <da8ee1e8b4e99261ec11544c4e1a4f81316ae965.1779032501.git.baruch@tkos.co.il>
On Sun, May 17, 2026 at 06:41:41PM +0300, Baruch Siach wrote:
> Fixes: a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug")
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Thank you, and sorry for this mistake!
Obviously: Acked-by: Willy Tarreau <w@1wt.eu>
Willy
> ---
> Documentation/process/threat-model.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
> index f177b8d3c1ca..9dd8011dde82 100644
> --- a/Documentation/process/threat-model.rst
> +++ b/Documentation/process/threat-model.rst
> @@ -176,7 +176,7 @@ regular bug:
> * problems seen only under development simulators, emulators, or combinations
> that do not exist on real systems at the time of reporting (issues
> involving tens of millions of threads, tens of thousands of CPUs,
> - unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds.
> + unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds).
>
> * issues whose reproduction requires hardware modification or emulation,
> including fake USB devices that pretend to be another one.
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH] docs: hwmon: htu31: document debugfs serial_number
From: Guenter Roeck @ 2026-05-17 16:35 UTC (permalink / raw)
To: Chen-Shi-Hong
Cc: Jonathan Corbet, Shuah Khan, linux-hwmon, linux-doc, linux-kernel
In-Reply-To: <20260517125320.2196-1-eric039eric@gmail.com>
On Sun, May 17, 2026 at 08:52:21PM +0800, Chen-Shi-Hong wrote:
> Document the debugfs serial_number file exposed by the htu31 driver.
>
> The driver creates a debugfs entry for the sensor serial number, but
> the documentation currently only describes the sysfs interface.
>
> Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
Applied.
Thanks,
Guenter
> ---
> Documentation/hwmon/htu31.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/hwmon/htu31.rst b/Documentation/hwmon/htu31.rst
> index ccde84264643..9ab774dcf65d 100644
> --- a/Documentation/hwmon/htu31.rst
> +++ b/Documentation/hwmon/htu31.rst
> @@ -35,3 +35,10 @@ temp1_input: temperature input
> humidity1_input: humidity input
> heater_enable: heater control
> =================== =================
> +
> +debugfs-Interface
> +-----------------
> +
> +=================== =========================================
> +serial_number: unique serial number of the sensor
> +=================== =========================================
^ permalink raw reply
* [PATCH 0/2] docs: iio: update dated triggered buffer 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
Noticed this example was out of date while grepping for something else.
And when I did get_maintainer.pl on it, it didn't match the IIO
subsystem, so we get a bonus patch to fix that too.
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
David Lechner (2):
MAINTAINERS: add match for IIO API docs
docs: iio: triggered-buffers: use new helpers in example
Documentation/driver-api/iio/triggered-buffers.rst | 8 ++++----
MAINTAINERS | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
---
base-commit: 8678fb54958893818ddeccd05fea560a4e1fc759
change-id: 20260517-iio-doc-triggered-buffer-update-helpers-ef7e3895c9f4
Best regards,
--
David Lechner <dlechner@baylibre.com>
^ permalink raw reply
* [PATCH 1/2] MAINTAINERS: add match for IIO API docs
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>
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.
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0de74503df08..d14854677649 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12512,6 +12512,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
F: Documentation/ABI/testing/configfs-iio*
F: Documentation/ABI/testing/sysfs-bus-iio*
F: Documentation/devicetree/bindings/iio/
+F: Documentation/driver-api/iio/
F: Documentation/iio/
F: drivers/iio/
F: drivers/staging/iio/
--
2.43.0
^ permalink raw reply related
* [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
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