* Re: [PATCH 0/3] KVM: arm64: Fix teardown of non-protected VMs with pKVM
From: Mark Brown @ 2026-04-01 13:33 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Marc Zyngier, 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>
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
On Tue, Mar 31, 2026 at 04:50:52PM +0100, Will Deacon wrote:
> 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.
> Rather than send a v6 of the whole series, here are three patches that
> apply on top of v5 and fix the issue by (a) preventing teardown of a
> referenced VM and (b) allowing some references to be taken on a dying
> VM. As an added bonus, this simplifies the locking on the reclaim path
> because now a VM reference is enough to stop the page-tables from going
> away.
This series fixes the warnings I reported with pKVM on N1DSP yesterday:
Tested-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Miguel Ojeda @ 2026-04-01 13:31 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng,
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: <DHHUQRB9ZL54.VQZ7OUZNSYDS@garyguo.net>
On Wed, Apr 1, 2026 at 3:28 PM Gary Guo <gary@garyguo.net> wrote:
>
> This diff fails to apply on linux-next, due to conflict with ece7e57afd51
> ("docs: changes.rst and ver_linux: sort the lists").
Yeah, sorry, I should have added `--base-commit` -- it is `rust-next`,
i.e. 3a2486cc1da5 ("kbuild: rust: provide an option to inline C
helpers into Rust").
There will be other conflicts too, e.g. in the list of features in
`scripts/Makefile.build`.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Dennis Gilmore @ 2026-04-01 13:29 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Chukun Pan, Alexey Charkov,
Peter Robinson, Michael Riesch, Mykola Kvach, Jimmy Hon,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <7c4791e9-6621-4afb-a166-55211b18fb08@lunn.ch>
Hi Andrew,
On Wed, Apr 1, 2026 at 6:56 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Tue, Mar 31, 2026 at 08:07:07PM -0500, dennis@ausil.us wrote:
> > From: Dennis Gilmore <dennis@ausil.us>
> >
> > Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
> >
> > - eMMC module, you can optionally solder a SPI NOR in place and turn
> > off the eMMC
> > - PCIe-attached NIC (pcie2x1l1)
> > - PCIe NVMe slot (pcie2x1l2)
> > - AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
> > - BCM4345C5 Bluetooth
> > - es8388 audio
> > - USB 2.0 and USB 3.0
>
> You said in patch 0/X that the Ethernet driver had just been
> accepted. So i was expecting a node for it here?
>
> Andrew
On the Orange Pi 5 Pro, Ethernet is connected to PCIe; there is no
need to define anything
Dennis
^ permalink raw reply
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Gary Guo @ 2026-04-01 13: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-2-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, 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>
> ---
> Documentation/process/changes.rst | 2 +-
> scripts/min-tool-version.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index 6b373e193548..474594bd4831 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
This diff fails to apply on linux-next, due to conflict with ece7e57afd51
("docs: changes.rst and ver_linux: sort the lists").
Best,
Gary
> @@ -31,7 +31,7 @@ you probably needn't concern yourself with pcmciautils.
> ====================== =============== ========================================
> GNU C 8.1 gcc --version
> Clang/LLVM (optional) 15.0.0 clang --version
> -Rust (optional) 1.78.0 rustc --version
> +Rust (optional) 1.85.0 rustc --version
> bindgen (optional) 0.65.1 bindgen --version
> GNU make 4.0 make --version
> bash 4.2 bash --version
> diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
> index 99b5575c1ef7..a270ec761f64 100755
> --- a/scripts/min-tool-version.sh
> +++ b/scripts/min-tool-version.sh
> @@ -31,7 +31,7 @@ llvm)
> fi
> ;;
> rustc)
> - echo 1.78.0
> + echo 1.85.0
> ;;
> bindgen)
> echo 0.65.1
^ permalink raw reply
* Re: [PATCH v5 2/3] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: Dennis Gilmore @ 2026-04-01 13:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Chukun Pan, Alexey Charkov,
Peter Robinson, Michael Riesch, Mykola Kvach, Jimmy Hon,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <b733883d-e515-4946-a81f-d1a595985e01@lunn.ch>
Hi Andrew,
On Wed, Apr 1, 2026 at 6:52 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > +&gmac1 {
> > + clock_in_out = "output";
> > + phy-handle = <&rgmii_phy1>;
> > + phy-mode = "rgmii-rxid";
> > + pinctrl-0 = <&gmac1_miim
> > + &gmac1_tx_bus2
> > + &gmac1_rx_bus2
> > + &gmac1_rgmii_clk
> > + &gmac1_rgmii_bus>;
> > + pinctrl-names = "default";
> > + tx_delay = <0x42>;
>
> phy-mode = "rgmii-rxid" means the PCB provides the 2ns delay for
> TX. This is unlikely to be correct. Please try "rgmii-id" and delete
> the tx_delay.
As I mentioned to you in v2 I do not have the affected hardware to
test any changes. This patch is just moving the existing definition
from the common dtsi to the two devices that have gmac1 wired up. I
am not comfortable making changes here that I can not verify if they
work or not.
Dennis
> https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
>
> Andrew
>
> ---
> pw-bot: cr
^ permalink raw reply
* Re: [PATCH 04/33] rust: remove `RUSTC_HAS_SLICE_AS_FLATTENED` and simplify code
From: Gary Guo @ 2026-04-01 13:18 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-5-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> With the Rust version bump in place, the `RUSTC_HAS_SLICE_AS_FLATTENED`
> Kconfig (automatic) option is always true.
>
> Thus remove the option and simplify the code.
>
> In particular, this includes removing the `slice` module which contained
> the temporary slice helpers, i.e. the `AsFlattened` extension trait and
> its `impl`s.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> init/Kconfig | 3 ---
> rust/kernel/lib.rs | 1 -
> rust/kernel/prelude.rs | 3 ---
> rust/kernel/slice.rs | 49 ------------------------------------------
> 4 files changed, 56 deletions(-)
> delete mode 100644 rust/kernel/slice.rs
^ permalink raw reply
* Re: [PATCH] net: lpc_eth: Fix a possible memory leak in lpc_mii_probe()
From: Ma Ke @ 2026-04-01 13:18 UTC (permalink / raw)
To: vz
Cc: alexandre.belloni, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-kernel, make24, netdev, pabeni,
piotr.wojtaszczyk, stable
In-Reply-To: <b44db9e6-f820-439d-a7ed-c1e2514579a8@mleia.com>
On 3/30/26 13:04, Vladimir Zapolskiy wrote:
> On 3/30/26 11:16, Ma Ke wrote:
> > lpc_mii_probe() calls of_phy_find_device() to obtain a phy_device
> > pointer. of_phy_find_device() increments the refcount of the device.
> > The current implementation does not decrement the refcount after using
> > the pointer, which leads to a memory leak.
>
> this is correct, there is an actual detected bug.
>
> >
> > Add phy_device_free() to balance the refcount.
>
> But this does not sound right, you shoud use of_node_put(pldat->phy_node).
>
> >
> > Found by code review.
> >
> > Signed-off-by: Ma Ke <make24@iscas.ac.cn>
> > Cc: stable@vger.kernel.org
> > Fixes: 3503bf024b3e ("net: lpc_eth: parse phy nodes from device tree")
> > ---
> > drivers/net/ethernet/nxp/lpc_eth.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
> > index 8b9a3e3bba30..8ce7c9bb6dd6 100644
> > --- a/drivers/net/ethernet/nxp/lpc_eth.c
> > +++ b/drivers/net/ethernet/nxp/lpc_eth.c
> > @@ -751,7 +751,7 @@ static void lpc_handle_link_change(struct net_device *ndev)
> > static int lpc_mii_probe(struct net_device *ndev)
> > {
> > struct netdata_local *pldat = netdev_priv(ndev);
> > - struct phy_device *phydev;
> > + struct phy_device *phydev, *phydev_tmp;
> >
> > /* Attach to the PHY */
> > if (lpc_phy_interface_mode(&pldat->pdev->dev) == PHY_INTERFACE_MODE_MII)
> > @@ -760,17 +760,18 @@ static int lpc_mii_probe(struct net_device *ndev)
> > netdev_info(ndev, "using RMII interface\n");
> >
> > if (pldat->phy_node)
> > - phydev = of_phy_find_device(pldat->phy_node);
> > + phydev_tmp = of_phy_find_device(pldat->phy_node);
> > else
> > - phydev = phy_find_first(pldat->mii_bus);
> > - if (!phydev) {
> > + phydev_tmp = phy_find_first(pldat->mii_bus);
> > + if (!phydev_tmp) {
>
> I didn't get it, why the new phydev_tmp is needed above, please
> restore the original code above.
>
> > netdev_err(ndev, "no PHY found\n");
> > return -ENODEV;
> > }
> >
> > - phydev = phy_connect(ndev, phydev_name(phydev),
> > + phydev = phy_connect(ndev, phydev_name(phydev_tmp),
> > &lpc_handle_link_change,
> > lpc_phy_interface_mode(&pldat->pdev->dev));
> > + phy_device_free(phydev_tmp);
>
> This is plainly wrong and has to be dropped or changed to
>
> if (pldat->phy_node)
> of_node_put(pldat->phy_node);
>
> > if (IS_ERR(phydev)) {
> > netdev_err(ndev, "Could not attach to PHY\n");
> > return PTR_ERR(phydev);
>
> Is it AI generated fix or what?.. The change looks bad, it introduces
> more severe issues than it fixes.
>
> If you think you cannot create a proper change, let me know.
>
> --
> Best wishes,
> Vladimir
Thank you very much for your detailed review and guidance.
Now I think your point probably is: you are saying that the real leak
is not from of_phy_find_device(), but from the device node
pldat->phy_node which was obtained earlier (probably by
of_parse_phandle()) and never freed by of_node_put(). And you suggest
to add of_node_put(pldat->phy_node) instead of my wrong
phy_device_free().
However, I am still a little confused. In lpc_mii_probe(),
of_phy_find_device() is called. From my understanding, this function
increases the reference count of the device. To balance it, I thought
phy_device_free() (which calls put_device()) should be used.
Could you please kindly advise the correct patch? I will follow your
guidance and submit a proper fix.
I apologize again for my previous wrong patch. Thank you very much for
your help.
Best regards,
Ma Ke
^ permalink raw reply
* Re: [PATCH 03/33] rust: simplify `RUSTC_VERSION` Kconfig conditions
From: Gary Guo @ 2026-04-01 13:18 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-4-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> With the Rust version bump in place, several Kconfig conditions based on
> `RUSTC_VERSION` are always true.
>
> Thus simplify them.
>
> The minimum supported major LLVM version by our new Rust minimum version
> is now LLVM 18, instead of LLVM 16. However, there are no possible
> cleanups for `RUSTC_LLVM_VERSION`.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> arch/Kconfig | 3 +--
> arch/arm64/Kconfig | 8 --------
> arch/riscv/Kconfig | 3 ---
> init/Kconfig | 2 --
> 4 files changed, 1 insertion(+), 15 deletions(-)
^ permalink raw reply
* [PATCH 1/2] arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S
From: Diederik de Haas @ 2026-04-01 13:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Diederik de Haas, Arnd Bergmann, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260401131551.734456-1-diederik@cknow-tech.com>
According to the NanoPi R5S 2204 schematic on page 6, GPIO0_C4 is for
GMAC0_INT/PMEB_GPIO0_C4, while GPIO0_C5 is for GMAC0_RSTn_GPIO0_C5.
While the 'reset-gpios' property was set correctly, the corresponding
pinctrl didn't match that.
Next to fixing the pinctrl definition, also change the node name and
phandle to match what is used in the schematic.
Fixes: c6629b9a6738 ("arm64: dts: rockchip: Add FriendlyElec Nanopi R5S")
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
---
arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
index 718d1a2da8e5..90ce6f0e1dcf 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
@@ -98,7 +98,7 @@ &mdio0 {
rgmii_phy0: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
- pinctrl-0 = <ð_phy0_reset_pin>;
+ pinctrl-0 = <&gmac0_rstn_gpio0_c5_pin>;
pinctrl-names = "default";
};
};
@@ -132,8 +132,8 @@ &pcie3x2 {
&pinctrl {
gmac0 {
- eth_phy0_reset_pin: eth-phy0-reset-pin {
- rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_up>;
+ gmac0_rstn_gpio0_c5_pin: gmac0-rstn-gpio0-c5-pin {
+ rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] Improve gmac0 DT config for NanoPi R5S
From: Diederik de Haas @ 2026-04-01 13:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Diederik de Haas, Arnd Bergmann, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
These 2 patches contain a fix for an incorrect pinctlr definition and
replaces several deprecated snps,reset* properties with their
non-deprecated replacements.
Diederik de Haas (2):
arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S
arm64: dts: rockchip: Replace deprecated snps,* props for NanoPi R5S
arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 2/2] arm64: dts: rockchip: Replace deprecated snps,* props for NanoPi R5S
From: Diederik de Haas @ 2026-04-01 13:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Diederik de Haas, Arnd Bergmann, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260401131551.734456-1-diederik@cknow-tech.com>
The various snps,reset-* properties are deprecated, so convert them into
their replacements.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
---
arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
index 90ce6f0e1dcf..92d044ec696b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-nanopi-r5s.dts
@@ -85,10 +85,6 @@ &gmac0_tx_bus2
&gmac0_rx_bus2
&gmac0_rgmii_clk
&gmac0_rgmii_bus>;
- snps,reset-gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_LOW>;
- snps,reset-active-low;
- /* Reset time is 15ms, 50ms for rtl8211f */
- snps,reset-delays-us = <0 15000 50000>;
tx_delay = <0x3c>;
rx_delay = <0x2f>;
status = "okay";
@@ -100,6 +96,9 @@ rgmii_phy0: ethernet-phy@1 {
reg = <1>;
pinctrl-0 = <&gmac0_rstn_gpio0_c5_pin>;
pinctrl-names = "default";
+ reset-assert-us = <15000>;
+ reset-deassert-us = <50000>;
+ reset-gpios = <&gpio0 RK_PC5 GPIO_ACTIVE_LOW>;
};
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 02/33] rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
From: Gary Guo @ 2026-04-01 13: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-3-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> Following the Rust compiler bump, we can now update Clippy's MSRV we
> set in the configuration, which will improve the diagnostics it generates.
>
> Thus do so and clean a few of the `allow`s that are not needed anymore.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> .clippy.toml | 2 +-
> drivers/gpu/nova-core/gsp/cmdq.rs | 6 +-----
> rust/kernel/ptr.rs | 1 -
> rust/kernel/transmute.rs | 2 --
> 4 files changed, 2 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Jason Gunthorpe @ 2026-04-01 12:58 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: 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, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
Jon Hunter, patches, Robin Murphy, Samiullah Khawaja, stable,
Vasant Hegde
In-Reply-To: <ac0AKyvHMYHlqL5i@google.com>
On Wed, Apr 01, 2026 at 11:23:23AM +0000, Pranjal Shrivastava wrote:
> I was wondering if, as a longer-term direction, having an explicit flag
> for these drivers to indicate they always require a sync would be a
> cleaner way to handle this than the trivial population?
My first thought was to just set the gather to start=0,end=ULONG_MAX
but it turned out to be trivial to just set the right gather parameters
and it looks like it is basically the same cost..
Adding a flag would mean we have to test the flag on the other case
where we don't use this flow, which doesn't seem good either.
Jason
^ permalink raw reply
* RE: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux
From: Erim, Salih @ 2026-04-01 13:12 UTC (permalink / raw)
To: Simek, Michal, Jonathan Cameron, Christofer Jonason,
O'Griofa, Conall
Cc: 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: <IA1PR12MB7736AE6EEE95D5D184A15B9F9F50A@IA1PR12MB7736.namprd12.prod.outlook.com>
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Salih Erim <salih.erim@amd.com>
> -----Original Message-----
> From: Erim, Salih
> Sent: Wednesday, April 1, 2026 2:12 PM
> To: Simek, Michal <michal.simek@amd.com>; Jonathan Cameron
> <jic23@kernel.org>; Christofer Jonason <christofer.jonason@guidelinegeo.com>;
> O'Griofa, Conall <conall.ogriofa@amd.com>
> Cc: 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
> Subject: RE: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable
> for dual mux
>
> Hi Christofer,
>
> The code change looks correct to me - it aligns postdisable with preenable by
> reusing xadc_get_seq_mode(), and the scope is limited to dual external mux
> configurations.
>
> Since this is targeting stable, could you please share what hardware/board this was
> tested on and how you verified that VAUX[8-15] channels return correct data with
> the fix applied?
>
> Reviewed-by: Salih Emin <salih.emin@amd.com>
>
> Thanks,
> Salih
>
>
> > -----Original Message-----
> > From: Simek, Michal <michal.simek@amd.com>
> > Sent: Tuesday, March 10, 2026 7:43 AM
> > To: Jonathan Cameron <jic23@kernel.org>; Christofer Jonason
> > <christofer.jonason@guidelinegeo.com>; Erim, Salih
> > <Salih.Erim@amd.com>; O'Griofa, Conall <conall.ogriofa@amd.com>
> > Cc: 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
> > Subject: Re: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in
> > postdisable for dual mux
> >
> > +Salih, Conall,
> >
> > On 3/7/26 13:41, Jonathan Cameron wrote:
> > > On Wed, 4 Mar 2026 10:07:27 +0100
> > > Christofer Jonason <christofer.jonason@guidelinegeo.com> wrote:
> > >
> > >> xadc_postdisable() unconditionally sets the sequencer to continuous
> > >> mode. For dual external multiplexer configurations this is incorrect:
> > >> simultaneous sampling mode is required so that ADC-A samples
> > >> through the mux on VAUX[0-7] while ADC-B simultaneously samples
> > >> through the mux on VAUX[8-15]. In continuous mode only ADC-A is
> > >> active, so VAUX[8-15] channels return incorrect data.
> > >>
> > >> Since postdisable is also called from xadc_probe() to set the
> > >> initial idle state, the wrong sequencer mode is active from the
> > >> moment the driver loads.
> > >>
> > >> The preenable path already uses xadc_get_seq_mode() which returns
> > >> SIMULTANEOUS for dual mux. Fix postdisable to do the same.
> > >>
> > >> Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver")
> > >> Cc: stable@vger.kernel.org
> > >> Signed-off-by: Christofer Jonason
> > >> <christofer.jonason@guidelinegeo.com>
> > >
> > > I'll leave this on list for a little longer as I'd really like a
> > > confirmation of this one from the AMD Xilinx folk.
> >
> > Salih/Conall: Please look at this patch and provide your comment or tag.
> >
> > Thanks,
> > Michal
^ permalink raw reply
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Gary Guo @ 2026-04-01 13:11 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-2-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, 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>
Acked-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/process/changes.rst | 2 +-
> scripts/min-tool-version.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* RE: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux
From: Erim, Salih @ 2026-04-01 13:11 UTC (permalink / raw)
To: Simek, Michal, Jonathan Cameron, Christofer Jonason,
O'Griofa, Conall
Cc: 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: <1166aeef-0c93-408d-b265-9037f2840074@amd.com>
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Christofer,
The code change looks correct to me - it aligns postdisable with
preenable by reusing xadc_get_seq_mode(), and the scope is limited
to dual external mux configurations.
Since this is targeting stable, could you please share what hardware/board
this was tested on and how you verified that VAUX[8-15] channels
return correct data with the fix applied?
Reviewed-by: Salih Emin <salih.emin@amd.com>
Thanks,
Salih
> -----Original Message-----
> From: Simek, Michal <michal.simek@amd.com>
> Sent: Tuesday, March 10, 2026 7:43 AM
> To: Jonathan Cameron <jic23@kernel.org>; Christofer Jonason
> <christofer.jonason@guidelinegeo.com>; Erim, Salih <Salih.Erim@amd.com>;
> O'Griofa, Conall <conall.ogriofa@amd.com>
> Cc: 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
> Subject: Re: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable
> for dual mux
>
> +Salih, Conall,
>
> On 3/7/26 13:41, Jonathan Cameron wrote:
> > On Wed, 4 Mar 2026 10:07:27 +0100
> > Christofer Jonason <christofer.jonason@guidelinegeo.com> wrote:
> >
> >> xadc_postdisable() unconditionally sets the sequencer to continuous
> >> mode. For dual external multiplexer configurations this is incorrect:
> >> simultaneous sampling mode is required so that ADC-A samples through
> >> the mux on VAUX[0-7] while ADC-B simultaneously samples through the
> >> mux on VAUX[8-15]. In continuous mode only ADC-A is active, so
> >> VAUX[8-15] channels return incorrect data.
> >>
> >> Since postdisable is also called from xadc_probe() to set the initial
> >> idle state, the wrong sequencer mode is active from the moment the
> >> driver loads.
> >>
> >> The preenable path already uses xadc_get_seq_mode() which returns
> >> SIMULTANEOUS for dual mux. Fix postdisable to do the same.
> >>
> >> Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver")
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Christofer Jonason
> >> <christofer.jonason@guidelinegeo.com>
> >
> > I'll leave this on list for a little longer as I'd really like a
> > confirmation of this one from the AMD Xilinx folk.
>
> Salih/Conall: Please look at this patch and provide your comment or tag.
>
> Thanks,
> Michal
^ permalink raw reply
* Re: [PATCH] ASoC: mxs-sgtl5000: disable MCLK on error paths of mxs_sgtl5000_probe()
From: Mark Brown @ 2026-04-01 12:53 UTC (permalink / raw)
To: Haoxiang Li
Cc: lgirdwood, perex, tiwai, shawnguo, s.hauer, kernel, festevam,
linux-sound, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260401053051.586290-1-lihaoxiang@isrc.iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
On Wed, Apr 01, 2026 at 01:30:51PM +0800, Haoxiang Li wrote:
> Call mxs_saif_put_mclk() to disable MCLK on error
> paths of mxs_sgtl5000_probe().
> ret = devm_snd_soc_register_card(&pdev->dev, card);
> - if (ret)
> + if (ret) {
> + mxs_saif_put_mclk(0);
> return dev_err_probe(&pdev->dev, ret, "snd_soc_register_card failed\n");
> + }
This fixes the leak here, however it does highlight that there's a
preexisting issue on remove where we disable the MCLK in remove() but
due to the use of devm_ above we're only unregistering the card after
that has returned.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] dt-bindings: arm-smmu: Add compatible for Hawi SoC
From: Mukesh Ojha @ 2026-04-01 12:47 UTC (permalink / raw)
To: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy
Cc: Robin Murphy, linux-arm-kernel, iommu, devicetree, linux-kernel,
Mukesh Ojha
Qualcomm Hawi SoC include apps smmu that implements arm,mmu-500, which
is used to translate device-visible virtual addresses to physical
addresses. Add compatible for these items.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 27d25bc98cbe..06fb5c8e7547 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -93,6 +93,7 @@ properties:
items:
- enum:
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v2 00/14] net: stmmac: TSO fixes/cleanups
From: Russell King (Oracle) @ 2026-04-01 12:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <420f910f-523d-4a74-a255-2fe48909283a@lunn.ch>
On Wed, Apr 01, 2026 at 02:19:27PM +0200, Andrew Lunn wrote:
> > I'm moving the setup of the GSO features, cleaning those up, and
> > adding a warning if platform glue requests this to be enabled but the
> > hardware has no support. Hopefully this will never trigger if everyone
> > got the STMMAC_FLAG_TSO_EN flag correct.
>
> Is this:
>
> snps,tso:
> $ref: /schemas/types.yaml#/definitions/flag
> description:
> Enables the TSO feature otherwise it will be managed by MAC HW capability
> register.
Like much of stmmac, this description is totally wrong.
snps,tso sets STMMAC_FLAG_TSO_EN in priv->plat->flags, and priv->tso in
unpatched stmmac:
/* Disable tso if asked by ethtool */
if ((priv->plat->flags & STMMAC_FLAG_TSO_EN) && (priv->dma_cap.tsoen)) {
if (features & NETIF_F_TSO)
priv->tso = true;
else
priv->tso = false;
}
and:
if ((priv->plat->flags & STMMAC_FLAG_TSO_EN) && (priv->dma_cap.tsoen)) {
ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
if (priv->plat->core_type == DWMAC_CORE_GMAC4)
ndev->hw_features |= NETIF_F_GSO_UDP_L4;
priv->tso = true;
dev_info(priv->device, "TSO feature enabled\n");
}
So, basically, TSO is only enabled when both the hardware supports it
_and_ snps,tso is specified.
Whereas the description suggests that snps,tso overrides the hardware
if it's specified, otherwise the hardware capability is used.
Given that the hardware capability says whether the hardware is, umm,
*capable* of TSO... yea, DT binding is basically wrong.
Now, how many of those snps.tso in DT are ignored because the hardware
doesn't support TSO... I guess we'll find out!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] clk: visconti: pll: initialize clk_init_data to zero
From: Benoît Monin @ 2026-04-01 12:30 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Nobuhiro Iwamatsu, Rosen Penev,
Brian Masney
Cc: linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <20260330-clk-visconti-init-v1-1-ac3e825e54b5@redhat.com>
On Monday, 30 March 2026 at 16:32:37 CEST, Brian Masney wrote:
> Sashiko reported the following:
>
> > The struct clk_init_data init is declared on the stack without being
> > fully zero-initialized. While fields like name, flags, parent_names,
> > num_parents, and ops are explicitly assigned, the parent_data and
> > parent_hws fields are left containing stack garbage.
>
> clk_core_populate_parent_map() currently prefers the parent names over
> the parent data and hws, so this isn't a problem at the moment. If that
> ordering ever changed in the future, then this could lead to some
> unexpected crashes. Let's just go ahead and make sure that the struct
> clk_init_data is initialized to zero as a good practice.
>
> Fixes: b4cbe606dc367 ("clk: visconti: Add support common clock driver and reset driver")
> Link: https://sashiko.dev/#/patchset/20260326042317.122536-1-rosenp%40gmail.com
> Signed-off-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Benoît Monin <benoit.monin@bootlin.com>
Best regards,
--
Benoît Monin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers
From: Sebastian Ene @ 2026-04-01 12:32 UTC (permalink / raw)
To: catalin.marinas, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm
Cc: joey.gouly, korneld, maz, mrigendra.chaubey, oupton, perlarsen,
sebastianene, suzuki.poulose, will, yuzenghui
Make the SMC handlers accept a 64bit value for the function-id to keep
it uniform with the rest of the code and prevent a u64 -> u32 -> u64
conversion as it currently happens when we handle PSCI.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/include/asm/kvm_hyp.h | 2 +-
arch/arm64/kvm/hyp/include/nvhe/ffa.h | 2 +-
arch/arm64/kvm/hyp/nvhe/ffa.c | 2 +-
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 76ce2b94bd97..c9976425a85c 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -119,7 +119,7 @@ void __sve_restore_state(void *sve_pffr, u32 *fpsr, int restore_ffr);
u64 __guest_enter(struct kvm_vcpu *vcpu);
-bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt, u32 func_id);
+bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt, u64 func_id);
#ifdef __KVM_NVHE_HYPERVISOR__
void __noreturn __hyp_do_panic(struct kvm_cpu_context *host_ctxt, u64 spsr,
diff --git a/arch/arm64/kvm/hyp/include/nvhe/ffa.h b/arch/arm64/kvm/hyp/include/nvhe/ffa.h
index 146e0aebfa1c..21afca11ae0b 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/ffa.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/ffa.h
@@ -12,6 +12,6 @@
#define FFA_MAX_FUNC_NUM 0xFF
int hyp_ffa_init(void *pages);
-bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id);
+bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u64 func_id);
#endif /* __KVM_HYP_FFA_H */
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 94161ea1cd60..87e6d36f120a 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -862,7 +862,7 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
hyp_spin_unlock(&host_buffers.lock);
}
-bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
+bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u64 func_id)
{
struct arm_smccc_1_2_regs res;
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index c3e196fb8b18..79f390057c19 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -278,7 +278,7 @@ static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_
}
}
-bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
+bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt, u64 func_id)
{
unsigned long ret;
--
2.53.0.1185.g05d4b7b318-goog
^ permalink raw reply related
* Re: [PATCH 21/33] gpu: nova-core: bindings: remove unneeded `cfg_attr`
From: Danilo Krummrich @ 2026-04-01 12:29 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-22-ojeda@kernel.org>
On Wed Apr 1, 2026 at 1:45 PM CEST, 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>
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH 11/33] rust: alloc: simplify with `NonNull::add()` now that it is stable
From: Danilo Krummrich @ 2026-04-01 12:28 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-12-ojeda@kernel.org>
On Wed Apr 1, 2026 at 1:45 PM CEST, Miguel Ojeda wrote:
> Currently we need to go through raw pointers and then re-create the
> `NonNull` from the result of offsetting the raw pointer.
>
> Thus, now that we bump the Rust minimum version, simplify using
> `NonNull::add()` and clean the TODO note.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Danilo Krummrich @ 2026-04-01 12:28 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-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>
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8x-colibri: Correct SODIMM PAD settings
From: Peng Fan @ 2026-04-01 12:30 UTC (permalink / raw)
To: Alexander Stein
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Philippe Schenker, Ernest Van Hoecke, linux-arm-kernel,
devicetree, imx, linux-kernel, Peng Fan, Daniel Baluta
In-Reply-To: <1955363.tdWV9SEqCh@steina-w>
On Wed, Apr 01, 2026 at 10:02:48AM +0200, Alexander Stein wrote:
>Am Mittwoch, 1. April 2026, 09:26:03 CEST schrieb Daniel Baluta:
>> On 4/1/26 09:40, Peng Fan (OSS) wrote:
>> > From: Peng Fan <peng.fan@nxp.com>
>> >
>> > SION is BIT(30), not BIT(26). Correct it.
>> >
>> > Fixes: 7ece3cbc8b1ef ("arm64: dts: colibri-imx8x: Add atmel pinctrl groups")
>> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
>>
>> What is the general attitude around using symbolic macros for pin config?
>> Like here: https://www.spinics.net/lists/kernel/msg6072866.html
>>
>> I think there are useful to avoid this kind of bugs.
>>
>> If I get enough Ack's I can move forward and replace all magic numbers from imx dtses.
>
>Somehow I completely missed these defines :-/ That's a good improvement,
>especially as SION bit is "custom".
For in tree dts, I think we need to keep as it is to make stable tree
maintainers apply fixes easily.
For upstreaming new dts, we could force developers to use MACROs.
Regards
Peng
>
>Best regards,
>Alexander
>--
>TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
>Amtsgericht München, HRB 105018
>Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
>http://www.tq-group.com/
>
>
^ 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