* Re: [PATCH] perf/arm-cmn: Fix resource_size_t printk specifier in arm_cmn_init_dtc()
From: Will Deacon @ 2026-03-26 15:34 UTC (permalink / raw)
To: Robin Murphy, Mark Rutland, Ilkka Koskinen, Nathan Chancellor
Cc: catalin.marinas, kernel-team, Will Deacon, linux-arm-kernel,
linux-perf-users, linux-kernel
In-Reply-To: <20260325-perf-arm-cmn-fix-resource_size_t-format-v1-1-e84d52ee3e81@kernel.org>
On Wed, 25 Mar 2026 19:19:26 -0700, Nathan Chancellor wrote:
> When building for 32-bit ARM, there is a warning when using the %llx
> specifier to print a resource_size_t variable:
>
> drivers/perf/arm-cmn.c: In function 'arm_cmn_init_dtc':
> drivers/perf/arm-cmn.c:2149:73: error: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'resource_size_t' {aka 'unsigned int'} [-Werror=format=]
> 2149 | "Failed to request DTC region 0x%llx\n", base);
> | ~~~^ ~~~~
> | | |
> | | resource_size_t {aka unsigned int}
> | long long unsigned int
> | %x
>
> [...]
Applied to will (for-next/perf), thanks!
[1/1] perf/arm-cmn: Fix resource_size_t printk specifier in arm_cmn_init_dtc()
https://git.kernel.org/will/c/47f06ebbe8da
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Russell King (Oracle) @ 2026-03-26 15:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Heiner Kallweit,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <044110c5-da1e-48c0-93fd-35553e86b271@lunn.ch>
On Thu, Mar 26, 2026 at 04:24:23PM +0100, Andrew Lunn wrote:
> On Thu, Mar 26, 2026 at 03:13:19PM +0000, Russell King (Oracle) wrote:
> > On Thu, Mar 26, 2026 at 01:04:15PM +0100, Louis-Alexis Eyraud wrote:
> > > +static int an8801r_set_wol(struct phy_device *phydev,
> > > + struct ethtool_wolinfo *wol)
> > > +{
> > > + struct net_device *attach_dev = phydev->attached_dev;
> > > + const unsigned char *macaddr = attach_dev->dev_addr;
> >
> > This isn't a criticism for this patch, but a discussion point for
> > phylib itself.
> >
> > It occurs to me that there's a weakness in the phylib interface for WoL,
> > specifically when WoL is enabled at the PHY, but someone then changes
> > the interface's MAC address - there doesn't seem to be a way for the
> > address programmed into the PHY to be updated. Should there be?
> >
> > Do we instead expect users to disable WoL before changing the MAC for
> > a network interface?
>
> Program the MAC address during suspend? I assume userspace is no
> longer active at this point, so the address should be stable.
What is the timing requirements for a system going into suspend vs a WoL
packet being sent? Should a WoL packet abort entry into suspend? If yes,
then we need to program the MAC before the PHY is suspended, because
suspend could already be in progress.
--
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 v3 09/10] dt-bindings: firmware: add arm,ras-cper
From: Rob Herring @ 2026-03-26 15:24 UTC (permalink / raw)
To: Ahmed Tiba
Cc: linux-acpi, devicetree, linux-cxl, Michael.Zhao2,
linux-arm-kernel, Dmitry.Lamerov, rafael, conor, will, bp,
catalin.marinas, krzk+dt, linux-doc, mchehab+huawei, tony.luck
In-Reply-To: <20260318-topics-ahmtib01-ras_ffh_arm_internal_review-v3-9-48e6a1c249ef@arm.com>
On Wed, Mar 18, 2026 at 08:48:06PM +0000, Ahmed Tiba wrote:
> Describe the DeviceTree node that exposes the Arm firmware-first
> CPER provider and hook the file into MAINTAINERS so the
> binding has an owner.
>
> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
> ---
> .../devicetree/bindings/firmware/arm,ras-cper.yaml | 71 ++++++++++++++++++++++
> MAINTAINERS | 5 ++
> 2 files changed, 76 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> new file mode 100644
> index 000000000000..bd93cfb8d222
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> @@ -0,0 +1,71 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/arm,ras-cper.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Arm RAS CPER provider
> +
> +maintainers:
> + - Ahmed Tiba <ahmed.tiba@arm.com>
> +
> +description: |
> + Arm Reliability, Availability and Serviceability (RAS) firmware can expose
> + a firmware-first CPER error source directly via DeviceTree. Firmware
> + provides the CPER Generic Error Status block and notifies the OS through
> + an interrupt.
> +
> +properties:
> + compatible:
> + const: arm,ras-cper
> +
> + reg:
> + minItems: 1
> + items:
> + - description:
> + CPER Generic Error Status block exposed by firmware
> + - description:
> + Optional 32- or 64-bit doorbell register used on platforms
> + where firmware needs an explicit "ack" handshake before overwriting
> + the CPER buffer. Firmware watches bit 0 and expects the OS to set it
> + once the current status block has been consumed.
> +
> + interrupts:
> + maxItems: 1
> + description:
> + Interrupt used to signal that a new status record is ready.
> +
> + memory-region:
> + $ref: /schemas/types.yaml#/definitions/phandle
memory-region already has a defined type. You just need to define how
many entries (maxItems: 1).
> + description:
> + Optional phandle to the reserved-memory entry that backs the status
> + buffer so firmware and the OS use the same carved-out region.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ras_cper_buffer: cper@fe800000 {
> + reg = <0x0 0xfe800000 0x0 0x1000>;
> + no-map;
> + };
> + };
> +
> + error-handler@fe800000 {
> + compatible = "arm,ras-cper";
> + reg = <0xfe800000 0x1000>,
Wait! Why is the reserved address here? There's 2 problems with that.
There shouldn't be same address in 2 places in the DT. The 2nd is
reserved memory should only be regions within DRAM (or whatever is
system memory).
Rob
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Andrew Lunn @ 2026-03-26 15:24 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Heiner Kallweit,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <acVND6DdpM9czIwU@shell.armlinux.org.uk>
On Thu, Mar 26, 2026 at 03:13:19PM +0000, Russell King (Oracle) wrote:
> On Thu, Mar 26, 2026 at 01:04:15PM +0100, Louis-Alexis Eyraud wrote:
> > +static int an8801r_set_wol(struct phy_device *phydev,
> > + struct ethtool_wolinfo *wol)
> > +{
> > + struct net_device *attach_dev = phydev->attached_dev;
> > + const unsigned char *macaddr = attach_dev->dev_addr;
>
> This isn't a criticism for this patch, but a discussion point for
> phylib itself.
>
> It occurs to me that there's a weakness in the phylib interface for WoL,
> specifically when WoL is enabled at the PHY, but someone then changes
> the interface's MAC address - there doesn't seem to be a way for the
> address programmed into the PHY to be updated. Should there be?
>
> Do we instead expect users to disable WoL before changing the MAC for
> a network interface?
Program the MAC address during suspend? I assume userspace is no
longer active at this point, so the address should be stable.
Andrew
^ permalink raw reply
* Re: (subset) [PATCH v10 0/5] Add MIPI CSI-2 support for i.MX8ULP
From: Frank Li @ 2026-03-26 15:20 UTC (permalink / raw)
To: Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel,
Guoniu Zhou
Cc: Frank Li, linux-media, devicetree, imx, linux-arm-kernel,
linux-kernel, Conor Dooley
In-Reply-To: <20251205-csi2_imx8ulp-v10-0-190cdadb20a3@nxp.com>
On Fri, 05 Dec 2025 17:07:42 +0800, Guoniu Zhou wrote:
> The serial adds MIPI CSI-2 support for i.MX8ULP.
>
>
Applied, thanks!
[5/5] arm64: dts: imx8ulp: Add CSI and ISI Nodes
commit: 73f3ca0f85285b2fc4ea05affb9a44bf899cd595
Add extra empty line between reg and child node.
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Russell King (Oracle) @ 2026-03-26 15:18 UTC (permalink / raw)
To: Christian Schrefl
Cc: Miguel Ojeda, Alice Ryhl, Ard Biesheuvel, Jamie Cunliffe,
Will Deacon, Catalin Marinas, Miguel Ojeda, a.hindborg, acourbot,
akpm, anton.ivanov, bjorn3_gh, boqun.feng, dakr, david, gary,
johannes, justinstitt, linux-arm-kernel, linux-kbuild,
linux-kernel, linux-mm, linux-um, llvm, lossin, mark.rutland,
mmaurer, morbo, nathan, nick.desaulniers+lkml, nicolas.schier,
nsc, peterz, richard, rust-for-linux, tmgross, urezki
In-Reply-To: <9cf5a94c-0f37-446c-b63d-ddac5674d220@gmail.com>
On Thu, Mar 26, 2026 at 03:31:26PM +0100, Christian Schrefl wrote:
> Hi Miguel,
>
> On 3/26/26 2:47 PM, Miguel Ojeda wrote:
> > On Thu, Mar 26, 2026 at 11:10 AM Alice Ryhl <aliceryhl@google.com> wrote:
> >>
> >> I noticed that the Makefile currently uses the arm-unknown-linux-gnueabi
> >> target. It should probably not be -linux target to avoid this? Probably
> >> it should just be armv7a-none-eabi, right? We gate HAVE_RUST on
> >> CPU_32v7, so we should not need to consider the other variants.
> >
> > I think Christian tried several targets back then and eventually
> > picked that one.
> >
> > Christian: what was the reason to pick the `-linux-` one? e.g. was
> > there something you wanted to rely on that target spec that you
> > couldn't enable or disable via `rustc` flags or similar?
>
> It should probably be fine to use armv7a-none-eabi. I've mostly used
> arm-unknown-linux-gnueabi
I'm not sure if this is still true, but I believe it used to be the case
that the -linux-gnueabi target has one behaviour for enums (fixed size)
whereas -none-eabi, the size of the type depends on the range of values
included in the enum.
Certianly, when Arm Ltd were proposing EABI, EABI had the latter
behaviour, and I think there were cases where Linux used "enum" in
its UAPI.
--
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 net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Russell King (Oracle) @ 2026-03-26 15:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Andrew Lunn,
Heiner Kallweit, kevin-kw.huang, macpaul.lin, matthias.bgg,
kernel, netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <20260326-add-airoha-an8801-support-v2-4-1a42d6b6050f@collabora.com>
On Thu, Mar 26, 2026 at 01:04:15PM +0100, Louis-Alexis Eyraud wrote:
> +static int an8801r_set_wol(struct phy_device *phydev,
> + struct ethtool_wolinfo *wol)
> +{
> + struct net_device *attach_dev = phydev->attached_dev;
> + const unsigned char *macaddr = attach_dev->dev_addr;
This isn't a criticism for this patch, but a discussion point for
phylib itself.
It occurs to me that there's a weakness in the phylib interface for WoL,
specifically when WoL is enabled at the PHY, but someone then changes
the interface's MAC address - there doesn't seem to be a way for the
address programmed into the PHY to be updated. Should there be?
Do we instead expect users to disable WoL before changing the MAC for
a network interface?
--
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 v2 5/5] arm64: dts: freescale: add i.MX91 9x9 QSB basic support
From: Andrew Lunn @ 2026-03-26 15:10 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel, Daniel Baluta
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-5-b991b81639e6@nxp.com>
> 4. Remove clock-frequency property from mdio node.
> +&eqos {
> + phy-handle = <ðphy1>;
> + phy-mode = "rgmii-id";
> + pinctrl-0 = <&pinctrl_eqos>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <5000000>;
???
Andrew
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: dts: imx93-9x9-qsb: remove unused property clock-frequency from mdio node
From: Andrew Lunn @ 2026-03-26 15:08 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-4-b991b81639e6@nxp.com>
On Thu, Mar 26, 2026 at 03:51:40PM +0800, Joy Zou wrote:
> The clock-frequency property is not implemented. Remove it to clean up the
> device tree.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Thanks for these patches.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/5] arm64: dts: imx93-11x11-evk: remove unused property clock-frequency from mdio node
From: Andrew Lunn @ 2026-03-26 15:07 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-3-b991b81639e6@nxp.com>
On Thu, Mar 26, 2026 at 03:51:39PM +0800, Joy Zou wrote:
> The clock-frequency property is not implemented. Remove it to clean up the
> device tree.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/5] arm64: dts: imx91-11x11-evk: remove unused property clock-frequency from mdio node
From: Andrew Lunn @ 2026-03-26 15:07 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-2-b991b81639e6@nxp.com>
On Thu, Mar 26, 2026 at 03:51:38PM +0800, Joy Zou wrote:
> The clock-frequency property is not implemented. Remove it to clean up the
> device tree.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Set slot width for non-TDM mode
From: Alexey Charkov @ 2026-03-26 14:58 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Heiko Stuebner, Sugar Zhang, linux-rockchip, linux-sound,
linux-arm-kernel, linux-kernel
In-Reply-To: <14828456.uLZWGnKmhe@workhorse>
On Wed, Mar 18, 2026 at 11:56 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On Wednesday, 18 March 2026 15:50:25 Central European Standard Time Alexey Charkov wrote:
> > Currently the slot width in non-TDM mode is always kept at the POR value
> > of 32 bits, regardless of the sample width, which doesn't work well for
> > some codecs such as NAU8822.
> >
> > Set the slot width according to the sample width in non-TDM mode, which
> > is what other CPU DAI drivers do.
> >
> > Tested on the following RK3576 configurations:
> > - SAI2 + NAU8822 (codec as the clock master), custom board
> > - SAI1 + ES8388 (codec as the clock master), RK3576 EVB1
> > - SAI2 + RT5616 (SAI as the clock master), FriendlyElec NanoPi M5
> >
> > NAU8822 didn't work prior to this patch but works after the patch. Other
> > two configurations work both before and after the patch.
> >
> > Fixes: cc78d1eaabad ("ASoC: rockchip: add Serial Audio Interface (SAI) driver")
> > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > ---
> > sound/soc/rockchip/rockchip_sai.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
> > index 1bf614dbdf4d..ed393e5034a4 100644
> > --- a/sound/soc/rockchip/rockchip_sai.c
> > +++ b/sound/soc/rockchip/rockchip_sai.c
> > @@ -628,6 +628,10 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
> >
> > regmap_update_bits(sai->regmap, reg, SAI_XCR_VDW_MASK | SAI_XCR_CSR_MASK, val);
> >
> > + if (!sai->is_tdm)
> > + regmap_update_bits(sai->regmap, reg, SAI_XCR_SBW_MASK,
> > + SAI_XCR_SBW(params_physical_width(params)));
> > +
> > regmap_read(sai->regmap, reg, &val);
> >
> > slot_width = SAI_XCR_SBW_V(val);
> >
> > ---
> > base-commit: 8e5a478b6d6a5bb0a3d52147862b15e4d826af19
> > change-id: 20260318-sai-slot-width-378eed5c22cd
> >
> > Best regards,
> >
>
> Thanks for the patch! Looking at where else this reg mask is used, I
> got curious about `rockchip_sai_set_tdm_slot`. It seems to reset
> SAI_XCR_SBW back to 32 when something calls it with 0 slots. Do we
> have to adjust this as well there?
Hmm, from what I'm understanding set_tdm_slot is called before
hw_params - e.g. the Freescale SAI driver doesn't even program the
slot width to the hardware from set_tdm_slot and only updates the
requested value in its internal data structure - to be then written
out when hw_params runs. So I believe it should work as-is, although I
haven't seen any TDM users of the Rockchip SAI in the wild to verify
:)
> I think what we're running into here is the difference between I2S
> normal mode, and I2S justified mode. In justified modes, it'd be
> normal to have a slot bit width of 32 but a valid data width of, say,
> 16. In that case, VDJ would specify whether something is left or right
> justified as far as I can tell.
>
> So basically I'm wondering if we've accidentally been sending
> I2S left-justified data all along when using SND_SOC_DAIFMT_I2S,
> and whether we should only be setting this in SND_SOC_DAIFMT_I2S.
Isn't the difference between SND_SOC_DAIFMT_I2S vs.
SND_SOC_DAIFMT_LEFT_J just about clock timings / edges? I thought both
can have slot width >= sample width, but I could be wrong (not an
audio guru here).
> Either way, I can give this a
>
> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
> for ES8388 on my ROCK 4D (with my enablement patches for it there
> on top that I need to get back around to).
Thanks a lot!
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: remoteproc: k3-r5f: Add memory-region-names
From: Rob Herring (Arm) @ 2026-03-26 14:53 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: Nishanth Menon, devicetree, Conor Dooley, Vignesh Raghavendra,
Mathieu Poirier, Dhruva Gole, Akashdeep Kaur, Kevin Hilman,
Bjorn Andersson, linux-remoteproc, linux-kernel, Kendall Willis,
Vishal Mahaveer, Sebin Francis, Krzysztof Kozlowski, Tero Kristo,
linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-2-c41473cb23c3@baylibre.com>
On Wed, 18 Mar 2026 16:13:08 +0100, Markus Schneider-Pargmann (TI) wrote:
> Add names to the memory-region-names for easier identification of memory
> regions. As the meaning of the second memory region can be different
> also require the use of memory-region-names if memory-region is in use.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: remoteproc: k3-r5f: Split up memory regions
From: Rob Herring (Arm) @ 2026-03-26 14:53 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: Nishanth Menon, Mathieu Poirier, Conor Dooley,
Vignesh Raghavendra, Tero Kristo, Dhruva Gole, Akashdeep Kaur,
Kevin Hilman, Bjorn Andersson, linux-remoteproc, linux-kernel,
Kendall Willis, devicetree, Vishal Mahaveer, Sebin Francis,
Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-1-c41473cb23c3@baylibre.com>
On Wed, 18 Mar 2026 16:13:07 +0100, Markus Schneider-Pargmann (TI) wrote:
> Split up the region reserved for the firmware image in more specific
> sections to expose the full fixed layout. Especially the LPM metadata
> section is important for bootloaders as it contains information about
> how to exit IO+DDR. This is read by the bootloader but is written by the
> firmware.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 29 ++++++++++++++--------
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 02/11] drm/fourcc: Add DRM_FORMAT_XV15/XV20
From: Simon Ser @ 2026-03-26 14:48 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Dave Stevenson, Vishal Sagar, Anatoliy Klymenko,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Laurent Pinchart, Michal Simek, dri-devel,
linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Dmitry Baryshkov
In-Reply-To: <67120b18-8763-4b93-b89f-7f919f38e08e@ideasonboard.com>
On Friday, March 20th, 2026 at 11:37, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
> On 19/03/2026 17:15, Simon Ser wrote:
> > What is the difference between DRM_FORMAT_XV15 and DRM_FORMAT_P030?
>
> Good question. I thought the Cr & Cb are swapped between those formats.
>
> The VC4 driver uses HVS_PIXEL_ORDER_XYCBCR define, and the comment in
> drm_fourcc.h starts with "YCbCr420". So, CbCr. But then the comments
> then continue with CrCb.
>
> XV15/20 isn't super clear either, starting with "YCrCb" but then "Cb:Cr
> plane".
>
> The components in the plane descriptions look identical though, hinting
> they are the same. So to be sure, I tested it:
>
> I had test pattern support for XV15/20 in pykms, which I can test on a
> Xilinx board. P030 is a bit more difficult, as on RPi5 it requires
> DRM_FORMAT_MOD_BROADCOM_SAND128. But with a linear -> SAND128 converter,
> I was able to test linear NV12 converted to NV12+SAND128 and shown on
> the screen (just for reference), and similarly linear XV15 ->
> P030+SAND128. And, indeed, the linear XV15 test pattern shows correctly
> on screen when converted to SAND128. So afaics XV15 is indeed identical
> to P030, and I can drop XV15.
>
> This then brings up the question about XV20. That format doesn't exist
> yet, but should it then be named similarly to P030? However, I have no
> idea what P030 means, so I don't know what a 2x1 subsampled P030 would
> be called...
>
> Thoughts/ideas? Or just keep XV20?
I've replied with some ideas on the new version's thread :)
^ permalink raw reply
* Re: [PATCH v5] nvme: Skip trace complete_rq on host path error
From: Keith Busch @ 2026-03-26 14:43 UTC (permalink / raw)
To: hch@lst.de
Cc: 전민식, Justin Tee, axboe@kernel.dk,
sven@kernel.org, j@jannau.net, neal@gompa.dev, sagi@grimberg.me,
justin.tee@broadcom.com, nareshgottumukkala83@gmail.com,
paul.ely@broadcom.com, James Smart, kch@nvidia.com,
linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org, 이은수,
칸찬
In-Reply-To: <20260326143124.GA17507@lst.de>
On Thu, Mar 26, 2026 at 03:31:24PM +0100, hch@lst.de wrote:
> On Thu, Mar 26, 2026 at 08:28:46AM -0600, Keith Busch wrote:
> > On Thu, Mar 26, 2026 at 03:51:52PM +0900, 전민식 wrote:
> > > {
> > > struct nvme_ctrl *ctrl = nvme_req(req)->ctrl;
> > >
> > > - trace_nvme_complete_rq(req);
> > > + /*
> > > + * The idea for these trace events was to match up commands
> > > + * dispatched to hardware with the hardware's posted response.
> > > + * So skip tracing for undispatched commands.
> > > + */
> > > + if (nvme_req(req)->status != NVME_SC_HOST_PATH_ERROR)
> > > + trace_nvme_complete_rq(req);
> > > +
> >
> > Well, how do we know a controller doesnn't actually return that status
> > code? I was just suggesting to skip the trace for the condition we never
> > dispatched the command. An added bonus is we don't need a mostly
> > unnecessary 'if' check on every IO.
>
> The 7?h error values were added for host use. The description of
> the section in the spec suggests this, but isn't actually as clear
> as I would like it. I wonder if we need to verify that controller
> don't incorrectly return it, as that could cause some problems?
Yeah, the spec is not very clear on their use. It just defines the codes
and a one sentence description, and then never mentioned again. I think
it allows the possibility for the controller to internally complete a
command with such status from some undefined OOB mechanism. I'm not sure
why the host needs to have their own self-generated status codes anyway
since it can already attach whatever arbitrary flags it wants to its
private data, like how we use NVME_REQ_CANCELLED.
Anyway if a controller did return it for whatever reason, even if it is
a bug, we'd want to see it in the trace.
^ permalink raw reply
* Re: [PATCH v9 05/11] drm/fourcc: Add DRM_FORMAT_X403
From: Simon Ser @ 2026-03-26 14:43 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen
In-Reply-To: <20260325-xilinx-formats-v9-5-d03b7e3752e4@ideasonboard.com>
On Wednesday, March 25th, 2026 at 15:02, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
> +/*
> + * 3 plane non-subsampled (444) YCbCr
> + * 10 bpc, 30 bits per sample image data in a single contiguous buffer.
> + * index 0: Y plane, [31:0] x:Y2:Y1:Y0 [2:10:10:10] little endian
> + * index 1: Cb plane, [31:0] x:Cb2:Cb1:Cb0 [2:10:10:10] little endian
> + * index 2: Cr plane, [31:0] x:Cr2:Cr1:Cr0 [2:10:10:10] little endian
> + */
> +#define DRM_FORMAT_X403 fourcc_code('X', '4', '0', '3')
So, this one is different from the Q family, because Q has padding in
LSB rather than MSB. Speaking of, maybe we should add "LSB aligned" to
the doc comment to make that clear?
Re-reading the sibling thread about DRM_FORMAT_XV20, sounds like the
first digit matches my expectations for sub-sampling. How did you pick
the last two digits? I think I would've expected "30" here rather than
"03", since the last two planes are Cb Cr rather than Cr Cb.
Has the first "X" letter been picked arbitrarily? It's already used to
denote padding in other formats so I wonder if we should pick that
instead of, say, "T".
Simon
^ permalink raw reply
* Re: [PATCH v2] irqchip/gic-v3: Print a warning for out-of-range interrupt numbers
From: Thomas Gleixner @ 2026-03-26 14:43 UTC (permalink / raw)
To: Geert Uytterhoeven, Marc Zyngier
Cc: linux-arm-kernel, linux-renesas-soc, linux-kernel,
Geert Uytterhoeven
In-Reply-To: <ce695ea46decc816974179314a86f2b9b5cad6a9.1772799134.git.geert+renesas@glider.be>
On Fri, Mar 06 2026 at 13:13, Geert Uytterhoeven wrote:
> gic_irq_domain_translate() does not check if an interrupt number lies
> within the valid range of the specified interrupt type. Add these
> checks, and print a warning if the interrupt number is out of range.
>
> This can help flagging incorrectly described Extended SPI and PPI
> interrupts in DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Marc, any objections or comments?
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: freescale: imx95-toradex-smarc: Use gpio-hog for WIFI_UART_EN
From: Franz Schnyder @ 2026-03-26 14:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini
In-Reply-To: <20260326143711.143462-1-fra.schnyder@gmail.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
On the Toradex SMARC iMX95, the WiFi UART signals are shared with the
JTAG. The WIFI_UART_EN signal is used to select between these
two functions. A GPIO hog is used to select the UART function by
default. This DT file is going to be used by both Linux and the boot
firmware, and the boot firmware will configure the GPIO hog way before
the Linux kernel is booted, therefore there is no actual race condition
between the Linux kernel BT UART driver and GPIO hog probe.
Configure WIFI_UART_EN as a gpio-hog driven high.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: Remove unused label for wifi-uart-en-hog node
Add explanation to clarify the safe usage of the GPIO hog
---
arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index a90edefc5197..8eef26eb0f87 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -451,6 +451,13 @@ som_gpio_expander_1: gpio@21 {
"",
"",
"SMARC_SDIO_WP";
+
+ wifi-uart-en-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ line-name = "WIFI_UART_EN";
+ output-high;
+ };
};
embedded-controller@28 {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on lpuart5
From: Franz Schnyder @ 2026-03-26 14:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini
In-Reply-To: <20260326143711.143462-1-fra.schnyder@gmail.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
The Toradex SMARC iMX95 uses the MAYA-W260 WiFi/Bluetooth module, which
uses the UART interface for Bluetooth.
Add UART support to enable bluetooth functionality on the MAYA-W260.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
Although Documentation/devicetree/bindings/dts-coding-style.rst
recommends an empty line between status and latest property, leave it
unchanged for consistency with the rest of the file.
v2: no changes
---
.../dts/freescale/imx95-toradex-smarc.dtsi | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 1d369983cf7d..a90edefc5197 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -616,6 +616,19 @@ &lpuart3 {
pinctrl-0 = <&pinctrl_uart3>;
};
+/* On-module Bluetooth */
+&lpuart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_bt_uart>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ fw-init-baudrate = <3000000>;
+ };
+};
+
/* SMARC SER2 */
&lpuart6 {
pinctrl-names = "default";
@@ -830,6 +843,14 @@ &wdog3 {
};
&scmi_iomuxc {
+ /* On-module Bluetooth, UART pins shared with JTAG */
+ pinctrl_bt_uart: btuartgrp {
+ fsl,pins = <IMX95_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e>, /* WiFI_UART_RXD */
+ <IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e>, /* WiFI_UART_TXD */
+ <IMX95_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e>, /* WiFI_UART_RTS# */
+ <IMX95_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e>; /* WiFI_UART_CTS# */
+ };
+
/* SMARC CAM_MCK */
pinctrl_cam_mck: cammckgrp {
fsl,pins = <IMX95_PAD_CCM_CLKO1__CCMSRCGPCMIX_TOP_CLKO_1 0x51e>; /* SMARC S6 - CAM_MCK */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] arm64: dts: freescale: imx95-toradex-smarc: Add SER2 interface
From: Franz Schnyder @ 2026-03-26 14:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini
In-Reply-To: <20260326143711.143462-1-fra.schnyder@gmail.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
The Toradex SMARC iMX95 has four exposed serial interfaces, one of these
is SER2, which supports RTS/CTS.
Add UART support for SMARC SER2.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: no changes
---
.../dts/freescale/imx95-toradex-smarc-dev.dts | 5 +++++
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 16 ++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
index 5b05f256fd52..7437e523ff63 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
@@ -210,6 +210,11 @@ &lpuart3 {
status = "okay";
};
+/* SMARC SER2 */
+&lpuart6 {
+ status = "okay";
+};
+
/* SMARC MDIO, shared between all ethernet ports */
&netc_emdio {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 7a73958f6eec..1d369983cf7d 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -22,6 +22,7 @@ aliases {
rtc1 = &scmi_bbm;
serial0 = &lpuart2;
serial1 = &lpuart1;
+ serial2 = &lpuart6;
serial3 = &lpuart3;
};
@@ -615,6 +616,13 @@ &lpuart3 {
pinctrl-0 = <&pinctrl_uart3>;
};
+/* SMARC SER2 */
+&lpuart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ uart-has-rtscts;
+};
+
&mu7 {
status = "okay";
};
@@ -1105,6 +1113,14 @@ pinctrl_uart3: uart3grp {
<IMX95_PAD_GPIO_IO15__LPUART3_RX 0x31e>; /* SMARC P141 - SER3_RX */
};
+ /* SMARC SER2 */
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO34__LPUART6_CTS_B 0x31e>, /* SMARC P139 - SER2_CTS# */
+ <IMX95_PAD_GPIO_IO07__LPUART6_RTS_B 0x31e>, /* SMARC P138 - SER2_RTS# */
+ <IMX95_PAD_GPIO_IO05__LPUART6_RX 0x31e>, /* SMARC P137 - SER2_RX */
+ <IMX95_PAD_GPIO_IO04__LPUART6_TX 0x31e>; /* SMARC P136 - SER2_TX */
+ };
+
/* On-module eMMC */
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>, /* SD1_CLK */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] arm64: dts: freescale: imx95-toradex-smarc: Add Bluetooth and SER2
From: Franz Schnyder @ 2026-03-26 14:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini
From: Franz Schnyder <franz.schnyder@toradex.com>
This patch series adds support for missing interfaces on the Toradex
SMARC i.MX95 SoM.
It adds:
- SER2 interface
- UART interface for Bluetooth
- WIFI_UART_EN as a gpio-hog to select the UART function by default,
as the MAYA-W260 UART signals are shared with the JTAG.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: Remove unused label for wifi-uart-en-hog node
Add explanation to clarify the safe usage of the GPIO hog
---
Franz Schnyder (3):
arm64: dts: freescale: imx95-toradex-smarc: Add SER2 interface
arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on
lpuart5
arm64: dts: freescale: imx95-toradex-smarc: Use gpio-hog for
WIFI_UART_EN
.../dts/freescale/imx95-toradex-smarc-dev.dts | 5 +++
.../dts/freescale/imx95-toradex-smarc.dtsi | 44 +++++++++++++++++++
2 files changed, 49 insertions(+)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v3 4/5] KVM: arm64: Enable HDBSS support and handle HDBSSF events
From: Leonardo Bras @ 2026-03-26 14:31 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <acQj5grOdZT8LUGp@devkitleo>
On Wed, Mar 25, 2026 at 06:05:26PM +0000, Leonardo Bras wrote:
> Hello Tian,
>
> I am currently working on HACDBS enablement(which will be rebased on top of
> this patchset) and due to the fact HACDBS and HDBSS are kind of
> complementary I will sometimes come with some questions for issues I have
> faced myself on that part. :)
>
> (see below)
>
> On Wed, Feb 25, 2026 at 12:04:20PM +0800, Tian Zheng wrote:
> > From: eillon <yezhenyu2@huawei.com>
> >
> > HDBSS is enabled via an ioctl from userspace (e.g. QEMU) at the start of
> > migration. This feature is only supported in VHE mode.
> >
> > Initially, S2 PTEs doesn't contain the DBM attribute. During migration,
> > write faults are handled by user_mem_abort, which relaxes permissions
> > and adds the DBM bit when HDBSS is active. Once DBM is set, subsequent
> > writes no longer trap, as the hardware automatically transitions the page
> > from writable-clean to writable-dirty.
> >
> > KVM does not scan S2 page tables to consume DBM. Instead, when HDBSS is
> > enabled, the hardware observes the clean->dirty transition and records
> > the corresponding page into the HDBSS buffer.
> >
> > During sync_dirty_log, KVM kicks all vCPUs to force VM-Exit, ensuring
> > that check_vcpu_requests flushes the HDBSS buffer and propagates the
> > accumulated dirty information into the userspace-visible dirty bitmap.
> >
> > Add fault handling for HDBSS including buffer full, external abort, and
> > general protection fault (GPF).
> >
> > Signed-off-by: eillon <yezhenyu2@huawei.com>
> > Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> > ---
> > arch/arm64/include/asm/esr.h | 5 ++
> > arch/arm64/include/asm/kvm_host.h | 17 +++++
> > arch/arm64/include/asm/kvm_mmu.h | 1 +
> > arch/arm64/include/asm/sysreg.h | 11 ++++
> > arch/arm64/kvm/arm.c | 102 ++++++++++++++++++++++++++++++
> > arch/arm64/kvm/hyp/vhe/switch.c | 19 ++++++
> > arch/arm64/kvm/mmu.c | 70 ++++++++++++++++++++
> > arch/arm64/kvm/reset.c | 3 +
> > 8 files changed, 228 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> > index 81c17320a588..2e6b679b5908 100644
> > --- a/arch/arm64/include/asm/esr.h
> > +++ b/arch/arm64/include/asm/esr.h
> > @@ -437,6 +437,11 @@
> > #ifndef __ASSEMBLER__
> > #include <asm/types.h>
> >
> > +static inline bool esr_iss2_is_hdbssf(unsigned long esr)
> > +{
> > + return ESR_ELx_ISS2(esr) & ESR_ELx_HDBSSF;
> > +}
> > +
> > static inline unsigned long esr_brk_comment(unsigned long esr)
> > {
> > return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 5d5a3bbdb95e..57ee6b53e061 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -55,12 +55,17 @@
> > #define KVM_REQ_GUEST_HYP_IRQ_PENDING KVM_ARCH_REQ(9)
> > #define KVM_REQ_MAP_L1_VNCR_EL2 KVM_ARCH_REQ(10)
> > #define KVM_REQ_VGIC_PROCESS_UPDATE KVM_ARCH_REQ(11)
> > +#define KVM_REQ_FLUSH_HDBSS KVM_ARCH_REQ(12)
> >
> > #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
> > KVM_DIRTY_LOG_INITIALLY_SET)
> >
> > #define KVM_HAVE_MMU_RWLOCK
> >
> > +/* HDBSS entry field definitions */
> > +#define HDBSS_ENTRY_VALID BIT(0)
> > +#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
> > +
> > /*
> > * Mode of operation configurable with kvm-arm.mode early param.
> > * See Documentation/admin-guide/kernel-parameters.txt for more information.
> > @@ -84,6 +89,7 @@ int __init kvm_arm_init_sve(void);
> > u32 __attribute_const__ kvm_target_cpu(void);
> > void kvm_reset_vcpu(struct kvm_vcpu *vcpu);
> > void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu);
> > +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
> >
> > struct kvm_hyp_memcache {
> > phys_addr_t head;
> > @@ -405,6 +411,8 @@ struct kvm_arch {
> > * the associated pKVM instance in the hypervisor.
> > */
> > struct kvm_protected_vm pkvm;
> > +
> > + bool enable_hdbss;
> > };
> >
> > struct kvm_vcpu_fault_info {
> > @@ -816,6 +824,12 @@ struct vcpu_reset_state {
> > bool reset;
> > };
> >
> > +struct vcpu_hdbss_state {
> > + phys_addr_t base_phys;
> > + u32 size;
> > + u32 next_index;
> > +};
> > +
> > struct vncr_tlb;
> >
> > struct kvm_vcpu_arch {
> > @@ -920,6 +934,9 @@ struct kvm_vcpu_arch {
> >
> > /* Per-vcpu TLB for VNCR_EL2 -- NULL when !NV */
> > struct vncr_tlb *vncr_tlb;
> > +
> > + /* HDBSS registers info */
> > + struct vcpu_hdbss_state hdbss;
> > };
> >
> > /*
> > diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> > index d968aca0461a..3fea8cfe8869 100644
> > --- a/arch/arm64/include/asm/kvm_mmu.h
> > +++ b/arch/arm64/include/asm/kvm_mmu.h
> > @@ -183,6 +183,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> >
> > int kvm_handle_guest_sea(struct kvm_vcpu *vcpu);
> > int kvm_handle_guest_abort(struct kvm_vcpu *vcpu);
> > +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
> >
> > phys_addr_t kvm_mmu_get_httbr(void);
> > phys_addr_t kvm_get_idmap_vector(void);
> > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> > index f4436ecc630c..d11f4d0dd4e7 100644
> > --- a/arch/arm64/include/asm/sysreg.h
> > +++ b/arch/arm64/include/asm/sysreg.h
> > @@ -1039,6 +1039,17 @@
> >
> > #define GCS_CAP(x) ((((unsigned long)x) & GCS_CAP_ADDR_MASK) | \
> > GCS_CAP_VALID_TOKEN)
> > +
> > +/*
> > + * Definitions for the HDBSS feature
> > + */
> > +#define HDBSS_MAX_SIZE HDBSSBR_EL2_SZ_2MB
> > +
> > +#define HDBSSBR_EL2(baddr, sz) (((baddr) & GENMASK(55, 12 + sz)) | \
> > + FIELD_PREP(HDBSSBR_EL2_SZ_MASK, sz))
> > +
> > +#define HDBSSPROD_IDX(prod) FIELD_GET(HDBSSPROD_EL2_INDEX_MASK, prod)
> > +
> > /*
> > * Definitions for GICv5 instructions]
> > */
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index 29f0326f7e00..d64da05e25c4 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -125,6 +125,87 @@ int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
> > return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
> > }
> >
> > +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu)
> > +{
> > + struct page *hdbss_pg;
> > +
> > + hdbss_pg = phys_to_page(vcpu->arch.hdbss.base_phys);
> > + if (hdbss_pg)
> > + __free_pages(hdbss_pg, vcpu->arch.hdbss.size);
> > +
> > + vcpu->arch.hdbss.size = 0;
> > +}
> > +
> > +static int kvm_cap_arm_enable_hdbss(struct kvm *kvm,
> > + struct kvm_enable_cap *cap)
> > +{
> > + unsigned long i;
> > + struct kvm_vcpu *vcpu;
> > + struct page *hdbss_pg = NULL;
> > + __u64 size = cap->args[0];
> > + bool enable = cap->args[1] ? true : false;
> > +
> > + if (!system_supports_hdbss())
> > + return -EINVAL;
> > +
> > + if (size > HDBSS_MAX_SIZE)
> > + return -EINVAL;
> > +
> > + if (!enable && !kvm->arch.enable_hdbss) /* Already Off */
> > + return 0;
> > +
> > + if (enable && kvm->arch.enable_hdbss) /* Already On, can't set size */
> > + return -EINVAL;
> > +
> > + if (!enable) { /* Turn it off */
> > + kvm->arch.mmu.vtcr &= ~(VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA);
> > +
> > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > + /* Kick vcpus to flush hdbss buffer. */
> > + kvm_vcpu_kick(vcpu);
> > +
> > + kvm_arm_vcpu_free_hdbss(vcpu);
> > + }
> > +
> > + kvm->arch.enable_hdbss = false;
> > +
> > + return 0;
> > + }
> > +
> > + /* Turn it on */
> > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > + hdbss_pg = alloc_pages(GFP_KERNEL_ACCOUNT, size);
> > + if (!hdbss_pg)
> > + goto error_alloc;
> > +
> > + vcpu->arch.hdbss = (struct vcpu_hdbss_state) {
> > + .base_phys = page_to_phys(hdbss_pg),
> > + .size = size,
> > + .next_index = 0,
> > + };
> > + }
> > +
> > + kvm->arch.enable_hdbss = true;
> > + kvm->arch.mmu.vtcr |= VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA;
> > +
> > + /*
> > + * We should kick vcpus out of guest mode here to load new
> > + * vtcr value to vtcr_el2 register when re-enter guest mode.
> > + */
> > + kvm_for_each_vcpu(i, vcpu, kvm)
> > + kvm_vcpu_kick(vcpu);
> > +
> > + return 0;
> > +
> > +error_alloc:
> > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > + if (vcpu->arch.hdbss.base_phys)
> > + kvm_arm_vcpu_free_hdbss(vcpu);
> > + }
> > +
> > + return -ENOMEM;
> > +}
> > +
> > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > struct kvm_enable_cap *cap)
> > {
> > @@ -182,6 +263,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > r = 0;
> > set_bit(KVM_ARCH_FLAG_EXIT_SEA, &kvm->arch.flags);
> > break;
> > + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
> > + mutex_lock(&kvm->lock);
> > + r = kvm_cap_arm_enable_hdbss(kvm, cap);
> > + mutex_unlock(&kvm->lock);
> > + break;
> > default:
> > break;
> > }
> > @@ -471,6 +557,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > r = kvm_supports_cacheable_pfnmap();
> > break;
> >
> > + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
> > + r = system_supports_hdbss();
> > + break;
> > default:
> > r = 0;
> > }
> > @@ -1120,6 +1209,9 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu)
> > if (kvm_dirty_ring_check_request(vcpu))
> > return 0;
> >
> > + if (kvm_check_request(KVM_REQ_FLUSH_HDBSS, vcpu))
> > + kvm_flush_hdbss_buffer(vcpu);
> > +
> > check_nested_vcpu_requests(vcpu);
> > }
> >
> > @@ -1898,7 +1990,17 @@ long kvm_arch_vcpu_unlocked_ioctl(struct file *filp, unsigned int ioctl,
> >
> > void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
> > {
> > + /*
> > + * Flush all CPUs' dirty log buffers to the dirty_bitmap. Called
> > + * before reporting dirty_bitmap to userspace. Send a request with
> > + * KVM_REQUEST_WAIT to flush buffer synchronously.
> > + */
> > + struct kvm_vcpu *vcpu;
> > +
> > + if (!kvm->arch.enable_hdbss)
> > + return;
> >
> > + kvm_make_all_cpus_request(kvm, KVM_REQ_FLUSH_HDBSS);
> > }
> >
> > static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
> > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> > index 9db3f11a4754..600cbc4f8ae9 100644
> > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > @@ -213,6 +213,23 @@ static void __vcpu_put_deactivate_traps(struct kvm_vcpu *vcpu)
> > local_irq_restore(flags);
> > }
> >
> > +static void __load_hdbss(struct kvm_vcpu *vcpu)
> > +{
> > + struct kvm *kvm = vcpu->kvm;
> > + u64 br_el2, prod_el2;
> > +
> > + if (!kvm->arch.enable_hdbss)
> > + return;
> > +
> > + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
> > + prod_el2 = vcpu->arch.hdbss.next_index;
> > +
> > + write_sysreg_s(br_el2, SYS_HDBSSBR_EL2);
> > + write_sysreg_s(prod_el2, SYS_HDBSSPROD_EL2);
> > +
> > + isb();
> > +}
> > +
>
> I see in the code below you trust that the tracking will happen with
> PAGE_SIZE granularity (you track with PAGE_SHIFT).
Oh, that was misleading :\
The mentioned routine is not wrong AFAICS, but without the patch I sent, if
the VMM does not manually set eager splitting, and is using some sort of
hugepages (even transparent, without noticing) it could end up sending just
PAGE_SIZE instead of the whole hugepage size, which breaks migration.
Does that make sense?
Thanks!
Leo
>
> That may be a problem when we have guest memory backed by hugepages or
> transparent huge pages.
>
> When we are using HDBSS, there is no fault happening, so we have no way of
> doing on-demand block splitting, so we need to make use of eager block
> splitting, _before_ we start to track anything, or else we may have
> different-sized pages in the HDBSS buffer, which is harder to deal with.
>
> Suggestion: do the eager splitting before we enable HDBSS.
>
> For this to happen, we have to enable the EAGER_SPLIT_CHUNK_SIZE
> capability, which can only be enabled when all memslots are empty.
>
> I suggest doing that at kvm_init_stage2_mmu(), and checking if HDBSS is
> in which case we set mmu->split_page_chunk_size to PAGESIZE.
>
> I will send a patch you can put before this one to make sure it works :)
>
> Thanks!
> Leo
>
>
> > void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
> > {
> > host_data_ptr(host_ctxt)->__hyp_running_vcpu = vcpu;
> > @@ -220,10 +237,12 @@ void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
> > __vcpu_load_switch_sysregs(vcpu);
> > __vcpu_load_activate_traps(vcpu);
> > __load_stage2(vcpu->arch.hw_mmu, vcpu->arch.hw_mmu->arch);
> > + __load_hdbss(vcpu);
> > }
> >
> > void kvm_vcpu_put_vhe(struct kvm_vcpu *vcpu)
> > {
> > + kvm_flush_hdbss_buffer(vcpu);
> > __vcpu_put_deactivate_traps(vcpu);
> > __vcpu_put_switch_sysregs(vcpu);
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 070a01e53fcb..42b0710a16ce 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -1896,6 +1896,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> > if (writable)
> > prot |= KVM_PGTABLE_PROT_W;
> >
> > + if (writable && kvm->arch.enable_hdbss && logging_active)
> > + prot |= KVM_PGTABLE_PROT_DBM;
> > +
> > if (exec_fault)
> > prot |= KVM_PGTABLE_PROT_X;
> >
> > @@ -2033,6 +2036,70 @@ int kvm_handle_guest_sea(struct kvm_vcpu *vcpu)
> > return 0;
> > }
> >
> > +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu)
> > +{
> > + int idx, curr_idx;
> > + u64 br_el2;
> > + u64 *hdbss_buf;
> > + struct kvm *kvm = vcpu->kvm;
> > +
> > + if (!kvm->arch.enable_hdbss)
> > + return;
> > +
> > + curr_idx = HDBSSPROD_IDX(read_sysreg_s(SYS_HDBSSPROD_EL2));
> > + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
> > +
> > + /* Do nothing if HDBSS buffer is empty or br_el2 is NULL */
> > + if (curr_idx == 0 || br_el2 == 0)
> > + return;
> > +
> > + hdbss_buf = page_address(phys_to_page(vcpu->arch.hdbss.base_phys));
> > + if (!hdbss_buf)
> > + return;
> > +
> > + guard(write_lock_irqsave)(&vcpu->kvm->mmu_lock);
> > + for (idx = 0; idx < curr_idx; idx++) {
> > + u64 gpa;
> > +
> > + gpa = hdbss_buf[idx];
> > + if (!(gpa & HDBSS_ENTRY_VALID))
> > + continue;
> > +
> > + gpa &= HDBSS_ENTRY_IPA;
> > + kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
> > + }
>
> Here ^
>
> > +
> > + /* reset HDBSS index */
> > + write_sysreg_s(0, SYS_HDBSSPROD_EL2);
> > + vcpu->arch.hdbss.next_index = 0;
> > + isb();
> > +}
> > +
> > +static int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu)
> > +{
> > + u64 prod;
> > + u64 fsc;
> > +
> > + prod = read_sysreg_s(SYS_HDBSSPROD_EL2);
> > + fsc = FIELD_GET(HDBSSPROD_EL2_FSC_MASK, prod);
> > +
> > + switch (fsc) {
> > + case HDBSSPROD_EL2_FSC_OK:
> > + /* Buffer full, which is reported as permission fault. */
> > + kvm_flush_hdbss_buffer(vcpu);
> > + return 1;
> > + case HDBSSPROD_EL2_FSC_ExternalAbort:
> > + case HDBSSPROD_EL2_FSC_GPF:
> > + return -EFAULT;
> > + default:
> > + /* Unknown fault. */
> > + WARN_ONCE(1,
> > + "Unexpected HDBSS fault type, FSC: 0x%llx (prod=0x%llx, vcpu=%d)\n",
> > + fsc, prod, vcpu->vcpu_id);
> > + return -EFAULT;
> > + }
> > +}
> > +
> > /**
> > * kvm_handle_guest_abort - handles all 2nd stage aborts
> > * @vcpu: the VCPU pointer
> > @@ -2071,6 +2138,9 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
> >
> > is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
> >
> > + if (esr_iss2_is_hdbssf(esr))
> > + return kvm_handle_hdbss_fault(vcpu);
> > +
> > if (esr_fsc_is_translation_fault(esr)) {
> > /* Beyond sanitised PARange (which is the IPA limit) */
> > if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > index 959532422d3a..c03a4b310b53 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -161,6 +161,9 @@ void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu)
> > free_page((unsigned long)vcpu->arch.ctxt.vncr_array);
> > kfree(vcpu->arch.vncr_tlb);
> > kfree(vcpu->arch.ccsidr);
> > +
> > + if (vcpu->kvm->arch.enable_hdbss)
> > + kvm_arm_vcpu_free_hdbss(vcpu);
> > }
> >
> > static void kvm_vcpu_reset_sve(struct kvm_vcpu *vcpu)
> > --
> > 2.33.0
> >
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Christian Schrefl @ 2026-03-26 14:31 UTC (permalink / raw)
To: Miguel Ojeda, Alice Ryhl, Ard Biesheuvel, Jamie Cunliffe,
Will Deacon, Catalin Marinas
Cc: Russell King (Oracle), Miguel Ojeda, a.hindborg, acourbot, akpm,
anton.ivanov, bjorn3_gh, boqun.feng, dakr, david, gary, johannes,
justinstitt, linux-arm-kernel, linux-kbuild, linux-kernel,
linux-mm, linux-um, llvm, lossin, mark.rutland, mmaurer, morbo,
nathan, nick.desaulniers+lkml, nicolas.schier, nsc, peterz,
richard, rust-for-linux, tmgross, urezki
In-Reply-To: <CANiq72mzPpkELXis1CiSbKUmBXNQYMiMmjj-7-sYiLh4T_JSOQ@mail.gmail.com>
Hi Miguel,
On 3/26/26 2:47 PM, Miguel Ojeda wrote:
> On Thu, Mar 26, 2026 at 11:10 AM Alice Ryhl <aliceryhl@google.com> wrote:
>>
>> I noticed that the Makefile currently uses the arm-unknown-linux-gnueabi
>> target. It should probably not be -linux target to avoid this? Probably
>> it should just be armv7a-none-eabi, right? We gate HAVE_RUST on
>> CPU_32v7, so we should not need to consider the other variants.
>
> I think Christian tried several targets back then and eventually
> picked that one.
>
> Christian: what was the reason to pick the `-linux-` one? e.g. was
> there something you wanted to rely on that target spec that you
> couldn't enable or disable via `rustc` flags or similar?
It should probably be fine to use armv7a-none-eabi. I've mostly used
arm-unknown-linux-gnueabi since I though it needed to match the
bindgen-target (which is -linux-gnu for all architectures) and
because from what I understand clang also uses arm-linux-gnueabi [1].
Also when I selected the target I thought that we would also support
armv6, but since I had no v6 hardware to test on I disabled it.
[1]: https://github.com/Rust-for-Linux/linux/blob/rust-next/scripts/Makefile.clang#L4
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH v5] nvme: Skip trace complete_rq on host path error
From: hch @ 2026-03-26 14:31 UTC (permalink / raw)
To: Keith Busch
Cc: 전민식, hch@lst.de, Justin Tee, axboe@kernel.dk,
sven@kernel.org, j@jannau.net, neal@gompa.dev, sagi@grimberg.me,
justin.tee@broadcom.com, nareshgottumukkala83@gmail.com,
paul.ely@broadcom.com, James Smart, kch@nvidia.com,
linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org, 이은수,
칸찬
In-Reply-To: <acVCnozG1WKPkq1L@kbusch-mbp>
On Thu, Mar 26, 2026 at 08:28:46AM -0600, Keith Busch wrote:
> On Thu, Mar 26, 2026 at 03:51:52PM +0900, 전민식 wrote:
> > {
> > struct nvme_ctrl *ctrl = nvme_req(req)->ctrl;
> >
> > - trace_nvme_complete_rq(req);
> > + /*
> > + * The idea for these trace events was to match up commands
> > + * dispatched to hardware with the hardware's posted response.
> > + * So skip tracing for undispatched commands.
> > + */
> > + if (nvme_req(req)->status != NVME_SC_HOST_PATH_ERROR)
> > + trace_nvme_complete_rq(req);
> > +
>
> Well, how do we know a controller doesnn't actually return that status
> code? I was just suggesting to skip the trace for the condition we never
> dispatched the command. An added bonus is we don't need a mostly
> unnecessary 'if' check on every IO.
The 7?h error values were added for host use. The description of
the section in the spec suggests this, but isn't actually as clear
as I would like it. I wonder if we need to verify that controller
don't incorrectly return it, as that could cause some problems?
Independent of that your patch below looks sane to me.
^ 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