* [PATCH v3 5/5] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
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
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v3 0/5] J722S SGMII support
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW and SERDES are very similar to the variants found on the
AM64, but they additionally support SGMII. Introduce new compatible
strings for the J722S to add this support to the drivers.
This is a prerequisite for the Single-Pair Ethernet interface of the
TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
submitted separately.
For SGMII to actually work on the J722S, the am65-cpsw needs to be extended
as well, which has been submitted for net-next:
https://patchwork.kernel.org/project/netdevbpf/list/?series=1075806
Fallback compatible strings allow for the patches to be applied in any
order and to go through different trees without breaking existing
functionality.
v3:
- Drop am65-cpsw changes from this series, they need to go through net-next
- Fix missing PHY_GMII_SEL_RGMII_ID_MODE and PHY_GMII_SEL_FIXED_TX_DELAY in
gmii-sel driver for RGMII delay mode configuration
v2:
- Keep support for the AM64 compatible strings as a fallback, adjust commit
messages
- Drop reference to AM64_CPSW_QUIRK_CUT_THRU flag, which only exists in the
TI vendor kernel
Nora Schiffer (5):
dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel
compatible
phy: ti: phy-j721e-wiz: add support for J722S SoC family
phy: ti: gmii-sel: add support for J722S SoC family
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel
and CPSW3G
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++------
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++--
drivers/phy/ti/phy-gmii-sel.c | 13 ++++++++++
drivers/phy/ti/phy-j721e-wiz.c | 24 +++++++++++++++++++
5 files changed, 75 insertions(+), 18 deletions(-)
--
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
https://www.tq-group.com/
^ permalink raw reply
* [PATCH v3 3/5] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6e9ecb88dc8b7..99a80740cdc6b 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
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
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v3 4/5] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..c2865a6b1d7fb 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,15 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .features = BIT(PHY_GMII_SEL_RGMII_ID_MODE) |
+ BIT(PHY_GMII_SEL_FIXED_TX_DELAY),
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +316,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
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
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v3 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..283e3eedc0f31 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,19 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - items:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
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
https://www.tq-group.com/
^ permalink raw reply related
* 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
* 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 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 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
* [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] 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
* 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
* [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] 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
* 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 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: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] 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 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
* [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
* [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 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
* 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
* 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 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
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