* 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
* [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
* [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 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 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 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 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel 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 gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index be41b4547ec6d..6e12a75100eb8 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -47,15 +47,21 @@ description: |
properties:
compatible:
- enum:
- - ti,am3352-phy-gmii-sel
- - ti,dra7xx-phy-gmii-sel
- - ti,am43xx-phy-gmii-sel
- - ti,dm814-phy-gmii-sel
- - ti,am654-phy-gmii-sel
- - ti,j7200-cpsw5g-phy-gmii-sel
- - ti,j721e-cpsw9g-phy-gmii-sel
- - ti,j784s4-cpsw9g-phy-gmii-sel
+ oneOf:
+ - items:
+ - enum:
+ - ti,am3352-phy-gmii-sel
+ - ti,dra7xx-phy-gmii-sel
+ - ti,am43xx-phy-gmii-sel
+ - ti,dm814-phy-gmii-sel
+ - ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ - items:
+ - enum:
+ - ti,j722s-phy-gmii-sel
+ - const: ti,am654-phy-gmii-sel
reg:
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 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Alice Ryhl @ 2026-04-01 12:24 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, 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 01, 2026 at 01:45:08PM +0200, 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 really *should* pick up 1.85.1. It contains bugfixes serious
enough that the Rust team decided it was reasonble to release a point
release.
> 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: Alice Ryhl <aliceryhl@google.com>
^ permalink raw reply
* Re: [PATCH v2] iommu/rockchip: Drop global rk_ops in favor of per-device ops
From: Jonas Karlman @ 2026-04-01 8:25 UTC (permalink / raw)
To: Simon Xue, Shawn Lin
Cc: iommu, linux-arm-kernel, linux-rockchip, linux-kernel,
Joerg Roedel, Will Deacon, Robin Murphy, Heiko Stuebner
In-Reply-To: <b046ad1c-9cfc-4399-a8df-e4fffff434f9@rock-chips.com>
Hi,
On 4/1/2026 9:59 AM, Simon Xue wrote:
> Hi all,
>
> A gentle ping on this patch.
>
> 在 2026/3/13 17:32, Shawn Lin 写道:
>> 在 2026/03/10 星期二 18:53, Simon Xue 写道:
>>> The driver currently uses a global rk_ops pointer, forcing all IOMMU
>>> instances to share the same operations. This restricts the driver from
>>> supporting SoCs that might integrate different versions of IOMMU
>>> hardware.
>>>
>>> Since the IOMMU framework passes the master device information to
>>> iommu_paging_domain_alloc(), the global variable is no longer needed.
>>>
>>> Fix this by moving rk_ops into struct rk_iommu and struct
>>> rk_iommu_domain.
>>> Initialize it per-device during probe via of_device_get_match_data(),
>>> and replace all global references with the instance-specific pointers.
>>>
>>
>> Thanks for the patch, Simon. I've tested it on the RK3576 EVB1 with
>> PCIe1 + IOMMU. NVMe works fine on it, and I also verified the IOVA
>> allocated in the NVMe driver, they look correct as I manually limited
>> the memblock to under 2GB, so here it is:
>>
>> nvme 0001:21:00.0: cq_dma_addr: 0x00000000f7fc7000
>>
>> Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
>> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
>>
>>> Signed-off-by: Simon Xue <xxm@rock-chips.com>
>>> ---
>>> v2:
>>> - Remove the one-time-used 'ops' variable in rk_iommu_probe()
>>>
>>> drivers/iommu/rockchip-iommu.c | 71 ++++++++++++++++------------------
>>> 1 file changed, 33 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/drivers/iommu/rockchip-iommu.c
>>> b/drivers/iommu/rockchip-iommu.c
>>> index 0013cf196c57..4da80136933c 100644
>>> --- a/drivers/iommu/rockchip-iommu.c
>>> +++ b/drivers/iommu/rockchip-iommu.c
>>> @@ -82,6 +82,14 @@
>>> */
>>> #define RK_IOMMU_PGSIZE_BITMAP 0x007ff000
>>> +struct rk_iommu_ops {
>>> + phys_addr_t (*pt_address)(u32 dte);
>>> + u32 (*mk_dtentries)(dma_addr_t pt_dma);
>>> + u32 (*mk_ptentries)(phys_addr_t page, int prot);
>>> + u64 dma_bit_mask;
>>> + gfp_t gfp_flags;
>>> +};
>>> +
>>> struct rk_iommu_domain {
>>> struct list_head iommus;
>>> u32 *dt; /* page directory table */
>>> @@ -89,6 +97,7 @@ struct rk_iommu_domain {
>>> spinlock_t iommus_lock; /* lock for iommus list */
>>> spinlock_t dt_lock; /* lock for modifying page directory table */
>>> struct device *dma_dev;
>>> + const struct rk_iommu_ops *rk_ops;
>>> struct iommu_domain domain;
>>> };
>>> @@ -98,14 +107,6 @@ static const char * const rk_iommu_clocks[] = {
>>> "aclk", "iface",
>>> };
>>> -struct rk_iommu_ops {
>>> - phys_addr_t (*pt_address)(u32 dte);
>>> - u32 (*mk_dtentries)(dma_addr_t pt_dma);
>>> - u32 (*mk_ptentries)(phys_addr_t page, int prot);
>>> - u64 dma_bit_mask;
>>> - gfp_t gfp_flags;
>>> -};
>>> -
>>> struct rk_iommu {
>>> struct device *dev;
>>> void __iomem **bases;
>>> @@ -117,6 +118,7 @@ struct rk_iommu {
>>> struct iommu_device iommu;
>>> struct list_head node; /* entry in rk_iommu_domain.iommus */
>>> struct iommu_domain *domain; /* domain to which iommu is
>>> attached */
>>> + const struct rk_iommu_ops *rk_ops;
Do we really need the rk_ops on both the rk_iommu and rk_iommu_domain?
>>> };
>>> struct rk_iommudata {
>>> @@ -124,7 +126,6 @@ struct rk_iommudata {
>>> struct rk_iommu *iommu;
>>> };
>>> -static const struct rk_iommu_ops *rk_ops;
>>> static struct iommu_domain rk_identity_domain;
>>> static inline void rk_table_flush(struct rk_iommu_domain *dom,
>>> dma_addr_t dma,
>>> @@ -510,7 +511,7 @@ static int rk_iommu_force_reset(struct rk_iommu
>>> *iommu)
>>> * and verifying that upper 5 (v1) or 7 (v2) nybbles are read
>>> back.
>>> */
>>> for (i = 0; i < iommu->num_mmu; i++) {
>>> - dte_addr = rk_ops->pt_address(DTE_ADDR_DUMMY);
>>> + dte_addr = iommu->rk_ops->pt_address(DTE_ADDR_DUMMY);
Maybe this patch it trying to do too much at once that makes it harder
to review? To simplify review maybe one patch just drops the global
rk_ops and a assigns a local version based on domain/iommu, and a second
patch changes to use the iommu->rk_ops directly? Just a thought.
>>> rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR, dte_addr);
>>> if (dte_addr != rk_iommu_read(iommu->bases[i],
>>> RK_MMU_DTE_ADDR)) {
>>> @@ -551,7 +552,7 @@ static void log_iova(struct rk_iommu *iommu, int
>>> index, dma_addr_t iova)
>>> page_offset = rk_iova_page_offset(iova);
>>> mmu_dte_addr = rk_iommu_read(base, RK_MMU_DTE_ADDR);
>>> - mmu_dte_addr_phys = rk_ops->pt_address(mmu_dte_addr);
>>> + mmu_dte_addr_phys = iommu->rk_ops->pt_address(mmu_dte_addr);
>>> dte_addr_phys = mmu_dte_addr_phys + (4 * dte_index);
>>> dte_addr = phys_to_virt(dte_addr_phys);
>>> @@ -560,14 +561,14 @@ static void log_iova(struct rk_iommu *iommu,
>>> int index, dma_addr_t iova)
>>> if (!rk_dte_is_pt_valid(dte))
>>> goto print_it;
>>> - pte_addr_phys = rk_ops->pt_address(dte) + (pte_index * 4);
>>> + pte_addr_phys = iommu->rk_ops->pt_address(dte) + (pte_index * 4);
>>> pte_addr = phys_to_virt(pte_addr_phys);
>>> pte = *pte_addr;
>>> if (!rk_pte_is_page_valid(pte))
>>> goto print_it;
>>> - page_addr_phys = rk_ops->pt_address(pte) + page_offset;
>>> + page_addr_phys = iommu->rk_ops->pt_address(pte) + page_offset;
>>> page_flags = pte & RK_PTE_PAGE_FLAGS_MASK;
>>> print_it:
>>> @@ -663,13 +664,13 @@ static phys_addr_t rk_iommu_iova_to_phys(struct
>>> iommu_domain *domain,
>>> if (!rk_dte_is_pt_valid(dte))
>>> goto out;
>>> - pt_phys = rk_ops->pt_address(dte);
>>> + pt_phys = rk_domain->rk_ops->pt_address(dte);
>>> page_table = (u32 *)phys_to_virt(pt_phys);
>>> pte = page_table[rk_iova_pte_index(iova)];
>>> if (!rk_pte_is_page_valid(pte))
>>> goto out;
>>> - phys = rk_ops->pt_address(pte) + rk_iova_page_offset(iova);
>>> + phys = rk_domain->rk_ops->pt_address(pte) +
>>> rk_iova_page_offset(iova);
>>> out:
>>> spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
>>> @@ -730,7 +731,7 @@ static u32 *rk_dte_get_page_table(struct
>>> rk_iommu_domain *rk_domain,
>>> if (rk_dte_is_pt_valid(dte))
>>> goto done;
>>> - page_table = iommu_alloc_pages_sz(GFP_ATOMIC | rk_ops->gfp_flags,
>>> + page_table = iommu_alloc_pages_sz(GFP_ATOMIC |
>>> rk_domain->rk_ops->gfp_flags,
>>> SPAGE_SIZE);
>>> if (!page_table)
>>> return ERR_PTR(-ENOMEM);
>>> @@ -742,13 +743,13 @@ static u32 *rk_dte_get_page_table(struct
>>> rk_iommu_domain *rk_domain,
>>> return ERR_PTR(-ENOMEM);
>>> }
>>> - dte = rk_ops->mk_dtentries(pt_dma);
>>> + dte = rk_domain->rk_ops->mk_dtentries(pt_dma);
>>> *dte_addr = dte;
>>> rk_table_flush(rk_domain,
>>> rk_domain->dt_dma + dte_index * sizeof(u32), 1);
>>> done:
>>> - pt_phys = rk_ops->pt_address(dte);
>>> + pt_phys = rk_domain->rk_ops->pt_address(dte);
>>> return (u32 *)phys_to_virt(pt_phys);
>>> }
>>> @@ -790,7 +791,7 @@ static int rk_iommu_map_iova(struct
>>> rk_iommu_domain *rk_domain, u32 *pte_addr,
>>> if (rk_pte_is_page_valid(pte))
>>> goto unwind;
>>> - pte_addr[pte_count] = rk_ops->mk_ptentries(paddr, prot);
>>> + pte_addr[pte_count] = rk_domain->rk_ops->mk_ptentries(paddr,
>>> prot);
>>> paddr += SPAGE_SIZE;
>>> }
>>> @@ -812,7 +813,7 @@ static int rk_iommu_map_iova(struct
>>> rk_iommu_domain *rk_domain, u32 *pte_addr,
>>> pte_count * SPAGE_SIZE);
>>> iova += pte_count * SPAGE_SIZE;
>>> - page_phys = rk_ops->pt_address(pte_addr[pte_count]);
>>> + page_phys = rk_domain->rk_ops->pt_address(pte_addr[pte_count]);
>>> pr_err("iova: %pad already mapped to %pa cannot remap to phys:
>>> %pa prot: %#x\n",
>>> &iova, &page_phys, &paddr, prot);
>>> @@ -849,7 +850,7 @@ static int rk_iommu_map(struct iommu_domain
>>> *domain, unsigned long _iova,
>>> pte_index = rk_iova_pte_index(iova);
>>> pte_addr = &page_table[pte_index];
>>> - pte_dma = rk_ops->pt_address(dte_index) + pte_index *
>>> sizeof(u32);
>>> + pte_dma = rk_domain->rk_ops->pt_address(dte_index) + pte_index *
>>> sizeof(u32);
>>> ret = rk_iommu_map_iova(rk_domain, pte_addr, pte_dma, iova,
>>> paddr, size, prot);
>>> @@ -887,7 +888,7 @@ static size_t rk_iommu_unmap(struct
>>> iommu_domain *domain, unsigned long _iova,
>>> return 0;
>>> }
>>> - pt_phys = rk_ops->pt_address(dte);
>>> + pt_phys = rk_domain->rk_ops->pt_address(dte);
>>> pte_addr = (u32 *)phys_to_virt(pt_phys) + rk_iova_pte_index(iova);
>>> pte_dma = pt_phys + rk_iova_pte_index(iova) * sizeof(u32);
>>> unmap_size = rk_iommu_unmap_iova(rk_domain, pte_addr, pte_dma,
>>> size);
>>> @@ -945,7 +946,7 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
>>> for (i = 0; i < iommu->num_mmu; i++) {
>>> rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
>>> - rk_ops->mk_dtentries(rk_domain->dt_dma));
>>> + iommu->rk_ops->mk_dtentries(rk_domain->dt_dma));
>>> rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
>>> rk_iommu_write(iommu->bases[i], RK_MMU_INT_MASK,
>>> RK_MMU_IRQ_MASK);
>>> }
>>> @@ -1068,17 +1069,19 @@ static struct iommu_domain
>>> *rk_iommu_domain_alloc_paging(struct device *dev)
>>> if (!rk_domain)
>>> return NULL;
>>> + iommu = rk_iommu_from_dev(dev);
>>> + rk_domain->rk_ops = iommu->rk_ops;
As mentioned above, this seem strange and is possible just a shortcut
due to current call-paths? Why do we assign "iommu ops" to the domain?
Regards,
Jonas
>>> +
>>> /*
>>> * rk32xx iommus use a 2 level pagetable.
>>> * Each level1 (dt) and level2 (pt) table has 1024 4-byte entries.
>>> * Allocate one 4 KiB page for each table.
>>> */
>>> - rk_domain->dt = iommu_alloc_pages_sz(GFP_KERNEL |
>>> rk_ops->gfp_flags,
>>> + rk_domain->dt = iommu_alloc_pages_sz(GFP_KERNEL |
>>> rk_domain->rk_ops->gfp_flags,
>>> SPAGE_SIZE);
>>> if (!rk_domain->dt)
>>> goto err_free_domain;
>>> - iommu = rk_iommu_from_dev(dev);
>>> rk_domain->dma_dev = iommu->dev;
>>> rk_domain->dt_dma = dma_map_single(rk_domain->dma_dev,
>>> rk_domain->dt,
>>> SPAGE_SIZE, DMA_TO_DEVICE);
>>> @@ -1117,7 +1120,7 @@ static void rk_iommu_domain_free(struct
>>> iommu_domain *domain)
>>> for (i = 0; i < NUM_DT_ENTRIES; i++) {
>>> u32 dte = rk_domain->dt[i];
>>> if (rk_dte_is_pt_valid(dte)) {
>>> - phys_addr_t pt_phys = rk_ops->pt_address(dte);
>>> + phys_addr_t pt_phys = rk_domain->rk_ops->pt_address(dte);
>>> u32 *page_table = phys_to_virt(pt_phys);
>>> dma_unmap_single(rk_domain->dma_dev, pt_phys,
>>> SPAGE_SIZE, DMA_TO_DEVICE);
>>> @@ -1197,7 +1200,6 @@ static int rk_iommu_probe(struct
>>> platform_device *pdev)
>>> struct device *dev = &pdev->dev;
>>> struct rk_iommu *iommu;
>>> struct resource *res;
>>> - const struct rk_iommu_ops *ops;
>>> int num_res = pdev->num_resources;
>>> int err, i;
>>> @@ -1211,16 +1213,9 @@ static int rk_iommu_probe(struct
>>> platform_device *pdev)
>>> iommu->dev = dev;
>>> iommu->num_mmu = 0;
>>> - ops = of_device_get_match_data(dev);
>>> - if (!rk_ops)
>>> - rk_ops = ops;
>>> -
>>> - /*
>>> - * That should not happen unless different versions of the
>>> - * hardware block are embedded the same SoC
>>> - */
>>> - if (WARN_ON(rk_ops != ops))
>>> - return -EINVAL;
>>> + iommu->rk_ops = of_device_get_match_data(dev);
>>> + if (!iommu->rk_ops)
>>> + return -ENOENT;
>>> iommu->bases = devm_kcalloc(dev, num_res, sizeof(*iommu->bases),
>>> GFP_KERNEL);
>>> @@ -1286,7 +1281,7 @@ static int rk_iommu_probe(struct
>>> platform_device *pdev)
>>> goto err_pm_disable;
>>> }
>>> - dma_set_mask_and_coherent(dev, rk_ops->dma_bit_mask);
>>> + dma_set_mask_and_coherent(dev, iommu->rk_ops->dma_bit_mask);
>>> err = iommu_device_sysfs_add(&iommu->iommu, dev, NULL,
>>> dev_name(dev));
>>> if (err)
>>>
>>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH] iommu/rockchip: fix page table allocation flags for v2 IOMMU
From: Jonas Karlman @ 2026-04-01 8:41 UTC (permalink / raw)
To: Simon, Midgy BALON
Cc: iommu, joro, will, robin.murphy, heiko, linux-arm-kernel,
linux-rockchip, linux-kernel, stable
In-Reply-To: <0f285782-b12a-4abd-bca7-b6c549bed59f@rock-chips.com>
Hi Simon,
On 4/1/2026 9:48 AM, Simon wrote:
> Hi Midgy,
>
> 在 2026/3/31 15:50, Midgy BALON 写道:
>> commit 2a7e6400f72b ("iommu: rockchip: Allocate tables from all
>> available memory for IOMMU v2") removed GFP_DMA32 from
>> iommu_data_ops_v2, reasoning that RK356x and RK3588 IOMMU v2 hardware
>> supports up to 40-bit physical addresses for page tables. However, the
>> RK3568 IOMMU page-table walker uses a 32-bit AXI bus: it cannot access
>> physical addresses above 4 GB regardless of the address encoding range.
>>
>> On boards with more than 4 GB of RAM (e.g. 8 GB LPDDR4X), removing
>> GFP_DMA32 causes two distinct failure modes:
>>
>> 1. Direct allocation above 4 GB: iommu_alloc_pages_sz() may return
>> memory above 0x100000000. The hardware page-table walker issues a
>> bus error trying to dereference those addresses, causing an IOMMU
>> fault on the first DMA transaction.
>
> Which IP block is hitting this? We'd like to take a look on our end.
I have seen reports that the NPU MMU on RK3568/RK3566 is having some
issue using DTE/PTE with >32-bit addresses, maybe it uses a different
MMU hw revision or has some hw errata?
From my own testing at least the VOP2 MMU on RK3568 (and RK3588) was
able to handle 40-bit addressable DTE/PTE, hence the original commit
2a7e6400f72b ("iommu: rockchip: Allocate tables from all available
memory for IOMMU v2").
As also mentioned in my reply at [1], maybe the NPU MMU has some hw
limitation or errata and may need to use a different compatible.
[1] https://lore.kernel.org/r/3cd63b3d-1c5e-4a11-856e-c4aeb5d97d55@kwiboo.se/
Regards,
Jonas
>
>> 2. SWIOTLB bounce-buffer poisoning: without GFP_DMA32, page tables land
>> above the SWIOTLB window. dma_map_single() with DMA_BIT_MASK(32)
>> then bounces them into a buffer below 4 GB. rk_dte_get_page_table()
>> returns phys_to_virt() of the bounce buffer address; PTEs are written
>> there; the next dma_sync_single_for_device(DMA_TO_DEVICE) copies the
>> original (zero) data back over the bounce buffer, silently erasing the
>> freshly written PTEs. The IOMMU faults because every PTE reads as zero.
>
> This probably need a separate patch. One way to fix it would be to track the
> original L2 page table base addresses in struct rk_iommu_domain,
> then have rk_dte_get_page_table() return the tracked address instead of
> deriving it from the DTE.
>
>> Restore GFP_DMA32 (and DMA_BIT_MASK(32)) for iommu_data_ops_v2, which
>> currently only serves "rockchip,rk3568-iommu" in mainline.
>>
>> Tested on Radxa ROCK 3B (RK3568, 8 GB LPDDR4X):
>> - MobileNetV1 via RKNN: 5.8 ms/inference (IOMMU mode)
>> - YOLOv5s 640x640 via RKNN: ~57 ms/inference (IOMMU mode)
>> - No IOMMU faults, correct inference results
>>
>> Fixes: 2a7e6400f72b ("iommu: rockchip: Allocate tables from all available memory for IOMMU v2")
>> Cc: stable@vger.kernel.org
>> Cc: Jonas Karlman <jonas@kwiboo.se>
>> Signed-off-by: Midgy BALON <midgy971@gmail.com>
>> ---
>> drivers/iommu/rockchip-iommu.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
>> index 85f3667e797..8b45db29471 100644
>> --- a/drivers/iommu/rockchip-iommu.c
>> +++ b/drivers/iommu/rockchip-iommu.c
>> @@ -1358,8 +1358,8 @@ static struct rk_iommu_ops iommu_data_ops_v2 = {
>> .pt_address = &rk_dte_pt_address_v2,
>> .mk_dtentries = &rk_mk_dte_v2,
>> .mk_ptentries = &rk_mk_pte_v2,
>> - .dma_bit_mask = DMA_BIT_MASK(40),
>> - .gfp_flags = 0,
>> + .dma_bit_mask = DMA_BIT_MASK(32),
>> + .gfp_flags = GFP_DMA32,
>> };
>>
>> static const struct of_device_id rk_iommu_dt_ids[] = {
^ permalink raw reply
* Re: [PATCH net-next v2 00/14] net: stmmac: TSO fixes/cleanups
From: Andrew Lunn @ 2026-04-01 12:19 UTC (permalink / raw)
To: Russell King (Oracle)
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: <aczHVF04LIGq_lYO@shell.armlinux.org.uk>
> 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.
I would not be too surprised if there is cargo cult copy/paste going
on and some do get it wrong.
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi: snps,tso;
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi: snps,tso;
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi: snps,tso;
arch/arm64/boot/dts/toshiba/tmpv7708.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3576.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3576.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3568.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3528.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3528.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/qcs404.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/lemans.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/lemans.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/sm8150.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/sc8280xp.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/sc8280xp.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/monaco.dtsi: snps,tso;
arch/arm64/boot/dts/st/stm32mp253.dtsi: snps,tso;
arch/arm64/boot/dts/st/stm32mp233.dtsi: snps,tso;
arch/arm64/boot/dts/st/stm32mp231.dtsi: snps,tso;
arch/arm64/boot/dts/st/stm32mp251.dtsi: snps,tso;
arch/riscv/boot/dts/sophgo/sg2042.dtsi: snps,tso;
arch/riscv/boot/dts/sophgo/sg2044.dtsi: snps,tso;
arch/riscv/boot/dts/starfive/jh7110.dtsi: snps,tso;
arch/riscv/boot/dts/starfive/jh7110.dtsi: snps,tso;
arch/arm/boot/dts/axis/artpec6.dtsi: snps,tso;
arch/arm/boot/dts/rockchip/rv1126.dtsi: snps,tso;
arch/arm/boot/dts/st/stm32mp131.dtsi: snps,tso;
arch/arm/boot/dts/st/stm32mp133.dtsi: snps,tso;
arch/arm/boot/dts/st/stm32mp151.dtsi: snps,tso;
Andrew
^ permalink raw reply
* [PATCH net-next v3 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Nora Schiffer @ 2026-04-01 12:05 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
v2: keep ti,am642-cpsw-nuss as a fallback
v3: resubmission for net-next, no changes
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index a959c1d7e643a..70d25f5ff1cfe 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -53,13 +53,19 @@ properties:
"#size-cells": true
compatible:
- enum:
- - ti,am642-cpsw-nuss
- - ti,am654-cpsw-nuss
- - ti,j7200-cpswxg-nuss
- - ti,j721e-cpsw-nuss
- - ti,j721e-cpswxg-nuss
- - ti,j784s4-cpswxg-nuss
+ oneOf:
+ - items:
+ - enum:
+ - ti,am642-cpsw-nuss
+ - ti,am654-cpsw-nuss
+ - ti,j7200-cpswxg-nuss
+ - ti,j721e-cpsw-nuss
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
+ - items:
+ - enum:
+ - ti,j722s-cpsw-nuss
+ - const: ti,am642-cpsw-nuss
reg:
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
* [PATCH net-next v3 2/2] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-01 12:05 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <e7ec1b928357d1240a962a88dc6ac67fd2c92357.1774958552.git.nora.schiffer@ew.tq-group.com>
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
v2: drop AM64_CPSW_QUIRK_CUT_THRU flag, which is a downstream ti-linux feature
v3: resubmission for net-next, no changes
SGMII operation also requires changes to the phy-j721e-wiz and gmii-sel drivers.
The full series was previously posted here:
https://lore.kernel.org/lkml/cover.1774354734.git.nora.schiffer@ew.tq-group.com/
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d9400599e80a4..7ac75fc8cdcf4 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -3468,6 +3468,13 @@ static const struct am65_cpsw_pdata am64x_cpswxg_pdata = {
.fdqring_mode = K3_RINGACC_RING_MODE_RING,
};
+static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
+ .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ,
+ .ale_dev_id = "am64-cpswxg",
+ .fdqring_mode = K3_RINGACC_RING_MODE_RING,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const struct am65_cpsw_pdata j7200_cpswxg_pdata = {
.quirks = 0,
.ale_dev_id = "am64-cpswxg",
@@ -3495,6 +3502,7 @@ static const struct of_device_id am65_cpsw_nuss_of_mtable[] = {
{ .compatible = "ti,am654-cpsw-nuss", .data = &am65x_sr1_0},
{ .compatible = "ti,j721e-cpsw-nuss", .data = &j721e_pdata},
{ .compatible = "ti,am642-cpsw-nuss", .data = &am64x_cpswxg_pdata},
+ { .compatible = "ti,j722s-cpsw-nuss", .data = &j722s_cpswxg_pdata},
{ .compatible = "ti,j7200-cpswxg-nuss", .data = &j7200_cpswxg_pdata},
{ .compatible = "ti,j721e-cpswxg-nuss", .data = &j721e_cpswxg_pdata},
{ .compatible = "ti,j784s4-cpswxg-nuss", .data = &j784s4_cpswxg_pdata},
--
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: imx8mp-phyboard-pollux: Add HDMI support
From: Yannic Moog @ 2026-04-01 12:06 UTC (permalink / raw)
To: Paul Kocialkowski, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <20260330223712.2615273-1-paulk@sys-base.io>
On Tue, 2026-03-31 at 00:37 +0200, Paul Kocialkowski wrote:
> The PHYTEC phyBOARD Pollux comes with a HDMI port on the base board.
> Add the required device-tree nodes to enable support for it.
"Only" video is supported, but it does work. You could add that to the description since audio is
also supported upstream and part of HDMI.
Yannic
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Yannic Moog <y.moog@phytec.de>
> ---
> .../freescale/imx8mp-phyboard-pollux-rdk.dts | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
> b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
> index 0fe52c73fc8f..0d52f29813f1 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
> @@ -38,6 +38,18 @@ fan0: fan {
> #cooling-cells = <2>;
> };
>
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + label = "hdmi";
> + type = "a";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_tx_out>;
> + };
> + };
> + };
> +
> panel_lvds1: panel-lvds1 {
> /* compatible panel in overlay */
> backlight = <&backlight_lvds1>;
> @@ -201,6 +213,28 @@ &flexcan2 {
> status = "okay";
> };
>
> +&hdmi_pvi {
> + status = "okay";
> +};
> +
> +&hdmi_tx {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hdmi>;
> + status = "okay";
> +
> + ports {
> + port@1 {
> + hdmi_tx_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> +};
> +
> +&hdmi_tx_phy {
> + status = "okay";
> +};
> +
> &i2c2 {
> clock-frequency = <400000>;
> pinctrl-names = "default", "gpio";
> @@ -244,6 +278,10 @@ &i2c3 {
> scl-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> };
>
> +&lcdif3 {
> + status = "okay";
> +};
> +
> &ldb_lvds_ch1 {
> remote-endpoint = <&panel1_in>;
> };
> @@ -444,6 +482,15 @@ MX8MP_IOMUXC_SAI5_RXD0__GPIO3_IO21 0x154
> >;
> };
>
> + pinctrl_hdmi: hdmigrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c3
> + MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c3
> + MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0
> x19
> + MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0
> x19
> + >;
> + };
> +
> pinctrl_i2c2: i2c2grp {
> fsl,pins = <
> MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c2
^ permalink raw reply
* Re: [PATCH] clk: bcm: rpi: Mark VEC clock as CLK_IGNORE_UNUSED
From: Mark Brown @ 2026-04-01 12:05 UTC (permalink / raw)
To: Maíra Canal
Cc: Michael Turquette, Stephen Boyd, Florian Fainelli,
Broadcom internal kernel review list, Maxime Ripard,
Stefan Wahren, Dom Cobley, Dave Stevenson, linux-clk,
linux-rpi-kernel, linux-arm-kernel, kernel-dev
In-Reply-To: <20260401111416.562279-2-mcanal@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
On Wed, Apr 01, 2026 at 08:13:57AM -0300, Maíra Canal wrote:
> On Raspberry Pi 3B, the VEC clock is used by the VideoCore firmware
> display driver, which remains active until the vc4 driver loads and
> sends NOTIFY_DISPLAY_DONE. If this clock is disabled during boot, a bus
> lockup happens and the firmware becomes unresponsive, causing a complete
> system lockup.
>
> Mark the VEC clock with CLK_IGNORE_UNUSED so it survives the unused
> clock disablement and remains available until the vc4 driver takes over
> display management.
Tested-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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