* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Arnd Bergmann @ 2026-04-01 14:56 UTC (permalink / raw)
To: Lorenzo Pieralisi, Shivendra Pratap
Cc: Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, André Draszik, Kathiravan Thirumoorthy,
linux-pm, linux-kernel, linux-arm-kernel, linux-arm-msm,
devicetree, Srinivas Kandagatla
In-Reply-To: <ac0trUGsRBLPS+ux@lpieralisi>
On Wed, Apr 1, 2026, at 16:37, Lorenzo Pieralisi wrote:
> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>>
>> > > +#include <linux/err.h>
>> > > +#include <linux/of.h>
>> > > +#include <linux/psci.h>
>> > > +#include <linux/reboot.h>
>> > > +#include <linux/reboot-mode.h>
>> > > +#include <linux/types.h>
>> > > +
>> > > +/*
>> > > + * Predefined reboot-modes are defined as per the values
>> > > + * of enum reboot_mode defined in the kernel: reboot.c.
>> > > + */
>> > > +static struct mode_info psci_resets[] = {
>> > > + { .mode = "warm", .magic = REBOOT_WARM},
>> > > + { .mode = "soft", .magic = REBOOT_SOFT},
>> > > + { .mode = "cold", .magic = REBOOT_COLD},
>
> These strings match the command userspace issue right ? I think that we
> should make them match the corresponding PSCI reset types, the list above
> maps command to reboot_mode values and those can belong to any reboot
> mode driver to be honest they don't make much sense in a PSCI reboot
> mode driver only.
>
> It is a question for everyone here: would it make sense to make these
> predefined resets a set of strings, eg:
>
> psci-system-reset
> psci-system-reset2-arch-warm-reset
>
> and then vendor resets:
>
> psci-system-reset2-vendor-reset
>
> at least we know what a string maps to ?
>
> We can export a function from the PSCI driver to detect whether PSCI
> SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
> instance that we can call from this driver to detect its presence.
Sorry I've been out of the loop for this series for a while, but
can someone refresh me on why we got back to mixing in
the 'enum reboot_mode' from legacy i386 and arm32 into the new
interface?
I don't mind having whichever strings are defined for PSCI present
in the user interface, but this seems like a mistake to me.
If at all possible, lets define your own magic constants that
are not tied to "enum reboot_mode" or the legacy reboot= command
line argument.
Arnd
^ permalink raw reply
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Benno Lossin @ 2026-04-01 14:57 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, 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: <20260401114540.30108-2-ojeda@kernel.org>
On Wed Apr 1, 2026 at 1:45 PM CEST, Miguel Ojeda 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's release happened on 2025-08-09 [4], 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 version.
>
> Then, in later commits, clean up most of the workarounds and other bits
> that this upgrade of the minimum allows us.
>
> pin-init was left as-is since the patches come from upstream. And the
> vendored crates are unmodified, since we do not want to change those.
>
> Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the
> Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION`
> tests can also be updated, but there are no suitable ones to simplify.
>
> Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also
> provide versioned packages with a Rust 1.85.1 toolchain even back to
> Ubuntu 22.04 LTS [6].
>
> 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://www.debian.org/releases/trixie/ [4]
> Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]
> Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [6]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Very happy to see this!
Acked-by: Benno Lossin <lossin@kernel.org>
Cheers,
Benno
> ---
> Documentation/process/changes.rst | 2 +-
> scripts/min-tool-version.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 15/33] rust: rust_is_available: remove warning for 0.66.[01] buggy versions
From: Gary Guo @ 2026-04-01 14:58 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: <20260401114540.30108-16-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> It is not possible anymore to fall into the issue that this warning was
> alerting about given the `bindgen` version bump.
>
> Thus simplify by removing the machinery behind it, including tests.
The scripts/rust_is_available.sh change looks correct to me, although I couldn't
get scripts/rust_is_available_test.py to run on NixOS.
Looks like it filtered out PATH but uses /usr/bin/env to find python binary? For
obvious reasons that will only work if python is located /usr/bin/python.
Best,
Gary
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> scripts/rust_is_available.sh | 13 ------------
> scripts/rust_is_available_bindgen_0_66.h | 2 --
> scripts/rust_is_available_test.py | 26 +++---------------------
> 3 files changed, 3 insertions(+), 38 deletions(-)
> delete mode 100644 scripts/rust_is_available_bindgen_0_66.h
>
> diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
> index d2323de0692c..77896e31dab5 100755
> --- a/scripts/rust_is_available.sh
> +++ b/scripts/rust_is_available.sh
> @@ -163,19 +163,6 @@ if [ "$rust_bindings_generator_cversion" -lt "$rust_bindings_generator_min_cvers
> echo >&2 "***"
> exit 1
> fi
> -if [ "$rust_bindings_generator_cversion" -eq 6600 ] ||
> - [ "$rust_bindings_generator_cversion" -eq 6601 ]; then
> - # Distributions may have patched the issue (e.g. Debian did).
> - if ! "$BINDGEN" $(dirname $0)/rust_is_available_bindgen_0_66.h >/dev/null; then
> - echo >&2 "***"
> - echo >&2 "*** Rust bindings generator '$BINDGEN' versions 0.66.0 and 0.66.1 may not"
> - echo >&2 "*** work due to a bug (https://github.com/rust-lang/rust-bindgen/pull/2567),"
> - echo >&2 "*** unless patched (like Debian's)."
> - echo >&2 "*** Your version: $rust_bindings_generator_version"
> - echo >&2 "***"
> - warning=1
> - fi
> -fi
>
> # Check that the `libclang` used by the Rust bindings generator is suitable.
> #
> diff --git a/scripts/rust_is_available_bindgen_0_66.h b/scripts/rust_is_available_bindgen_0_66.h
> deleted file mode 100644
> index c0431293421c..000000000000
> --- a/scripts/rust_is_available_bindgen_0_66.h
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -#define A "\0"
> diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
> index 4fcc319dea84..b66fa5933844 100755
> --- a/scripts/rust_is_available_test.py
> +++ b/scripts/rust_is_available_test.py
> @@ -54,17 +54,12 @@ else:
> """)
>
> @classmethod
> - def generate_bindgen(cls, version_stdout, libclang_stderr, version_0_66_patched=False, libclang_concat_patched=False):
> + def generate_bindgen(cls, version_stdout, libclang_stderr, libclang_concat_patched=False):
> if libclang_stderr is None:
> libclang_case = f"raise SystemExit({cls.bindgen_default_bindgen_libclang_failure_exit_code})"
> else:
> libclang_case = f"print({repr(libclang_stderr)}, file=sys.stderr)"
>
> - if version_0_66_patched:
> - version_0_66_case = "pass"
> - else:
> - version_0_66_case = "raise SystemExit(1)"
> -
> if libclang_concat_patched:
> libclang_concat_case = "print('pub static mut foofoo: ::std::os::raw::c_int;')"
> else:
> @@ -74,8 +69,6 @@ else:
> import sys
> if "rust_is_available_bindgen_libclang.h" in " ".join(sys.argv):
> {libclang_case}
> -elif "rust_is_available_bindgen_0_66.h" in " ".join(sys.argv):
> - {version_0_66_case}
> elif "rust_is_available_bindgen_libclang_concat.h" in " ".join(sys.argv):
> {libclang_concat_case}
> else:
> @@ -83,8 +76,8 @@ else:
> """)
>
> @classmethod
> - def generate_bindgen_version(cls, stdout, version_0_66_patched=False):
> - return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr, version_0_66_patched)
> + def generate_bindgen_version(cls, stdout):
> + return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr)
>
> @classmethod
> def generate_bindgen_libclang_failure(cls):
> @@ -245,19 +238,6 @@ else:
> result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
> self.assertIn(f"Rust bindings generator '{bindgen}' is too old.", result.stderr)
>
> - def test_bindgen_bad_version_0_66_0_and_0_66_1(self):
> - for version in ("0.66.0", "0.66.1"):
> - with self.subTest(version=version):
> - bindgen = self.generate_bindgen_version(f"bindgen {version}")
> - result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
> - self.assertIn(f"Rust bindings generator '{bindgen}' versions 0.66.0 and 0.66.1 may not", result.stderr)
> -
> - def test_bindgen_bad_version_0_66_0_and_0_66_1_patched(self):
> - for version in ("0.66.0", "0.66.1"):
> - with self.subTest(version=version):
> - bindgen = self.generate_bindgen_version(f"bindgen {version}", True)
> - result = self.run_script(self.Expected.SUCCESS, { "BINDGEN": bindgen })
> -
> def test_bindgen_libclang_failure(self):
> bindgen = self.generate_bindgen_libclang_failure()
> result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
^ permalink raw reply
* RE: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux
From: Erim, Salih @ 2026-04-01 15:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Simek, Michal, Jonathan Cameron, Christofer Jonason,
O'Griofa, Conall, lars@metafoo.de, dlechner@baylibre.com,
nuno.sa@analog.com, andy@kernel.org,
victor.jonsson@guidelinegeo.com, linux-iio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <CAHp75Vcg1u86z_TWwz+1Gk9QQ9RB63QmNcqpkGa5HQHZhSE=5Q@mail.gmail.com>
Hi Andy,
...
> On Wed, Apr 1, 2026 at 4:58 PM Erim, Salih <Salih.Erim@amd.com> wrote:
> > > -----Original Message-----
> > > From: Erim, Salih <Salih.Erim@amd.com>
> > > Sent: Wednesday, April 1, 2026 2:13 PM
>
>
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > I am deeply sorry about these markings. Please try to ignore them, and I will do
> my best to escape from them.
>
> Maybe, but ignoring them might be subject to law enforcement or other legal actions.
> You must get rid of them for your OSS contributions.
You are right, My mistake is replying OSS emails with Outlook, it does marking automatically.
I need to start using another email - mutt, thunderbird etc. Thanks for the warning.
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks,
Salih.
^ permalink raw reply
* Re: [PATCH 17/33] rust: kbuild: update `bindgen --rust-target` version and replace comment
From: Gary Guo @ 2026-04-01 15:05 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: <20260401114540.30108-18-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> As the comment in the `Makefile` explains, previously, we needed to
> limit ourselves to the list of Rust versions known by `bindgen` for its
> `--rust-target` option.
>
> In other words, we needed to consult the versions known by the minimum
> version of `bindgen` that we supported.
>
> Now that we bumped the minimum version of `bindgen`, that limitation
> does not apply anymore.
>
> Thus replace the comment and simply write our minimum supported Rust
> version there, which is much simpler.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/Makefile | 16 ++--------------
> 1 file changed, 2 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH 18/33] rust: kbuild: remove "dummy parameter" workaround for `bindgen` < 0.71.1
From: Gary Guo @ 2026-04-01 15:05 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: <20260401114540.30108-19-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> Until the version bump of `bindgen`, we needed to pass a dummy parameter
> to avoid failing the `--version` call.
>
> Thus remove it.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> init/Kconfig | 7 +------
> scripts/rust_is_available.sh | 8 +-------
> 2 files changed, 2 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [PATCH 19/33] rust: kbuild: remove "`try` keyword" workaround for `bindgen` < 0.59.2
From: Gary Guo @ 2026-04-01 15:05 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: <20260401114540.30108-20-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> There is a workaround that has not been needed, even already after commit
> 08ab786556ff ("rust: bindgen: upgrade to 0.65.1"), but it does not hurt.
>
> Thus remove it.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/bindgen_parameters | 4 ----
> 1 file changed, 4 deletions(-)
^ permalink raw reply
* Re: [PATCH 20/33] rust: kbuild: remove unneeded old `allow`s for generated layout tests
From: Gary Guo @ 2026-04-01 15:05 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: <20260401114540.30108-21-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> The issue that required `allow`s for `cfg(test)` code generated by
> `bindgen` for layout testing was fixed back in `bindgen` 0.60.0 [1],
> so it could have been removed even before the version bump, but it does
> not hurt.
>
> Thus remove it now.
>
> Link: https://github.com/rust-lang/rust-bindgen/pull/2203 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/bindings/lib.rs | 4 ----
> rust/uapi/lib.rs | 4 ----
> 2 files changed, 8 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 0/6] drm/sun4i: Support LVDS on D1s/T113 combo D-PHY
From: Kuba Szczodrzyński @ 2026-04-01 15:04 UTC (permalink / raw)
To: Parthiban, Maxime Ripard, Samuel Holland, Chen-Yu Tsai,
Jernej Skrabec, Maarten Lankhorst, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: David Airlie, Simona Vetter, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv, linux-phy, devicetree, dri-devel,
paulk
In-Reply-To: <1027afd7-dec6-4ff3-85eb-2d9a1646ada6@linumiz.com>
Hi,
W dniu 2026-04-01 o 10:39:42, Parthiban pisze:
> Dear Kuba,
>
> On 2/7/26 2:34 PM, Parthiban wrote:
>> On 11/16/25 2:46 PM, Kuba Szczodrzyński wrote:
>>> Some Allwinner chips (notably the D1s/T113 and the A100) have a "combo
>>> MIPI DSI D-PHY" which is required when using single-link LVDS0. The same
>>> PD0..PD9 pins are used for either DSI or LVDS.
>>>
>>> Other than having to use the combo D-PHY, LVDS output is configured in
>>> the same way as on older chips.
>>>
>>> This series enables the sun6i MIPI D-PHY to also work in LVDS mode. It
>>> is then configured by the LCD TCON, which allows connecting a
>>> single-link LVDS display panel.
> Now I also have the MIPI and LVDS working together on A133. Can I pick your
> changes and post a combined series for the display support for A133? This will
> also address D1s/T114 as well.
I guess it's been waiting for too long anyway - so yes, if you know how
to push it further, then please do so.
Regards Kuba
> --
> Thanks,
> Parthiban
> https://linumiz.com
> https://www.linkedin.com/company/linumiz
^ permalink raw reply
* Re: [PATCH 21/33] gpu: nova-core: bindings: remove unneeded `cfg_attr`
From: Gary Guo @ 2026-04-01 15:08 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: <20260401114540.30108-22-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> These were likely copied from the `bindings` and `uapi` crates, but are
> unneeded since there are no `cfg(test)`s in the bindings.
>
> In addition, the issue that triggered the addition in those crates
> originally is also fixed in `bindgen` (please see the previous commit).
>
> Thus remove them.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> drivers/gpu/nova-core/gsp/fw/r570_144.rs | 3 ---
I believe drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs is generated
manually and checked in to the source tree? It might be useful to actually have
the command line and bindgen version used to generate the file present
somewhere for knowing about possible compatibility issues like this one and
reproducibility..
Best,
Gary
> 1 file changed, 3 deletions(-)
^ permalink raw reply
* Re: [PATCH 27/33] docs: rust: quick-start: remove Nix "unstable channel" note
From: Gary Guo @ 2026-04-01 15:10 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: <20260401114540.30108-28-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> 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]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/rust/quick-start.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 28/33] docs: rust: quick-start: remove GDB/Binutils mention
From: Gary Guo @ 2026-04-01 15:15 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: <20260401114540.30108-29-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> 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.
I suppose people could have been using an old LTS distro + rustup and run into
this issue. Albeit it's probably quite unlikely.
Reviewed-by: Gary Guo <gary@garyguo.net>
>
> 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/
> 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``).
^ permalink raw reply
* Re: [PATCH 29/33] docs: rust: general-information: simplify Kconfig example
From: Gary Guo @ 2026-04-01 15:16 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: <20260401114540.30108-30-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> 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.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/rust/general-information.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 30/33] docs: rust: general-information: use real example
From: Gary Guo @ 2026-04-01 15:16 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: <20260401114540.30108-31-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> 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.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/rust/general-information.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH v20 01/10] power: reset: reboot-mode: Remove devres based allocations
From: Krzysztof Kozlowski @ 2026-04-01 15:19 UTC (permalink / raw)
To: Shivendra Pratap, Lorenzo Pieralisi, Arnd Bergmann,
Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla
Cc: Florian Fainelli, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Kathiravan Thirumoorthy, linux-pm, linux-kernel, linux-arm-kernel,
linux-arm-msm, devicetree, Srinivas Kandagatla
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-1-cf7d346b8372@oss.qualcomm.com>
On 04/03/2026 19:03, Shivendra Pratap wrote:
> Devres APIs are intended for use in drivers, where the managed lifetime
> of resources is tied directly to the driver attach/detach cycle. In
> shared subsystem code, there is no guarantee that the subsystem
> functions will only be called after a driver has been attached, nor that
> they will not be referenced after the managed resources have been
> released during driver detach.
>
> To ensure correct lifetime handling, avoid using devres-based
> allocations in the reboot-mode and explicitly handle allocation and
> cleanup of resources.
>
> Fixes: 4fcd504edbf7 ("power: reset: add reboot mode driver")
I don't think this is correct tag.
That commit added code which was a driver, not subsystem level things.
Using devres, as you pointed out, in platform_driver is correct.
Otherwise please specify what bug from that commit is being fixed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 31/33] rust: declare cfi_encoding for lru_status
From: Gary Guo @ 2026-04-01 15:20 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: <20260401114540.30108-32-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> 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
> [ 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>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> 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
^ permalink raw reply
* Re: [PATCH 32/33] rust: kbuild: support global per-version flags
From: Gary Guo @ 2026-04-01 15:26 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: <20260401114540.30108-33-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda 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.
>
> 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`.
>
> An alternative is moving all those three down, but that would mean
> separating them from the other `KBUILD_*` variables.
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).
Best,
Gary
>
> Link: https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1]
> Link: https://patch.msgid.link/20260307170929.153892-1-ojeda@kernel.org
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> Makefile | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 1a219bf1c771..20c8179d96ee 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -834,6 +834,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)
> +KBUILD_RUSTFLAGS += $(rust_common_flags_per_version)
> +
> include $(srctree)/arch/$(SRCARCH)/Makefile
>
> ifdef need-config
^ permalink raw reply
* Re: Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Liviu Dudau @ 2026-04-01 15:26 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB4707335CC7035232D44E6ED9F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On Wed, Apr 01, 2026 at 10:31:01AM +0000, Guangliu Ding wrote:
> Hi Liviu
>
> > On Wed, Apr 01, 2026 at 09:43:12AM +0000, Guangliu Ding wrote:
> > > Hi Daniel
> > >
> > > > On 4/1/26 11:48, Guangliu Ding wrote:
> > > > > [You don't often get email from guangliu.ding@nxp.com. Learn why
> > > > > this is important at https://aka.ms/LearnAboutSenderIdentification
> > > > > ]
> > > > >
> > > > > Hi Liviu
> > > > >
> > > > > Thanks for your review. Please refer to my comments below:
> > > > >
> > > > >> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> > > > >>> Add compatible string of Mali G310 GPU on i.MX952 board.
> > > > >>>
> > > > >>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > > > >>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> > > > >>> ---
> > > > >>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > > > >>> | 1
> > > > >>> +
> > > > >>> 1 file changed, 1 insertion(+)
> > > > >>>
> > > > >>> diff --git
> > > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yam
> > > > >>> l
> > > > >> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > > > >>> index 8eccd4338a2b..6a10843a26e2 100644
> > > > >>> ---
> > > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yam
> > > > >>> l
> > > > >>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf
> > > > >>> +++ .yam
> > > > >>> +++ l
> > > > >>> @@ -20,6 +20,7 @@ properties:
> > > > >>> - enum:
> > > > >>> - mediatek,mt8196-mali
> > > > >>> - nxp,imx95-mali # G310
> > > > >>> + - nxp,imx952-mali # G310
> > > > >> Can you explain why this is needed? Can it not be covered by the
> > > > >> existing compatible?
> > > > > There are functional differences in GPU module (GPUMIX) between
> > > > > i.MX95 and i.MX952. So they cannot be fully covered by a single existing
> > compatible.
> > > > > On i.MX952, The GPU clock is controlled by hardware GPU auto
> > > > > clock-gating mechanism, while the GPU clock is managed explicitly
> > > > > by the
> > > > driver on i.MX95.
> > > > > Because of these behavioral differences, separate compatible
> > > > > strings "nxp,imx95-mali" and "nxp,imx952-mali" are needed to allow
> > > > > the driver to handle the two variants independently and to keep
> > > > > room for future
> > > > divergence.
> > > >
> > > >
> > > > This information should be added in the commit message explaining
> > > > why
> > > >
> > > > the change is needed.
> > > >
> > > >
> > > > But then where is the driver code taking care of these diferences?
> > > >
> > >
> > > Yes. Currently the driver does not require "nxp,imx952-mali" string.
> > > However, when GPU ipa_counters are enabled to calculate the GPU
> > > busy_time/idle_time for GPU DVFS feature, they will conflict with the
> > > hardware GPU auto clock‑gating mechanism, causing GPU clock to remain
> > always on.
> > > In such cases, ipa_counters need to be disabled so that the GPU auto
> > > clock‑gating mechanism can operate normally, using "nxp,imx952-mali"
> > string.
> >
> > OK, I understand that you're following guidance from some other senior
> > people on how to upstream patches so you've tried to create the smallest
> > patchset to ensure that it gets reviewed and accepted, but in this case we need
> > to see the other patches as well to decide if your approach is the right one and
> > we do need a separate compatible string.
> >
> > If enabling GPU ipa_counters causes the clocks to get stuck active, that feels
> > like a hardware bug, so figuring out how to handle that is more important than
> > adding a compatible string.
> >
> > Either add the patch(es) that use the compatible to this series in v2, or put a
> > comment in the commit message on where we can see the driver changes.
> >
>
> According to discussions with the GPU vendor, this is a hardware limitation
> of Mali-G310 rather than a hardware bug, and it has been addressed in newer
> Mali GPU families.
I represent the said GPU vendor and I think I know what you're talking about, but you're
taking the wrong approach. All G310s have a problem where in order to enable access to
the ipa_counters the automatic clock gating gets disabled. So the solution that needs
to be implemented when we add support for IPA_COUNTERs will apply to all GPUs, not just
MX952.
>
> In addition, ipa_counters are not enabled in the current Panthor driver. We observed
> this issue with the private Mali DDK where ipa_counters were enabled.
> Therefore, keeping the compatible string is necessary to allow for future divergence.
This is not an MX952 issue only. You might be aware of it on your SoC, but it's not just
for it.
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH v5 00/38] KVM: arm64: Add support for protected guest memory with pKVM
From: Marc Zyngier @ 2026-04-01 15:28 UTC (permalink / raw)
To: kvmarm, Will Deacon
Cc: linux-arm-kernel, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Quentin Perret, Fuad Tabba,
Vincent Donnefort, Mostafa Saleh, Alexandru Elisei
In-Reply-To: <20260330144841.26181-1-will@kernel.org>
On Mon, 30 Mar 2026 15:48:01 +0100, Will Deacon wrote:
> As promised on Friday, here's v5 of the pKVM protected memory patches
> previously posted here:
>
> v1: https://lore.kernel.org/kvmarm/20260105154939.11041-1-will@kernel.org/
> v2: https://lore.kernel.org/kvmarm/20260119124629.2563-1-will@kernel.org/
> v3: https://lore.kernel.org/r/20260305144351.17071-1-will@kernel.org
> v4: https://lore.kernel.org/r/20260327140039.21228-1-will@kernel.org
>
> [...]
Applied to next, thanks!
[01/38] KVM: arm64: Remove unused PKVM_ID_FFA definition
commit: 660b208e8b5ea0f5a68a8333e18960d89d484a27
[02/38] KVM: arm64: Don't leak stage-2 page-table if VM fails to init under pKVM
commit: 5e66f723d4de432a5acb481293d81dc88c7f61a4
[03/38] KVM: arm64: Move handle check into pkvm_pgtable_stage2_destroy_range()
commit: 9f02deef471e1b6637a6641ce6bf9e2a1dd7d2c1
[04/38] KVM: arm64: Rename __pkvm_pgtable_stage2_unmap()
commit: ff1e7f9897947ea79ece7eb587c8d93957af5ee8
[05/38] KVM: arm64: Don't advertise unsupported features for protected guests
commit: be3473c338d23c87485d7728818005f32b58009f
[06/38] KVM: arm64: Expose self-hosted debug regs as RAZ/WI for protected guests
commit: 3a81a814437d187ac893b3d937985d6503ff3841
[07/38] KVM: arm64: Remove is_protected_kvm_enabled() checks from hypercalls
commit: 733774b5204553ab5524c0330f262184d9d573f6
[08/38] KVM: arm64: Ignore MMU notifier callbacks for protected VMs
commit: 7250533ad2c1f0e49567077e9b0f66b0349b357e
[09/38] KVM: arm64: Prevent unsupported memslot operations on protected VMs
commit: f0877a1455cc6a93be14e4da741ce26ac0d6ca6d
[10/38] KVM: arm64: Ignore -EAGAIN when mapping in pages for the pKVM host
commit: 73c55be08932a348f8b0a44f561c33eaa2cf1ad2
[11/38] KVM: arm64: Split teardown hypercall into two phases
commit: 6c58f914eb9c4ce5225d03183ae1290d72b5f639
[12/38] KVM: arm64: Introduce __pkvm_host_donate_guest()
commit: 1e579adca1774b3713d1efa67d92a88ec86c04fa
[13/38] KVM: arm64: Hook up donation hypercall to pkvm_pgtable_stage2_map()
commit: 5fef16ef49126b0f71fb3e401aae4dca1865e6f9
[14/38] KVM: arm64: Handle aborts from protected VMs
commit: ea03466e806fea942841a41cfaab8db8c851aa71
[15/38] KVM: arm64: Introduce __pkvm_reclaim_dying_guest_page()
commit: 0bf5f4d400cd11ab86b25a56b101726e35f3e7cb
[16/38] KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()
commit: 4e6e03f9eaddb6be5ca8477dc5642e94ddece47e
[17/38] KVM: arm64: Factor out pKVM host exception injection logic
commit: 90c59c4d920f3ea6e7b4dd8702b87b38c7162755
[18/38] KVM: arm64: Support translation faults in inject_host_exception()
commit: be9ed3529e0599f036a425d83ecc6dd4a085c9d2
[19/38] KVM: arm64: Inject SIGSEGV on illegal accesses
commit: 9ff714a09222128da16900fc7c15dea65692fc26
[20/38] KVM: arm64: Avoid pointless annotation when mapping host-owned pages
commit: 664d61690357ac2154cd01d859d97455aa49a81d
[21/38] KVM: arm64: Generalise kvm_pgtable_stage2_set_owner()
commit: c6ba94640cf7b6da902d1d8a1383c7cf2303ca1f
[22/38] KVM: arm64: Introduce host_stage2_set_owner_metadata_locked()
commit: afa72d207e6b5d49ac597fcd04f0865af63cf589
[23/38] KVM: arm64: Change 'pkvm_handle_t' to u16
commit: 44887977ab0fdaa0af4d1cc97cda413884c0ef86
[24/38] KVM: arm64: Annotate guest donations with handle and gfn in host stage-2
commit: 70346d632b4d98dd33391fa263ab8bed7d9d934f
[25/38] KVM: arm64: Introduce hypercall to force reclaim of a protected page
commit: 56080f53a6ad779b971eb7f4f7a232498805d867
[26/38] KVM: arm64: Reclaim faulting page from pKVM in spurious fault handler
commit: 281a38ad2920b5ccfbbc2a0ca0caeee110ad5d6b
[27/38] KVM: arm64: Return -EFAULT from VCPU_RUN on access to a poisoned pte
commit: 5991916392d844ba6ed6c0d320ac6578f52e39b6
[28/38] KVM: arm64: Add hvc handler at EL2 for hypercalls from protected VMs
commit: 94c525051542c54907e2d3e9d2b008575829cdc8
[29/38] KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs
commit: 03313efed5e2ca55e862bf514b907a431ebf642a
[30/38] KVM: arm64: Implement the MEM_UNSHARE hypercall for protected VMs
commit: 246c976c370de9380660e2bb641758dc0aae8c5c
[31/38] KVM: arm64: Allow userspace to create protected VMs when pKVM is enabled
commit: 8800dbf6614aad1013ea5f348520a2ce5ba4b6c8
[32/38] KVM: arm64: Add some initial documentation for pKVM
commit: 287c6981f12a008bafc46f18a3e48540a1172a52
[33/38] KVM: arm64: Extend pKVM page ownership selftests to cover guest donation
commit: c290df5278fe8c9844b93751620664c3ca3b6e00
[34/38] KVM: arm64: Register 'selftest_vm' in the VM table
commit: 8972a991606bc021249ae53a95c131a79fdeda4a
[35/38] KVM: arm64: Extend pKVM page ownership selftests to cover forced reclaim
commit: f4a5a6770af9b87a8e87717e1b97af052979f4ec
[36/38] KVM: arm64: Extend pKVM page ownership selftests to cover guest hvcs
commit: feae58b6ee45096b1d8c29076f0d8098d9788e57
[37/38] KVM: arm64: Rename PKVM_PAGE_STATE_MASK
commit: 5bae7bc6360a7297e0be2c37017fe863b965646d
[38/38] drivers/virt: pkvm: Add Kconfig dependency on DMA_RESTRICTED_POOL
commit: 61135967fa76d37883d90ccccc5a1cb73e90b94d
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 0/3] KVM: arm64: Fix teardown of non-protected VMs with pKVM
From: Marc Zyngier @ 2026-04-01 15:29 UTC (permalink / raw)
To: kvmarm, Will Deacon
Cc: linux-arm-kernel, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Quentin Perret, Fuad Tabba,
Vincent Donnefort, Mostafa Saleh, Alexandru Elisei
In-Reply-To: <20260331155056.28220-1-will@kernel.org>
On Tue, 31 Mar 2026 16:50:52 +0100, Will Deacon wrote:
> Sashiko continues to throw rocks at me.
>
> This time, it spotted that my fix (introduced in v5 [1] of the pKVM
> series) to prevent taking a reference on a VM in the 'is_dying' state
> also prevents unsharing of pages shared with a non-protected VM if that
> VM is torn down by its VM fd being destroyed, rather than the usual path
> via the MMU notifiers.
>
> [...]
Applied to next, thanks!
[1/3] KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm'
commit: 760299a1d8102b36bed5c25c5a3f94b5a0eee081
[2/3] KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM
commit: 2400696883870ec3fb0fb9925426c62a3383ca36
[3/3] KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim
commit: bc20692f528b2ac8226bafe5b1db9a1f8be96dbf
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 00/16] KVM: arm64: First batch of vgic-v5 related fixes
From: Marc Zyngier @ 2026-04-01 15:30 UTC (permalink / raw)
To: kvmarm, kvm, linux-arm-kernel, Marc Zyngier
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Sascha Bischoff, Mark Brown
In-Reply-To: <20260401103611.357092-1-maz@kernel.org>
On Wed, 01 Apr 2026 11:35:55 +0100, Marc Zyngier wrote:
> This is the second revision of this series attempting to fix a number
> of issues reported on the vgic-v5 PPI series.
>
> * From v1 [1]:
>
> - Partially reverted the effective priority mask fix, as Sascha
> pointed out the crucial difference in the way GICv5 manages the
> PCR compared to GICv[234]'s PMR.
>
> [...]
Applied to next, thanks!
[01/16] KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize time
commit: ecc7f02499544ae879716be837af78260a6a10f7
[02/16] KVM: arm64: Don't skip per-vcpu NV initialisation
commit: d82d09d5ba4be0b5eb053b2ba2bc0e82c49cf2c8
[03/16] arm64: Fix field references for ICH_PPI_DVIR[01]_EL2
commit: 77acae60be60adddf33e4c7e9cf73291f64fb9e8
[04/16] KVM: arm64: Fix writeable mask for ID_AA64PFR2_EL1
commit: 76efe94b1c5cc9b5fac7c5c1096d03f1596c7267
[05/16] KVM: arm64: Account for RESx bits in __compute_fgt()
commit: d70d4323dd9636e35696639f6b4c2b2735291516
[06/16] KVM: arm64: vgic-v5: Hold config_lock while finalizing GICv5 PPIs
commit: e63d0a32e7368f3eb935755db87add1bf000ea90
[07/16] KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2
commit: 170a77b4185a87cc7e02e404d22b9bf3f9923884
[08/16] KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined behaviours
commit: 42d7eac8291d2724b3897141ab2f226c69b7923e
[09/16] KVM: arm64: vgic-v5: Make the effective priority mask a strict limit
commit: a4a645584793dbbb4e5a1a876800654a8883326e
[10/16] KVM: arm64: vgic-v5: Correctly set dist->ready once initialised
commit: 848fa8373a53b0e5d871560743e13278da56fabc
[11/16] KVM: arm64: Kill arch_timer_context::direct field
commit: 8fe30434a81d36715ab83fdb4a5e6c967d2e3ecf
[12/16] KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer()
commit: fbcbf259d97d340376a176de20bdc04687356949
[13/16] KVM: arm64: Move GICv5 timer PPI validation into timer_irqs_are_valid()
commit: 06c85b58e0b13e67f4e56cbba346201bfe95ad00
[14/16] KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handling
commit: be46a408f376df31762e8a9914dc6d082755e686
[15/16] KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't supported
commit: f4626281c6bb563ef5ad9d3a59a1449b45a3dc30
[16/16] KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtime
commit: b3265a1b2bd00335308f27477cecb7702f4bb615
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 00/30] KVM: arm64: Combined user_mem_abort() rework
From: Marc Zyngier @ 2026-04-01 15:34 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm, Marc Zyngier
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
On Fri, 27 Mar 2026 11:35:48 +0000, Marc Zyngier wrote:
> Fuad and I have been working on this "put a stick of dynamite in
> user_mem_abort() and watch the resulting firework" project, and it
> looks surprisingly OK so far. Disappointingly so, I'd even say.
>
> This v2 is has very few changes from the original posting (cleaning up
> the comments in Fuad's series [1], and some minor restructuring in
> mine [2]), but I wanted to post the combined series for people's
> awareness and for the sake of running it through sashiko.
>
> [...]
Applied to next, thanks!
[01/30] KVM: arm64: Extract VMA size resolution in user_mem_abort()
commit: 66fcf492008db407e8d600ceaefd2c8a8070c5ae
[02/30] KVM: arm64: Introduce struct kvm_s2_fault to user_mem_abort()
commit: 0b236c72c02df36992b7d6ff29cbe5abef973250
[03/30] KVM: arm64: Extract PFN resolution in user_mem_abort()
commit: bae99813c6a9ce474cbb7b6553dc6e379b2f4375
[04/30] KVM: arm64: Isolate mmap_read_lock inside new kvm_s2_fault_get_vma_info() helper
commit: f5a5bb8de11863bd92f4188b7e823e3fca4d68e6
[05/30] KVM: arm64: Extract stage-2 permission logic in user_mem_abort()
commit: a6e11bd6e1bd9ea9a42738c5a6ac12881b5fcb36
[06/30] KVM: arm64: Extract page table mapping in user_mem_abort()
commit: 5557a3f843bcef3de9a1237020348b2859812170
[07/30] KVM: arm64: Simplify nested VMA shift calculation
commit: 2175ca5384ba9f3d1f45745522cdeb5865488400
[08/30] KVM: arm64: Remove redundant state variables from struct kvm_s2_fault
commit: 9a57bc1b3c6b1f583f43acf7719d66e6b30ef2a9
[09/30] KVM: arm64: Simplify return logic in user_mem_abort()
commit: 3825373b91b0fbedc65205a59f95379aaf596aad
[10/30] KVM: arm64: Initialize struct kvm_s2_fault completely at declaration
commit: 975bad4bb21e4eea7ecc0f32f4cbbb91a9c8d48f
[11/30] KVM: arm64: Optimize early exit checks in kvm_s2_fault_pin_pfn()
commit: 3456943e8786d56aa2bd3f99e9ad2d735a9879c8
[12/30] KVM: arm64: Hoist MTE validation check out of MMU lock path
commit: 84699747aa554197f6d5b4f4c9d1bcb6cb28e21f
[13/30] KVM: arm64: Clean up control flow in kvm_s2_fault_map()
commit: 11f8f1b8a97b63b180f7aa021ec9abdead283025
[14/30] KVM: arm64: Kill fault->ipa
commit: 5729560e2c3cb67a22a1d72688e0bb8e96798313
[15/30] KVM: arm64: Make fault_ipa immutable
commit: f583a53c2b8a4bd77f090bb76512eb87bc80f2c4
[16/30] KVM: arm64: Move fault context to const structure
commit: c6f4d84643498bc855e2f6719a3233ded0e2dc63
[17/30] KVM: arm64: Replace fault_is_perm with a helper
commit: fe4b6f824f267739ef2c5f2f047c317eceb587c3
[18/30] KVM: arm64: Constrain fault_granule to kvm_s2_fault_map()
commit: 31571929e8a894d06291a9501b2be22cffe14443
[19/30] KVM: arm64: Kill write_fault from kvm_s2_fault
commit: 49902d7e010614888253a90252f4704edb2fe3e3
[20/30] KVM: arm64: Kill exec_fault from kvm_s2_fault
commit: c0d699915a835364b1c8d1eca11e11e7b82f0705
[21/30] KVM: arm64: Kill topup_memcache from kvm_s2_fault
commit: 1a3cd7cb5547979f96ec2a0920b8e39939c58db3
[22/30] KVM: arm64: Move VMA-related information to kvm_s2_fault_vma_info
commit: 4ff2ce512063ae79976c23b6fe2130611bcbae62
[23/30] KVM: arm64: Kill logging_active from kvm_s2_fault
commit: 18e1312879db0af5bfd1b1a8b6771d314ccd3ca9
[24/30] KVM: arm64: Restrict the scope of the 'writable' attribute
commit: 08abf09f4d763565ee9ed084401b7ac92f8b4952
[25/30] KVM: arm64: Move kvm_s2_fault.{pfn,page} to kvm_s2_vma_info
commit: f8dad9602ff305b879fa23688becd578102ba547
[26/30] KVM: arm64: Replace force_pte with a max_map_size attribute
commit: 29a5681843a52570ca9597bf355be33fe8753eb0
[27/30] KVM: arm64: Move device mapping management into kvm_s2_fault_pin_pfn()
commit: e314a4dbdb8b29b7e9a69afb8831a15a6d15c1ed
[28/30] KVM: arm64: Directly expose mapping prot and kill kvm_s2_fault
commit: adb70b3a8b31e9eb05f2ec3c76d85f9a7a8c8cbc
[29/30] KVM: arm64: Simplify integration of adjust_nested_*_perms()
commit: fb9888fdfada0b5ad977f08f7550432a08aacbb1
[30/30] KVM: arm64: Convert gmem_abort() to struct kvm_s2_fault_desc
commit: e9550374d13a4bfd0b8a711733f5d423c2e56b96
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 05/33] rust: remove `RUSTC_HAS_COERCE_POINTEE` and simplify code
From: Danilo Krummrich @ 2026-04-01 15:38 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, 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: <20260401114540.30108-6-ojeda@kernel.org>
On 4/1/26 1:45 PM, Miguel Ojeda wrote:
> rust/kernel/alloc/kbox.rs | 29 ++---------------------------
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH 02/33] rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
From: Danilo Krummrich @ 2026-04-01 15:39 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, 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: <20260401114540.30108-3-ojeda@kernel.org>
On 4/1/26 1:45 PM, Miguel Ojeda wrote:
> drivers/gpu/nova-core/gsp/cmdq.rs | 6 +-----
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH 33/33] rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
From: Gary Guo @ 2026-04-01 15:28 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: <20260401114540.30108-34-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> 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)
> |
>
> warning: operator precedence can trip the unwary
> --> drivers/gpu/nova-core/vbios.rs:511:17
> |
> 511 | / u32::from(data[29]) << 24
> 512 | | | u32::from(data[28]) << 16
> 513 | | | u32::from(data[27]) << 8
> | |______________________________________________^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
> help: consider parenthesizing your expression
> |
> 511 ~ u32::from(data[29]) << 24
> 512 + | u32::from(data[28]) << 16 | (u32::from(data[27]) << 8)
> |
>
> warning: operator precedence can trip the unwary
> --> drivers/gpu/nova-core/vbios.rs:511:17
> |
> 511 | / u32::from(data[29]) << 24
> 512 | | | u32::from(data[28]) << 16
> | |_______________________________________________^ help: consider parenthesizing your expression: `(u32::from(data[29]) << 24) | (u32::from(data[28]) << 16)`
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
>
> 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 "false positives"
> 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]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://lore.kernel.org/rust-for-linux/DFVDKMMA7KPC.2DN0951H3H55Y@kernel.org/
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
^ 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