* Re: [PATCH v2 07/33] rust: allow globally `clippy::incompatible_msrv`
From: Gary Guo @ 2026-04-06 0:18 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-8-ojeda@kernel.org>
On Mon Apr 6, 2026 at 12:52 AM BST, Miguel Ojeda wrote:
> `clippy::incompatible_msrv` is not buying us much, and we discussed
> allowing it several times in the past.
>
> For instance, there was recently another patch sent to `allow` it where
> needed [1]. While that particular case would not be needed after the
> minimum version bump to 1.85.0, it is simpler to just allow it to prevent
> future instances.
>
> Thus do so, and remove the last instance of locally allowing it we have
> in the tree (except the one in the vendored `proc_macro2` crate).
>
> Note that we still keep the `msrv` config option in `clippy.toml` since
> that affects other lints as well.
>
> Link: https://lore.kernel.org/rust-for-linux/20260404212831.78971-4-jhubbard@nvidia.com/ [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Makefile | 1 +
> rust/macros/helpers.rs | 1 -
> 2 files changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH v2] docs: fix typos and duplicated words across documentation
From: Manuel Cortez @ 2026-04-06 3:03 UTC (permalink / raw)
To: linux-doc, corbet; +Cc: rdunlap, Manuel Cortez
In-Reply-To: <20260405030359.7392-1-mdjesuscv@gmail.com>
Fix the following typos and duplicated words:
- admin-guide/pm/intel-speed-select.rst: "weather" -> "whether"
- core-api/real-time/differences.rst: "the the" -> "the"
- admin-guide/bcache.rst: "to to" -> "to"
Signed-off-by: Manuel Cortez <mdjesuscv@gmail.com>
---
Changes in v2:
- Dropped the networking/switchdev.rst change as "is in in" is correct
per Randy Dunlap's review.
Documentation/admin-guide/bcache.rst | 2 +-
Documentation/admin-guide/pm/intel-speed-select.rst | 2 +-
Documentation/core-api/real-time/differences.rst | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst
index f71f349553e4..325816edbdab 100644
--- a/Documentation/admin-guide/bcache.rst
+++ b/Documentation/admin-guide/bcache.rst
@@ -618,7 +618,7 @@ cache_replacement_policy
One of either lru, fifo or random.
freelist_percent
- Size of the freelist as a percentage of nbuckets. Can be written to to
+ Size of the freelist as a percentage of nbuckets. Can be written to
increase the number of buckets kept on the freelist, which lets you
artificially reduce the size of the cache at runtime. Mostly for testing
purposes (i.e. testing how different size caches affect your hit rate).
diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst
index a2bfb971654f..dec2a25f10bc 100644
--- a/Documentation/admin-guide/pm/intel-speed-select.rst
+++ b/Documentation/admin-guide/pm/intel-speed-select.rst
@@ -287,7 +287,7 @@ level.
Check presence of other Intel(R) SST features
---------------------------------------------
-Each of the performance profiles also specifies weather there is support of
+Each of the performance profiles also specifies whether there is support of
other two Intel(R) SST features (Intel(R) Speed Select Technology - Base Frequency
(Intel(R) SST-BF) and Intel(R) Speed Select Technology - Turbo Frequency (Intel
SST-TF)).
diff --git a/Documentation/core-api/real-time/differences.rst b/Documentation/core-api/real-time/differences.rst
index 83ec9aa1c61a..a129570dab5a 100644
--- a/Documentation/core-api/real-time/differences.rst
+++ b/Documentation/core-api/real-time/differences.rst
@@ -213,7 +213,7 @@ to suspend until the callback completes, ensuring forward progress without
risking livelock.
In order to solve the problem at the API level, the sequence locks were extended
-to allow a proper handover between the the spinning reader and the maybe
+to allow a proper handover between the spinning reader and the maybe
blocked writer.
Sequence locks
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2] docs: fix typos and duplicated words across documentation
From: Randy Dunlap @ 2026-04-06 5:00 UTC (permalink / raw)
To: Manuel Cortez, linux-doc, corbet
In-Reply-To: <20260406030323.1196-1-mdjesuscv@gmail.com>
On 4/5/26 8:03 PM, Manuel Cortez wrote:
> Fix the following typos and duplicated words:
>
> - admin-guide/pm/intel-speed-select.rst: "weather" -> "whether"
> - core-api/real-time/differences.rst: "the the" -> "the"
> - admin-guide/bcache.rst: "to to" -> "to"
>
> Signed-off-by: Manuel Cortez <mdjesuscv@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Changes in v2:
> - Dropped the networking/switchdev.rst change as "is in in" is correct
> per Randy Dunlap's review.
>
> Documentation/admin-guide/bcache.rst | 2 +-
> Documentation/admin-guide/pm/intel-speed-select.rst | 2 +-
> Documentation/core-api/real-time/differences.rst | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst
> index f71f349553e4..325816edbdab 100644
> --- a/Documentation/admin-guide/bcache.rst
> +++ b/Documentation/admin-guide/bcache.rst
> @@ -618,7 +618,7 @@ cache_replacement_policy
> One of either lru, fifo or random.
>
> freelist_percent
> - Size of the freelist as a percentage of nbuckets. Can be written to to
> + Size of the freelist as a percentage of nbuckets. Can be written to
> increase the number of buckets kept on the freelist, which lets you
> artificially reduce the size of the cache at runtime. Mostly for testing
> purposes (i.e. testing how different size caches affect your hit rate).
> diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst
> index a2bfb971654f..dec2a25f10bc 100644
> --- a/Documentation/admin-guide/pm/intel-speed-select.rst
> +++ b/Documentation/admin-guide/pm/intel-speed-select.rst
> @@ -287,7 +287,7 @@ level.
> Check presence of other Intel(R) SST features
> ---------------------------------------------
>
> -Each of the performance profiles also specifies weather there is support of
> +Each of the performance profiles also specifies whether there is support of
> other two Intel(R) SST features (Intel(R) Speed Select Technology - Base Frequency
> (Intel(R) SST-BF) and Intel(R) Speed Select Technology - Turbo Frequency (Intel
> SST-TF)).
> diff --git a/Documentation/core-api/real-time/differences.rst b/Documentation/core-api/real-time/differences.rst
> index 83ec9aa1c61a..a129570dab5a 100644
> --- a/Documentation/core-api/real-time/differences.rst
> +++ b/Documentation/core-api/real-time/differences.rst
> @@ -213,7 +213,7 @@ to suspend until the callback completes, ensuring forward progress without
> risking livelock.
>
> In order to solve the problem at the API level, the sequence locks were extended
> -to allow a proper handover between the the spinning reader and the maybe
> +to allow a proper handover between the spinning reader and the maybe
> blocked writer.
>
> Sequence locks
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 00/33] rust: bump minimum Rust and `bindgen` versions
From: Miguel Ojeda @ 2026-04-06 9:03 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
On Mon, Apr 6, 2026 at 1:53 AM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
> we are going to follow Debian Stable's Rust versions as our minimum
> supported version.
>
> Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
> still uses to this day [3] (i.e. no update to Rust 1.85.1).
>
> Debian Trixie was released with `bindgen` 0.71.1, which it also still
> uses to this day [4].
>
> Debian Trixie's release happened on 2025-08-09 [5], which means that a
> fair amount of time has passed since its release for kernel developers
> to upgrade.
>
> Thus bump the minimum to the new versions, i.e.
>
> - Rust: 1.78.0 -> 1.85.0
> - bindgen: 0.65.1 -> 0.71.1
>
> There are a few main parts to the series, in this order:
>
> - A few cleanups that can be performed before the bumps.
> - The Rust bump (and its cleanups).
> - The `bindgen` bump (and its cleanups).
> - Documentation updates.
> - The `cfi_encoding` patch, added here, which needs the bump.
> - The per-version flags support and a Clippy cleanup on top.
>
> Link: https://lwn.net/Articles/1050174/ [1]
> Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]
> Link: https://packages.debian.org/trixie/rustc [3]
> Link: https://packages.debian.org/trixie/bindgen [4]
> Link: https://www.debian.org/releases/trixie/ [5]
Applied series to `rust-next` -- thanks everyone!
Let's see if we find any issue in -next.
(If someone wants to give tags today, then I am happy to pick them up)
Cheers,
Miguel
^ permalink raw reply
* RE: [PATCH v6 3/4] iio: adc: ad4691: add triggered buffer support
From: Sabau, Radu bogdan @ 2026-04-06 9:22 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <e38e5b97-e90f-4613-a15e-6c3d08cd77f7@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 4, 2026 6:12 PM
...
> > +
> > +/*
> > + * Valid ACC_DEPTH values where the effective divisor equals the count.
> > + * From Table 13: ACC_DEPTH = 2^N yields right-shift = N, divisor = 2^N.
> > + */
> > +static const int ad4691_oversampling_ratios[] = { 1, 2, 4, 8, 16, 32 };
>
> It would be nice to add oversampling in a separate commit as that is a
> separate feature.
Do you think this would be suitable after the offload commit?
>
> Oversampling also affects sampling frequency. When there isn't oversampling,
> sample rate == conversion rate. However, with oversampling, sample rate ==
> conversion rate / oversampling ratio (because each sample involves #OSR
> conversions).
>
> So more code will be required to make IIO_CHAN_INFO_SAMP_FREQ
> attributes
> (both read/write_raw and read_avail) adjust the values based on the current
> oversampling ratio.
I agree with this, the sampling frequency differs when oversampling is used.
Will add that in the next version.
>
> > +
> > static const struct ad4691_chip_info ad4691_chip_info = {
> > .channels = ad4691_channels,
...
> > +
> > + st->scan_msg.spi = spi;
>
> This isn't how the SPI framework is intended to be used. We should
> have st->spi = spi in probe instead.
You are right. The spi pointer was removed from struct in earlier versions
since the message wasn't pre-prepared back then, though now it is needed.
>
> > +
> > + ret = spi_optimize_message(spi, &st->scan_msg);
> > + if (ret) {
...
> > +};
> > +
> > +static irqreturn_t ad4691_irq(int irq, void *private)
> > +{
> > + struct iio_dev *indio_dev = private;
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > +
> > + /*
> > + * GPx has asserted: stop conversions before reading so the
>
> Does this happen per-channel or only once per complete sequence?
>
This one happens per complete sequence.
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 9:34 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <1d0d41c8-7867-4459-a91a-a2c6774b1885@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 4, 2026 6:34 PM
...
> >
> > Add driver documentation under Documentation/iio/ad4691.rst covering
> > operating modes, oversampling, reference voltage, SPI offload paths,
> > and buffer data layout; register in MAINTAINERS and index.rst
>
> Documentation should be separate patch. It covers more than just SPI
> offload.
>
Noted. Thanks for this.
> >
> > Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
> >
> > Signed-off-by: Radu Sabau <radu.sabau@analog.com>
> > ---
...
> > +Selected when a ``pwms`` property is present in the device tree. The PWM
> drives
> > +the CNV pin independently of SPI at the configured conversion rate, and a
> GP
> > +pin (identified by ``interrupt-names``) asserts DATA_READY at end-of-burst
> to
> > +signal that the AVG_IN result registers are ready to be read.
> > +
> > +The IRQ handler stops the PWM, fires the IIO trigger, and the trigger
> handler
>
> If we stop the PWM after an IRQ, then we don't get a consistent sample rate.
> Ideally, we would leave the PWM running and just pick a rate slow enough
> that
> there is plenty of time to read the data. Otherwise, this mode doesn't seem
> particularly useful.
Should there also be a condition when setting the sampling frequency, that will
protect from setting too fast sample rates?
>
> > +reads all active ``AVG_IN(n)`` registers in a single optimised SPI message and
> > +pushes the scan to the buffer.
> > +
> > +The buffer sampling frequency (i.e. the PWM rate) is controlled by the
> > +``sampling_frequency`` attribute on the IIO buffer. Valid values span from
> the
> > +chip's minimum oscillator rate up to its maximum conversion rate
> > +(500 kSPS for AD4691/AD4693, 1 MSPS for AD4692/AD4694).
>
> Valid, but not usable without SPI offload.
The PWM is also be used with triggered-buffer in CNV Burst Mode.
>
> > +
> > +Autonomous Mode (idle / single-shot)
> > +-------------------------------------
> > +
...
> > +
> > +Manual offload
> > +--------------
> > +
> > +Used when no ``pwms`` property is present and SPI offload is available.
> > +
> > +A periodic SPI offload trigger controls the conversion rate. On each trigger
> > +period, the SPI engine executes an N+1 transfer message (same pipelined
> scheme
>
> How does this work with oversampling?
As per previous versions discussions, Manual Mode doesn't support oversampling,
since the chip only transfers the raw unfiltered 16-bit data without register interaction
in this mode.
>
> > +as software Manual Mode) and streams the data directly to the IIO DMA
> buffer.
...
> > +IIO DMA buffer:
> > +
> > +* **CNV Burst offload**: the SPI engine reads AVG_IN registers with a 2-
> byte
> > + address phase followed by a 2-byte data phase; the 16-bit result lands in
> > + the lower half of the 32-bit word (``shift=0``).
> > +* **Manual offload**: each 32-bit SPI word carries the channel byte in the
> > + first byte; the 16-bit result is returned in the upper half of the 32-bit
>
> I would expect the "first" byte to be in the "upper half" of the 32-bits as
> well. This layout could be explained better.
>
> Also, since extra data has to be read in this mode, does this affect the max
> conversion rate?
This is bad documentation on my part. "channel byte" isn't used anymore,
this is previous version behaviour. Right now, only 16-bits worth of actual
channel data are used.
>
> > + word (``shift=16``).
> > +
> > +The ``in_voltageN_type`` sysfs attribute reflects the active scan type.
> > +
> > +
> > +Unimplemented features
> > +======================
> > +
> > +* GPIO controller functionality of the GP pins
> > +* Clamp status and overrange events
> > +* Raw accumulator (ACC_IN) and accumulator status registers
> > +* ADC_BUSY and overrun status interrupts
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 10:39 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <22b44acb-bfb5-4b97-8fa2-aeb4aec704c2@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 4, 2026 6:57 PM
...
> > +
> > #define AD4691_CHANNEL(ch)
> \
> > { \
> > .type = IIO_VOLTAGE, \
> > @@ -122,11 +155,9 @@ struct ad4691_chip_info {
> > .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> \
> > .channel = ch, \
> > .scan_index = ch, \
> > - .scan_type = { \
> > - .sign = 'u', \
> > - .realbits = 16, \
> > - .storagebits = 16, \
> > - }, \
> > + .has_ext_scan_type = 1,
> \
> > + .ext_scan_type = ad4691_scan_types, \
> > + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
> \
>
> Usually, we just make two separte ad4691_chip_info structs for offload
> vs. not offload.
>
> ext_scan_type is generally only used when the scan type can change
> dynamically after probe.
>
So, just to be clear, you are saying I should have different chip_info structs
and change the triggered-buffer for offload ones if offload is present?
I am asking since offload has different scan types as well, and this would
mean 3 different chip_info structs for each chip -> total of 12 chip_info structs,
each with a different channel array, or perhaps there is a more compact way
to have this implemented.
I could make the channel arrays use the same macro and have the scan_type
reversed to storage and shift done as parameters.
Please let me know your thoughts on this.
> > }
> >
> > static const struct iio_chan_spec ad4691_channels[] = {
> > @@ -221,6 +252,17 @@ static const struct ad4691_chip_info
> ad4694_chip_info = {
> > .max_rate = 1 * HZ_PER_MHZ,
> > };
> >
...
> > }
> >
> > @@ -883,6 +1184,20 @@ static ssize_t sampling_frequency_store(struct
> device *dev,
> > if (iio_buffer_enabled(indio_dev))
> > return -EBUSY;
> >
> > + if (st->manual_mode && st->offload) {
> > + struct spi_offload_trigger_config config = {
> > + .type = SPI_OFFLOAD_TRIGGER_PERIODIC,
> > + .periodic = { .frequency_hz = freq },
> > + };
>
> Same comment as other patches. This needs to account for oversampling
> ratio.
>
I am thinking that since we would have different chip_info structs, manual
mode channels could omit the oversampling attribute, since it is not supported
by the chip on this mode.
> > +
> > + ret = spi_offload_trigger_validate(st->offload->trigger,
> &config);
> > + if (ret)
> > + return ret;
> > +
> > + st->offload->trigger_hz = config.periodic.frequency_hz;
> > + return len;
> > + }
> > +
> > ret = ad4691_set_pwm_freq(st, freq);
> > if (ret)
> > return ret;
> > @@ -968,10 +1283,23 @@ static irqreturn_t ad4691_trigger_handler(int
> irq, void *p)
> > return IRQ_HANDLED;
> > }
> >
> > +static int ad4691_get_current_scan_type(const struct iio_dev *indio_dev,
> > + const struct iio_chan_spec *chan)
> > +{
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > +
> > + if (!st->offload)
> > + return AD4691_SCAN_TYPE_NORMAL;
> > + if (st->manual_mode)
> > + return AD4691_SCAN_TYPE_OFFLOAD_MANUAL;
> > + return AD4691_SCAN_TYPE_OFFLOAD_CNV;
> > +}
> > +
> > static const struct iio_info ad4691_info = {
> > .read_raw = &ad4691_read_raw,
> > .write_raw = &ad4691_write_raw,
> > .read_avail = &ad4691_read_avail,
> > + .get_current_scan_type = &ad4691_get_current_scan_type,
> > .debugfs_reg_access = &ad4691_reg_access,
> > };
> >
> > @@ -1195,9 +1523,75 @@ static int ad4691_setup_triggered_buffer(struct
> iio_dev *indio_dev,
> >
> &ad4691_manual_buffer_setup_ops);
> > }
> >
> > +static int ad4691_setup_offload(struct iio_dev *indio_dev,
> > + struct ad4691_state *st,
> > + struct spi_offload *spi_offload)
> > +{
> > + struct device *dev = regmap_get_device(st->regmap);
> > + struct ad4691_offload_state *offload;
> > + struct dma_chan *rx_dma;
> > + int ret;
> > +
> > + offload = devm_kzalloc(dev, sizeof(*offload), GFP_KERNEL);
> > + if (!offload)
> > + return -ENOMEM;
> > +
> > + offload->spi = spi_offload;
> > + st->offload = offload;
> > +
> > + if (st->manual_mode) {
> > + offload->trigger =
> > + devm_spi_offload_trigger_get(dev, offload->spi,
> > +
> SPI_OFFLOAD_TRIGGER_PERIODIC);
> > + if (IS_ERR(offload->trigger))
> > + return dev_err_probe(dev, PTR_ERR(offload->trigger),
> > + "Failed to get periodic offload
> trigger\n");
> > +
> > + offload->trigger_hz = st->info->max_rate;
>
> I think I mentioned this elsewhere, but can we really get max_rate in manual
> mode
> due to the extra SPI overhead? Probably safer to start with a lower rate.
You are right a slower rate would be nicer, from my tests 311kHz worked perfect
with a 10MHz SPI frequency, but perhaps these numbers are a bit "odd".
How do you feel about 100kHz for a starting sample rate?
>
> > + } else {
> > + struct spi_offload_trigger_info trigger_info = {
> > + .fwnode = dev_fwnode(dev),
> > + .ops = &ad4691_offload_trigger_ops,
> > + .priv = st,
> > + };
> > +
> > + ret = devm_spi_offload_trigger_register(dev, &trigger_info);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "Failed to register offload
> trigger\n");
> > +
> > + offload->trigger =
> > + devm_spi_offload_trigger_get(dev, offload->spi,
> > +
> SPI_OFFLOAD_TRIGGER_DATA_READY);
> > + if (IS_ERR(offload->trigger))
> > + return dev_err_probe(dev, PTR_ERR(offload->trigger),
> > + "Failed to get DATA_READY offload
> trigger\n");
> > + }
> > +
> > + rx_dma = devm_spi_offload_rx_stream_request_dma_chan(dev,
> offload->spi);
> > + if (IS_ERR(rx_dma))
> > + return dev_err_probe(dev, PTR_ERR(rx_dma),
> > + "Failed to get offload RX DMA channel\n");
> > +
> > + if (st->manual_mode)
> > + indio_dev->setup_ops =
> &ad4691_manual_offload_buffer_setup_ops;
> > + else
> > + indio_dev->setup_ops =
> &ad4691_cnv_burst_offload_buffer_setup_ops;
> > +
> > + ret = devm_iio_dmaengine_buffer_setup_with_handle(dev, indio_dev,
> rx_dma,
> > +
> IIO_BUFFER_DIRECTION_IN);
> > + if (ret)
> > + return ret;
> > +
> > + indio_dev->buffer->attrs = ad4691_buffer_attrs;
>
> Should including ad4691_buffer_attrs depend on st->manual_mode?
>
> I thought it was only used when PWM is connected to CNV.
>
For offload manual mode, I thought buffer sampling frequency should also be available,
since the offload trigger's frequency is accessible.
> > +
> > + return 0;
> > +}
> > +
> > static int ad4691_probe(struct spi_device *spi)
> > {
> > struct device *dev = &spi->dev;
> > + struct spi_offload *spi_offload;
> > struct iio_dev *indio_dev;
> > struct ad4691_state *st;
> > int ret;
> > @@ -1232,6 +1626,13 @@ static int ad4691_probe(struct spi_device *spi)
> > if (ret)
> > return ret;
> >
> > + spi_offload = devm_spi_offload_get(dev, spi,
> &ad4691_offload_config);
> > + ret = PTR_ERR_OR_ZERO(spi_offload);
> > + if (ret == -ENODEV)
> > + spi_offload = NULL;
> > + else if (ret)
> > + return dev_err_probe(dev, ret, "Failed to get SPI offload\n");
> > +
> > indio_dev->name = st->info->name;
> > indio_dev->info = &ad4691_info;
> > indio_dev->modes = INDIO_DIRECT_MODE;
> > @@ -1239,7 +1640,10 @@ static int ad4691_probe(struct spi_device *spi)
> > indio_dev->channels = st->info->channels;
> > indio_dev->num_channels = st->info->num_channels;
>
> As mentioned earlier, we generally want separate channel structs
> for SPI offload. These will also have different num_channels because
> there is no timestamp channel in SPI offload.
If different chip_info structs will be used, wouldn't they already have specific
channels attached to them?
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 11:08 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414CB6B07EA81FB5A42436AF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Sabau, Radu bogdan
> Sent: Monday, April 6, 2026 1:39 PM
...
> > > #define AD4691_CHANNEL(ch)
> > \
> > > { \
> > > .type = IIO_VOLTAGE, \
> > > @@ -122,11 +155,9 @@ struct ad4691_chip_info {
> > > .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> > \
> > > .channel = ch, \
> > > .scan_index = ch, \
> > > - .scan_type = { \
> > > - .sign = 'u', \
> > > - .realbits = 16, \
> > > - .storagebits = 16, \
> > > - }, \
> > > + .has_ext_scan_type = 1,
> > \
> > > + .ext_scan_type = ad4691_scan_types, \
> > > + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
> > \
> >
> > Usually, we just make two separte ad4691_chip_info structs for offload
> > vs. not offload.
> >
> > ext_scan_type is generally only used when the scan type can change
> > dynamically after probe.
> >
>
> So, just to be clear, you are saying I should have different chip_info structs
> and change the triggered-buffer for offload ones if offload is present?
> I am asking since offload has different scan types as well, and this would
> mean 3 different chip_info structs for each chip -> total of 12 chip_info structs,
> each with a different channel array, or perhaps there is a more compact way
> to have this implemented.
> I could make the channel arrays use the same macro and have the scan_type
> reversed to storage and shift done as parameters.
>
I have given this a thought and I think this could be done in a more compact way:
1. Parametrize AD4691_CHANNEL to accept storagebits and shift, then define 4 channel
arrays:
- ad4691_channels[] - 16ch + timestamp (triggered-buffer path)
- ad4693_channels[] - 8ch + timestamp (triggered-buffer path)
- ad4691_offload_cnv_channels[] - 16 entries, storagebits=32, shift = 0
- ad4691_offload_manual_channels[] - 16 entries, storagebits=32, shift=16
The two offload arrays are shared across both chip families. Since num_channels
bound the interation in the IIO core, the 8ch chips simply use the first 8 entries of
the 16-entry offload arrays. Triggered-buffer path would need different channel
arrays since the timestamp index would be different, and offload doesn't use
timestamp.
2. chip_info could then stay at 2 structs, and have channels selected at probe for the
indio_dev, or have 4 chip info structs each having its own channels assigned, and only
num_channels could be changed at probe.
> Please let me know your thoughts on this.
^ permalink raw reply
* Re: [PATCH 33/33] rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
From: Miguel Ojeda @ 2026-04-06 13:21 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434476.73816.11744805605122440072.b4-review@b4>
On Thu, Apr 2, 2026 at 1:02 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Might be good to retain some of this in a code comment.
Bah, I missed this note among the rest, sorry (I didn't reply to the
ones where the commit went away due to the changes in v2) -- I agree
it wouldn't hurt to remember why it is there, even if it is already in
the Git log.
I will probably add it for tomorrow, especially if I have to rebase.
Thanks!
Cheers,
Miguel
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 13:30 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414C570998C4C1EE59ABFBBF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Sabau, Radu bogdan
> Sent: Monday, April 6, 2026 2:08 PM
>
> ...
>
> > > > #define AD4691_CHANNEL(ch)
> > > \
> > > > { \
> > > > .type = IIO_VOLTAGE, \
> > > > @@ -122,11 +155,9 @@ struct ad4691_chip_info {
> > > > .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> > > \
> > > > .channel = ch, \
> > > > .scan_index = ch, \
> > > > - .scan_type = { \
> > > > - .sign = 'u', \
> > > > - .realbits = 16, \
> > > > - .storagebits = 16, \
> > > > - }, \
> > > > + .has_ext_scan_type = 1,
> > > \
> > > > + .ext_scan_type = ad4691_scan_types, \
> > > > + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
> > > \
> > >
> > > Usually, we just make two separte ad4691_chip_info structs for offload
> > > vs. not offload.
> > >
> > > ext_scan_type is generally only used when the scan type can change
> > > dynamically after probe.
> > >
> >
> > So, just to be clear, you are saying I should have different chip_info structs
> > and change the triggered-buffer for offload ones if offload is present?
> > I am asking since offload has different scan types as well, and this would
> > mean 3 different chip_info structs for each chip -> total of 12 chip_info
> structs,
> > each with a different channel array, or perhaps there is a more compact way
> > to have this implemented.
> > I could make the channel arrays use the same macro and have the scan_type
> > reversed to storage and shift done as parameters.
> >
>
> I have given this a thought and I think this could be done in a more compact
> way:
>
> 1. Parametrize AD4691_CHANNEL to accept storagebits and shift, then define
> 4 channel
> arrays:
>
> - ad4691_channels[] - 16ch + timestamp (triggered-buffer path)
> - ad4693_channels[] - 8ch + timestamp (triggered-buffer path)
> - ad4691_offload_cnv_channels[] - 16 entries, storagebits=32, shift =
> 0
> - ad4691_offload_manual_channels[] - 16 entries, storagebits=32,
> shift=16
>
> The two offload arrays are shared across both chip families. Since
> num_channels
> bound the interation in the IIO core, the 8ch chips simply use the first 8
> entries of
> the 16-entry offload arrays. Triggered-buffer path would need different
> channel
> arrays since the timestamp index would be different, and offload doesn't use
> timestamp.
>
> 2. chip_info could then stay at 2 structs, and have channels selected at probe
> for the
> indio_dev, or have 4 chip info structs each having its own channels assigned,
> and only
> num_channels could be changed at probe.
>
I also have to mention that the oversampling commit would then implement
AD4691_MANUAL_CHANNEL macro which would miss the OVERSAMPLING
infomask, and offload_manual_channels will be declared using it.
More than this, that commit would also add other ad4691_manual_channels[]
and ad4693_manual_channels[] arrays that would use that MACRO as well.
Then, chip_info would have ad4691/93_channels assigned to it by default,
and indio_dev->channels will later be assigned at probe, depending on the
mode and offload.
If different chip_info structs would be wanted still, then my best guess is
to have different info structures (perhaps new types) in chip_info by default.
Something like *sw_info and *offload_info.
Each one would contain all the pre-defined channel arrays in them
(channels and manual_channels) and so have ad4691_sw_info and ad4691_offload_info.
After so, chip_info will also contain besides these 2 info structures, num_channels and max_rate.
At probe indio_dev assignments will be made from the chip_info entirely.
What's your guys take on this? I am keen to hearing your thoughts about this.
Thanks,
Radu
^ permalink raw reply
* Re: [PATCH v6 3/4] iio: adc: ad4691: add triggered buffer support
From: David Lechner @ 2026-04-06 13:39 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB84143905DD2E10BAC2151EEFF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 4:22 AM, Sabau, Radu bogdan wrote:
>> -----Original Message-----
>> From: David Lechner <dlechner@baylibre.com>
>> Sent: Saturday, April 4, 2026 6:12 PM
>
> ...
>
>>> +
>>> +/*
>>> + * Valid ACC_DEPTH values where the effective divisor equals the count.
>>> + * From Table 13: ACC_DEPTH = 2^N yields right-shift = N, divisor = 2^N.
>>> + */
>>> +static const int ad4691_oversampling_ratios[] = { 1, 2, 4, 8, 16, 32 };
>>
>> It would be nice to add oversampling in a separate commit as that is a
>> separate feature.
>
> Do you think this would be suitable after the offload commit?
>
Yes, I think that would be OK.
^ permalink raw reply
* Re: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: David Lechner @ 2026-04-06 13:44 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB84145906CC191F6AB8D2D3DAF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 4:34 AM, Sabau, Radu bogdan wrote:
>> -----Original Message-----
>> From: David Lechner <dlechner@baylibre.com>
>> Sent: Saturday, April 4, 2026 6:34 PM
>
> ...
>
>>> +Selected when a ``pwms`` property is present in the device tree. The PWM
>> drives
>>> +the CNV pin independently of SPI at the configured conversion rate, and a
>> GP
>>> +pin (identified by ``interrupt-names``) asserts DATA_READY at end-of-burst
>> to
>>> +signal that the AVG_IN result registers are ready to be read.
>>> +
>>> +The IRQ handler stops the PWM, fires the IIO trigger, and the trigger
>> handler
>>
>> If we stop the PWM after an IRQ, then we don't get a consistent sample rate.
>> Ideally, we would leave the PWM running and just pick a rate slow enough
>> that
>> there is plenty of time to read the data. Otherwise, this mode doesn't seem
>> particularly useful.
>
> Should there also be a condition when setting the sampling frequency, that will
> protect from setting too fast sample rates?
I haven't figured out a good way to do this since the real max rate
depends on a lot of different things and when not using offloading,
the time it takes to do SPI xfers is non-deterministic.
>>> +IIO DMA buffer:
>>> +
>>> +* **CNV Burst offload**: the SPI engine reads AVG_IN registers with a 2-
>> byte
>>> + address phase followed by a 2-byte data phase; the 16-bit result lands in
>>> + the lower half of the 32-bit word (``shift=0``).
>>> +* **Manual offload**: each 32-bit SPI word carries the channel byte in the
>>> + first byte; the 16-bit result is returned in the upper half of the 32-bit
>>
>> I would expect the "first" byte to be in the "upper half" of the 32-bits as
>> well. This layout could be explained better.
>>
>> Also, since extra data has to be read in this mode, does this affect the max
>> conversion rate?
>
> This is bad documentation on my part. "channel byte" isn't used anymore,
> this is previous version behaviour. Right now, only 16-bits worth of actual
> channel data are used.
>
Then why do we need the shift if there is no other data? Can't we rework
the SPI message so that there is no shift?
^ permalink raw reply
* Re: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: David Lechner @ 2026-04-06 13:53 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414CB6B07EA81FB5A42436AF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 5:39 AM, Sabau, Radu bogdan wrote:
>> -----Original Message-----
>> From: David Lechner <dlechner@baylibre.com>
>> Sent: Saturday, April 4, 2026 6:57 PM
>
> ...
>
>>> +
>>> #define AD4691_CHANNEL(ch)
>> \
>>> { \
>>> .type = IIO_VOLTAGE, \
>>> @@ -122,11 +155,9 @@ struct ad4691_chip_info {
>>> .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
>> \
>>> .channel = ch, \
>>> .scan_index = ch, \
>>> - .scan_type = { \
>>> - .sign = 'u', \
>>> - .realbits = 16, \
>>> - .storagebits = 16, \
>>> - }, \
>>> + .has_ext_scan_type = 1,
>> \
>>> + .ext_scan_type = ad4691_scan_types, \
>>> + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
>> \
>>
>> Usually, we just make two separte ad4691_chip_info structs for offload
>> vs. not offload.
>>
>> ext_scan_type is generally only used when the scan type can change
>> dynamically after probe.
>>
>
> So, just to be clear, you are saying I should have different chip_info structs
> and change the triggered-buffer for offload ones if offload is present?
> I am asking since offload has different scan types as well, and this would
> mean 3 different chip_info structs for each chip -> total of 12 chip_info structs,
> each with a different channel array, or perhaps there is a more compact way
> to have this implemented.
> I could make the channel arrays use the same macro and have the scan_type
> reversed to storage and shift done as parameters.
>
> Please let me know your thoughts on this.
If it gets too complex, we can dynamically create the chip info
struct during probe. But in general we prefer to statically define
them even if it gets a little verbose. Macros usually help here.
>>> }
>>>
>>> @@ -883,6 +1184,20 @@ static ssize_t sampling_frequency_store(struct
>> device *dev,
>>> if (iio_buffer_enabled(indio_dev))
>>> return -EBUSY;
>>>
>>> + if (st->manual_mode && st->offload) {
>>> + struct spi_offload_trigger_config config = {
>>> + .type = SPI_OFFLOAD_TRIGGER_PERIODIC,
>>> + .periodic = { .frequency_hz = freq },
>>> + };
>>
>> Same comment as other patches. This needs to account for oversampling
>> ratio.
>>
>
> I am thinking that since we would have different chip_info structs, manual
> mode channels could omit the oversampling attribute, since it is not supported
> by the chip on this mode.
Yes, this would be ideal.
>> SPI_OFFLOAD_TRIGGER_PERIODIC);
>>> + if (IS_ERR(offload->trigger))
>>> + return dev_err_probe(dev, PTR_ERR(offload->trigger),
>>> + "Failed to get periodic offload
>> trigger\n");
>>> +
>>> + offload->trigger_hz = st->info->max_rate;
>>
>> I think I mentioned this elsewhere, but can we really get max_rate in manual
>> mode
>> due to the extra SPI overhead? Probably safer to start with a lower rate.
>
> You are right a slower rate would be nicer, from my tests 311kHz worked perfect
> with a 10MHz SPI frequency, but perhaps these numbers are a bit "odd".
>
> How do you feel about 100kHz for a starting sample rate?
Sounds reasonable.
>> IIO_BUFFER_DIRECTION_IN);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + indio_dev->buffer->attrs = ad4691_buffer_attrs;
>>
>> Should including ad4691_buffer_attrs depend on st->manual_mode?
>>
>> I thought it was only used when PWM is connected to CNV.
>>
>
> For offload manual mode, I thought buffer sampling frequency should also be available,
> since the offload trigger's frequency is accessible.
Ah right. Not sure what I was thinking when I wrote that.
>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static int ad4691_probe(struct spi_device *spi)
>>> {
>>> struct device *dev = &spi->dev;
>>> + struct spi_offload *spi_offload;
>>> struct iio_dev *indio_dev;
>>> struct ad4691_state *st;
>>> int ret;
>>> @@ -1232,6 +1626,13 @@ static int ad4691_probe(struct spi_device *spi)
>>> if (ret)
>>> return ret;
>>>
>>> + spi_offload = devm_spi_offload_get(dev, spi,
>> &ad4691_offload_config);
>>> + ret = PTR_ERR_OR_ZERO(spi_offload);
>>> + if (ret == -ENODEV)
>>> + spi_offload = NULL;
>>> + else if (ret)
>>> + return dev_err_probe(dev, ret, "Failed to get SPI offload\n");
>>> +
>>> indio_dev->name = st->info->name;
>>> indio_dev->info = &ad4691_info;
>>> indio_dev->modes = INDIO_DIRECT_MODE;
>>> @@ -1239,7 +1640,10 @@ static int ad4691_probe(struct spi_device *spi)
>>> indio_dev->channels = st->info->channels;
>>> indio_dev->num_channels = st->info->num_channels;
>>
>> As mentioned earlier, we generally want separate channel structs
>> for SPI offload. These will also have different num_channels because
>> there is no timestamp channel in SPI offload.
>
> If different chip_info structs will be used, wouldn't they already have specific
> channels attached to them?
>
Yes.
^ permalink raw reply
* Re: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: David Lechner @ 2026-04-06 13:56 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414BB41577A8B5A0432463FF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 8:30 AM, Sabau, Radu bogdan wrote:
>
>
>> -----Original Message-----
>> From: Sabau, Radu bogdan
>> Sent: Monday, April 6, 2026 2:08 PM
>>
>> ...
>>
>>>>> #define AD4691_CHANNEL(ch)
>>>> \
>>>>> { \
>>>>> .type = IIO_VOLTAGE, \
>>>>> @@ -122,11 +155,9 @@ struct ad4691_chip_info {
>>>>> .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
>>>> \
>>>>> .channel = ch, \
>>>>> .scan_index = ch, \
>>>>> - .scan_type = { \
>>>>> - .sign = 'u', \
>>>>> - .realbits = 16, \
>>>>> - .storagebits = 16, \
>>>>> - }, \
>>>>> + .has_ext_scan_type = 1,
>>>> \
>>>>> + .ext_scan_type = ad4691_scan_types, \
>>>>> + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
>>>> \
>>>>
>>>> Usually, we just make two separte ad4691_chip_info structs for offload
>>>> vs. not offload.
>>>>
>>>> ext_scan_type is generally only used when the scan type can change
>>>> dynamically after probe.
>>>>
>>>
>>> So, just to be clear, you are saying I should have different chip_info structs
>>> and change the triggered-buffer for offload ones if offload is present?
>>> I am asking since offload has different scan types as well, and this would
>>> mean 3 different chip_info structs for each chip -> total of 12 chip_info
>> structs,
>>> each with a different channel array, or perhaps there is a more compact way
>>> to have this implemented.
>>> I could make the channel arrays use the same macro and have the scan_type
>>> reversed to storage and shift done as parameters.
>>>
>>
>> I have given this a thought and I think this could be done in a more compact
>> way:
>>
>> 1. Parametrize AD4691_CHANNEL to accept storagebits and shift, then define
>> 4 channel
>> arrays:
>>
>> - ad4691_channels[] - 16ch + timestamp (triggered-buffer path)
>> - ad4693_channels[] - 8ch + timestamp (triggered-buffer path)
>> - ad4691_offload_cnv_channels[] - 16 entries, storagebits=32, shift =
>> 0
>> - ad4691_offload_manual_channels[] - 16 entries, storagebits=32,
>> shift=16
>>
>> The two offload arrays are shared across both chip families. Since
>> num_channels
>> bound the interation in the IIO core, the 8ch chips simply use the first 8
>> entries of
>> the 16-entry offload arrays. Triggered-buffer path would need different
>> channel
>> arrays since the timestamp index would be different, and offload doesn't use
>> timestamp.
>>
>> 2. chip_info could then stay at 2 structs, and have channels selected at probe
>> for the
>> indio_dev, or have 4 chip info structs each having its own channels assigned,
>> and only
>> num_channels could be changed at probe.
>>
>
> I also have to mention that the oversampling commit would then implement
> AD4691_MANUAL_CHANNEL macro which would miss the OVERSAMPLING
> infomask, and offload_manual_channels will be declared using it.
> More than this, that commit would also add other ad4691_manual_channels[]
> and ad4693_manual_channels[] arrays that would use that MACRO as well.
>
> Then, chip_info would have ad4691/93_channels assigned to it by default,
> and indio_dev->channels will later be assigned at probe, depending on the
> mode and offload.
>
> If different chip_info structs would be wanted still, then my best guess is
> to have different info structures (perhaps new types) in chip_info by default.
> Something like *sw_info and *offload_info.
Yes, this is how I would do it too.
> Each one would contain all the pre-defined channel arrays in them
> (channels and manual_channels) and so have ad4691_sw_info and ad4691_offload_info.
> After so, chip_info will also contain besides these 2 info structures, num_channels and max_rate.
> At probe indio_dev assignments will be made from the chip_info entirely.
>
> What's your guys take on this? I am keen to hearing your thoughts about this.
>
> Thanks,
> Radu
>
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 14:16 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <420dba4a-0c31-47bc-b84a-5d29702b115e@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Monday, April 6, 2026 4:44 PM
...
> >
> > This is bad documentation on my part. "channel byte" isn't used anymore,
> > this is previous version behaviour. Right now, only 16-bits worth of actual
> > channel data are used.
> >
> Then why do we need the shift if there is no other data? Can't we rework
> the SPI message so that there is no shift?
I thought the shift is needed since DMA size is 32 bits, and value comes on the
upper word 16 bits, not on the lower ones as for CNV Burst.
Manual Mode layout: TX [CMD_HI CMD_LO DUMMY DUMMY], RX [DATA_HI DATA_LO DUMMY DUMMY]
CNV Burst layout: TX [REG_HI REG_LO DUMMY DUMMY], RX [DUMMY DUMMY DATA_HI DATA_LO]
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 14:20 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <83971700-ea17-4fd5-8985-68c798222800@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Monday, April 6, 2026 4:57 PM
...
> >
> > I also have to mention that the oversampling commit would then implement
> > AD4691_MANUAL_CHANNEL macro which would miss the OVERSAMPLING
> > infomask, and offload_manual_channels will be declared using it.
> > More than this, that commit would also add other
> ad4691_manual_channels[]
> > and ad4693_manual_channels[] arrays that would use that MACRO as well.
> >
> > Then, chip_info would have ad4691/93_channels assigned to it by default,
> > and indio_dev->channels will later be assigned at probe, depending on the
> > mode and offload.
> >
> > If different chip_info structs would be wanted still, then my best guess is
> > to have different info structures (perhaps new types) in chip_info by default.
> > Something like *sw_info and *offload_info.
>
> Yes, this is how I would do it too.
>
Ok then, will have different chip infos and each one will have respective channels
to them. Thanks for this, too!
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Jim Mattson @ 2026-04-06 14:23 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc, chao.gao
In-Reply-To: <20260404034954.t7iapenzvhdpagxp@desk>
On Fri, Apr 3, 2026 at 8:50 PM Pawan Gupta
<pawan.kumar.gupta@linux.intel.com> wrote:
>
> On Fri, Apr 03, 2026 at 07:21:02PM -0700, Jim Mattson wrote:
> > On Fri, Apr 3, 2026 at 5:22 PM Pawan Gupta
> > <pawan.kumar.gupta@linux.intel.com> wrote:
> > >
> > > On Fri, Apr 03, 2026 at 04:39:54PM -0700, Jim Mattson wrote:
> > > > > Since cloud providers have greater control over userspace, the decision to
> > > > > use BHI_DIS_S or not can be left to them. KVM would simply follow what it
> > > > > is asked to do by the userspace.
> > > >
> > > > I feel like we've gone over this before, but if userspace tells KVM
> > > > not to enable BHI_DIS_S, how do we inform Windows that it needs to do
> > > > the longer clearing sequence, despite the fact that the virtual CPU is
> > > > masquerading as Ice Lake?
> > >
> > > IMO, if an OS is allergic to a hardware mitigation, and is also aware that
> > > it is virtualized, it should default to a sw mitigation that works everywhere.
> >
> > Agreed. So, without any information to the contrary, VMs should assume
> > the long BHB clearing sequence is required.
> >
> > Returning to my earlier comment, the test should be:
> >
> > + if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL) ||
> > cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) {
> > + bhb_seq_outer_loop = 12;
> > + bhb_seq_inner_loop = 7;
> > + }
>
> To be clear, my comment was for an OS that doesn't want BHI_DIS_S
> under-the-hood with virtual-SPEC_CTRL. Linux doesn't have that problem,
> hardware mitigation on Linux is perfectly okay.
Today, BHI_DIS_S under-the-hood isn't offered. If the hypervisor
doesn't offer the paravirtual mitigation MSRs, the guest must assume
that the hypervisor will not set BHI_DIS_S on its behalf.
> Without virtual-SPEC_CTRL, the problem set is limited to guests that
> migrate accross Alder Lake generation CPUs. As you mentioned the change in
> MAXPHYADDR makes it unlikely.
I have been unable to make a compelling argument for not crossing this
boundary. The only applications I can point to that are broken by the
missing reserved bits are (nested) hypervisors using shadow-paging.
Since both nVMX and nSVM support TDP, the niche cache isn't a concern.
There are compelling business reasons to support seamless migration
from pre-Alder Lake to post-Alder Lake. If you know of any other
applications that will fail with a mis-emulated smaller MAXPHYADDR,
please let me know.
> With virtual-SPEC_CTRL support, guests that fall into the subset that
> migrate inspite of MAXPHYADDR change would also be mitigated. Then, on top
> of hardware mitigation, deploying the long sequence in the guest would
> incur a significant performance penalty for no good reason.
Yes, but the guest needs a way to determine whether the hypervisor
will do what's necessary to make the short sequence effective. And, in
particular, no KVM hypervisor today is prepared to do that.
When running under a hypervisor, without BHI_CTRL and without any
evidence to the contrary, the guest must assume that the longer
sequence is necessary. At the very least, we need a CPUID or MSR bit
that says, "the short BHB clearing sequence is adequate for this
vCPU."
^ permalink raw reply
* Re: [PATCH v2 01/33] rust: kbuild: remove `--remap-path-prefix` workarounds
From: Tamir Duberstein @ 2026-04-06 14:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-2-ojeda@kernel.org>
On Mon, 06 Apr 2026 01:52:37 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Commit 8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix
> to make paths relative"") removed `--remap-path-prefix` from the build
> system, so the workarounds are not needed anymore.
>
> Thus remove them.
>
> Note that the flag has landed again in parallel in this cycle in
> commit dda135077ecc ("rust: build: remap path to avoid absolute path"),
> together with `--remap-path-scope=macro` [1]. However, they are gated on
> `rustc-option-yn, --remap-path-scope=macro`, which means they are both
> only passed starting with Rust 1.95.0 [2]:
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 07/33] rust: allow globally `clippy::incompatible_msrv`
From: Tamir Duberstein @ 2026-04-06 14:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-8-ojeda@kernel.org>
On Mon, 06 Apr 2026 01:52:43 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> diff --git a/Makefile b/Makefile
> index a63684c36d60..78f5ee173eda 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -486,6 +486,7 @@ export rust_common_flags := --edition=2021 \
> -Wclippy::as_underscore \
> -Wclippy::cast_lossless \
> -Wclippy::ignored_unit_patterns \
> + -Aclippy::incompatible_msrv \
Could you add a reference to the upstream bug report [0] here?
Link: https://github.com/rust-lang/rust-clippy/issues/14425 [0]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 15/33] rust: macros: simplify code using `feature(extract_if)`
From: Tamir Duberstein @ 2026-04-06 14:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-16-ojeda@kernel.org>
On Mon, 06 Apr 2026 01:52:51 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> `feature(extract_if)` [1] was stabilized in Rust 1.87.0 [2], and the last
> significant change happened in Rust 1.85.0 [3] when the range parameter
> was added.
>
> That is, with our new minimum version, we can start using the feature.
>
> Thus simplify the code using the feature and remove the TODO comment.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 32/33] rust: kbuild: support global per-version flags
From: Tamir Duberstein @ 2026-04-06 14:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-33-ojeda@kernel.org>
On Mon, 06 Apr 2026 01:53:08 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Sometimes it is useful to gate global Rust flags per compiler version.
> For instance, we may want to disable a lint that has false positives in
> a single version [1].
>
> We already had helpers like `rustc-min-version` for that, which we use
> elsewhere, but we cannot currently use them for `rust_common_flags`,
> which contains the global flags for all Rust code (kernel and host),
> because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which
> does not exist when `rust_common_flags` is defined.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 07/33] rust: allow globally `clippy::incompatible_msrv`
From: Miguel Ojeda @ 2026-04-06 14:37 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177548573697.95472.13544191227699996309.b4-review@b4>
On Mon, Apr 6, 2026 at 4:29 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Could you add a reference to the upstream bug report [0] here?
Of course, thanks for the tags!
Cheers,
Miguel
^ permalink raw reply
* [PATCH v9 1/3] dt-bindings: hwmon: Document the LTC4283 Swap Controller
From: Nuno Sá via B4 Relay @ 2026-04-06 14:31 UTC (permalink / raw)
To: linux-gpio, linux-hwmon, devicetree, linux-doc
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Linus Walleij, Bartosz Golaszewski
In-Reply-To: <20260406-ltc4283-support-v9-0-b66cfc749261@analog.com>
From: Nuno Sá <nuno.sa@analog.com>
The LTC4283 is a negative voltage hot swap controller that drives an
external N-channel MOSFET to allow a board to be safely inserted and
removed from a live backplane.
Special note for the "adi,vpower-drns-enable" property. It allows to choose
between the attenuated MOSFET drain voltage or the attenuated input
voltage at the RTNS pin (effectively choosing between input or output
power). This is a system level decision not really intended to change at
runtime and hence is being added as a Firmware property.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
.../devicetree/bindings/hwmon/adi,ltc4283.yaml | 272 +++++++++++++++++++++
MAINTAINERS | 6 +
2 files changed, 278 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml
new file mode 100644
index 000000000000..05e2132ad4d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml
@@ -0,0 +1,272 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,ltc4283.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LTC4283 Negative Voltage Hot Swap Controller
+
+maintainers:
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ The LTC4283 negative voltage hot swap controller drives an external N-channel
+ MOSFET to allow a board to be safely inserted and removed from a live
+ backplane.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ltc4283.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc4283
+
+ reg:
+ maxItems: 1
+
+ adi,rsense-nano-ohms:
+ description: Value of the sense resistor.
+
+ adi,current-limit-sense-microvolt:
+ description:
+ The current limit sense voltage of the chip is adjustable between
+ 15mV and 30mV in 1mV steps. This effectively limits the current
+ on the load.
+ minimum: 15000
+ maximum: 30000
+ default: 15000
+
+ adi,current-limit-foldback-factor:
+ description:
+ Specifies the foldback factor for the current limit. The current limit
+ can be reduced (folded back) to one of four preset levels. The value
+ represents the percentage of the current limit sense voltage to use
+ during foldback. A value of 100 means no foldback.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [10, 20, 50, 100]
+ default: 100
+
+ adi,cooling-delay-ms:
+ description:
+ Cooling time to apply after an overcurrent fault, FET bad or
+ external fault.
+ enum: [512, 1002, 2005, 4100, 8190, 16400, 32800, 65600]
+ default: 512
+
+ adi,fet-bad-timer-delay-ms:
+ description:
+ FET bad timer delay. After a FET bad status condition is detected,
+ this timer is started. If the condition persists for the
+ specified time, the FET is turned off and a fault is logged.
+ enum: [256, 512, 1002, 2005]
+ default: 256
+
+ adi,power-good-reset-on-fet:
+ description:
+ If set, resets the power good status when the MOSFET is turned off.
+ Otherwise, it resets when a low output voltage is detected.
+ type: boolean
+
+ adi,fet-turn-off-disable:
+ description:
+ If set, the MOSFET is not turned off when a FET fault is detected.
+ type: boolean
+
+ adi,tmr-pull-down-disable:
+ description: Disables 2uA pull-down current on the TMR pin.
+ type: boolean
+
+ adi,dvdt-inrush-control-disable:
+ description:
+ Disables dV/dt inrush control during startup. In dV/dt mode, the inrush
+ current is limited by controlling a constant output voltage ramp rate.
+ When disabled, the inrush control mechanism is active current limiting.
+ type: boolean
+
+ adi,fault-log-enable:
+ description:
+ If set, enables logging fault registers and ADC data into EEPROM upon a
+ fault.
+ type: boolean
+
+ adi,vpower-drns-enable:
+ description:
+ If set, enables the attenuated MOSFET drain voltage to be monitored. This
+ effectively means that the MOSFET power is monitored. If not set, the
+ attenuated input voltage (and hence input power) is monitored.
+ type: boolean
+
+ adi,external-fault-fet-off-enable:
+ description: Turns MOSFET off following an external fault.
+ type: boolean
+
+ adi,undervoltage-retry-disable:
+ description: Do not retry to turn on the MOSFET after an undervoltage fault.
+ type: boolean
+
+ adi,overvoltage-retry-disable:
+ description: Do not retry to turn on the MOSFET after an overvoltage fault.
+ type: boolean
+
+ adi,external-fault-retry-enable:
+ description: Retry to turn on the MOSFET after an external fault.
+ type: boolean
+
+ adi,overcurrent-retries:
+ description: Configures auto-retry following an Overcurrent fault.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [latch-off, "1", "7", unlimited]
+ default: latch-off
+
+ adi,fet-bad-retries:
+ description:
+ Configures auto-retry following a FET bad fault and a consequent MOSFET
+ turn off.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [latch-off, "1", "7", unlimited]
+ default: latch-off
+
+ adi,pgio1-func:
+ description: Configures the function of the PGIO1 pin.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [inverted_power_good, power_good, gpio]
+ default: inverted_power_good
+
+ adi,pgio2-func:
+ description: Configures the function of the PGIO2 pin.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [inverted_power_good, power_good, gpio, active_current_limiting]
+ default: inverted_power_good
+
+ adi,pgio3-func:
+ description: Configures the function of the PGIO3 pin.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [inverted_power_good_input, power_good_input, gpio]
+ default: inverted_power_good_input
+
+ adi,pgio4-func:
+ description: Configures the function of the PGIO4 pin.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [inverted_external_fault, external_fault, gpio]
+ default: inverted_external_fault
+
+ adi,gpio-on-adio1:
+ description: If set, the ADIO1 pin is used as a GPIO.
+ type: boolean
+
+ adi,gpio-on-adio2:
+ description: If set, the ADIO2 pin is used as a GPIO.
+ type: boolean
+
+ adi,gpio-on-adio3:
+ description: If set, the ADIO3 pin is used as a GPIO.
+ type: boolean
+
+ adi,gpio-on-adio4:
+ description: If set, the ADIO4 pin is used as a GPIO.
+ type: boolean
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+dependencies:
+ adi,gpio-on-adio1:
+ - gpio-controller
+ - '#gpio-cells'
+ adi,gpio-on-adio2:
+ - gpio-controller
+ - '#gpio-cells'
+ adi,gpio-on-adio3:
+ - gpio-controller
+ - '#gpio-cells'
+ adi,gpio-on-adio4:
+ - gpio-controller
+ - '#gpio-cells'
+ adi,external-fault-retry-enable:
+ - adi,pgio4-func
+ adi,external-fault-fet-off-enable:
+ - adi,pgio4-func
+
+required:
+ - compatible
+ - reg
+ - adi,rsense-nano-ohms
+
+allOf:
+ - if:
+ properties:
+ adi,pgio1-func:
+ const: gpio
+ required:
+ - adi,pgio1-func
+ then:
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+
+ - if:
+ properties:
+ adi,pgio2-func:
+ const: gpio
+ required:
+ - adi,pgio2-func
+ then:
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+
+ - if:
+ properties:
+ adi,pgio3-func:
+ const: gpio
+ required:
+ - adi,pgio3-func
+ then:
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+
+ - if:
+ properties:
+ adi,pgio4-func:
+ const: gpio
+ required:
+ - adi,pgio4-func
+ then:
+ properties:
+ adi,external-fault-retry-enable: false
+ adi,external-fault-fet-off-enable: false
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ swap-controller@15 {
+ compatible = "adi,ltc4283";
+ reg = <0x15>;
+
+ adi,rsense-nano-ohms = <500>;
+ adi,current-limit-sense-microvolt = <25000>;
+ adi,current-limit-foldback-factor = <10>;
+ adi,cooling-delay-ms = <8190>;
+ adi,fet-bad-timer-delay-ms = <512>;
+
+ adi,external-fault-fet-off-enable;
+ adi,pgio4-func = "external_fault";
+
+ adi,gpio-on-adio1;
+ adi,pgio1-func = "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e008c2bcc187..3f727d7fdfa4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15161,6 +15161,12 @@ F: Documentation/devicetree/bindings/hwmon/adi,ltc4282.yaml
F: Documentation/hwmon/ltc4282.rst
F: drivers/hwmon/ltc4282.c
+LTC4283 HARDWARE MONITOR AND GPIO DRIVER
+M: Nuno Sá <nuno.sa@analog.com>
+L: linux-hwmon@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml
+
LTC4286 HARDWARE MONITOR DRIVER
M: Delphine CC Chiu <Delphine_CC_Chiu@Wiwynn.com>
L: linux-hwmon@vger.kernel.org
--
2.53.0
^ permalink raw reply related
* [PATCH v9 3/3] gpio: gpio-ltc4283: Add support for the LTC4283 Swap Controller
From: Nuno Sá via B4 Relay @ 2026-04-06 14:31 UTC (permalink / raw)
To: linux-gpio, linux-hwmon, devicetree, linux-doc
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Linus Walleij, Bartosz Golaszewski,
Bartosz Golaszewski
In-Reply-To: <20260406-ltc4283-support-v9-0-b66cfc749261@analog.com>
From: Nuno Sá <nuno.sa@analog.com>
The LTC4283 device has up to 8 pins that can be configured as GPIOs.
Note that PGIO pins are not set as GPIOs by default so if they are
configured to be used as GPIOs we need to make sure to initialize them
to a sane default. They are set as inputs by default.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
MAINTAINERS | 2 +
drivers/gpio/Kconfig | 15 +++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ltc4283.c | 218 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 236 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a63833b6fe8b..0947cdbac5e5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15163,9 +15163,11 @@ F: drivers/hwmon/ltc4282.c
LTC4283 HARDWARE MONITOR AND GPIO DRIVER
M: Nuno Sá <nuno.sa@analog.com>
+L: linux-gpio@vger.kernel.org
L: linux-hwmon@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml
+F: drivers/gpio/gpio-ltc4283.c
F: drivers/hwmon/ltc4283.c
LTC4286 HARDWARE MONITOR DRIVER
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b45fb799e36c..ba2621024598 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1758,6 +1758,21 @@ config GPIO_WM8994
endmenu
+menu "Auxiliary Bus GPIO drivers"
+ depends on AUXILIARY_BUS
+
+config GPIO_LTC4283
+ tristate "Analog Devices LTC4283 GPIO support"
+ depends on SENSORS_LTC4283
+ help
+ If you say yes here you want the GPIO function available in Analog
+ Devices LTC4283 Negative Voltage Hot Swap Controller.
+
+ This driver can also be built as a module. If so, the module will
+ be called gpio-ltc4283.
+
+endmenu
+
menu "PCI GPIO expanders"
depends on PCI
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c05f7d795c43..ff37aca5029c 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_GPIO_LP873X) += gpio-lp873x.o
obj-$(CONFIG_GPIO_LP87565) += gpio-lp87565.o
obj-$(CONFIG_GPIO_LPC18XX) += gpio-lpc18xx.o
obj-$(CONFIG_GPIO_LPC32XX) += gpio-lpc32xx.o
+obj-$(CONFIG_GPIO_LTC4283) += gpio-ltc4283.o
obj-$(CONFIG_GPIO_MACSMC) += gpio-macsmc.o
obj-$(CONFIG_GPIO_MADERA) += gpio-madera.o
obj-$(CONFIG_GPIO_MAX3191X) += gpio-max3191x.o
diff --git a/drivers/gpio/gpio-ltc4283.c b/drivers/gpio/gpio-ltc4283.c
new file mode 100644
index 000000000000..6609443c5d62
--- /dev/null
+++ b/drivers/gpio/gpio-ltc4283.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Analog Devices LTC4283 GPIO driver
+ *
+ * Copyright 2025 Analog Devices Inc.
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/bitfield.h>
+#include <linux/bitmap.h>
+#include <linux/bits.h>
+#include <linux/device.h>
+#include <linux/gpio/driver.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#define LTC4283_PINS_MAX 8
+#define LTC4283_PGIOX_START_NR 4
+#define LTC4283_INPUT_STATUS 0x02
+#define LTC4283_PGIO_CONFIG 0x10
+#define LTC4283_PGIO_CFG_MASK(pin) \
+ GENMASK(((pin) - LTC4283_PGIOX_START_NR) * 2 + 1, (((pin) - LTC4283_PGIOX_START_NR) * 2))
+#define LTC4283_PGIO_CONFIG_2 0x11
+
+#define LTC4283_ADIO_CONFIG 0x12
+/* starts at bit 4 */
+#define LTC4283_ADIOX_CONFIG_MASK(pin) BIT((pin) + 4)
+#define LTC4283_PGIO_DIR_IN 3
+#define LTC4283_PGIO_DIR_OUT 2
+
+struct ltc4283_gpio {
+ struct gpio_chip gpio_chip;
+ struct regmap *regmap;
+};
+
+static int ltc4283_pgio_get_direction(const struct ltc4283_gpio *st, unsigned int off)
+{
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(st->regmap, LTC4283_PGIO_CONFIG, &val);
+ if (ret)
+ return ret;
+
+ val = field_get(LTC4283_PGIO_CFG_MASK(off), val);
+ if (val == LTC4283_PGIO_DIR_IN)
+ return GPIO_LINE_DIRECTION_IN;
+
+ return GPIO_LINE_DIRECTION_OUT;
+}
+
+static int ltc4283_gpio_get_direction(struct gpio_chip *gc, unsigned int off)
+{
+ struct ltc4283_gpio *st = gpiochip_get_data(gc);
+ unsigned int val;
+ int ret;
+
+ if (off >= LTC4283_PGIOX_START_NR)
+ return ltc4283_pgio_get_direction(st, off);
+
+ ret = regmap_read(st->regmap, LTC4283_ADIO_CONFIG, &val);
+ if (ret)
+ return ret;
+
+ if (val & LTC4283_ADIOX_CONFIG_MASK(off))
+ return GPIO_LINE_DIRECTION_IN;
+
+ return GPIO_LINE_DIRECTION_OUT;
+}
+
+static int ltc4283_gpio_direction_set(const struct ltc4283_gpio *st,
+ unsigned int off, bool input)
+{
+ if (off >= LTC4283_PGIOX_START_NR) {
+ unsigned int val = LTC4283_PGIO_DIR_OUT;
+
+ if (input)
+ val = LTC4283_PGIO_DIR_IN;
+
+ val = field_prep(LTC4283_PGIO_CFG_MASK(off), val);
+ return regmap_update_bits(st->regmap, LTC4283_PGIO_CONFIG,
+ LTC4283_PGIO_CFG_MASK(off), val);
+ }
+
+ return regmap_update_bits(st->regmap, LTC4283_ADIO_CONFIG,
+ LTC4283_ADIOX_CONFIG_MASK(off),
+ field_prep(LTC4283_ADIOX_CONFIG_MASK(off), input));
+}
+
+static int __ltc4283_gpio_set_value(const struct ltc4283_gpio *st,
+ unsigned int off, int val)
+{
+ u32 reg = off < LTC4283_PGIOX_START_NR ? LTC4283_ADIO_CONFIG : LTC4283_PGIO_CONFIG_2;
+
+ return regmap_update_bits(st->regmap, reg, BIT(off),
+ field_prep(BIT(off), !!val));
+}
+
+static int ltc4283_gpio_direction_input(struct gpio_chip *gc, unsigned int off)
+{
+ struct ltc4283_gpio *st = gpiochip_get_data(gc);
+
+ return ltc4283_gpio_direction_set(st, off, true);
+}
+
+static int ltc4283_gpio_direction_output(struct gpio_chip *gc, unsigned int off, int val)
+{
+ struct ltc4283_gpio *st = gpiochip_get_data(gc);
+ int ret;
+
+ ret = ltc4283_gpio_direction_set(st, off, false);
+ if (ret)
+ return ret;
+
+ return __ltc4283_gpio_set_value(st, off, val);
+}
+
+static int ltc4283_gpio_get_value(struct gpio_chip *gc, unsigned int off)
+{
+ struct ltc4283_gpio *st = gpiochip_get_data(gc);
+ unsigned int val, reg;
+ int ret, dir;
+
+ dir = ltc4283_gpio_get_direction(gc, off);
+ if (dir < 0)
+ return dir;
+
+ if (dir == GPIO_LINE_DIRECTION_IN) {
+ ret = regmap_read(st->regmap, LTC4283_INPUT_STATUS, &val);
+ if (ret)
+ return ret;
+
+ /* ADIO1 is at bit 3. */
+ if (off < LTC4283_PGIOX_START_NR)
+ return !!(val & BIT(3 - off));
+
+ /* PGIO1 is at bit 7. */
+ return !!(val & BIT(7 - (off - LTC4283_PGIOX_START_NR)));
+ }
+
+ if (off < LTC4283_PGIOX_START_NR)
+ reg = LTC4283_ADIO_CONFIG;
+ else
+ reg = LTC4283_PGIO_CONFIG_2;
+
+ ret = regmap_read(st->regmap, reg, &val);
+ if (ret)
+ return ret;
+
+ return !!(val & BIT(off));
+}
+
+static int ltc4283_gpio_set_value(struct gpio_chip *gc, unsigned int off, int val)
+{
+ struct ltc4283_gpio *st = gpiochip_get_data(gc);
+
+ return __ltc4283_gpio_set_value(st, off, val);
+}
+
+static int ltc4283_init_valid_mask(struct gpio_chip *gc, unsigned long *valid_mask,
+ unsigned int ngpios)
+{
+ unsigned long *mask = dev_get_platdata(gc->parent);
+
+ bitmap_copy(valid_mask, mask, ngpios);
+ return 0;
+}
+
+static int ltc4283_gpio_probe(struct auxiliary_device *adev,
+ const struct auxiliary_device_id *id)
+{
+ struct device *dev = &adev->dev;
+ struct ltc4283_gpio *st;
+ struct gpio_chip *gc;
+
+ st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+
+ st->regmap = dev_get_regmap(dev->parent, NULL);
+ if (!st->regmap)
+ return dev_err_probe(dev, -ENODEV,
+ "Failed to get regmap\n");
+
+ gc = &st->gpio_chip;
+ gc->parent = dev;
+ gc->get_direction = ltc4283_gpio_get_direction;
+ gc->direction_input = ltc4283_gpio_direction_input;
+ gc->direction_output = ltc4283_gpio_direction_output;
+ gc->get = ltc4283_gpio_get_value;
+ gc->set = ltc4283_gpio_set_value;
+ gc->init_valid_mask = ltc4283_init_valid_mask;
+ gc->can_sleep = true;
+
+ gc->base = -1;
+ gc->ngpio = LTC4283_PINS_MAX;
+ gc->label = adev->name;
+ gc->owner = THIS_MODULE;
+
+ return devm_gpiochip_add_data(dev, &st->gpio_chip, st);
+}
+
+static const struct auxiliary_device_id ltc4283_aux_id_table[] = {
+ { "ltc4283.gpio" },
+ { }
+};
+MODULE_DEVICE_TABLE(auxiliary, ltc4283_aux_id_table);
+
+static struct auxiliary_driver ltc4283_gpio_driver = {
+ .probe = ltc4283_gpio_probe,
+ .id_table = ltc4283_aux_id_table,
+};
+module_auxiliary_driver(ltc4283_gpio_driver);
+
+MODULE_AUTHOR("Nuno Sá <nuno.sa@analog.com>");
+MODULE_DESCRIPTION("GPIO LTC4283 Driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v9 0/3] hwmon: Add support for the LTC4283 Hot Swap Controller
From: Nuno Sá via B4 Relay @ 2026-04-06 14:31 UTC (permalink / raw)
To: linux-gpio, linux-hwmon, devicetree, linux-doc
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Linus Walleij, Bartosz Golaszewski,
Bartosz Golaszewski
This is v8 for the LTC4283 how swap controller.
Similar to the LTC4282 device, we're clearing some fault logs in the
reset_history attributes.
Guenter, for my last email worrying about rsense low values, this is
what I got internally:
"10uOhm at the smallest sense voltage of 15mV would be 1500A and 72kW, which
seems a tad excessive. The highest currents I’ve seen are around 200A, and
the -48V market 4283 serves is generally a lot lower than that. Normal values
are around 200uOhm. I’d say the resolution should be around 1uohm and if a
minimum is needed, 50uOhm is probably safe."
For the resolution, I'm pretty sure I got the tenths of micro
resolution for ltc4282 so I just kept it in here. So, if you don't mind
I would prefer to keep it this way to be safer and changing that now would
require me to change some formulas and I would prefer not to do that at
this stage.
---
Changes in v9:
- Patch 2:
* Add max and min rsense values to avoid 32bit overflows in power and
rsense * 256;
* Fix typo in ltc4283_read_in_alarm() s/LTC4283_CHAN_ADIN34/LTC4283_CHAN_ADIO34;
* Clamp 'val * MILLI' for LTC4283_ADC1_FS_uV in ltc4283_read_in_alarm();
* Adapt rsense default and property reading for the new range values.
* Properly construct an auxdev id from the i2c client.
- Link to v8: https://patch.msgid.link/20260327-ltc4283-support-v8-0-471de255d728@analog.com
---
---
Nuno Sá (3):
dt-bindings: hwmon: Document the LTC4283 Swap Controller
hwmon: ltc4283: Add support for the LTC4283 Swap Controller
gpio: gpio-ltc4283: Add support for the LTC4283 Swap Controller
.../devicetree/bindings/hwmon/adi,ltc4283.yaml | 272 +++
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/ltc4283.rst | 266 +++
MAINTAINERS | 9 +
drivers/gpio/Kconfig | 15 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ltc4283.c | 218 +++
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/ltc4283.c | 1808 ++++++++++++++++++++
10 files changed, 2603 insertions(+)
---
base-commit: 30a90fa04af6937493fbba20e3e923b5b5a162b4
change-id: 20260303-ltc4283-support-063f78acc5a4
--
Thanks!
- Nuno Sá
^ 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