* Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Rob Herring @ 2026-04-07 20:44 UTC (permalink / raw)
To: Ryan Chen
Cc: Jeremy Kerr, Krzysztof Kozlowski,
andriy.shevchenko@linux.intel.com, Andi Shyti,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <TY2PPF5CB9A1BE64B7988CD85A7189164E1F253A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
On Tue, Mar 31, 2026 at 07:30:58AM +0000, Ryan Chen wrote:
> > Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> > and enable-dma properties
> >
> > Hi Ryan,
> >
> > > > Sounds reasonable, but before you do so, how are you planning to
> > > > manage the allocation of DMA channels across multiple i2c peripherals?
> > > >
> > > The AST2600 I2C hardware has only one can use DMA at a time.
> > > To avoid the complexity of managing DMA channel contention, I plan to
> > > use buffer mode by default for all controllers, which still provides
> > > better performance than byte mode without requiring DMA channel
> > allocation.
> >
> > OK, but your wording there ("by default") implies that DMA is still selectable
> > for one controller peripheral. In which case: you still have the problem of
> > managing DMA channel contention, but now it's at runtime instead.
> >
> > So my question still stands: how are you planning to enforce that DMA is only
> > enabled for one controller?
> >
> > Or are you planning to disable I2C DMA entirely on AST2600?
> Yes, This is my intent to do.
> Disable I2C DMA entirely on AST2600.
> If I remove DMA, should can I keep byte and buffer for sysfs?
28 versions and it's still not clear when you need what mode. Sigh. The
only thing better about sysfs then it's not my problem, but that really
doesn't sound much better.
DMA is only going to be useful for transfers above a certain size. If
you are doing the typical SMBus style register accesses, then DMA is
completely useless. The setup DMA overhead is going to be greater than
just directly reading/writing the I2C controller FIFOs. What's the size
that makes DMA useful? 16, 32, 64 bytes? Something greater than the max
size in buffer mode probably. Really, provide some data that DMA gives
better performance and/or less CPU usage. If you set some minimum size
and request DMA only above that size, is there really that much
contention? If there's some specific device that really needs DMA, then
make that device's driver request it and reserve it.
For byte mode, there's not a clear need nor description of why. Someone
once long ago asked for it... Who cares, if they really want it, then
the issue needs to be described. If a certain device requires certain
timing that byte mode provides, then that should be some property the
driver for the device communicates to the controller. No need for DT
nor sysfs in that case.
Rob
^ permalink raw reply
* Re: [PATCH v2 01/33] rust: kbuild: remove `--remap-path-prefix` workarounds
From: Nicolas Schier @ 2026-04-07 19:39 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Danilo Krummrich, Andreas Hindborg,
Catalin Marinas, Will Deacon, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Courbot, David Airlie, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, 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: <20260405235309.418950-2-ojeda@kernel.org>
On Mon, Apr 06, 2026 at 01:52:37AM +0200, Miguel Ojeda wrote:
> Commit 8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix
> to make paths relative"") removed `--remap-path-prefix` from the build
> system, so the workarounds are not needed anymore.
>
> Thus remove them.
>
> Note that the flag has landed again in parallel in this cycle in
> commit dda135077ecc ("rust: build: remap path to avoid absolute path"),
> together with `--remap-path-scope=macro` [1]. However, they are gated on
> `rustc-option-yn, --remap-path-scope=macro`, which means they are both
> only passed starting with Rust 1.95.0 [2]:
>
> `--remap-path-scope` is only stable in Rust 1.95, so use `rustc-option`
> to detect its presence. This feature has been available as
> `-Zremap-path-scope` for all versions that we support; however due to
> bugs in the Rust compiler, it does not work reliably until 1.94. I opted
> to not enable it for 1.94 as it's just a single version that we missed.
>
> In turn, that means the workarounds removed here should not be needed
> again (even with the flag added again above), since:
>
> - `rustdoc` now recognizes the `--remap-path-prefix` flag since Rust
> 1.81.0 [3] (even if it is still an unstable feature [4]).
>
> - The Internal Compiler Error [5] that the comment mentions was fixed in
> Rust 1.87.0 [6]. We tested that was the case in a previous version
> of this series by making the workaround conditional [7][8].
>
> ...which are both older versions than Rust 1.95.0.
>
> We will still need to skip `--remap-path-scope` for `rustdoc` though,
> since `rustdoc` does not support that one yet [4].
>
> Link: https://github.com/rust-lang/rust/issues/111540 [1]
> Link: https://github.com/rust-lang/rust/pull/147611 [2]
> Link: https://github.com/rust-lang/rust/pull/107099 [3]
> Link: https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#--remap-path-prefix-remap-source-code-paths-in-output [4]
> Link: https://github.com/rust-lang/rust/issues/138520 [5]
> Link: https://github.com/rust-lang/rust/pull/138556 [6]
> Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-9-ojeda@kernel.org/ [7]
> Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-10-ojeda@kernel.org/ [8]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> rust/Makefile | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
Acked-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
^ permalink raw reply
* Re: [PATCH v2 25/33] docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection title
From: Nicolas Schier @ 2026-04-07 19:38 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Danilo Krummrich, Andreas Hindborg,
Catalin Marinas, Will Deacon, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Courbot, David Airlie, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, 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,
Tamir Duberstein
In-Reply-To: <20260405235309.418950-26-ojeda@kernel.org>
On Mon, Apr 06, 2026 at 01:53:01AM +0200, Miguel Ojeda wrote:
> Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few
> weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu
> 25.10 has [2][3].
>
> We could update the title and the paragraph, but to simplify and to
> make it more consistent with the other distributions' sections, let's
> instead just remove that title. It will also reduce the differences
> later on to keep it updated. Eventually, when we remove the remaining
> subsection for older LTSs, Ubuntu should be a small section like the
> other distributions.
>
> Thus remove the title and add the mention of Ubuntu 26.04 LTS.
>
> Link: https://documentation.ubuntu.com/release-notes/26.04/schedule/#resolute-raccoon-schedule [1]
> Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all§ion=all [2]
> Link: https://packages.ubuntu.com/search?keywords=bindgen&searchon=names&exact=1&suite=all§ion=all [3]
> Reviewed-by: Tamir Duberstein <tamird@kernel.org>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> Documentation/rust/quick-start.rst | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
^ permalink raw reply
* Re: [PATCH v2 24/33] docs: rust: quick-start: update minimum Ubuntu version
From: Nicolas Schier @ 2026-04-07 19:37 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Danilo Krummrich, Andreas Hindborg,
Catalin Marinas, Will Deacon, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Courbot, David Airlie, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, 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,
Tamir Duberstein
In-Reply-To: <20260405235309.418950-25-ojeda@kernel.org>
On Mon, Apr 06, 2026 at 01:53:00AM +0200, Miguel Ojeda wrote:
> Ubuntu 25.04 is out of support [1], and Ubuntu 25.10 is the latest
> supported one.
>
> Moreover, Ubuntu 25.10 is the first that provides a recent enough Rust
> given the minimum bump -- they provide 1.85.1 [2].
>
> Thus update it.
>
> Link: https://ubuntu.com/about/release-cycle [1]
> Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all§ion=all [2]
> Reviewed-by: Tamir Duberstein <tamird@kernel.org>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> Documentation/rust/quick-start.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
^ permalink raw reply
* Re: [PATCH v2 33/33] rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
From: Nicolas Schier @ 2026-04-07 19:35 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Danilo Krummrich, Andreas Hindborg,
Catalin Marinas, Will Deacon, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Courbot, David Airlie, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, 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,
Tamir Duberstein
In-Reply-To: <20260405235309.418950-34-ojeda@kernel.org>
On Mon, Apr 06, 2026 at 01:53:09AM +0200, Miguel Ojeda wrote:
> The Clippy `precedence` lint was extended in Rust 1.85.0 to include
> bitmasking and shift operations [1]. However, because it generated
> many hits, in Rust 1.86.0 it was split into a new `precedence_bits`
> lint which is not enabled by default [2].
>
> In other words, only Rust 1.85 has a different behavior. For instance,
> it reports:
>
> warning: operator precedence can trip the unwary
> --> drivers/gpu/nova-core/fb/hal/ga100.rs:16:5
> |
> 16 | / u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT
> 17 | | | u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
> 18 | | << FLUSH_SYSMEM_ADDR_SHIFT_HI
> | |_________________________________________^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
> = note: `-W clippy::precedence` implied by `-W clippy::all`
> = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`
> help: consider parenthesizing your expression
> |
> 16 ~ (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT) | (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
> 17 + << FLUSH_SYSMEM_ADDR_SHIFT_HI)
> |
>
> While so far we try our best to keep all versions Clippy-clean, the
> minimum (which is now Rust 1.85.0 after the bump) and the latest stable
> are the most important ones; and this may be considered a "false positive"
> with respect to the behavior in other versions.
>
> Thus allow this lint for this version using the per-version flags
> mechanism introduced in the previous commit.
>
> Link: https://github.com/rust-lang/rust-clippy/issues/14097 [1]
> Link: https://github.com/rust-lang/rust-clippy/pull/14115 [2]
> Link: https://lore.kernel.org/rust-for-linux/DFVDKMMA7KPC.2DN0951H3H55Y@kernel.org/
> Reviewed-by: Tamir Duberstein <tamird@kernel.org>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Acked-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
^ permalink raw reply
* Re: [PATCH v2 32/33] rust: kbuild: support global per-version flags
From: Nicolas Schier @ 2026-04-07 19:35 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Danilo Krummrich, Andreas Hindborg,
Catalin Marinas, Will Deacon, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Courbot, David Airlie, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, 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: <20260405235309.418950-33-ojeda@kernel.org>
On Mon, Apr 06, 2026 at 01:53:08AM +0200, Miguel Ojeda wrote:
> Sometimes it is useful to gate global Rust flags per compiler version.
> For instance, we may want to disable a lint that has false positives in
> a single version [1].
>
> We already had helpers like `rustc-min-version` for that, which we use
> elsewhere, but we cannot currently use them for `rust_common_flags`,
> which contains the global flags for all Rust code (kernel and host),
> because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which
> does not exist when `rust_common_flags` is defined.
>
> Thus, to support that, introduce `rust_common_flags_per_version`,
> defined after the `include/config/auto.conf` inclusion (where
> `CONFIG_RUSTC_VERSION` becomes available), and append it to
> `rust_common_flags`, `KBUILD_HOSTRUSTFLAGS` and `KBUILD_RUSTFLAGS`.
>
> In addition, move the expansion of `HOSTRUSTFLAGS` to the same place,
> so that users can also override per-version flags [2].
>
> Link: https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1]
> Link: https://lore.kernel.org/rust-for-linux/CANiq72mTaA2tjhkLKf0-2hrrrt9rxWPgy6SfNSbponbGOegQvA@mail.gmail.com/ [2]
> Link: https://patch.msgid.link/20260307170929.153892-1-ojeda@kernel.org
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> Makefile | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
Acked-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
^ permalink raw reply
* [PATCH] crypto: tstmgr - guard xxhash tests
From: Hamza Mahfooz @ 2026-04-07 19:28 UTC (permalink / raw)
To: linux-crypto
Cc: Herbert Xu, David S. Miller, Maxime Coquelin, Alexandre Torgue,
linux-stm32, linux-arm-kernel, linux-kernel, Hamza Mahfooz,
Jeff Barnes, Paul Monson
If the kernel isn't built with CONFIG_CRYPTO_XXHASH and booted with FIPS
mode enabled it will currently panic. So, only benchmark xxhash64 if
CRYPTO_XXHASH is enabled.
Cc: Jeff Barnes <jeffbarnes@linux.microsoft.com>
Cc: Paul Monson <paul.monson@capgemini.com>
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
crypto/testmgr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 4985411dedaec..9e4a040029ab8 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -5609,7 +5609,9 @@ static const struct alg_test_desc alg_test_descs[] = {
#endif
.alg = "xxhash64",
.test = alg_test_hash,
+#if IS_ENABLED(CONFIG_CRYPTO_XXHASH)
.fips_allowed = 1,
+#endif
.suite = {
.hash = __VECS(xxhash64_tv_template)
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 5/5] dt-bindings: usb: atmel,at91sam9rl-udc: convert to DT schema
From: Rob Herring (Arm) @ 2026-04-07 19:11 UTC (permalink / raw)
To: Charan Pedumuru
Cc: Greg Kroah-Hartman, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, Claudiu Beznea, Nicolas Ferre, Herve Codina,
devicetree, linux-kernel, linux-usb, Alexandre Belloni
In-Reply-To: <20260327-atmel-usb-v4-5-eb8b6e49b29d@gmail.com>
On Fri, 27 Mar 2026 16:47:46 +0000, Charan Pedumuru wrote:
> Convert Atmel High-Speed USB Device Controller (USBA) binding to DT schema.
> Changes during conversion:
> - Make the "clock-names" property flexible enough to accept the items
> in any order as the existing in tree DTS nodes doesn't follow an order.
>
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
> .../bindings/usb/atmel,at91sam9rl-udc.yaml | 74 ++++++++++++++++++++++
> .../devicetree/bindings/usb/atmel-usb.txt | 46 --------------
> 2 files changed, 74 insertions(+), 46 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: usb: generic-ohci: add AT91RM9200 OHCI binding support
From: Rob Herring (Arm) @ 2026-04-07 19:08 UTC (permalink / raw)
To: Charan Pedumuru
Cc: linux-arm-kernel, Conor Dooley, linux-usb, Claudiu Beznea,
Herve Codina, Krzysztof Kozlowski, Greg Kroah-Hartman,
linux-kernel, Alexandre Belloni, Nicolas Ferre, devicetree
In-Reply-To: <20260327-atmel-usb-v4-2-eb8b6e49b29d@gmail.com>
On Fri, 27 Mar 2026 16:47:43 +0000, Charan Pedumuru wrote:
> Convert the Atmel AT91RM9200 OHCI USB host controller binding to DT schema
> by defining it in the existing generic OHCI schema.
>
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
> .../devicetree/bindings/usb/atmel-usb.txt | 27 --------------
> .../devicetree/bindings/usb/generic-ohci.yaml | 41 ++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 27 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Rob Herring @ 2026-04-07 18:44 UTC (permalink / raw)
To: Padmashree S S
Cc: andrew, gregory.clement, sebastian.hesselbarth, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260327114653.593582-1-padmashreess2006@gmail.com>
On Fri, Mar 27, 2026 at 05:16:53PM +0530, Padmashree S S wrote:
> Convert armada-380-mpcore-soc-ctrl to DT schema
>
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
> .../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
> .../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
> 2 files changed, 32 insertions(+), 14 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
Please move this to
bindings/soc/marvell/marvell,armada-380-mpcore-soc-ctrl.yaml
Don't forget to update the '$id' value.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
From: Rob Herring (Arm) @ 2026-04-07 18:40 UTC (permalink / raw)
To: Andre Przywara
Cc: Jernej Skrabec, Samuel Holland, linux-gpio, linux-sunxi,
devicetree, linux-arm-kernel, Krzysztof Kozlowski, linux-kernel,
Conor Dooley, Chen-Yu Tsai
In-Reply-To: <20260327113006.3135663-3-andre.przywara@arm.com>
On Fri, 27 Mar 2026 11:30:05 +0000, Andre Przywara wrote:
> The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
> instance, but it skips the first bank (PortA), so their index goes from
> 1 to 10. The same is actually true for the IRQ banks: there are registers
> for 11 banks, though the first bank is not implemented (RAZ/WI).
> In contrast to previous SoCs, the count of the IRQ banks starts with this
> first unimplemented bank, so we need to provide an interrupt for it.
> And indeed the A523 user manual lists an interrupt number for PortA, so we
> need to increase the maximum number of interrupts per pin controller to 11,
> to be able to assign the correct interrupt number for each bank.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/4] perf arm_spe: Decode Arm N1 IMPDEF events
From: Ian Rogers @ 2026-04-07 18:26 UTC (permalink / raw)
To: James Clark
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Adrian Hunter, Al Grant,
linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <ee012f48-5d08-4004-b9d0-bcac825cb50c@linaro.org>
On Tue, Apr 7, 2026 at 5:35 AM James Clark <james.clark@linaro.org> wrote:
>
>
>
> On 02/04/2026 4:26 pm, Ian Rogers wrote:
> > On Wed, Apr 1, 2026 at 7:26 AM James Clark <james.clark@linaro.org> wrote:
> >>
> >> From the TRM [1], N1 has one IMPDEF event which isn't covered by the
> >> common list. Add a framework so that more cores can be added in the
> >> future and that the N1 IMPDEF event can be decoded. Also increase the
> >> size of the buffer because we're adding more strings and if it gets
> >> truncated it falls back to a hex dump only.
> >>
> >> [1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
> >> Suggested-by: Al Grant <al.grant@arm.com>
> >> Signed-off-by: James Clark <james.clark@linaro.org>
> >> ---
> >> tools/perf/util/arm-spe-decoder/Build | 2 +
> >> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 45 ++++++++++++++++++++--
> >> .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 ++-
> >> tools/perf/util/arm-spe.c | 13 ++++---
> >> 4 files changed, 54 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
> >> index ab500e0efe24..97a298d1e279 100644
> >> --- a/tools/perf/util/arm-spe-decoder/Build
> >> +++ b/tools/perf/util/arm-spe-decoder/Build
> >> @@ -1 +1,3 @@
> >> perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
> >> +
> >> +CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
> >> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >> index c880b0dec3a1..42a7501d4dfe 100644
> >> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >> @@ -15,6 +15,8 @@
> >>
> >> #include "arm-spe-pkt-decoder.h"
> >>
> >> +#include "../../arm64/include/asm/cputype.h"
> >
> > Sashiko spotted:
> > https://sashiko.dev/#/patchset/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c%40linaro.org
> > """
> > This isn't a bug, but does this include directive rely on accidental
> > path normalization?
> >
> > The relative path ../../arm64/include/asm/cputype.h does not exist relative
> > to arm-spe-pkt-decoder.c. It only compiles because the Build file adds
> > -I$(srctree)/tools/arch/arm64/include/ to CFLAGS.
> >
> > Would it be cleaner to use #include <asm/cputype.h> to explicitly rely on
> > the include path?
> > [ ... ]
> > """
> > I wouldn't use <asm/cputype.h> due to cross-compilation and the like,
> > instead just add the extra "../" into the include path.
> >
>
> Do you mean change the #include to this?
>
> #include "../../../arm64/include/asm/cputype.h"
>
> I still need to add:
>
> CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/
>
> To make the this include in cputype.h work:
>
> #include <asm/sysreg.h>
>
> Which probably only works because there isn't a sysreg.h on other
> architectures. But I'm not sure what the significance of ../../ vs
> ../../../ is if either compile? arm-spe.c already does it with ../../
> which is what I copied.
Hmm.. maybe the path should be
"../../../arch/arm64/include/asm/cputype.h". The include preference is
for a path relative to the source file and
../../arm64/include/asm/cputype.h doesn't exist. It is kind of horrid
to add an include path and then use a relative path to escape into a
higher-level directory. arm-spe.c is a little different as it is one
directory higher in the directory layout.
Thanks,
Ian
> >> +
> >> static const char * const arm_spe_packet_name[] = {
> >> [ARM_SPE_PAD] = "PAD",
> >> [ARM_SPE_END] = "END",
> >> @@ -307,6 +309,11 @@ static const struct ev_string common_ev_strings[] = {
> >> { .event = 0, .desc = NULL },
> >> };
> >>
> >> +static const struct ev_string n1_event_strings[] = {
> >> + { .event = 12, .desc = "LATE-PREFETCH" },
> >> + { .event = 0, .desc = NULL },
> >> +};
> >> +
> >> static u64 print_event_list(int *err, char **buf, size_t *buf_len,
> >> const struct ev_string *ev_strings, u64 payload)
> >> {
> >> @@ -318,14 +325,44 @@ static u64 print_event_list(int *err, char **buf, size_t *buf_len,
> >> return payload;
> >> }
> >>
> >> +struct event_print_handle {
> >> + const struct midr_range *midr_ranges;
> >> + const struct ev_string *ev_strings;
> >> +};
> >> +
> >> +#define EV_PRINT(range, strings) \
> >> + { \
> >> + .midr_ranges = range, \
> >> + .ev_strings = strings, \
> >> + }
> >> +
> >> +static const struct midr_range n1_event_encoding_cpus[] = {
> >> + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
> >> + {},
> >> +};
> >> +
> >> +static const struct event_print_handle event_print_handles[] = {
> >> + EV_PRINT(n1_event_encoding_cpus, n1_event_strings),
> >> +};
> >> +
> >> static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
> >> - char *buf, size_t buf_len)
> >> + char *buf, size_t buf_len, u64 midr)
> >> {
> >> u64 payload = packet->payload;
> >> int err = 0;
> >>
> >> arm_spe_pkt_out_string(&err, &buf, &buf_len, "EV");
> >> - print_event_list(&err, &buf, &buf_len, common_ev_strings, payload);
> >> + payload = print_event_list(&err, &buf, &buf_len, common_ev_strings,
> >> + payload);
> >> +
> >> + /* Try to decode IMPDEF bits for known CPUs */
> >> + for (unsigned int i = 0; i < ARRAY_SIZE(event_print_handles); i++) {
> >> + if (is_midr_in_range_list(midr,
> >> + event_print_handles[i].midr_ranges))
> >> + payload = print_event_list(&err, &buf, &buf_len,
> >> + event_print_handles[i].ev_strings,
> >> + payload);
> >> + }
> >>
> >> return err;
> >> }
> >> @@ -506,7 +543,7 @@ static int arm_spe_pkt_desc_counter(const struct arm_spe_pkt *packet,
> >> }
> >>
> >> int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
> >> - size_t buf_len)
> >> + size_t buf_len, u64 midr)
> >> {
> >> int idx = packet->index;
> >> unsigned long long payload = packet->payload;
> >> @@ -522,7 +559,7 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
> >> arm_spe_pkt_out_string(&err, &buf, &blen, "%s", name);
> >> break;
> >> case ARM_SPE_EVENTS:
> >> - err = arm_spe_pkt_desc_event(packet, buf, buf_len);
> >> + err = arm_spe_pkt_desc_event(packet, buf, buf_len, midr);
> >> break;
> >> case ARM_SPE_OP_TYPE:
> >> err = arm_spe_pkt_desc_op_type(packet, buf, buf_len);
> >> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> >> index adf4cde320aa..17b067fe3c87 100644
> >> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> >> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> >> @@ -11,7 +11,7 @@
> >> #include <stddef.h>
> >> #include <stdint.h>
> >>
> >> -#define ARM_SPE_PKT_DESC_MAX 256
> >> +#define ARM_SPE_PKT_DESC_MAX 512
> >>
> >> #define ARM_SPE_NEED_MORE_BYTES -1
> >> #define ARM_SPE_BAD_PACKET -2
> >> @@ -186,5 +186,6 @@ const char *arm_spe_pkt_name(enum arm_spe_pkt_type);
> >> int arm_spe_get_packet(const unsigned char *buf, size_t len,
> >> struct arm_spe_pkt *packet);
> >>
> >> -int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len);
> >> +int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len,
> >> + u64 midr);
> >> #endif
> >> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> >> index 7447b000f9cd..46f0309c092b 100644
> >> --- a/tools/perf/util/arm-spe.c
> >> +++ b/tools/perf/util/arm-spe.c
> >> @@ -135,7 +135,7 @@ struct data_source_handle {
> >> }
> >>
> >> static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
> >> - unsigned char *buf, size_t len)
> >> + unsigned char *buf, size_t len, u64 midr)
> >> {
> >> struct arm_spe_pkt packet;
> >> size_t pos = 0;
> >> @@ -161,7 +161,7 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
> >> color_fprintf(stdout, color, " ");
> >> if (ret > 0) {
> >> ret = arm_spe_pkt_desc(&packet, desc,
> >> - ARM_SPE_PKT_DESC_MAX);
> >> + ARM_SPE_PKT_DESC_MAX, midr);
> >> if (!ret)
> >> color_fprintf(stdout, color, " %s\n", desc);
> >> } else {
> >> @@ -174,10 +174,10 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
> >> }
> >>
> >> static void arm_spe_dump_event(struct arm_spe *spe, unsigned char *buf,
> >> - size_t len)
> >> + size_t len, u64 midr)
> >> {
> >> printf(".\n");
> >> - arm_spe_dump(spe, buf, len);
> >> + arm_spe_dump(spe, buf, len, midr);
> >> }
> >>
> >> static int arm_spe_get_trace(struct arm_spe_buffer *b, void *data)
> >> @@ -1469,8 +1469,11 @@ static int arm_spe_process_auxtrace_event(struct perf_session *session,
> >> /* Dump here now we have copied a piped trace out of the pipe */
> >> if (dump_trace) {
> >> if (auxtrace_buffer__get_data(buffer, fd)) {
> >> + u64 midr = 0;
> >> +
> >> + arm_spe__get_midr(spe, buffer->cpu.cpu, &midr);
> >
> > Sashiko claims to have spotted an issue here:
> > """
> > Is it possible for arm_spe__get_midr() to cause a segmentation fault here?
> >
> > If the trace is from an older recording (metadata version 1) and the
> > environment lacks a CPUID string (such as during cross-architecture
> > analysis), perf_env__cpuid() returns NULL.
> >
> > It appears arm_spe__get_midr() then passes this NULL pointer to
> > strtol(cpuid, NULL, 16), which leads to undefined behavior.
> > """
> >
> > But this feels like, if this happens you're already having a bad time
> > and these changes aren't necessarily making things worse.
> >
> > Thanks,
> > Ian
> >
>
> Yeah I think it might be possible so I can add an error instead of a
> segfault. I'll check the rest of the Sashiko comments too.
>
> >> arm_spe_dump_event(spe, buffer->data,
> >> - buffer->size);
> >> + buffer->size, midr);
> >> auxtrace_buffer__put_data(buffer);
> >> }
> >> }
> >>
> >> --
> >> 2.34.1
> >>
>
^ permalink raw reply
* Re: [PATCH v4 01/27] media: dt-bindings: media: rockchip-rga: add rockchip,rk3588-rga3
From: Rob Herring (Arm) @ 2026-04-07 18:10 UTC (permalink / raw)
To: Sven Püschel
Cc: Jacob Chen, devicetree, sebastian.reichel, Ezequiel Garcia,
Krzysztof Kozlowski, Mauro Carvalho Chehab, Heiko Stuebner,
linux-rockchip, linux-kernel, Conor Dooley, linux-arm-kernel,
kernel, nicolas, linux-media
In-Reply-To: <20260325-spu-rga3-v4-1-e90ec1c61354@pengutronix.de>
On Wed, 25 Mar 2026 15:50:32 +0100, Sven Püschel wrote:
> Add a new compatible for the RGA3 (Raster Graphic Acceleration 3)
> peripheral found on the RK3588 SoC. Also specify an iommu property,
> as the RGA3 contains the generic rockchip iommu. While other versions
> also have an iommu, it's usually specific to them.
>
> The RK3588 contains one RGA2-Enhance core (also contained on the RK3399)
> and two RGA3 cores. Both feature a similar functionality of scaling,
> cropping and rotating of up to two input images into one output image.
> Key differences of the RGA3 are:
>
> - supports 10bit YUV output formats
> - supports 8x8 tiles and FBCD as inputs and outputs
> - supports BT2020 color space conversion
> - max output resolution of (8192-64)x(8192-64)
> - MMU can map up to 32G DDR RAM
> - fully planar formats (3 planes) are not supported
> - max scale up/down factor of 8 (RGA2 allows up to 16)
>
> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
>
> ---
>
> Changed in v3/v4:
> - Dropped Acked-by: Krzysztof Kozlowski due to the added iommus property
> and description adjustments.
> ---
> Documentation/devicetree/bindings/media/rockchip-rga.yaml | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/6] mm: change to return bool for the MMU notifier's young flag check
From: Sean Christopherson @ 2026-04-07 17:52 UTC (permalink / raw)
To: Baolin Wang
Cc: Lorenzo Stoakes (Oracle), akpm, david, Liam.Howlett, vbabka, rppt,
surenb, mhocko, linux-arm-kernel, x86, linux-parisc, linuxppc-dev,
linux-riscv, linux-s390, kvm, open, linux-kernel
In-Reply-To: <2a216ee2-aebb-42ba-b2aa-826488448bbe@linux.alibaba.com>
On Tue, Apr 07, 2026, Baolin Wang wrote:
> On 4/4/26 7:12 AM, Sean Christopherson wrote:
> > On Fri, Mar 20, 2026, Baolin Wang wrote:
> > > > > -static __always_inline int kvm_age_hva_range(struct mmu_notifier *mn,
> > > > > - unsigned long start,
> > > > > - unsigned long end,
> > > > > - gfn_handler_t handler,
> > > > > - bool flush_on_ret)
> > > > > +static __always_inline bool kvm_age_hva_range(struct mmu_notifier *mn,
> > > > > + unsigned long start,
> > > > > + unsigned long end,
> > > > > + gfn_handler_t handler,
> > > > > + bool flush_on_ret)
> > > >
> > > > Can we please fix this terrrible indentation while we're here :)?
> > > >
> > > > static __always_inline bool kvm_age_hva_range(struct mmu_notifier *mn,
> > > > unsigned long start, unsigned long end, gfn_handler_t handler,
> > > > bool flush_on_ret)
> > > >
> > > > Would be nicer, thanks!
> >
> > No, please keep this as-is. KVM's preferred style is exactly this (and I personally
> > find mm's style much harder to parse).
>
> Um, Andrew has already queued v2[1] into the mm-stable branch. Do you want
> me to send a follow-up patch to restore the original KVM coding style?
Nah, not worth the churn. Thanks though!
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: sram: Document Allwinner H616 VE SRAM
From: Rob Herring (Arm) @ 2026-04-07 17:51 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-kernel, linux-arm-kernel, Jernej Skrabec, devicetree,
linux-sunxi, Conor Dooley, Krzysztof Kozlowski, Samuel Holland
In-Reply-To: <20260324164357.1607247-2-wens@kernel.org>
On Wed, 25 Mar 2026 00:43:49 +0800, Chen-Yu Tsai wrote:
> The Allwinner H616 has two switchable peripheral SRAM regions:
>
> - The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
> to this region is enabled by default. CPU access can be disabled,
> after which reads will show the same stale value for all addresses,
> while writes are ignored.
>
> The mux value for this region is different from previous generations,
> and thus needs a completely new compatible.
>
> - The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
> KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
> CPU access is disabled, the whole region reads as zero, while writes
> are ignored.
>
> The mux value for this region is the same as on the A64 and H6. The
> existing compatible for the A64 already covers this.
>
> Add the compatible for the VE SRAM to the list of covered compatibles in
> the generic SRAM region binding.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: sram: sunxi-sram: Add H616 SRAM regions
From: Rob Herring (Arm) @ 2026-04-07 17:49 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-kernel, Conor Dooley, Jernej Skrabec, devicetree,
Krzysztof Kozlowski, linux-arm-kernel, Samuel Holland,
linux-sunxi
In-Reply-To: <20260324164357.1607247-3-wens@kernel.org>
On Wed, 25 Mar 2026 00:43:50 +0800, Chen-Yu Tsai wrote:
> The Allwinner H616 has two switchable peripheral SRAM regions:
>
> - The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
> to this region is enabled by default. CPU access can be disabled,
> after which reads will show the same stale value for all addresses,
> while writes are ignored.
>
> The mux value for this region is different from previous generations.
>
> - The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
> KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
> CPU access is disabled, the whole region reads as zero, while writes
> are ignored.
>
> The mux value for this region is the same as on the A64 and H6.
>
> Add compatible strings for both of them.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v2] Bluetooth: Add Broadcom channel priority commands
From: Sasha Finkelstein via B4 Relay @ 2026-04-07 17:46 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
Luiz Augusto von Dentz, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-kernel, asahi, linux-arm-kernel, linux-bluetooth, netdev,
Sasha Finkelstein
From: Sasha Finkelstein <fnkl.kernel@gmail.com>
Certain Broadcom bluetooth chips (bcm4377/bcm4378/bcm438) need ACL
streams carrying audio to be set as "high priority" using a vendor
specific command to prevent 10-ish second-long dropouts whenever
something does a device scan. This patch sends the command when the
socket priority is set to TC_PRIO_INTERACTIVE, as BlueZ does for audio.
Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
---
Changes in v2:
- new ioctl got nack-ed, so let's use sk_priority as the trigger
- Link to v1: https://lore.kernel.org/r/20260407-brcm-prio-v1-1-f38b17376640@gmail.com
---
MAINTAINERS | 2 ++
drivers/bluetooth/hci_bcm4377.c | 2 ++
include/net/bluetooth/bluetooth.h | 4 ++++
include/net/bluetooth/hci_core.h | 11 +++++++++++
net/bluetooth/Kconfig | 7 +++++++
net/bluetooth/Makefile | 1 +
net/bluetooth/brcm.c | 29 +++++++++++++++++++++++++++++
net/bluetooth/brcm.h | 17 +++++++++++++++++
net/bluetooth/hci_conn.c | 28 ++++++++++++++++++++++++++++
net/bluetooth/l2cap_sock.c | 13 +++++++++++++
10 files changed, 114 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c3fe46d7c4bc..81be021367ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2562,6 +2562,8 @@ F: include/dt-bindings/pinctrl/apple.h
F: include/linux/mfd/macsmc.h
F: include/linux/soc/apple/*
F: include/uapi/drm/asahi_drm.h
+F: net/bluetooth/brcm.c
+F: net/bluetooth/brcm.h
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 925d0a635945..5f79920c0306 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -2397,6 +2397,8 @@ static int bcm4377_probe(struct pci_dev *pdev, const struct pci_device_id *id)
if (bcm4377->hw->broken_le_ext_adv_report_phy)
hci_set_quirk(hdev, HCI_QUIRK_FIXUP_LE_EXT_ADV_REPORT_PHY);
+ hci_set_brcm_capable(hdev);
+
pci_set_drvdata(pdev, bcm4377);
hci_set_drvdata(hdev, bcm4377);
SET_HCIDEV_DEV(hdev, &pdev->dev);
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 69eed69f7f26..07a250673950 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -457,6 +457,7 @@ struct l2cap_ctrl {
};
struct hci_dev;
+struct hci_conn;
typedef void (*hci_req_complete_t)(struct hci_dev *hdev, u8 status, u16 opcode);
typedef void (*hci_req_complete_skb_t)(struct hci_dev *hdev, u8 status,
@@ -469,6 +470,9 @@ void hci_req_cmd_complete(struct hci_dev *hdev, u16 opcode, u8 status,
int hci_ethtool_ts_info(unsigned int index, int sk_proto,
struct kernel_ethtool_ts_info *ts_info);
+int hci_conn_setsockopt(struct hci_conn *conn, struct sock *sk, int level,
+ int optname, sockptr_t optval, unsigned int optlen);
+
#define HCI_REQ_START BIT(0)
#define HCI_REQ_SKB BIT(1)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index a7bffb908c1e..947e7c2b08dd 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -642,6 +642,10 @@ struct hci_dev {
bool aosp_quality_report;
#endif
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ bool brcm_capable;
+#endif
+
int (*open)(struct hci_dev *hdev);
int (*close)(struct hci_dev *hdev);
int (*flush)(struct hci_dev *hdev);
@@ -1791,6 +1795,13 @@ static inline void hci_set_aosp_capable(struct hci_dev *hdev)
#endif
}
+static inline void hci_set_brcm_capable(struct hci_dev *hdev)
+{
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ hdev->brcm_capable = true;
+#endif
+}
+
static inline void hci_devcd_setup(struct hci_dev *hdev)
{
#ifdef CONFIG_DEV_COREDUMP
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index 6b2b65a66700..0f2a5fbcafc5 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -110,6 +110,13 @@ config BT_AOSPEXT
This options enables support for the Android Open Source
Project defined HCI vendor extensions.
+config BT_BRCMEXT
+ bool "Enable Broadcom extensions"
+ depends on BT
+ help
+ This option enables support for the Broadcom defined HCI
+ vendor extensions.
+
config BT_DEBUGFS
bool "Export Bluetooth internals in debugfs"
depends on BT && DEBUG_FS
diff --git a/net/bluetooth/Makefile b/net/bluetooth/Makefile
index a7eede7616d8..b4c9013a46ce 100644
--- a/net/bluetooth/Makefile
+++ b/net/bluetooth/Makefile
@@ -24,5 +24,6 @@ bluetooth-$(CONFIG_BT_LE) += iso.o
bluetooth-$(CONFIG_BT_LEDS) += leds.o
bluetooth-$(CONFIG_BT_MSFTEXT) += msft.o
bluetooth-$(CONFIG_BT_AOSPEXT) += aosp.o
+bluetooth-$(CONFIG_BT_BRCMEXT) += brcm.o
bluetooth-$(CONFIG_BT_DEBUGFS) += hci_debugfs.o
bluetooth-$(CONFIG_BT_SELFTEST) += selftest.o
diff --git a/net/bluetooth/brcm.c b/net/bluetooth/brcm.c
new file mode 100644
index 000000000000..9aa0a265ab3d
--- /dev/null
+++ b/net/bluetooth/brcm.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 The Asahi Linux Contributors
+ */
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "brcm.h"
+
+int brcm_set_high_priority(struct hci_dev *hdev, u16 handle, bool enable)
+{
+ struct sk_buff *skb;
+ u8 cmd[3];
+
+ if (!hdev->brcm_capable)
+ return 0;
+
+ cmd[0] = handle;
+ cmd[1] = handle >> 8;
+ cmd[2] = !!enable;
+
+ skb = hci_cmd_sync(hdev, 0xfc57, sizeof(cmd), cmd, HCI_CMD_TIMEOUT);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ kfree_skb(skb);
+ return 0;
+}
diff --git a/net/bluetooth/brcm.h b/net/bluetooth/brcm.h
new file mode 100644
index 000000000000..fdaee63bd1d2
--- /dev/null
+++ b/net/bluetooth/brcm.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2026 The Asahi Linux Contributors
+ */
+
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+
+int brcm_set_high_priority(struct hci_dev *hdev, u16 handle, bool enable);
+
+#else
+
+static inline int brcm_set_high_priority(struct hci_dev *hdev, u16 handle, bool enable)
+{
+ return 0;
+}
+
+#endif
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 11d3ad8d2551..096163840f62 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -35,6 +35,7 @@
#include <net/bluetooth/iso.h>
#include <net/bluetooth/mgmt.h>
+#include "brcm.h"
#include "smp.h"
#include "eir.h"
@@ -3070,6 +3071,33 @@ int hci_conn_set_phy(struct hci_conn *conn, u32 phys)
}
}
+int hci_conn_setsockopt(struct hci_conn *conn, struct sock *sk, int level,
+ int optname, sockptr_t optval, unsigned int optlen)
+{
+ int val;
+ bool old_high, new_high, changed;
+
+ if (level != SOL_SOCKET)
+ return 0;
+
+ if (optname != SO_PRIORITY)
+ return 0;
+
+ if (optlen < sizeof(int))
+ return -EINVAL;
+
+ if (copy_from_sockptr(&val, optval, sizeof(val)))
+ return -EFAULT;
+
+ old_high = sk->sk_priority >= TC_PRIO_INTERACTIVE;
+ new_high = val >= TC_PRIO_INTERACTIVE;
+ changed = old_high != new_high;
+ if (!changed)
+ return 0;
+
+ return brcm_set_high_priority(conn->hdev, conn->handle, new_high);
+}
+
static int abort_conn_sync(struct hci_dev *hdev, void *data)
{
struct hci_conn *conn = data;
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 71e8c1b45bce..d5eef87accc4 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -891,6 +891,16 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname,
BT_DBG("sk %p", sk);
+ if (level == SOL_SOCKET) {
+ conn = chan->conn;
+ if (conn)
+ err = hci_conn_setsockopt(conn->hcon, sock->sk, level,
+ optname, optval, optlen);
+ if (err)
+ return err;
+ return sock_setsockopt(sock, level, optname, optval, optlen);
+ }
+
if (level == SOL_L2CAP)
return l2cap_sock_setsockopt_old(sock, optname, optval, optlen);
@@ -1931,6 +1941,9 @@ static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
INIT_LIST_HEAD(&l2cap_pi(sk)->rx_busy);
+ if (sock)
+ set_bit(SOCK_CUSTOM_SOCKOPT, &sock->flags);
+
chan = l2cap_chan_create();
if (!chan) {
sk_free(sk);
---
base-commit: bfe62a454542cfad3379f6ef5680b125f41e20f4
change-id: 20260407-brcm-prio-b630e6cc3834
Best regards,
--
Sasha Finkelstein <fnkl.kernel@gmail.com>
^ permalink raw reply related
* Re: [PATCH v0 06/15] mshv: Implement mshv bridge device for VFIO
From: Mukesh R @ 2026-04-07 17:41 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: linux-kernel, linux-hyperv, linux-arm-kernel, iommu, linux-pci,
linux-arch, kys, haiyangz, wei.liu, decui, longli,
catalin.marinas, will, tglx, mingo, bp, dave.hansen, hpa, joro,
lpieralisi, kwilczynski, mani, robh, bhelgaas, arnd, nunodasneves,
mhklinux, romank
In-Reply-To: <aW-oniY3VpagQMPb@skinsburskii.localdomain>
On 1/20/26 08:09, Stanislav Kinsburskii wrote:
> On Mon, Jan 19, 2026 at 10:42:21PM -0800, Mukesh R wrote:
>> From: Mukesh Rathor <mrathor@linux.microsoft.com>
>>
>> Add a new file to implement VFIO-MSHV bridge pseudo device. These
>> functions are called in the VFIO framework, and credits to kvm/vfio.c
>> as this file was adapted from it.
>>
>> Original author: Wei Liu <wei.liu@kernel.org>
>> (Slightly modified from the original version).
>>
>
> There is a Linux standard for giving credits when code is adapted from.
> This doesn't follow that standard. Please fix.
>
>> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
>> ---
>> drivers/hv/Makefile | 3 +-
>> drivers/hv/mshv_vfio.c | 210 +++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 212 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/hv/mshv_vfio.c
>>
>> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
>> index a49f93c2d245..eae003c4cb8f 100644
>> --- a/drivers/hv/Makefile
>> +++ b/drivers/hv/Makefile
>> @@ -14,7 +14,8 @@ hv_vmbus-y := vmbus_drv.o \
>> hv_vmbus-$(CONFIG_HYPERV_TESTING) += hv_debugfs.o
>> hv_utils-y := hv_util.o hv_kvp.o hv_snapshot.o hv_utils_transport.o
>> mshv_root-y := mshv_root_main.o mshv_synic.o mshv_eventfd.o mshv_irq.o \
>> - mshv_root_hv_call.o mshv_portid_table.o mshv_regions.o
>> + mshv_root_hv_call.o mshv_portid_table.o mshv_regions.o \
>> + mshv_vfio.o
>> mshv_vtl-y := mshv_vtl_main.o
>>
>> # Code that must be built-in
>> diff --git a/drivers/hv/mshv_vfio.c b/drivers/hv/mshv_vfio.c
>> new file mode 100644
>> index 000000000000..6ea4d99a3bd2
>> --- /dev/null
>> +++ b/drivers/hv/mshv_vfio.c
>> @@ -0,0 +1,210 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * VFIO-MSHV bridge pseudo device
>> + *
>> + * Heavily inspired by the VFIO-KVM bridge pseudo device.
>> + */
>> +#include <linux/errno.h>
>> +#include <linux/file.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/slab.h>
>> +#include <linux/vfio.h>
>> +
>> +#include "mshv.h"
>> +#include "mshv_root.h"
>> +
>> +struct mshv_vfio_file {
>> + struct list_head node;
>> + struct file *file; /* list of struct mshv_vfio_file */
>> +};
>> +
>> +struct mshv_vfio {
>> + struct list_head file_list;
>> + struct mutex lock;
>> +};
>> +
>> +static bool mshv_vfio_file_is_valid(struct file *file)
>> +{
>> + bool (*fn)(struct file *file);
>> + bool ret;
>> +
>> + fn = symbol_get(vfio_file_is_valid);
>> + if (!fn)
>> + return false;
>> +
>> + ret = fn(file);
>> +
>> + symbol_put(vfio_file_is_valid);
>> +
>> + return ret;
>> +}
>> +
>> +static long mshv_vfio_file_add(struct mshv_device *mshvdev, unsigned int fd)
>> +{
>> + struct mshv_vfio *mshv_vfio = mshvdev->device_private;
>> + struct mshv_vfio_file *mvf;
>> + struct file *filp;
>> + long ret = 0;
>> +
>> + filp = fget(fd);
>> + if (!filp)
>> + return -EBADF;
>> +
>> + /* Ensure the FD is a vfio FD. */
>> + if (!mshv_vfio_file_is_valid(filp)) {
>> + ret = -EINVAL;
>> + goto out_fput;
>> + }
>> +
>> + mutex_lock(&mshv_vfio->lock);
>> +
>> + list_for_each_entry(mvf, &mshv_vfio->file_list, node) {
>> + if (mvf->file == filp) {
>> + ret = -EEXIST;
>> + goto out_unlock;
>> + }
>> + }
>> +
>> + mvf = kzalloc(sizeof(*mvf), GFP_KERNEL_ACCOUNT);
>> + if (!mvf) {
>> + ret = -ENOMEM;
>> + goto out_unlock;
>> + }
>> +
>> + mvf->file = get_file(filp);
>> + list_add_tail(&mvf->node, &mshv_vfio->file_list);
>> +
>> +out_unlock:
>> + mutex_unlock(&mshv_vfio->lock);
>> +out_fput:
>> + fput(filp);
>> + return ret;
>> +}
>> +
>> +static long mshv_vfio_file_del(struct mshv_device *mshvdev, unsigned int fd)
>> +{
>> + struct mshv_vfio *mshv_vfio = mshvdev->device_private;
>> + struct mshv_vfio_file *mvf;
>> + long ret;
>> +
>> + CLASS(fd, f)(fd);
>> +
>> + if (fd_empty(f))
>> + return -EBADF;
>> +
>> + ret = -ENOENT;
>> + mutex_lock(&mshv_vfio->lock);
>> +
>> + list_for_each_entry(mvf, &mshv_vfio->file_list, node) {
>> + if (mvf->file != fd_file(f))
>> + continue;
>> +
>> + list_del(&mvf->node);
>> + fput(mvf->file);
>> + kfree(mvf);
>> + ret = 0;
>> + break;
>> + }
>> +
>> + mutex_unlock(&mshv_vfio->lock);
>> + return ret;
>> +}
>> +
>> +static long mshv_vfio_set_file(struct mshv_device *mshvdev, long attr,
>> + void __user *arg)
>> +{
>> + int32_t __user *argp = arg;
>> + int32_t fd;
>> +
>> + switch (attr) {
>> + case MSHV_DEV_VFIO_FILE_ADD:
>> + if (get_user(fd, argp))
>> + return -EFAULT;
>> + return mshv_vfio_file_add(mshvdev, fd);
>> +
>> + case MSHV_DEV_VFIO_FILE_DEL:
>> + if (get_user(fd, argp))
>> + return -EFAULT;
>> + return mshv_vfio_file_del(mshvdev, fd);
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static long mshv_vfio_set_attr(struct mshv_device *mshvdev,
>> + struct mshv_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case MSHV_DEV_VFIO_FILE:
>> + return mshv_vfio_set_file(mshvdev, attr->attr,
>> + u64_to_user_ptr(attr->addr));
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static long mshv_vfio_has_attr(struct mshv_device *mshvdev,
>> + struct mshv_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case MSHV_DEV_VFIO_FILE:
>> + switch (attr->attr) {
>> + case MSHV_DEV_VFIO_FILE_ADD:
>> + case MSHV_DEV_VFIO_FILE_DEL:
>> + return 0;
>> + }
>> +
>> + break;
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static long mshv_vfio_create_device(struct mshv_device *mshvdev, u32 type)
>> +{
>> + struct mshv_device *tmp;
>> + struct mshv_vfio *mshv_vfio;
>> +
>> + /* Only one VFIO "device" per VM */
>> + hlist_for_each_entry(tmp, &mshvdev->device_pt->pt_devices,
>> + device_ptnode)
>> + if (tmp->device_ops == &mshv_vfio_device_ops)
>> + return -EBUSY;
>> +
>> + mshv_vfio = kzalloc(sizeof(*mshv_vfio), GFP_KERNEL_ACCOUNT);
>> + if (mshv_vfio == NULL)
>> + return -ENOMEM;
>> +
>> + INIT_LIST_HEAD(&mshv_vfio->file_list);
>> + mutex_init(&mshv_vfio->lock);
>> +
>> + mshvdev->device_private = mshv_vfio;
>> +
>> + return 0;
>> +}
>> +
>> +/* This is called from mshv_device_fop_release() */
>> +static void mshv_vfio_release_device(struct mshv_device *mshvdev)
>> +{
>> + struct mshv_vfio *mv = mshvdev->device_private;
>> + struct mshv_vfio_file *mvf, *tmp;
>> +
>> + list_for_each_entry_safe(mvf, tmp, &mv->file_list, node) {
>> + fput(mvf->file);
>
> This put must be sync as device must be detached from domain before
> attempting partition destruction.
Like I said in 6.6 PR, this does not attach or detach devices.
> This was explicitly mentioned in the patch originated this code.
> Please fix, add a comment and credits to the commit message.
That was ".detstroy" hook which is gone.
Thanks,
-Mukesh
> Thanks,
> Stanislav
>
>
>> + list_del(&mvf->node);
>> + kfree(mvf);
>> + }
>> +
>> + kfree(mv);
>> + kfree(mshvdev);
>> +}
>> +
>> +struct mshv_device_ops mshv_vfio_device_ops = {
>> + .device_name = "mshv-vfio",
>> + .device_create = mshv_vfio_create_device,
>> + .device_release = mshv_vfio_release_device,
>> + .device_set_attr = mshv_vfio_set_attr,
>> + .device_has_attr = mshv_vfio_has_attr,
>> +};
>> --
>> 2.51.2.vfs.0.1
>>
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Catalin Marinas @ 2026-04-07 17:37 UTC (permalink / raw)
To: Ryan Roberts
Cc: Will Deacon, David Hildenbrand (Arm), Dev Jain, Yang Shi,
Suzuki K Poulose, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <b545e650-f84f-4911-9902-b914870f0e1d@arm.com>
On Tue, Apr 07, 2026 at 02:06:10PM +0100, Ryan Roberts wrote:
> On 07/04/2026 11:52, Catalin Marinas wrote:
> > As the name implies, linear_map_requires_bbml2 tracks only this -
> > BBML2_NOABORT is required because the linear map uses large blocks.
> > Prior to your patches, that's only used as far as
> > linear_map_maybe_split_to_ptes() and if splitting took place, this
> > variable is no longer relevant (should be turned to false but since it's
> > not used, it doesn't matter).
> >
> > With your patches, its use was extended to runtime and I think it
> > remains true even if linear_map_maybe_split_to_ptes() changed the block
> > mappings. Do we need this:
>
> I'll admit it is ugly but it's not a bug; the system capabilitites are finalized
> by the time we call linear_map_maybe_split_to_ptes().
>
> The "if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))" check
> in split_kernel_leaf_mapping() would ideally be "if (!force_pte_mapping() ||
> is_kfence_address((void *)start))", but it is not safe to call
> force_pte_mapping() from a secondary cpu prior to finalizing the system caps.
> I'm reusing the flag that I already had available to work around that.
The confusing part is that the flag may be false incorrectly due to the
is_realm_world() evaluation. Nothing to do with this patch though and
the subject even mentions the rodata=full case. We should fix it
separately.
We could have set the flag to zero in linear_map_maybe_split_to_ptes(),
though split_kernel_leaf_mapping() already exits early due to the
!system_supports_bbml2_noabort() && system_capabilities_finalized(), so
not a correctness issue.
> But regardless, I think we are talking about the pre-existing
> is_real_world() bug, so I'm not personally planning to do anything further here
> unless you shout.
Not for this series. Steven or Suzuki should address the other problem
with is_realm_world().
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Catalin Marinas @ 2026-04-07 17:21 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Yang Shi, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <1db93bd3-cb47-445b-b8ca-6de6f04b41cc@arm.com>
On Tue, Apr 07, 2026 at 10:57:35AM +0100, Suzuki K Poulose wrote:
> On 02/04/2026 21:43, Catalin Marinas wrote:
> > On Mon, Mar 30, 2026 at 05:17:02PM +0100, Ryan Roberts wrote:
> > > int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
> > > {
> > > int ret;
> > > - /*
> > > - * !BBML2_NOABORT systems should not be trying to change permissions on
> > > - * anything that is not pte-mapped in the first place. Just return early
> > > - * and let the permission change code raise a warning if not already
> > > - * pte-mapped.
> > > - */
> > > - if (!system_supports_bbml2_noabort())
> > > - return 0;
> > > -
> > > /*
> > > * If the region is within a pte-mapped area, there is no need to try to
> > > * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
> > > * change permissions from atomic context so for those cases (which are
> > > * always pte-mapped), we must not go any further because taking the
> > > - * mutex below may sleep.
> > > + * mutex below may sleep. Do not call force_pte_mapping() here because
> > > + * it could return a confusing result if called from a secondary cpu
> > > + * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
> > > + * what we need.
> > > */
> > > - if (force_pte_mapping() || is_kfence_address((void *)start))
> > > + if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
> > > return 0;
> > > + if (!system_supports_bbml2_noabort()) {
> > > + /*
> > > + * !BBML2_NOABORT systems should not be trying to change
> > > + * permissions on anything that is not pte-mapped in the first
> > > + * place. Just return early and let the permission change code
> > > + * raise a warning if not already pte-mapped.
> > > + */
> > > + if (system_capabilities_finalized())
> > > + return 0;
> > > +
> > > + /*
> > > + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
> > > + * page allocator. Can't split until it's available.
> > > + */
> > > + if (WARN_ON(!page_alloc_available))
> > > + return -EBUSY;
> > > +
> > > + /*
> > > + * Boot-time: Started secondary cpus but don't know if they
> > > + * support BBML2_NOABORT yet. Can't allow splitting in this
> > > + * window in case they don't.
> > > + */
> > > + if (WARN_ON(num_online_cpus() > 1))
> > > + return -EBUSY;
> > > + }
> >
> > I think sashiko is over cautions here
> > (https://sashiko.dev/#/patchset/20260330161705.3349825-1-ryan.roberts@arm.com)
> > but it has a somewhat valid point from the perspective of
> > num_online_cpus() semantics. We have have num_online_cpus() == 1 while
> > having a secondary CPU just booted and with its MMU enabled. I don't
> > think we can have any asynchronous tasks running at that point to
> > trigger a spit though. Even async_init() is called after smp_init().
> >
> > An option may be to attempt cpus_read_trylock() as this lock is taken by
> > _cpu_up(). If it fails, return -EBUSY, otherwise check num_online_cpus()
> > and unlock (and return -EBUSY if secondaries already started).
> >
> > Another thing I couldn't get my head around - IIUC is_realm_world()
> > won't return true for map_mem() yet (if in a realm).
>
> That is correct. map_mem() comes from paginig_init(), which gets called
> before arm64_rsi_init(). Realm check was delayed until psci_xx_init().
> We had a version which parsed the DT for PSCI conduit early enough
> to be able to make the SMC calls to detect the Realm. But there
> were concerns around it.
Ah, yes, I remember.
Does it mean that commit 42be24a4178f ("arm64: Enable memory encrypt for
Realms") was broken without rodata=full w.r.t. the linear map? Commit
a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full")
introduced force_pte_mapping() but it just copied the logic in the
existing can_set_direct_map(). Looking at the linear_map_requires_bbml2
assignment, we get (!is_realm_world() && is_realm_world()) and it
cancels out, no effect on it but we don't get pte mappings either (even
if we don't have BBML2).
I think we need at least some safety checks:
1. BBML2_NOABORT support on the boot CPU - continue with the existing
logic (as per Ryan's series)
2. !system_supports_bbml2_noabort() - split in
linear_map_maybe_split_to_ptes(). This does not currently happen
because linear_map_requires_bbml2 may be false in the absence of
rodata=full. Not sure how to fix this without some variable telling
us how the linear map was mapped. The requires_bbml2 flag doesn't
3. Panic in arm64_rsi_init() if !BBML2_NOABORT on the boot CPU _and_ we
have block mappings already. People can avoid it with rodata=full
4. If (3) is a common case, a better alternative is to rewrite the
linear map sometime after arm64_rsi_init() but before we call
split_kernel_leaf_mapping().
--
Catalin
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: dma: arm-dma350: document combined and per-channel IRQ topologies
From: Rob Herring @ 2026-04-07 17:20 UTC (permalink / raw)
To: Jun Guo
Cc: peter.chen, fugang.duan, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li, dmaengine, devicetree,
linux-kernel, cix-kernel-upstream, linux-arm-kernel
In-Reply-To: <20260324120113.3681830-2-jun.guo@cixtech.com>
On Tue, Mar 24, 2026 at 08:01:11PM +0800, Jun Guo wrote:
> Document the interrupt topologies supported by DMA-350 integration:
> - one combined interrupt for all channels, or
> - one interrupt per channel (up to 8 channels).
>
> Assisted-by: Cursor:GPT-5.3-Codex
> Signed-off-by: Jun Guo <jun.guo@cixtech.com>
> ---
> .../devicetree/bindings/dma/arm,dma-350.yaml | 25 ++++++++++++-------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> index 429f682f15d8..bec9dc32541b 100644
> --- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> +++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> @@ -22,15 +22,22 @@ properties:
>
> interrupts:
> minItems: 1
> - items:
> - - description: Channel 0 interrupt
> - - description: Channel 1 interrupt
> - - description: Channel 2 interrupt
> - - description: Channel 3 interrupt
> - - description: Channel 4 interrupt
> - - description: Channel 5 interrupt
> - - description: Channel 6 interrupt
> - - description: Channel 7 interrupt
> + maxItems: 8
Don't need maxItems
> + description:
> + Either one interrupt per channel (8 interrupts), or one
> + combined interrupt for all channels.
> + oneOf:
> + - items:
> + - description: Channel 0 interrupt
> + - description: Channel 1 interrupt
> + - description: Channel 2 interrupt
> + - description: Channel 3 interrupt
> + - description: Channel 4 interrupt
> + - description: Channel 5 interrupt
> + - description: Channel 6 interrupt
> + - description: Channel 7 interrupt
> + - items:
> + - description: Combined interrupt shared by all channels
>
> "#dma-cells":
> const: 1
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC
From: Will Deacon @ 2026-04-07 17:03 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Robin Murphy, Mukesh Ojha
Cc: catalin.marinas, kernel-team, Will Deacon, Robin Murphy,
linux-arm-kernel, iommu, devicetree, linux-kernel
In-Reply-To: <20260403080956.2714415-1-mukesh.ojha@oss.qualcomm.com>
On Fri, 03 Apr 2026 13:39:56 +0530, Mukesh Ojha wrote:
> 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.
>
>
Applied to iommu (arm/smmu/bindings), thanks!
[1/1] dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC
https://git.kernel.org/iommu/c/5e8323c3d528
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH V2] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Mark Brown @ 2026-04-07 11:53 UTC (permalink / raw)
To: michal.simek, linux-spi, linux-kernel, linux-arm-kernel, Pei Xiao
In-Reply-To: <24043625f89376da36feca2408f990a85be7ab36.1775555500.git.xiaopei01@kylinos.cn>
On Tue, 07 Apr 2026 17:55:08 +0800, Pei Xiao wrote:
> spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.0
Thanks!
[1/1] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/1f8fd9490e31
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
From: Mark Brown @ 2026-04-07 12:12 UTC (permalink / raw)
To: hayashi.kunihiko, mhiramat, linux-spi, linux-arm-kernel,
linux-kernel, Pei Xiao
In-Reply-To: <b2deeefd4ef1a4bce71116aabfcb7e81400f6d37.1775546948.git.xiaopei01@kylinos.cn>
On Tue, 07 Apr 2026 15:30:28 +0800, Pei Xiao wrote:
> spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1
Thanks!
[1/1] spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/sound/c/fdca270f8f87
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v6 2/3] dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
From: Conor Dooley @ 2026-04-07 16:20 UTC (permalink / raw)
To: florin.leotescu
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel,
daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260402122514.1811737-3-florin.leotescu@oss.nxp.com>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Thu, Apr 02, 2026 at 03:25:13PM +0300, florin.leotescu@oss.nxp.com wrote:
> From: Florin Leotescu <florin.leotescu@nxp.com>
>
> The EMC2305 fan controller supports multiple independent PWM fan
> outputs. Some systems require fans to enter a defined safe state
> during system shutdown or reboot handoff, until firmware or the next
> boot stage reconfigures the controller.
>
> Add an optional "fan-shutdown-percent" property to fan child nodes
> allowing the PWM duty cycle applied during shutdown to be configured
> per fan output.
>
> Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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