* 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: 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 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 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 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 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 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 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 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
* [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 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
* Re: [PATCH v2 01/33] rust: kbuild: remove `--remap-path-prefix` workarounds
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-2-ojeda@kernel.org>
On Mon Apr 6, 2026 at 12:52 AM BST, Miguel Ojeda 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]:
>
> `--remap-path-scope` is only stable in Rust 1.95, so use `rustc-option`
> to detect its presence. This feature has been available as
> `-Zremap-path-scope` for all versions that we support; however due to
> bugs in the Rust compiler, it does not work reliably until 1.94. I opted
> to not enable it for 1.94 as it's just a single version that we missed.
>
> In turn, that means the workarounds removed here should not be needed
> again (even with the flag added again above), since:
>
> - `rustdoc` now recognizes the `--remap-path-prefix` flag since Rust
> 1.81.0 [3] (even if it is still an unstable feature [4]).
>
> - The Internal Compiler Error [5] that the comment mentions was fixed in
> Rust 1.87.0 [6]. We tested that was the case in a previous version
> of this series by making the workaround conditional [7][8].
>
> ...which are both older versions than Rust 1.95.0.
>
> We will still need to skip `--remap-path-scope` for `rustdoc` though,
> since `rustdoc` does not support that one yet [4].
>
> Link: https://github.com/rust-lang/rust/issues/111540 [1]
> Link: https://github.com/rust-lang/rust/pull/147611 [2]
> Link: https://github.com/rust-lang/rust/pull/107099 [3]
> Link: https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#--remap-path-prefix-remap-source-code-paths-in-output [4]
> Link: https://github.com/rust-lang/rust/issues/138520 [5]
> Link: https://github.com/rust-lang/rust/pull/138556 [6]
> Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-9-ojeda@kernel.org/ [7]
> Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-10-ojeda@kernel.org/ [8]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Gary Guo <gary@garyguo.net>
> ---
> rust/Makefile | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH 23/33] docs: rust: quick-start: update Ubuntu versioned packages
From: Miguel Ojeda @ 2026-04-06 0:14 UTC (permalink / raw)
To: Gary Guo, Fiona Behrens
Cc: Tamir Duberstein, 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, 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: <DHLMTLCY6U4N.3VOMQXRIT1RFY@garyguo.net>
On Mon, Apr 6, 2026 at 2:06 AM Gary Guo <gary@garyguo.net> wrote:
>
> It's still required.
Thanks for confirming!
> Perhaps having a repo in rust-for-linux GitHub org (or somewhere else in
> kernel.org SCM) where we can point people to?
...and for all these details :)
I agree that it doesn't fit perfectly within the kernel, but an update
every kernel cycle or so should be fine, I think, if you think that is
enough.
Otherwise, regarding the repository, that sounds great to me -- we
already had an old https://github.com/Rust-for-Linux/nix and
https://github.com/Rust-for-Linux/nixpkgs. Not sure if Fiona (Cc'd)
wants them, but perhaps you could reuse them (otherwise we should
archive them).
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 32/33] rust: kbuild: support global per-version flags
From: Gary Guo @ 2026-04-06 0:09 UTC (permalink / raw)
To: Miguel Ojeda, Gary Guo, Nathan Chancellor, Nicolas Schier
Cc: Miguel Ojeda, 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, 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: <CANiq72mTaA2tjhkLKf0-2hrrrt9rxWPgy6SfNSbponbGOegQvA@mail.gmail.com>
On Mon Apr 6, 2026 at 12:15 AM BST, Miguel Ojeda wrote:
> On Thu, Apr 2, 2026 at 12:28 AM Gary Guo <gary@garyguo.net> wrote:
>>
>> I think I would prefer moving these down.
>>
>> The current approach append the flags to all variables, which will cause the
>> following equivalence to stop holding after the flag update.
>>
>> KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
>> -Zallow-features= $(HOSTRUSTFLAGS)
>>
>> (Per version flags doesn't go before -O anymore, it comes after HOSTRUSTFLAGS).
>
> [ For context for others, Sashiko reported the same and we also talked
> about it in a Rust for Linux call. ]
>
> I have been thinking about this, and about potential other ways to
> achieve the same thing. I think the best at the moment is to move just
> the `$(HOSTRUSTFLAGS)` below, but not the rest.
>
> The reason is that it is closer to what we do with other user (kernel)
> flags (e.g. arch flags come after the general ones). But I am
> wondering if we should/could set all the user variables later in the
> `Makefile` in general `HOST*FLAGS` later in the `Makefile`.
>
> In fact, there is already a limitation with the host flags: `-Werror`,
> i.e. that one gets appended later, and so users cannot override it.
I cared a bit more about the code clarity (where appending to all variables
feel like a hack, while moving the code block is natural).
Best,
Gary
> [...]
>
> Anyway, for now I moved the expansion of `HOSTRUSTFLAGS` in v2. If
> Kbuild (Nathan, Nicolas) think it is a good idea to do one of the
> bigger changes (e.g. for more `HOST*` flags, appending it even later),
> then we can do it afterwards.
>
> Cheers,
> Miguel
^ permalink raw reply
* Re: [PATCH 23/33] docs: rust: quick-start: update Ubuntu versioned packages
From: Gary Guo @ 2026-04-06 0:06 UTC (permalink / raw)
To: Miguel Ojeda, 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: <CANiq72nqenC30r7QQAmdKxS8ehGU2SoSGr+LCnoTAGLegH-KnA@mail.gmail.com>
On Sun Apr 5, 2026 at 8:35 PM BST, Miguel Ojeda wrote:
> On Thu, Apr 2, 2026 at 1:01 AM Tamir Duberstein <tamird@kernel.org> wrote:
>>
>> RUST_LIB_SRC is also mentioned in the nix section, do you know if it is
>> still needed there?
>
> Yeah, that would be nice to know.
It's still required. It's used here:
https://github.com/NixOS/nixpkgs/blob/acf7ae578589bb8bdd6f9273141d7053fed84bed/pkgs/os-specific/linux/kernel/generic.nix#L186
>
> I tried on my own, and it does seem still required (at least with
> those packages mentioned in the example). But perhaps a Nix user knows
> of a better way to do it, anyway.
>
> So I kept it.
>
> By the way, I think it would be nice to have a "standard",
> well-maintained `shell.nix` (or a flake or whatever is best nowadays)
> in the kernel tree somewhere, i.e. one that is known to work, that
> covers most tooling used in the kernel, etc.
>
> Cheers,
> Miguel
I have my dev shell here in case it helps:
https://github.com/nbdd0121/nix-collection/blob/trunk/dev/linux.nix
It makes use of oxalica's rust-overlay. It can be used with shell.nix by a
fetchTarball, but for obvious reasons you want that to be pinned and not be
fetching latest version everytime.
Flake is good for pinning, but using flake is a two-edged sword -- it both gives
you superb reproducibility so years down the line you can still build an old
environment (assuming the source tarballs used are still available or NixOS
cache server still has a copy).
But it also means that it can be outdated. So people (myself included) usually
combine pinning + regular updating by having flake.lock routinely updated.
I'm not sure that really fits well inside kernel.
If we don't use anything outside nixpkgs though, we can use "channel" feature of
imperative nix which says `import <nixpkgs>` will import user's local nixpkgs
version. A shell.nix using only that should work, but it will only be able to
use latest rustc/clippy/cargo/bindgen in nixpkgs and won't be able to include
things like klint.
Perhaps having a repo in rust-for-linux GitHub org (or somewhere else in
kernel.org SCM) where we can point people to?
Best,
Gary
^ permalink raw reply
* [PATCH v2 33/33] rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
From: Miguel Ojeda @ 2026-04-05 23:53 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, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
The Clippy `precedence` lint was extended in Rust 1.85.0 to include
bitmasking and shift operations [1]. However, because it generated
many hits, in Rust 1.86.0 it was split into a new `precedence_bits`
lint which is not enabled by default [2].
In other words, only Rust 1.85 has a different behavior. For instance,
it reports:
warning: operator precedence can trip the unwary
--> drivers/gpu/nova-core/fb/hal/ga100.rs:16:5
|
16 | / u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT
17 | | | u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
18 | | << FLUSH_SYSMEM_ADDR_SHIFT_HI
| |_________________________________________^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
= note: `-W clippy::precedence` implied by `-W clippy::all`
= help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`
help: consider parenthesizing your expression
|
16 ~ (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT) | (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
17 + << FLUSH_SYSMEM_ADDR_SHIFT_HI)
|
While so far we try our best to keep all versions Clippy-clean, the
minimum (which is now Rust 1.85.0 after the bump) and the latest stable
are the most important ones; and this may be considered a "false positive"
with respect to the behavior in other versions.
Thus allow this lint for this version using the per-version flags
mechanism introduced in the previous commit.
Link: https://github.com/rust-lang/rust-clippy/issues/14097 [1]
Link: https://github.com/rust-lang/rust-clippy/pull/14115 [2]
Link: https://lore.kernel.org/rust-for-linux/DFVDKMMA7KPC.2DN0951H3H55Y@kernel.org/
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a305ae4be522..b8c38aa49cf4 100644
--- a/Makefile
+++ b/Makefile
@@ -838,7 +838,8 @@ export WARN_ON_UNUSED_TRACEPOINTS
# Per-version Rust flags. These are like `rust_common_flags`, but may
# depend on the Rust compiler version (e.g. using `rustc-min-version`).
-rust_common_flags_per_version :=
+rust_common_flags_per_version := \
+ $(if $(call rustc-min-version,108600),,-Aclippy::precedence)
rust_common_flags += $(rust_common_flags_per_version)
KBUILD_HOSTRUSTFLAGS += $(rust_common_flags_per_version) $(HOSTRUSTFLAGS)
--
2.53.0
^ permalink raw reply related
* [PATCH v2 32/33] rust: kbuild: support global per-version flags
From: Miguel Ojeda @ 2026-04-05 23:53 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-1-ojeda@kernel.org>
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.
Thus, to support that, introduce `rust_common_flags_per_version`,
defined after the `include/config/auto.conf` inclusion (where
`CONFIG_RUSTC_VERSION` becomes available), and append it to
`rust_common_flags`, `KBUILD_HOSTRUSTFLAGS` and `KBUILD_RUSTFLAGS`.
In addition, move the expansion of `HOSTRUSTFLAGS` to the same place,
so that users can also override per-version flags [2].
Link: https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1]
Link: https://lore.kernel.org/rust-for-linux/CANiq72mTaA2tjhkLKf0-2hrrrt9rxWPgy6SfNSbponbGOegQvA@mail.gmail.com/ [2]
Link: https://patch.msgid.link/20260307170929.153892-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Makefile | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 78f5ee173eda..a305ae4be522 100644
--- a/Makefile
+++ b/Makefile
@@ -506,7 +506,7 @@ KBUILD_HOSTCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) \
KBUILD_HOSTCXXFLAGS := -Wall -O2 $(HOST_LFS_CFLAGS) $(HOSTCXXFLAGS) \
-I $(srctree)/scripts/include
KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
- -Zallow-features= $(HOSTRUSTFLAGS)
+ -Zallow-features=
KBUILD_HOSTLDFLAGS := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS)
KBUILD_HOSTLDLIBS := $(HOST_LFS_LIBS) $(HOSTLDLIBS)
KBUILD_PROCMACROLDFLAGS := $(or $(PROCMACROLDFLAGS),$(KBUILD_HOSTLDFLAGS))
@@ -836,6 +836,14 @@ endif # CONFIG_TRACEPOINTS
export WARN_ON_UNUSED_TRACEPOINTS
+# Per-version Rust flags. These are like `rust_common_flags`, but may
+# depend on the Rust compiler version (e.g. using `rustc-min-version`).
+rust_common_flags_per_version :=
+
+rust_common_flags += $(rust_common_flags_per_version)
+KBUILD_HOSTRUSTFLAGS += $(rust_common_flags_per_version) $(HOSTRUSTFLAGS)
+KBUILD_RUSTFLAGS += $(rust_common_flags_per_version)
+
include $(srctree)/arch/$(SRCARCH)/Makefile
ifdef need-config
--
2.53.0
^ permalink raw reply related
* [PATCH v2 31/33] rust: declare cfi_encoding for lru_status
From: Miguel Ojeda @ 2026-04-05 23:53 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-1-ojeda@kernel.org>
From: Alice Ryhl <aliceryhl@google.com>
By default bindgen will convert 'enum lru_status' into a typedef for an
integer. For the most part, an integer of the same size as the enum
results in the correct ABI, but in the specific case of CFI, that is not
the case. The CFI encoding is supposed to be the same as a struct called
'lru_status' rather than the name of the underlying native integer type.
To fix this, tell bindgen to generate a newtype and set the CFI type
explicitly. Note that we need to set the CFI attribute explicitly as
bindgen is using repr(transparent), which is otherwise identical to the
inner type for ABI purposes.
This allows us to remove the page range helper C function in Binder
without risking a CFI failure when list_lru_walk calls the provided
function pointer.
The --with-attribute-custom-enum argument requires bindgen v0.71 or
greater.
[ In particular, the feature was added in 0.71.0 [1][2].
In addition, `feature(cfi_encoding)` has been available since
Rust 1.71.0 [3].
Link: https://github.com/rust-lang/rust-bindgen/issues/2520 [1]
Link: https://github.com/rust-lang/rust-bindgen/pull/2866 [2]
Link: https://github.com/rust-lang/rust/pull/105452 [3]
- Miguel ]
My testing procedure was to add this to the android17-6.18 branch and
verify that rust_shrink_free_page is successfully called without crash,
and verify that it does in fact crash when the cfi_encoding is set to
other values. Note that I couldn't test this on android16-6.12 as that
branch uses a bindgen version that is too old.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260223-cfi-lru-status-v2-1-89c6448a63a4@google.com
Reviewed-by: Gary Guo <gary@garyguo.net>
[ Rebased on top of the minimum Rust version bump series which provide
the required `bindgen` version. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
drivers/android/binder/Makefile | 3 +--
drivers/android/binder/page_range.rs | 6 +++---
drivers/android/binder/page_range_helper.c | 24 ----------------------
drivers/android/binder/page_range_helper.h | 15 --------------
rust/bindgen_parameters | 4 ++++
rust/bindings/bindings_helper.h | 1 -
rust/bindings/lib.rs | 1 +
rust/uapi/lib.rs | 1 +
8 files changed, 10 insertions(+), 45 deletions(-)
delete mode 100644 drivers/android/binder/page_range_helper.c
delete mode 100644 drivers/android/binder/page_range_helper.h
diff --git a/drivers/android/binder/Makefile b/drivers/android/binder/Makefile
index 09eabb527fa0..7e0cd9782a8b 100644
--- a/drivers/android/binder/Makefile
+++ b/drivers/android/binder/Makefile
@@ -5,5 +5,4 @@ obj-$(CONFIG_ANDROID_BINDER_IPC_RUST) += rust_binder.o
rust_binder-y := \
rust_binder_main.o \
rust_binderfs.o \
- rust_binder_events.o \
- page_range_helper.o
+ rust_binder_events.o
diff --git a/drivers/android/binder/page_range.rs b/drivers/android/binder/page_range.rs
index fdd97112ef5c..8e9f5c4819d0 100644
--- a/drivers/android/binder/page_range.rs
+++ b/drivers/android/binder/page_range.rs
@@ -642,15 +642,15 @@ fn drop(self: Pin<&mut Self>) {
unsafe {
bindings::list_lru_walk(
list_lru,
- Some(bindings::rust_shrink_free_page_wrap),
+ Some(rust_shrink_free_page),
ptr::null_mut(),
nr_to_scan,
)
}
}
-const LRU_SKIP: bindings::lru_status = bindings::lru_status_LRU_SKIP;
-const LRU_REMOVED_ENTRY: bindings::lru_status = bindings::lru_status_LRU_REMOVED_RETRY;
+const LRU_SKIP: bindings::lru_status = bindings::lru_status::LRU_SKIP;
+const LRU_REMOVED_ENTRY: bindings::lru_status = bindings::lru_status::LRU_REMOVED_RETRY;
/// # Safety
/// Called by the shrinker.
diff --git a/drivers/android/binder/page_range_helper.c b/drivers/android/binder/page_range_helper.c
deleted file mode 100644
index 496887723ee0..000000000000
--- a/drivers/android/binder/page_range_helper.c
+++ /dev/null
@@ -1,24 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-/* C helper for page_range.rs to work around a CFI violation.
- *
- * Bindgen currently pretends that `enum lru_status` is the same as an integer.
- * This assumption is fine ABI-wise, but once you add CFI to the mix, it
- * triggers a CFI violation because `enum lru_status` gets a different CFI tag.
- *
- * This file contains a workaround until bindgen can be fixed.
- *
- * Copyright (C) 2025 Google LLC.
- */
-#include "page_range_helper.h"
-
-unsigned int rust_shrink_free_page(struct list_head *item,
- struct list_lru_one *list,
- void *cb_arg);
-
-enum lru_status
-rust_shrink_free_page_wrap(struct list_head *item, struct list_lru_one *list,
- void *cb_arg)
-{
- return rust_shrink_free_page(item, list, cb_arg);
-}
diff --git a/drivers/android/binder/page_range_helper.h b/drivers/android/binder/page_range_helper.h
deleted file mode 100644
index 18dd2dd117b2..000000000000
--- a/drivers/android/binder/page_range_helper.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (C) 2025 Google, Inc.
- */
-
-#ifndef _LINUX_PAGE_RANGE_HELPER_H
-#define _LINUX_PAGE_RANGE_HELPER_H
-
-#include <linux/list_lru.h>
-
-enum lru_status
-rust_shrink_free_page_wrap(struct list_head *item, struct list_lru_one *list,
- void *cb_arg);
-
-#endif /* _LINUX_PAGE_RANGE_HELPER_H */
diff --git a/rust/bindgen_parameters b/rust/bindgen_parameters
index 112ec197ef0a..6f02d9720ad2 100644
--- a/rust/bindgen_parameters
+++ b/rust/bindgen_parameters
@@ -19,6 +19,10 @@
# warning. We don't need to peek into it anyway.
--opaque-type spinlock
+# enums that appear in indirect function calls should specify a cfi type
+--newtype-enum lru_status
+--with-attribute-custom-enum=lru_status='#[cfi_encoding="10lru_status"]'
+
# `seccomp`'s comment gets understood as a doctest
--no-doc-comments
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 083cc44aa952..faf3ee634ced 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -149,5 +149,4 @@ const vm_flags_t RUST_CONST_HELPER_VM_NOHUGEPAGE = VM_NOHUGEPAGE;
#if IS_ENABLED(CONFIG_ANDROID_BINDER_IPC_RUST)
#include "../../drivers/android/binder/rust_binder.h"
#include "../../drivers/android/binder/rust_binder_events.h"
-#include "../../drivers/android/binder/page_range_helper.h"
#endif
diff --git a/rust/bindings/lib.rs b/rust/bindings/lib.rs
index e18c160dad17..854e7c471434 100644
--- a/rust/bindings/lib.rs
+++ b/rust/bindings/lib.rs
@@ -19,6 +19,7 @@
unreachable_pub,
unsafe_op_in_unsafe_fn
)]
+#![feature(cfi_encoding)]
#[allow(dead_code)]
#[allow(clippy::cast_lossless)]
diff --git a/rust/uapi/lib.rs b/rust/uapi/lib.rs
index 821e286e0daa..b8a515de31ca 100644
--- a/rust/uapi/lib.rs
+++ b/rust/uapi/lib.rs
@@ -24,6 +24,7 @@
unsafe_op_in_unsafe_fn
)]
#![cfg_attr(CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES, allow(unnecessary_transmutes))]
+#![feature(cfi_encoding)]
// Manual definition of blocklisted types.
type __kernel_size_t = usize;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 30/33] docs: rust: general-information: use real example
From: Miguel Ojeda @ 2026-04-05 23:53 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, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
Currently the example in the documentation shows a version-based name
for the Kconfig example:
RUSTC_VERSION_MIN_107900
The reason behind it was to possibly avoid repetition in case several
features used the same minimum.
However, we ended up preferring to give them a descriptive name for each
feature added even if that could lead to some repetition. In practice,
the repetition has not happened so far, and even if it does at some point,
it is not a big deal.
Thus replace the example in the documentation with one of our current
examples (after removing previous ones from the bump), to show how they
actually look like, and in case someone `grep`s for it.
In addition, it has the advantage that it shows the `RUSTC_HAS_*`
pattern we follow in `init/Kconfig`, similar to the C side.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/rust/general-information.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rust/general-information.rst b/Documentation/rust/general-information.rst
index 91535b2306ed..09234bed272c 100644
--- a/Documentation/rust/general-information.rst
+++ b/Documentation/rust/general-information.rst
@@ -157,5 +157,5 @@ numerical comparisons, one may define a new Kconfig symbol:
.. code-block:: kconfig
- config RUSTC_VERSION_MIN_107900
- def_bool RUSTC_VERSION >= 107900
+ config RUSTC_HAS_SPAN_FILE
+ def_bool RUSTC_VERSION >= 108800
--
2.53.0
^ permalink raw reply related
* [PATCH v2 29/33] docs: rust: general-information: simplify Kconfig example
From: Miguel Ojeda @ 2026-04-05 23:53 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, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
There is no need to use `def_bool y if <expr>` -- one can simply write
`def_bool <expr>`.
In fact, the simpler form is how we actually use them in practice in
`init/Kconfig`.
Thus simplify the example.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/rust/general-information.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/rust/general-information.rst b/Documentation/rust/general-information.rst
index 6146b49b6a98..91535b2306ed 100644
--- a/Documentation/rust/general-information.rst
+++ b/Documentation/rust/general-information.rst
@@ -158,4 +158,4 @@ numerical comparisons, one may define a new Kconfig symbol:
.. code-block:: kconfig
config RUSTC_VERSION_MIN_107900
- def_bool y if RUSTC_VERSION >= 107900
+ def_bool RUSTC_VERSION >= 107900
--
2.53.0
^ permalink raw reply related
* [PATCH v2 28/33] docs: rust: quick-start: remove GDB/Binutils mention
From: Miguel Ojeda @ 2026-04-05 23:53 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, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
The versions provided nowadays by even a distribution like Debian Stable
(and Debian Old Stable) are newer than those mentioned [1].
Thus remove the workaround.
Note that the minimum binutils version in the kernel is still 2.30, so
one could argue part of the note is still relevant, but it is unlikely
a kernel developer using such an old binutils is enabling Rust on a
modern kernel, especially when using distribution toolchains, e.g. the
Rust minimum version is not satisfied by Debian Old Stable.
So we are at the point where keeping the docs short and relevant for
essentially everyone is probably the better trade-off.
Link: https://packages.debian.org/search?suite=all&searchon=names&keywords=binutils [1]
Link: https://lore.kernel.org/all/CANiq72mCpc9=2TN_zC4NeDMpFQtPXAFvyiP+gRApg2vzspPWmw@mail.gmail.com/
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/rust/quick-start.rst | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index 5bbe059a8fa3..a6ec3fa94d33 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -352,12 +352,3 @@ Hacking
To dive deeper, take a look at the source code of the samples
at ``samples/rust/``, the Rust support code under ``rust/`` and
the ``Rust hacking`` menu under ``Kernel hacking``.
-
-If GDB/Binutils is used and Rust symbols are not getting demangled, the reason
-is the toolchain does not support Rust's new v0 mangling scheme yet.
-There are a few ways out:
-
-- Install a newer release (GDB >= 10.2, Binutils >= 2.36).
-
-- Some versions of GDB (e.g. vanilla GDB 10.1) are able to use
- the pre-demangled names embedded in the debug info (``CONFIG_DEBUG_INFO``).
--
2.53.0
^ permalink raw reply related
* [PATCH v2 27/33] docs: rust: quick-start: remove Nix "unstable channel" note
From: Miguel Ojeda @ 2026-04-05 23:53 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, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
Nix does not need the "unstable channel" note, since its packages are
recent enough even in the stable channel [1][2].
Thus remove it to simplify the documentation.
Link: https://search.nixos.org/packages?channel=25.11&query=rust [1]
Link: https://search.nixos.org/packages?channel=25.11&query=bindgen [2]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/rust/quick-start.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index 1518367324fe..5bbe059a8fa3 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -68,8 +68,8 @@ of the box, e.g.::
Nix
***
-Nix (unstable channel) provides recent Rust releases and thus it should
-generally work out of the box, e.g.::
+Nix provides recent Rust releases and thus it should generally work out of the
+box, e.g.::
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 26/33] docs: rust: quick-start: remove Gentoo "testing" note
From: Miguel Ojeda @ 2026-04-05 23:53 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, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
Gentoo does not need the "testing" note, since its packages are recent
enough even in the stable branch [1][2].
Thus remove it to simplify the documentation.
Link: https://packages.gentoo.org/packages/dev-lang/rust [1]
Link: https://packages.gentoo.org/packages/dev-util/bindgen [2]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/rust/quick-start.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index db08c3a03a4f..1518367324fe 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -57,8 +57,8 @@ of the box, e.g.::
Gentoo Linux
************
-Gentoo Linux (and especially the testing branch) provides recent Rust releases
-and thus it should generally work out of the box, e.g.::
+Gentoo Linux provides recent Rust releases and thus it should generally work out
+of the box, e.g.::
USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen
--
2.53.0
^ permalink raw reply related
* [PATCH v2 25/33] docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection title
From: Miguel Ojeda @ 2026-04-05 23:53 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, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few
weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu
25.10 has [2][3].
We could update the title and the paragraph, but to simplify and to
make it more consistent with the other distributions' sections, let's
instead just remove that title. It will also reduce the differences
later on to keep it updated. Eventually, when we remove the remaining
subsection for older LTSs, Ubuntu should be a small section like the
other distributions.
Thus remove the title and add the mention of Ubuntu 26.04 LTS.
Link: https://documentation.ubuntu.com/release-notes/26.04/schedule/#resolute-raccoon-schedule [1]
Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all§ion=all [2]
Link: https://packages.ubuntu.com/search?keywords=bindgen&searchon=names&exact=1&suite=all§ion=all [3]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/rust/quick-start.rst | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index 34c39f208333..db08c3a03a4f 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -90,10 +90,7 @@ they should generally work out of the box, e.g.::
Ubuntu
******
-25.10
-~~~~~
-
-The latest Ubuntu releases provide recent Rust releases and thus they should
+Ubuntu 25.10 and 26.04 LTS provide recent Rust releases and thus they should
generally work out of the box, e.g.::
apt install rustc rust-src bindgen rustfmt rust-clippy
--
2.53.0
^ permalink raw reply related
* [PATCH v2 24/33] docs: rust: quick-start: update minimum Ubuntu version
From: Miguel Ojeda @ 2026-04-05 23:53 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, Tamir Duberstein
In-Reply-To: <20260405235309.418950-1-ojeda@kernel.org>
Ubuntu 25.04 is out of support [1], and Ubuntu 25.10 is the latest
supported one.
Moreover, Ubuntu 25.10 is the first that provides a recent enough Rust
given the minimum bump -- they provide 1.85.1 [2].
Thus update it.
Link: https://ubuntu.com/about/release-cycle [1]
Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all§ion=all [2]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/rust/quick-start.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index 54fe491deb7d..34c39f208333 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -90,7 +90,7 @@ they should generally work out of the box, e.g.::
Ubuntu
******
-25.04
+25.10
~~~~~
The latest Ubuntu releases provide recent Rust releases and thus they should
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox