* 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
* RE: Re: Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 15:59 UTC (permalink / raw)
To: Liviu Dudau
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: <ac05OpEMjKMd8CXy@e142607>
Hi Liviu
> 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.y
> > > > > >>> aml
> > > > > >>> | 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.
Yes. We have bring-up G310 (V2) GPU on both i.MX95 and i.MX952. And auto clock
gating mechanism is firstly introduced in i.MX952 (not supported on i.MX95).
According to your update, solution needs to be implemented to all GPUs which support
auto clock gating mechanism after IPA_COUNTERs are supported in the driver, right?
What's your suggestions for 952 gpu dtb node?
>
> >
> > 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 v12 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Krzysztof Kozlowski @ 2026-04-01 16:01 UTC (permalink / raw)
To: Frank Li, Vijayanand Jitta
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia,
linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Charan Teja Kalla
In-Reply-To: <acvdqQvcitLTCZbm@lizhi-Precision-Tower-5810>
On 31/03/2026 16:43, Frank Li wrote:
> On Tue, Mar 31, 2026 at 07:34:47PM +0530, Vijayanand Jitta wrote:
>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>
>> Change of_map_id() to take a pointer to struct of_phandle_args
>> instead of passing target device node and translated IDs separately.
>> Update all callers accordingly.
>>
>> Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
>> to separate the filter input from the output. Previously, the target
>> parameter served dual purpose: as an input filter (if non-NULL, only
>> match entries targeting that node) and as an output (receiving the
>> matched node with a reference held). Now filter_np is the explicit
>> input filter and arg->np is the pure output.
>>
>> Previously, of_map_id() would call of_node_put() on the matched node
>> when a filter was provided, making reference ownership inconsistent.
>> Remove this internal of_node_put() call so that of_map_id() now always
>> transfers ownership of the matched node reference to the caller via
>> arg->np. Callers are now consistently responsible for releasing this
>> reference with of_node_put(arg->np) when done.
>>
>> Suggested-by: Rob Herring (Arm) <robh@kernel.org>
>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
>> ---
>> drivers/cdx/cdx_msi.c | 7 ++--
>> drivers/iommu/of_iommu.c | 4 +-
>> drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++--
>> drivers/of/base.c | 68 +++++++++++++++++---------------
>> drivers/of/irq.c | 10 ++++-
>> drivers/pci/controller/dwc/pci-imx6.c | 32 +++++++--------
>>
>> for imx part.
>>
>> Reviewed-by: Frank Li <Frank.Li@nxp.com>
So that's an Ack. Leaving a Rb tag for a tiny tiny piece of big patch
will give impression that everything is reviewed on v13. And the patch
was not reviewed by you.
If you cannot certify the reviewers statement of oversight then use acked
"For instance, maintainers may use it to signify that they are OK with a
patch landing, but they may not have reviewed it as thoroughly as if a
Reviewed-by: was provided."
"For example, if a patch affects multiple subsystems and has an
Acked-by: from one subsystem maintainer then this usually indicates
acknowledgement of *just the part which affects that maintainer's code.*"
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-01 16:07 UTC (permalink / raw)
To: Guangliu Ding, Liviu Dudau
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: <AM0PR04MB47075AF2C5863FC665285CA9F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On 01/04/2026 13:27, Guangliu Ding wrote:
>>>>
>>>> We discuss only the lack of compatibility in terms of DT, how DT sees
>>>> compatible devices.
>>>>
>>>> And lack of driver code is clear indication that devices are
>>>> compatible in terms how DT understands it. Feel encouraged to bring
>>>> actual arguments in commit msgs in the future.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>
>>> So the best approach is only reserve "arm,mali-valhall-csf" for now,
>>> since currently there is no need for an additional compatible entry from a DT
>> compatibility perspective.
>>> We can introduce "nxp,imx952-mali" in future commits if hardware or
>>> driver differences actually require it, and include more detailed justification
>> in the commit message. Right?
>>
>> So does that mean you decided not to read writing bindings document?
>
> Actually, I followed the compatible string of gpu node in imx952.dtsi during
> code work since they share the same GPU IP.
> gpu: gpu@4d900000 {
> compatible = "nxp,imx95-mali", "arm,mali-valhall-csf"; >
>
> Is this line in writing bindings document that you want to mention about?
> Could you please share more suggestions about the patch optimization?
> DO add new compatibles in case there are new features or bugs.
Please read entire file. I feel like you avoid doing this and just ask
me to give you shortcut.
There is more than one point from that trivial writing bindings file
which applies here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] coresight: etm4x: fix inconsistencies with sysfs configration
From: Suzuki K Poulose @ 2026-04-01 16:14 UTC (permalink / raw)
To: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel
Cc: mike.leach, james.clark, alexander.shishkin, leo.yan
In-Reply-To: <20260317181705.2456271-2-yeoreum.yun@arm.com>
Hi Levi
On 17/03/2026 18:17, Yeoreum Yun wrote:
> The current ETM4x configuration via sysfs can lead to the following
> inconsistencies:
>
> - If a configuration is modified via sysfs while a perf session is
> active, the running configuration may differ between before
> a sched-out and after a subsequent sched-in.
>
> - Once a perf session is enabled, some read-only register fields
> (e.g., TRCSSCSR<n>) may not be reported correctly,
> because drvdata->config is cleared while enabling with perf mode,
> even though the information was previously read via etm4_init_arch_data().
Thank you for the patch. The patch looks good to me. Some minor comments
below.
>
> To resolve these inconsistencies, the configuration should be separated into:
>
> - active_config, which represents the currently applied configuration
To be more precise, it is the "Applied configuration for the current
session"
> - config, which stores the settings configured via sysfs.
While we are at it, should we stop using the drvdata->config for the
"capabilities" for the ETM (e.g., TRCSSCSRn in ss_status ?) Instead
we could save it in "drvdata->ss_status". This keeps everything
separated:
1. Boot time probed capabilities of ETM
2. Sysfs configuration for the next Run
3. Current active configuration for the ETM (sysfs or perf)
Suzuki
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> .../hwtracing/coresight/coresight-etm4x-cfg.c | 2 +-
> .../coresight/coresight-etm4x-core.c | 45 +++++++++++--------
> drivers/hwtracing/coresight/coresight-etm4x.h | 2 +
> 3 files changed, 30 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> index c302072b293a..84213d40d1ae 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> @@ -47,7 +47,7 @@ static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
> struct cscfg_regval_csdev *reg_csdev, u32 offset)
> {
> int err = -EINVAL, idx;
> - struct etmv4_config *drvcfg = &drvdata->config;
> + struct etmv4_config *drvcfg = &drvdata->active_config;
> u32 off_mask;
>
> if (((offset >= TRCEVENTCTL0R) && (offset <= TRCVIPCSSCTLR)) ||
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index d565a73f0042..c552129c4a0c 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -88,9 +88,11 @@ static int etm4_probe_cpu(unsigned int cpu);
> */
> static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n)
> {
> + struct etmv4_config *config = &drvdata->active_config;
> +
> return (n < drvdata->nr_ss_cmp) &&
> drvdata->nr_pe &&
> - (drvdata->config.ss_status[n] & TRCSSCSRn_PC);
> + (config->ss_status[n] & TRCSSCSRn_PC);
> }
>
> u64 etm4x_sysreg_read(u32 offset, bool _relaxed, bool _64bit)
> @@ -266,10 +268,11 @@ static void etm4x_prohibit_trace(struct etmv4_drvdata *drvdata)
> static u64 etm4x_get_kern_user_filter(struct etmv4_drvdata *drvdata)
> {
> u64 trfcr = drvdata->trfcr;
> + struct etmv4_config *config = &drvdata->active_config;
>
> - if (drvdata->config.mode & ETM_MODE_EXCL_KERN)
> + if (config->mode & ETM_MODE_EXCL_KERN)
> trfcr &= ~TRFCR_EL1_ExTRE;
> - if (drvdata->config.mode & ETM_MODE_EXCL_USER)
> + if (config->mode & ETM_MODE_EXCL_USER)
> trfcr &= ~TRFCR_EL1_E0TRE;
>
> return trfcr;
> @@ -277,7 +280,7 @@ static u64 etm4x_get_kern_user_filter(struct etmv4_drvdata *drvdata)
>
> /*
> * etm4x_allow_trace - Allow CPU tracing in the respective ELs,
> - * as configured by the drvdata->config.mode for the current
> + * as configured by the drvdata->active_config.mode for the current
> * session. Even though we have TRCVICTLR bits to filter the
> * trace in the ELs, it doesn't prevent the ETM from generating
> * a packet (e.g, TraceInfo) that might contain the addresses from
> @@ -288,12 +291,13 @@ static u64 etm4x_get_kern_user_filter(struct etmv4_drvdata *drvdata)
> static void etm4x_allow_trace(struct etmv4_drvdata *drvdata)
> {
> u64 trfcr, guest_trfcr;
> + struct etmv4_config *config = &drvdata->active_config;
>
> /* If the CPU doesn't support FEAT_TRF, nothing to do */
> if (!drvdata->trfcr)
> return;
>
> - if (drvdata->config.mode & ETM_MODE_EXCL_HOST)
> + if (config->mode & ETM_MODE_EXCL_HOST)
> trfcr = drvdata->trfcr & ~(TRFCR_EL1_ExTRE | TRFCR_EL1_E0TRE);
> else
> trfcr = etm4x_get_kern_user_filter(drvdata);
> @@ -301,7 +305,7 @@ static void etm4x_allow_trace(struct etmv4_drvdata *drvdata)
> write_trfcr(trfcr);
>
> /* Set filters for guests and pass to KVM */
> - if (drvdata->config.mode & ETM_MODE_EXCL_GUEST)
> + if (config->mode & ETM_MODE_EXCL_GUEST)
> guest_trfcr = drvdata->trfcr & ~(TRFCR_EL1_ExTRE | TRFCR_EL1_E0TRE);
> else
> guest_trfcr = etm4x_get_kern_user_filter(drvdata);
> @@ -494,7 +498,7 @@ static int etm4_enable_trace_unit(struct etmv4_drvdata *drvdata)
> static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
> {
> int i, rc;
> - struct etmv4_config *config = &drvdata->config;
> + struct etmv4_config *config = &drvdata->active_config;
> struct coresight_device *csdev = drvdata->csdev;
> struct device *etm_dev = &csdev->dev;
> struct csdev_access *csa = &csdev->access;
> @@ -666,7 +670,7 @@ static int etm4_config_timestamp_event(struct etmv4_drvdata *drvdata,
> {
> int ctridx;
> int rselector;
> - struct etmv4_config *config = &drvdata->config;
> + struct etmv4_config *config = &drvdata->active_config;
>
> /* No point in trying if we don't have at least one counter */
> if (!drvdata->nr_cntr)
> @@ -749,7 +753,7 @@ static int etm4_parse_event_config(struct coresight_device *csdev,
> {
> int ret = 0;
> struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> - struct etmv4_config *config = &drvdata->config;
> + struct etmv4_config *config = &drvdata->active_config;
> struct perf_event_attr max_timestamp = {
> .ATTR_CFG_FLD_timestamp_CFG = U64_MAX,
> };
> @@ -911,14 +915,17 @@ static int etm4_enable_sysfs(struct coresight_device *csdev, struct coresight_pa
>
> /* enable any config activated by configfs */
> cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset);
> +
> + raw_spin_lock(&drvdata->spinlock);
> +
> + drvdata->active_config = drvdata->config;
> +
> if (cfg_hash) {
> ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset);
> if (ret)
> return ret;
> }
>
> - raw_spin_lock(&drvdata->spinlock);
> -
> drvdata->trcid = path->trace_id;
>
> /* Tracer will never be paused in sysfs mode */
> @@ -1028,7 +1035,7 @@ static void etm4_disable_trace_unit(struct etmv4_drvdata *drvdata)
> static void etm4_disable_hw(struct etmv4_drvdata *drvdata)
> {
> u32 control;
> - struct etmv4_config *config = &drvdata->config;
> + struct etmv4_config *config = &drvdata->active_config;
> struct coresight_device *csdev = drvdata->csdev;
> struct csdev_access *csa = &csdev->access;
> int i;
> @@ -1374,12 +1381,14 @@ static void etm4_init_arch_data(void *info)
> u32 etmidr5;
> struct etm4_init_arg *init_arg = info;
> struct etmv4_drvdata *drvdata;
> + struct etmv4_config *config;
> struct csdev_access *csa;
> struct device *dev = init_arg->dev;
> int i;
>
> drvdata = dev_get_drvdata(init_arg->dev);
> csa = init_arg->csa;
> + config = &drvdata->active_config;
>
> /*
> * If we are unable to detect the access mechanism,
> @@ -1440,7 +1449,7 @@ static void etm4_init_arch_data(void *info)
>
> /* EXLEVEL_S, bits[19:16] Secure state instruction tracing */
> drvdata->s_ex_level = FIELD_GET(TRCIDR3_EXLEVEL_S_MASK, etmidr3);
> - drvdata->config.s_ex_level = drvdata->s_ex_level;
> + config->s_ex_level = drvdata->s_ex_level;
> /* EXLEVEL_NS, bits[23:20] Non-secure state instruction tracing */
> drvdata->ns_ex_level = FIELD_GET(TRCIDR3_EXLEVEL_NS_MASK, etmidr3);
> /*
> @@ -1491,8 +1500,7 @@ static void etm4_init_arch_data(void *info)
> */
> drvdata->nr_ss_cmp = FIELD_GET(TRCIDR4_NUMSSCC_MASK, etmidr4);
> for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> - drvdata->config.ss_status[i] =
> - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> + config->ss_status[i] = etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> }
> /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
> drvdata->numcidc = FIELD_GET(TRCIDR4_NUMCIDC_MASK, etmidr4);
> @@ -1685,7 +1693,7 @@ static void etm4_set_default(struct etmv4_config *config)
> static int etm4_get_next_comparator(struct etmv4_drvdata *drvdata, u32 type)
> {
> int nr_comparator, index = 0;
> - struct etmv4_config *config = &drvdata->config;
> + struct etmv4_config *config = &drvdata->active_config;
>
> /*
> * nr_addr_cmp holds the number of comparator _pair_, so time 2
> @@ -1726,7 +1734,7 @@ static int etm4_set_event_filters(struct etmv4_drvdata *drvdata,
> {
> int i, comparator, ret = 0;
> u64 address;
> - struct etmv4_config *config = &drvdata->config;
> + struct etmv4_config *config = &drvdata->active_config;
> struct etm_filters *filters = event->hw.addr_filters;
>
> if (!filters)
> @@ -2246,7 +2254,8 @@ static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg)
> if (!desc.name)
> return -ENOMEM;
>
> - etm4_set_default(&drvdata->config);
> + etm4_set_default(&drvdata->active_config);
> + drvdata->config = drvdata->active_config;
>
> pdata = coresight_get_platform_data(dev);
> if (IS_ERR(pdata))
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> index 89d81ce4e04e..76beb896f188 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> @@ -1022,6 +1022,7 @@ struct etmv4_save_state {
> * allows tracing at all ELs. We don't want to compute this
> * at runtime, due to the additional setting of TRFCR_CX when
> * in EL2. Otherwise, 0.
> + * @active_config: structure holding current applied configuration parameters.
> * @config: structure holding configuration parameters.
> * @save_state: State to be preserved across power loss
> * @skip_power_up: Indicates if an implementation can skip powering up
> @@ -1079,6 +1080,7 @@ struct etmv4_drvdata {
> bool skip_power_up : 1;
> bool paused : 1;
> u64 trfcr;
> + struct etmv4_config active_config;
> struct etmv4_config config;
> struct etmv4_save_state *save_state;
> DECLARE_BITMAP(arch_features, ETM4_IMPDEF_FEATURE_MAX);
^ permalink raw reply
* Re: [PATCH v2 6/7] MAINTAINERS: add exynos850-pmu.c to Exynos850 entry
From: Sam Protsenko @ 2026-04-01 16:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alexey Klimov, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar, Tudor Ambarus,
Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <f73173b4-f44a-4d01-abec-3366b6561332@kernel.org>
Hi Krzysztof,
On Wed, Apr 1, 2026 at 9:28 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 01/04/2026 06:51, Alexey Klimov wrote:
> > Update Exynos850 entry to include new file
> > drivers/soc/samsung/exynos850-pmu.c. Add myself as M
> > there.
> >
> > Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> > ---
> > MAINTAINERS | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e14e6f874e05..4b28e92b4d9b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -23601,6 +23601,7 @@ F: include/dt-bindings/clock/samsung,exynos2200-cmu.h
> >
> > SAMSUNG EXYNOS850 SoC SUPPORT
> > M: Sam Protsenko <semen.protsenko@linaro.org>
> > +M: Alexey Klimov <alexey.klimov@linaro.org>
>
> I am surprised to see this because I did not find many reviews from your
> side before.
>
It was me who advised Alexey to add himself on the list, as he's doing
a lot of Exynos850 related work nowadays, and we expect him to
continue doing that. If you think it's too early, let's get back to
this once there are more patches submitted under his name.
Thanks!
> Please first engage in reviewing of this platform, before assigning
> yourself as a maintainer.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: Use the correct buffer size during RXTX_MAP
From: Sudeep Holla @ 2026-04-01 16:21 UTC (permalink / raw)
To: Sebastian Ene; +Cc: linux-arm-kernel, linux-kernel, android-kvm, Sudeep Holla
In-Reply-To: <20260401111738.323647-1-sebastianene@google.com>
On Wed, Apr 01, 2026 at 11:17:38AM +0000, Sebastian Ene wrote:
> Don't use the discovered buffer size from an FFA_FEATURES call directly
> since we can run on a system that has the PAGE_SIZE larger than the
> returned size which makes the alloc_pages_exact for the buffer to be
> rounded up.
>
> Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()")
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> drivers/firmware/arm_ffa/driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index f2f94d4d533e..d0c926aca120 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -2078,7 +2078,7 @@ static int __init ffa_init(void)
>
> ret = ffa_rxtx_map(virt_to_phys(drv_info->tx_buffer),
> virt_to_phys(drv_info->rx_buffer),
> - rxtx_bufsz / FFA_PAGE_SIZE);
> + DIV_ROUND_UP(rxtx_bufsz, PAGE_SIZE) / FFA_PAGE_SIZE);
Did you mean to use PAGE_ALIGN() instead of DIV_ROUND_UP() ?
The new pg_cnt calculation is dimensionally incorrect and evaluates to 0 for
all the supported buffer sizes, so FFA_RXTX_MAP is always called with an
invalid page count.
Example: with rxtx_bufsz = 4K, the expression becomes 1 / 4096 on 4K/16K/64K
page kernel, so pg_cnt == 0. Wouldn’t this cause a boot-time regression for
FF-A driver init ? Have you tested this ? I am trying to understand what I
might be missing here.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] KVM: arm64: vgic-v5: Fold PPI state for all exposed PPIs
From: Sascha Bischoff @ 2026-04-01 16:21 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org
Cc: nd, maz@kernel.org, oliver.upton@linux.dev, Joey Gouly,
Suzuki Poulose, yuzenghui@huawei.com, broonie@kernel.org
GICv5 supports up to 128 PPIs, which would introduce a large amount of
overhead if all of them were actively tracked. Rather than keeping
track of all 128 potential PPIs, we instead only consider the set of
architected PPIs (the first 64). Moreover, we further reduce that set
by only exposing a subset of the PPIs to a guest. In practice, this
means that only 4 PPIs are typically exposed to a guest - the SW_PPI,
PMUIRQ, and the timers.
When folding the PPI state, changed bits in the active or pending were
used to choose which state to sync back. However, this breaks badly
for Edge interrupts when exiting the guest before it has consumed the
edge. There is no change in pending state detected, and the edge is
lost forever.
Given the reduced set of PPIs exposed to the guest, and the issues
around tracking the edges, drop the tracking of changed state, and
instead iterate over the limited subset of PPIs exposed to the guest
directly.
This change drops the second copy of the PPI pending state used for
detecting edges in the pending state, and reworks
vgic_v5_fold_ppi_state() to iterate over the VM's PPI mask instead.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 9 +--------
arch/arm64/kvm/hyp/vgic-v5-sr.c | 6 +++---
arch/arm64/kvm/vgic/vgic-v5.c | 28 +++++-----------------------
3 files changed, 9 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a7dc0aac3b934..729bd32207fa6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -803,14 +803,7 @@ struct kvm_host_data {
/* PPI state tracking for GICv5-based guests */
struct {
- /*
- * For tracking the PPI pending state, we need both the entry
- * state and exit state to correctly detect edges as it is
- * possible that an interrupt has been injected in software in
- * the interim.
- */
- DECLARE_BITMAP(pendr_entry, VGIC_V5_NR_PRIVATE_IRQS);
- DECLARE_BITMAP(pendr_exit, VGIC_V5_NR_PRIVATE_IRQS);
+ DECLARE_BITMAP(pendr, VGIC_V5_NR_PRIVATE_IRQS);
/* The saved state of the regs when leaving the guest */
DECLARE_BITMAP(activer_exit, VGIC_V5_NR_PRIVATE_IRQS);
diff --git a/arch/arm64/kvm/hyp/vgic-v5-sr.c b/arch/arm64/kvm/hyp/vgic-v5-sr.c
index 2c4304ffa9f33..47e6bcd437029 100644
--- a/arch/arm64/kvm/hyp/vgic-v5-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v5-sr.c
@@ -37,7 +37,7 @@ void __vgic_v5_save_ppi_state(struct vgic_v5_cpu_if *cpu_if)
bitmap_write(host_data_ptr(vgic_v5_ppi_state)->activer_exit,
read_sysreg_s(SYS_ICH_PPI_ACTIVER0_EL2), 0, 64);
- bitmap_write(host_data_ptr(vgic_v5_ppi_state)->pendr_exit,
+ bitmap_write(host_data_ptr(vgic_v5_ppi_state)->pendr,
read_sysreg_s(SYS_ICH_PPI_PENDR0_EL2), 0, 64);
cpu_if->vgic_ppi_priorityr[0] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR0_EL2);
@@ -52,7 +52,7 @@ void __vgic_v5_save_ppi_state(struct vgic_v5_cpu_if *cpu_if)
if (VGIC_V5_NR_PRIVATE_IRQS == 128) {
bitmap_write(host_data_ptr(vgic_v5_ppi_state)->activer_exit,
read_sysreg_s(SYS_ICH_PPI_ACTIVER1_EL2), 64, 64);
- bitmap_write(host_data_ptr(vgic_v5_ppi_state)->pendr_exit,
+ bitmap_write(host_data_ptr(vgic_v5_ppi_state)->pendr,
read_sysreg_s(SYS_ICH_PPI_PENDR1_EL2), 64, 64);
cpu_if->vgic_ppi_priorityr[8] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR8_EL2);
@@ -87,7 +87,7 @@ void __vgic_v5_restore_ppi_state(struct vgic_v5_cpu_if *cpu_if)
SYS_ICH_PPI_ENABLER0_EL2);
/* Update the pending state of the NON-DVI'd PPIs, only */
- bitmap_andnot(pendr, host_data_ptr(vgic_v5_ppi_state)->pendr_entry,
+ bitmap_andnot(pendr, host_data_ptr(vgic_v5_ppi_state)->pendr,
cpu_if->vgic_ppi_dvir, VGIC_V5_NR_PRIVATE_IRQS);
write_sysreg_s(bitmap_read(pendr, 0, 64), SYS_ICH_PPI_PENDR0_EL2);
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 8680a8354db9d..fdd39ea7f83ec 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -385,24 +385,14 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu *vcpu)
void vgic_v5_fold_ppi_state(struct kvm_vcpu *vcpu)
{
struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
- DECLARE_BITMAP(changed_active, VGIC_V5_NR_PRIVATE_IRQS);
- DECLARE_BITMAP(changed_pending, VGIC_V5_NR_PRIVATE_IRQS);
- DECLARE_BITMAP(changed_bits, VGIC_V5_NR_PRIVATE_IRQS);
- unsigned long *activer, *pendr_entry, *pendr;
+ unsigned long *activer, *pendr;
int i;
activer = host_data_ptr(vgic_v5_ppi_state)->activer_exit;
- pendr_entry = host_data_ptr(vgic_v5_ppi_state)->pendr_entry;
- pendr = host_data_ptr(vgic_v5_ppi_state)->pendr_exit;
+ pendr = host_data_ptr(vgic_v5_ppi_state)->pendr;
- bitmap_xor(changed_active, cpu_if->vgic_ppi_activer, activer,
- VGIC_V5_NR_PRIVATE_IRQS);
- bitmap_xor(changed_pending, pendr_entry, pendr,
- VGIC_V5_NR_PRIVATE_IRQS);
- bitmap_or(changed_bits, changed_active, changed_pending,
- VGIC_V5_NR_PRIVATE_IRQS);
-
- for_each_set_bit(i, changed_bits, VGIC_V5_NR_PRIVATE_IRQS) {
+ for_each_set_bit(i, vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask,
+ VGIC_V5_NR_PRIVATE_IRQS) {
u32 intid = vgic_v5_make_ppi(i);
struct vgic_irq *irq;
@@ -462,15 +452,7 @@ void vgic_v5_flush_ppi_state(struct kvm_vcpu *vcpu)
* incoming changes are merged with the outgoing changes on the return
* path.
*/
- bitmap_copy(host_data_ptr(vgic_v5_ppi_state)->pendr_entry, pendr,
- VGIC_V5_NR_PRIVATE_IRQS);
-
- /*
- * Make sure that we can correctly detect "edges" in the PPI
- * state. There's a path where we never actually enter the guest, and
- * failure to do this risks losing pending state
- */
- bitmap_copy(host_data_ptr(vgic_v5_ppi_state)->pendr_exit, pendr,
+ bitmap_copy(host_data_ptr(vgic_v5_ppi_state)->pendr, pendr,
VGIC_V5_NR_PRIVATE_IRQS);
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 07/16] KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2
From: Sascha Bischoff @ 2026-04-01 16:24 UTC (permalink / raw)
To: maz@kernel.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Joey Gouly, yuzenghui@huawei.com, Suzuki Poulose,
oupton@kernel.org, broonie@kernel.org, nd
In-Reply-To: <20260401103611.357092-8-maz@kernel.org>
On Wed, 2026-04-01 at 11:36 +0100, Marc Zyngier wrote:
> While it is perfectly correct to leave the pending state of a level
> interrupt as is when queuing it (it is, after all, only driven by
> the line), edge pending state must be transfered, as nothing will
> lower it.
>
> Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
> Fixes: 4d591252bacb2 ("KVM: arm64: gic-v5: Implement PPI interrupt
> injection")
> Link:
> https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c
> b/arch/arm64/kvm/vgic/vgic-v5.c
> index 119d7d01d0e77..422741c86c6a8 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -445,8 +445,11 @@ void vgic_v5_flush_ppi_state(struct kvm_vcpu
> *vcpu)
>
> irq = vgic_get_vcpu_irq(vcpu, intid);
>
> - scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
> + scoped_guard(raw_spinlock_irqsave, &irq->irq_lock) {
> __assign_bit(i, pendr, irq_is_pending(irq));
> + if (irq->config == VGIC_CONFIG_EDGE)
> + irq->pending_latch = false;
> + }
>
> vgic_put_irq(vcpu->kvm, irq);
> }
With this change we end up losing edges (so, actually have the opposite
problem!). I'd missed this in the previous iteration, but have just
uncovered it during testing. It was hidden by clearing TWI when we have
a single task running, and hence wasn't picked up with the GICv5 PPI
selftest until I stressed the test system more heavily.
In vgic_v5_fold_ppi_state() we detect changes in the active or pending
state on guest exit. If there is no change, i.e., the guest hasn't
consumed the edge yet, we don't end up syncing it back to the
corresponding struct vgic_irq, and lose it forever.
The detection of changes on fold was introduced in order to reduce the
overhead back when we were syncing the state for all 128 potential
PPIs. Now that we've reduced the set to the 64 architected PPIs, and
actually only use a subset of those (SW_PPI, PMUIRQ, timers - up to 4
in total currently) I'm not sure that makes sense anymore.
I think it instead makes sense to iterate over the mask of PPIs exposed
to the guest and sync only those back to KVM's vgic_irq state. This
means that we first of all avoid losing any edges, and secondly are
able to drop the extra pending state tracking.
I've just posted a patch based on this series which addresses the issue
here:
https://lore.kernel.org/linux-arm-kernel/20260401162152.932243-1-sascha.bischoff@arm.com
Thanks,
Sascha
^ permalink raw reply
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Robin Murphy @ 2026-04-01 16:33 UTC (permalink / raw)
To: Jason Gunthorpe, Alexandre Ghiti, AngeloGioacchino Del Regno,
Albert Ou, asahi, Baolin Wang, iommu, Janne Grunau,
Jernej Skrabec, Joerg Roedel, Jean-Philippe Brucker,
linux-arm-kernel, linux-mediatek, linux-riscv, linux-sunxi,
Matthias Brugger, Neal Gompa, Orson Zhai, Palmer Dabbelt,
Paul Walmsley, Samuel Holland, Sven Peter, virtualization,
Chen-Yu Tsai, Will Deacon, Yong Wu, Chunyan Zhang
Cc: Lu Baolu, Janusz Krzysztofik, Joerg Roedel, Jon Hunter, patches,
Samiullah Khawaja, stable, Vasant Hegde
In-Reply-To: <0-v1-664d3acaabb9+78b-iommu_gather_always_jgg@nvidia.com>
On 2026-03-31 8:56 pm, Jason Gunthorpe wrote:
> The fixed commit assumed that the gather would always be populated if
> an iotlb_sync was required.
>
> arm-smmu-v3, amd, VT-d, riscv, s390, mtk all use information from the
> gather during their iotlb_sync() and this approach works for them.
>
> However, arm-smmu, qcom_iommu, ipmmu-vmsa, sun50i, sprd, virtio,
> apple-dart all ignore the gather during their iotlb_sync(). They
> mostly issue a full flush.
>
> Unfortunately the latter set of drivers often don't bother to add
> anything to the gather since they don't intend on using it. Since the
> core code now blocks gathers that were never filled, this caused those
> drivers to stop getting their iotlb_sync() calls and breaks them.
>
> Since it is impossible to tell the difference between gathers that are
> empty because there is nothing to do and gathers that are empty
> because they are not used, fill in the gathers for the missing cases.
>
> io-pgtable might have intended to allow the driver to choose between
> gather or immediate flush because it passed gather to
> ops->tlb_add_page(), however no driver does anything with it.
Apart from arm-smmu-v3...
> mtk uses io-pgtable-arm-v7s but added the range to the gather in the
> unmap callback. Move this into the io-pgtable-arm unmap itself. That
> will fix all the armv7 using drivers (arm-smmu, qcom_iommu,
> ipmmu-vmsa).
io-pgtable-arm-v7s != io-pgtable-arm. You're *breaking* MTK (and failing
to fix the other v7s user, which is MSM).
> arm-smmu uses both ARM_V7S and ARM LPAE formats. The LPAE formats
> already have the gather population because SMMUv3 requires it, so it
> becomes consistent.
Huh? arm-smmu-v3 invokes iommu_iotlb_gather_add_page() itself, because
arm-smmu-v3 uses gathers; arm-smmu does not. io-pgtable-arm has nothing
to do with it. Invoking add range before add_page will end up defeating
the iommu_iotlb_gather_is_disjoint() check and making SMMUv3
overinvalidate between disjoint ranges.
I guess now I remember why we weren't validating gathers in core code
before :(
However, if it is for the sake of a core code check, why not just make
the core code robust itself?
Thanks,
Robin.
----->8-----
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 35db51780954..9ca23f89a279 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2714,6 +2714,10 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
iova, unmapped_page);
+ /* If the driver itself isn't using the gather, mark it used */
+ if (iotlb_gather->end <= iotlb_gather->start)
+ iommu_iotlb_gather_add_range(&iotlb_gather, iova, unmapped_page);
+
iova += unmapped_page;
unmapped += unmapped_page;
}
^ permalink raw reply related
* Re: [GIT PULL 2/2] Broadcom devicetree-arm64 changes for 7.1
From: Arnd Bergmann @ 2026-04-01 16:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Florian Fainelli
Cc: soc, Rob Herring, Gregor Herburger, Maíra Canal,
Stefan Wahren, linux-arm-kernel, Kevin Hilman,
bcm-kernel-feedback-list
In-Reply-To: <3f7879d0-9e5d-4c00-a5dc-4871a049afd0@kernel.org>
On Wed, Apr 1, 2026, at 16:47, Krzysztof Kozlowski wrote:
> On 01/04/2026 16:37, Arnd Bergmann wrote:
>> $ gpg --list-sigs 9BE46ADFE60625D891F72B8587D0969C44070704
>> pub dsa1024/61579915B563760E 2008-09-16 [SCA] [expired: 2024-11-06]
>
> dsa1024 might be another answer... DSA1024 was deprecated by NIST in
> 2013, so maybe gnugp even drops it just like keys with too weak signatures?
>
> But another problem is that I do not see it in the `git log` of keyring
> at all which suggests it wasn't ever submitted.
Indeed, that also explains why the Broadcom tree is hosted on github
rather than git.kernel.org. While using the kernel.org hosting
is by no means a requirement, github does occasionally cause problems,
and I do get a bit annoyed when it takes ages to pull from that.
Florian, I don't know if there is a Broadcom specific policy that
requires you to use the corporate github account, but if you
are setting up a new key already, it may be a good time to
also move the hosting.
> I don't think DSA1024 can be accepted now in keyring, so this requires a
> new key, cross signed by the old one.
+1
Arnd
^ 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