* [PATCH v3 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm
From: Moteen Shah @ 2026-03-30 9:44 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260330094459.128648-1-m-shah@ti.com>
From: Jayesh Choudhary <j-choudhary@ti.com>
Add device tree overlay to enable analog audio support on J721S2-EVM
using PCM3168A codec connected to McASP4 serializers.
- Add nodes for sound-card, audio codec, I2C3 and McASP4
- Add pinmux for I2C3, McASP4, AUDIO_EXT_REFCLK1 and WKUP_GPIO_0
- Add GPIO expander (TCA6408) for codec control
- Add GPIO hogs to route I2C3 lines and McASP serializers
- Set idle-state to 0 in mux0 and mux1 for McASP signal routing
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Co-developed-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 161 ++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index ba01a929e06f..17048f2f5043 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-audio.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
@@ -264,6 +265,8 @@ k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie1-ep.dtbo
k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-j721s2-evm-audio-dtbs := k3-j721s2-common-proc-board.dtb \
+ k3-j721s2-evm-audio.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
k3-j721s2-evm-pcie1-ep.dtbo
k3-j721s2-evm-usb0-type-a-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -328,6 +331,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
+ k3-j721s2-evm-audio.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
new file mode 100644
index 000000000000..2a3ff1cfc650
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Device Tree Overlay for J721S2 Audio Support
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "k3-pinctrl.h"
+
+&{/} {
+ codec_audio: sound {
+ compatible = "ti,j7200-cpb-audio";
+ model = "j721s2-cpb";
+
+ ti,cpb-mcasp = <&mcasp4>;
+ ti,cpb-codec = <&pcm3168a_1>;
+
+ clocks = <&k3_clks 213 0>, <&k3_clks 213 1>,
+ <&k3_clks 157 299>, <&k3_clks 157 328>;
+ clock-names = "cpb-mcasp-auxclk", "cpb-mcasp-auxclk-48000",
+ "cpb-codec-scki", "cpb-codec-scki-48000";
+ };
+
+ i2c_mux: mux-controller-2 {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ mux-gpios = <&wkup_gpio0 54 GPIO_ACTIVE_HIGH>;
+ idle-state = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_mux_pins_default>;
+ };
+};
+
+&main_pmx0 {
+ mcasp4_pins_default: mcasp4-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x0c8, PIN_OUTPUT_PULLDOWN, 1) /* (AD28) MCASP4_ACLKX */
+ J721S2_IOPAD(0x06c, PIN_OUTPUT_PULLDOWN, 1) /* (V26) MCASP4_AFSX */
+ J721S2_IOPAD(0x068, PIN_INPUT_PULLDOWN, 1) /* (U28) MCASP4_AXR1 */
+ J721S2_IOPAD(0x0c4, PIN_OUTPUT_PULLDOWN, 1) /* (AB26) MCASP4_AXR2 */
+ J721S2_IOPAD(0x070, PIN_OUTPUT_PULLDOWN, 1) /* (R27) MCASP4_AXR3 */
+ >;
+ };
+
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x078, PIN_OUTPUT, 1) /* (Y25) MCAN2_RX.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+};
+
+&wkup_pmx2 {
+ main_i2c3_mux_pins_default: main-i2c3-mux-default-pins {
+ pinctrl-single,pins = <
+ J721S2_WKUP_IOPAD(0x038, PIN_OUTPUT, 7) /* (B27) WKUP_GPIO0_54 */
+ >;
+ };
+};
+
+&exp2 {
+ p09-hog {
+ /* P09 - MCASP/TRACE_MUX_S0 */
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "MCASP/TRACE_MUX_S0";
+ };
+
+ p10-hog {
+ /* P10 - MCASP/TRACE_MUX_S1 */
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MCASP/TRACE_MUX_S1";
+ };
+};
+
+&mux0 {
+ idle-state = <0>;
+};
+
+&mux1 {
+ idle-state = <0>;
+};
+
+&scm_conf {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ audio_refclk1: clock-controller@42e4 {
+ compatible = "ti,am62-audio-refclk";
+ reg = <0x42e4 0x4>;
+ clocks = <&k3_clks 157 299>;
+ assigned-clocks = <&k3_clks 157 299>;
+ assigned-clock-parents = <&k3_clks 157 328>;
+ #clock-cells = <0>;
+ };
+};
+
+&k3_clks {
+ /* Configure AUDIO_EXT_REFCLK1 pin as output */
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+};
+
+&main_i2c3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_pins_default>;
+ clock-frequency = <400000>;
+ mux-states = <&i2c_mux 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ exp3: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "CODEC_RSTZ", "CODEC_SPARE1",
+ "UB926_RESETN", "UB926_LOCK",
+ "UB926_PWR_SW_CNTRL", "UB926_TUNER_RESET",
+ "UB926_GPIO_SPARE";
+ };
+
+ pcm3168a_1: audio-codec@44 {
+ compatible = "ti,pcm3168a";
+ reg = <0x44>;
+ #sound-dai-cells = <1>;
+ reset-gpios = <&exp3 0 GPIO_ACTIVE_LOW>;
+ clocks = <&audio_refclk1>;
+ clock-names = "scki";
+ VDD1-supply = <&vsys_3v3>;
+ VDD2-supply = <&vsys_3v3>;
+ VCCAD1-supply = <&vsys_5v0>;
+ VCCAD2-supply = <&vsys_5v0>;
+ VCCDA1-supply = <&vsys_5v0>;
+ VCCDA2-supply = <&vsys_5v0>;
+ };
+};
+
+&mcasp4 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcasp4_pins_default>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ auxclk-fs-ratio = <256>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 2 1 1
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+};
--
2.34.1
^ permalink raw reply related
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 9:54 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFoz-sm0pfvn5iSYFY0mrW38vaGRZsFvrVPqsv7BsYxeWQ@mail.gmail.com>
On 23/03/2026 12:13, Ulf Hansson wrote:
> Hi Krzysztof,
>
> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>>
>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
>>> This series adds support for the power domains on Google GS101.
>>>
>>> There are a few differences compared to SoCs already supported by this
>>> driver:
>>> * register access does not work via plain ioremap() / readl() /
>>> writel().
>>> Instead, the regmap created by the PMU driver must be used (which
>>> uses Arm SMCC calls under the hood).
>>> * DTZPC: a call needs to be made before and after power domain off/on,
>>> to inform the EL3 firmware of the request.
>>> * power domains can and are fed by a regulator rail and therefore
>>> regulator control needed be implemented.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
>>
>> Best regards,
>
> Usually I pick up the power-domain related changes for the DT bindings
> and host them via an immutable branch called "dt". If needed, SOC
> maintainers can pull it to apply/test the corresponding DTS changes.
>
> That said, I am open to whatever you think is best here. Perhaps it's
> easier if you can drop the DT patches and provide your acks instead or
> if you can share them via an immutable branch for me to pull?
I did not pick up any pmdomain binding patches. I picked up only soc and
according to cover letter there are no dependencies between anything here.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 0/2] Enable audio support for J721S2 EVM
From: Moteen Shah @ 2026-03-30 9:44 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
This patch series, adds support for analog audio on J721S2 EVM using
device tree overlays.
Earlier version of the patchset sent upstream[0] was rejected as
its dependency[1], which resolves the DTBS check errors introduced
by [0] also got rejected on the grounds of ABI breakage.
Another solution to fix the DTBS check errors introduced by [0] is
to modify the ti,j721e-system-controller.yaml binding to allow
audio-refclk as clock-controller child. This is done in the first
patch of this series.
Changes since v2:
Link to v2: https://lore.kernel.org/all/20260205130707.2033197-1-m-shah@ti.com/
- Fix Makefile entries to follow alphabetical ordering
- Update model string from "j721e-cpb" to "j721s2-cpb"
- Fix gpio-line-names typo: "UBS926_PWR_SW_CNTRL" -> "UB926_PWR_SW_CNTRL"
Changes since v1:
Link to v1: https://lore.kernel.org/all/20260112104536.83309-1-m-shah@ti.com/
- Convert the changes to an overlay
- Enumerate the I2C mux used
- Remove CANUART_MUX_SEL1 gpio hog
- Fix typos
- Add gpio-line-names
- Fix commit message to showcase the right idle-state for muxes
- Carry review from Rob and Hari
Test log: https://gist.github.com/Jamm02/4d4c00bf88fa76cddae6319124341c53
[0]: https://lore.kernel.org/linux-arm-kernel/20250604104656.38752-1-j-choudhary@ti.com/
[1]: https://lore.kernel.org/all/20250603095609.33569-4-j-choudhary@ti.com/
Jayesh Choudhary (1):
arm64: dts: ti: Add audio overlay for k3-j721s2-evm
Moteen Shah (1):
ti,j721e-system-controller.yaml: Allow audio-refclk as
clock-controller child
.../soc/ti/ti,j721e-system-controller.yaml | 6 +-
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 161 ++++++++++++++++++
3 files changed, 169 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
--
2.34.1
^ permalink raw reply
* Re: [PATCH] net: lpc_eth: Fix a possible memory leak in lpc_mii_probe()
From: Vladimir Zapolskiy @ 2026-03-30 10:04 UTC (permalink / raw)
To: Ma Ke, piotr.wojtaszczyk, andrew+netdev, davem, edumazet, kuba,
pabeni, alexandre.belloni
Cc: linux-arm-kernel, netdev, linux-kernel, stable
In-Reply-To: <20260330081636.2887980-1-make24@iscas.ac.cn>
Hello Ma Ke,
On 3/30/26 11:16, Ma Ke wrote:
> lpc_mii_probe() calls of_phy_find_device() to obtain a phy_device
> pointer. of_phy_find_device() increments the refcount of the device.
> The current implementation does not decrement the refcount after using
> the pointer, which leads to a memory leak.
this is correct, there is an actual detected bug.
>
> Add phy_device_free() to balance the refcount.
But this does not sound right, you shoud use of_node_put(pldat->phy_node).
>
> Found by code review.
>
> Signed-off-by: Ma Ke <make24@iscas.ac.cn>
> Cc: stable@vger.kernel.org
> Fixes: 3503bf024b3e ("net: lpc_eth: parse phy nodes from device tree")
> ---
> drivers/net/ethernet/nxp/lpc_eth.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
> index 8b9a3e3bba30..8ce7c9bb6dd6 100644
> --- a/drivers/net/ethernet/nxp/lpc_eth.c
> +++ b/drivers/net/ethernet/nxp/lpc_eth.c
> @@ -751,7 +751,7 @@ static void lpc_handle_link_change(struct net_device *ndev)
> static int lpc_mii_probe(struct net_device *ndev)
> {
> struct netdata_local *pldat = netdev_priv(ndev);
> - struct phy_device *phydev;
> + struct phy_device *phydev, *phydev_tmp;
>
> /* Attach to the PHY */
> if (lpc_phy_interface_mode(&pldat->pdev->dev) == PHY_INTERFACE_MODE_MII)
> @@ -760,17 +760,18 @@ static int lpc_mii_probe(struct net_device *ndev)
> netdev_info(ndev, "using RMII interface\n");
>
> if (pldat->phy_node)
> - phydev = of_phy_find_device(pldat->phy_node);
> + phydev_tmp = of_phy_find_device(pldat->phy_node);
> else
> - phydev = phy_find_first(pldat->mii_bus);
> - if (!phydev) {
> + phydev_tmp = phy_find_first(pldat->mii_bus);
> + if (!phydev_tmp) {
I didn't get it, why the new phydev_tmp is needed above, please
restore the original code above.
> netdev_err(ndev, "no PHY found\n");
> return -ENODEV;
> }
>
> - phydev = phy_connect(ndev, phydev_name(phydev),
> + phydev = phy_connect(ndev, phydev_name(phydev_tmp),
> &lpc_handle_link_change,
> lpc_phy_interface_mode(&pldat->pdev->dev));
> + phy_device_free(phydev_tmp);
This is plainly wrong and has to be dropped or changed to
if (pldat->phy_node)
of_node_put(pldat->phy_node);
> if (IS_ERR(phydev)) {
> netdev_err(ndev, "Could not attach to PHY\n");
> return PTR_ERR(phydev);
Is it AI generated fix or what?.. The change looks bad, it introduces
more severe issues than it fixes.
If you think you cannot create a proper change, let me know.
--
Best wishes,
Vladimir
^ permalink raw reply
* [PATCH 0/4] KVM: arm64: nv: Implement nested stage-2 reverse map
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
Hi,
This series optimizes the shadow s2 mmu unmapping during MMU notifiers.
Motivation
==========
KVM registers MMU notifiers to unmap stage-2 mappings for the guest when
the backing memory's userspace VA to PA translation has changed, some
reasons include memory reclaim and and migration. In the non-NV case
this is straight forward, the registered function simply unmaps the VM's
IPA from the stage-2 page tables. However, in the NV case the nested
MMUs store nested IPA to PA mappings, and we have no clue which of these
nested mappings are backed by the same memory that the MMU notifiers are
unmapping. The consequence is that since we don't know which nested
mappings should be removed, we can only unmap every nested MMU in its
entirety within the guest to be safe. This kills performance when MMU
notifiers are called often, and we would like a better alternative than
unmapping all shadow stage-2s everytime.
Design
======
The basic idea is create a reverse map from the canonical IPA to the
nested IPA, so that when the MMU notifier informs us about the canonical
IPA range that must be unmapped, we can look up the reverse map to find
the nested IPA range affected and unmap it from the nested MMU. To
achieve fine grained unmapping, each nested MMU is equipped with its own
reverse map.
The maple tree is chosen to store the reverse map, mainly for its good
support for dealing with ranges. Two methods of storing the reverse map
are considered: either using the canonical IPA as the key for the tree,
or using the PA as the key for the tree, the value stored is the nested
IPA range for both. In this series the method using canonical IPA as the
key is implemented, which I believe is a better scheme. A comparison
between the two is presented in a later section.
It is possible for a nested context to have multiple nested IPA ranges
mapped to the same IPA. In these cases idealy our reverse map should
contain 1-to-many relations, so that we are able to find all nested IPA
ranges to unmap during MMU notifiers. However since this requires more
information than what a 64 bit maple tree value can store, we will be
forced to store the information in allocated data pointed to by the
maple tree value. This creates extra memory we have to manage, and
increases the maintenance effort from tracking 1-to-many mappings, for
example by keeping a linked list of nested IPA ranges.
Instead, we introduce what is called the "polluted" canonical IPA
ranges, which means for these canonical IPA ranges we have lost track of
what nested IPA ranges are mapped to this canonical IPA range. Polluted
canonical IPA ranges are created when at shadow stage-2 fault time, we
find that the canonical IPA range we are trying to insert to the reverse
map overlaps one or more pre-existing ranges, in this case the minimum
polluted spanning range is calculated and inserted to replace all
pre-existing ranges.
Example:
|||| means existing range, ---- means empty range
input: $$$$$$$$$$$$$$$$$$$$$$$$$$
tree: --||||-----|||||||---------||||||||||-----------
free overlaps:
--||||------------------------------------------
insert spanning polluted range:
--||||-----||||||||||||||||||||||||||-----------
^^^^^^^^polluted!^^^^^^^^^
Later when a request to unmap a canonical IPA range arises which affects
a polluted canonical IPA range, simply fall back to unmapping the entire
nested MMU.
MMU notifier optimization
=========================
Every nested MMU keeps its own reverse map, therefore we must check
every nested MMU when we unmap canonical IPA ranges in the MMU notifier,
which is not efficient. We can leverage the canonical stage-2 MMU's
unused maple tree to point to the nested MMUs that hold mappings
of each stored canonical IPA range. This is implemented in patch 2 with
more detail in the commit message.
TLBI handling
=============
When a guest hypervisor issues a TLBI for a specific IPA range, KVM
unmaps that range from all the effected shadow stage-2s. During this we
get the opportunity to remove the reverse map, and lower the probability
of creating polluted reverse map ranges at subsequent stage-2 faults.
However, the TLBI ranges are specified in nested IPA, so in order to
locate the affected ranges in the reverse map maple tree, which is a
mapping from canonical IPA to nested IPA, we can only iterate through
the entire tree and check each entry. This is implemented in patch 3.
In patch 4, we further improve this by introducing a direct map that
goes from nested IPA to canonical IPA, allowing us to quicky locate
which reverse mapping to remove when handed a nested IPA range during
TLBI handling.
Reverse map key, canonical IPA vs PA
====================================
This is a brief comparison of using either canonical IPA or PA as the
key to the reverse map, base on the 4 aspects of the implementation.
Reverse map creation
--------------------
Using both canonical IPA and PA requires almost identical operations.
Canonical IPA unmapping (MMU notifier)
--------------------------------------
For canonical IPA as the key, simply search the reverse map and
invalidate the retrieved nested IPA range.
For PA as the key, we must first translate the given canonical IPA range
into PA either via
a) walking the user space page table or..
b) calling kvm_gmem_get_pfn() if the memslot is a guest_memfd one
Further, kvm_gmem_get_pfn() forcefully allocates the physical page if
the queried canonical IPA is not faulted in. This of course is not
acceptable for our use case, so writing some guest_memfd code will be
required for this to work.
Canonical IPA unmapping optimization
------------------------------------
Using both canonical IPA and PA requires identical operation.
TLBI handling
-------------
For canonical IPA as the key, like said above we can either:
a) iterate the reverse map to find the entry to remove, or
b) create a direct map to find the canonical IPA range
For PA as the key, it is more straightforward, simply find the PA by
walking the shadow stage-2, then remove the PA range from the reverse
map. However this still requires a page table walk.
Summary
-------
I believe it is clear that using canonical IPA as the key saves us a lot
of trouble:
a) no page table walks are required
b) we go from dealing with 3 address spaces (PA, canonical IPA, nested
IPA) to 2 (canonical IPA, nested IPA)
c) the problem with guest_memfd is circumvented
Locking
=======
All maple trees are protected by kvm.mmu_lock, therefore no maple tree
locks are taken.
Testing
=======
The current plan to test is to enhance kselftest with NV capability, so
that we can instruct L1 and L2 to set up and access memory to populate
shadow page tables, userspace can then trigger MMU notifiers by e.g.
munmap, mremap, etc. During these operations userspace can read the
shadow page tables exposed in debugfs [1] to check whether the shadow
page tables are in an expected state or not.
Thanks!
[1]: https://lore.kernel.org/kvmarm/20260317182638.1592507-2-weilin.chang@arm.com
Wei-Lin Chang (4):
KVM: arm64: nv: Avoid full shadow s2 unmap
KVM: arm64: nv: Accelerate canonical IPA unmapping with canonical s2
mmu maple tree
KVM: arm64: nv: Remove reverse map entries during TLBI handling
KVM: arm64: nv: Create nested IPA direct map to speed up reverse map
removal
arch/arm64/include/asm/kvm_host.h | 7 +
arch/arm64/include/asm/kvm_nested.h | 5 +
arch/arm64/kvm/mmu.c | 32 ++-
arch/arm64/kvm/nested.c | 342 +++++++++++++++++++++++++++-
arch/arm64/kvm/sys_regs.c | 3 +
5 files changed, 382 insertions(+), 7 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/4] KVM: arm64: nv: Avoid full shadow s2 unmap
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-1-weilin.chang@arm.com>
Currently we are forced to fully unmap all shadow stage-2 for a VM when
unmapping a page from the canonical stage-2, for example during an MMU
notifier call. This is because we are not tracking what canonical IPA
are mapped in the shadow stage-2 page tables hence there is no way to
know what to unmap.
Create a per kvm_s2_mmu maple tree to track canonical IPA range ->
nested IPA range, so that it is possible to partially unmap shadow
stage-2 when a canonical IPA range is unmapped. The algorithm is simple
and conservative:
At each shadow stage-2 map, insert the nested IPA range into the maple
tree, with the canonical IPA range as the key. If the canonical IPA
range doesn't overlap with existing ranges in the tree, insert as is,
and a reverse mapping for this range is established. But if the
canonical IPA range overlaps with any existing ranges in the tree, erase
those existing ranges, and create a new range that spans all the
overlapping ranges including the input range. In the mean time, mark
this new spanning canonical IPA range as "polluted" indicating we lost
track of the nested IPA ranges that map to this canonical IPA range.
The maple tree's 64 bit entry is enough to store the nested IPA and
polluted status (stored as a bit called UNKNOWN_IPA), therefore besides
maple tree's internal operation, memory allocation is avoided.
Example:
|||| means existing range, ---- means empty range
input: $$$$$$$$$$$$$$$$$$$$$$$$$$
tree: --||||-----|||||||---------||||||||||-----------
free overlaps:
--||||------------------------------------------
insert spanning range:
--||||-----||||||||||||||||||||||||||-----------
^^^^^^^^polluted!^^^^^^^^^
With the reverse map created, when a canonical IPA range gets unmapped,
look into each s2 mmu's maple tree and look for canonical IPA ranges
affected, and base on their polluted status:
polluted -> fall back and fully invalidate the current shadow stage-2,
also clear the tree
not polluted -> unmap the nested IPA range, and remove the reverse map
entry
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 3 +
arch/arm64/include/asm/kvm_nested.h | 4 +
arch/arm64/kvm/mmu.c | 27 +++++--
arch/arm64/kvm/nested.c | 112 +++++++++++++++++++++++++++-
4 files changed, 140 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 8545811e2238..1d0db7f268cc 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -217,6 +217,9 @@ struct kvm_s2_mmu {
*/
bool nested_stage2_enabled;
+ /* canonical IPA to nested IPA range lookup, protected by kvm.mmu_lock */
+ struct maple_tree nested_revmap_mt;
+
#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
struct dentry *shadow_pt_debugfs_dentry;
#endif
diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
index 091544e6af44..4d09d567d7f9 100644
--- a/arch/arm64/include/asm/kvm_nested.h
+++ b/arch/arm64/include/asm/kvm_nested.h
@@ -76,6 +76,8 @@ extern void kvm_s2_mmu_iterate_by_vmid(struct kvm *kvm, u16 vmid,
const union tlbi_info *info,
void (*)(struct kvm_s2_mmu *,
const union tlbi_info *));
+extern int kvm_record_nested_revmap(gpa_t gpa, struct kvm_s2_mmu *mmu,
+ gpa_t fault_gpa, size_t map_size);
extern void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu);
extern void kvm_vcpu_put_hw_mmu(struct kvm_vcpu *vcpu);
@@ -164,6 +166,8 @@ extern int kvm_s2_handle_perm_fault(struct kvm_vcpu *vcpu,
struct kvm_s2_trans *trans);
extern int kvm_inject_s2_fault(struct kvm_vcpu *vcpu, u64 esr_el2);
extern void kvm_nested_s2_wp(struct kvm *kvm);
+extern void kvm_unmap_gfn_range_nested(struct kvm *kvm, gpa_t gpa, size_t size,
+ bool may_block);
extern void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block);
extern void kvm_nested_s2_flush(struct kvm *kvm);
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 17d64a1e11e5..6beb07d817c8 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1107,8 +1107,10 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
free_percpu(mmu->last_vcpu_ran);
}
- if (kvm_is_nested_s2_mmu(kvm, mmu))
+ if (kvm_is_nested_s2_mmu(kvm, mmu)) {
+ mtree_destroy(&mmu->nested_revmap_mt);
kvm_init_nested_s2_mmu(mmu);
+ }
write_unlock(&kvm->mmu_lock);
@@ -1625,6 +1627,13 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
goto out_unlock;
}
+ if (nested) {
+ ret = kvm_record_nested_revmap(gfn << PAGE_SHIFT, pgt->mmu,
+ fault_ipa, PAGE_SIZE);
+ if (ret)
+ goto out_unlock;
+ }
+
ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault_ipa, PAGE_SIZE,
__pfn_to_phys(pfn), prot,
memcache, flags);
@@ -1922,6 +1931,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
prot &= ~KVM_NV_GUEST_MAP_SZ;
ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault_ipa, prot, flags);
} else {
+ if (nested) {
+ ret = kvm_record_nested_revmap(gfn << PAGE_SHIFT, pgt->mmu,
+ fault_ipa, vma_pagesize);
+ if (ret)
+ goto out_unlock;
+ }
ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault_ipa, vma_pagesize,
__pfn_to_phys(pfn), prot,
memcache, flags);
@@ -2223,14 +2238,16 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
{
+ gpa_t gpa = range->start << PAGE_SHIFT;
+ size_t size = (range->end - range->start) << PAGE_SHIFT;
+ bool may_block = range->may_block;
+
if (!kvm->arch.mmu.pgt)
return false;
- __unmap_stage2_range(&kvm->arch.mmu, range->start << PAGE_SHIFT,
- (range->end - range->start) << PAGE_SHIFT,
- range->may_block);
+ __unmap_stage2_range(&kvm->arch.mmu, gpa, size, may_block);
+ kvm_unmap_gfn_range_nested(kvm, gpa, size, may_block);
- kvm_nested_s2_unmap(kvm, range->may_block);
return false;
}
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 883b6c1008fb..53392cc7dbae 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -7,6 +7,7 @@
#include <linux/bitfield.h>
#include <linux/kvm.h>
#include <linux/kvm_host.h>
+#include <linux/maple_tree.h>
#include <asm/fixmap.h>
#include <asm/kvm_arm.h>
@@ -43,6 +44,16 @@ struct vncr_tlb {
*/
#define S2_MMU_PER_VCPU 2
+/*
+ * Per shadow S2 reverse map (IPA -> nested IPA range) maple tree payload
+ * layout:
+ *
+ * bits 55-12: nested IPA bits 55-12
+ * bit 0: polluted, 1 for polluted, 0 for not
+ */
+#define NESTED_IPA_MASK GENMASK_ULL(55, 12)
+#define UNKNOWN_IPA BIT(0)
+
void kvm_init_nested(struct kvm *kvm)
{
kvm->arch.nested_mmus = NULL;
@@ -769,12 +780,54 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
return s2_mmu;
}
+int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
+ gpa_t fault_ipa, size_t map_size)
+{
+ struct maple_tree *mt = &mmu->nested_revmap_mt;
+ gpa_t start = ipa;
+ gpa_t end = ipa + map_size - 1;
+ u64 entry, new_entry = 0;
+ int r = 0;
+
+ lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
+
+ MA_STATE(mas, mt, start, end);
+ entry = (u64)mas_find_range(&mas, end);
+
+ if (entry) {
+ /* maybe just a perm update... */
+ if (!(entry & UNKNOWN_IPA) && mas.index == start &&
+ mas.last == end &&
+ fault_ipa == (entry & NESTED_IPA_MASK))
+ goto out;
+ /*
+ * Remove every overlapping range, then create a "polluted"
+ * range that spans all these ranges and store it.
+ */
+ while (entry && mas.index <= end) {
+ start = min(mas.index, start);
+ end = max(mas.last, end);
+ mas_erase(&mas);
+ entry = (u64)mas_find_range(&mas, end);
+ }
+ new_entry |= UNKNOWN_IPA;
+ } else {
+ new_entry |= fault_ipa;
+ }
+
+ mas_set_range(&mas, start, end);
+ r = mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
+out:
+ return r;
+}
+
void kvm_init_nested_s2_mmu(struct kvm_s2_mmu *mmu)
{
/* CnP being set denotes an invalid entry */
mmu->tlb_vttbr = VTTBR_CNP_BIT;
mmu->nested_stage2_enabled = false;
atomic_set(&mmu->refcnt, 0);
+ mt_init(&mmu->nested_revmap_mt);
}
void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu)
@@ -1150,6 +1203,60 @@ void kvm_nested_s2_wp(struct kvm *kvm)
kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
}
+static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
+ size_t unmap_size, bool may_block)
+{
+ struct maple_tree *mt = &mmu->nested_revmap_mt;
+ gpa_t start = gpa;
+ gpa_t end = gpa + unmap_size - 1;
+ u64 entry;
+ size_t entry_size;
+
+ MA_STATE(mas, mt, gpa, end);
+ entry = (u64)mas_find_range(&mas, end);
+
+ while (entry && mas.index <= end) {
+ start = mas.last + 1;
+ entry_size = mas.last - mas.index + 1;
+ /*
+ * Give up and invalidate this s2 mmu if the unmap range
+ * touches any polluted range.
+ */
+ if (entry & UNKNOWN_IPA) {
+ mtree_destroy(mt);
+ kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu),
+ may_block);
+ return;
+ }
+ mas_erase(&mas);
+ kvm_stage2_unmap_range(mmu, entry & NESTED_IPA_MASK, entry_size,
+ may_block);
+ /*
+ * Other maple tree operations during preemption could render
+ * this ma_state invalid, so reset it.
+ */
+ mas_set_range(&mas, start, end);
+ entry = (u64)mas_find_range(&mas, end);
+ }
+}
+
+void kvm_unmap_gfn_range_nested(struct kvm *kvm, gpa_t gpa, size_t size,
+ bool may_block)
+{
+ int i;
+
+ if (!kvm->arch.nested_mmus_size)
+ return;
+
+ /* TODO: accelerate this using mt of canonical s2 mmu */
+ for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
+ struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+
+ if (kvm_s2_mmu_valid(mmu))
+ unmap_mmu_ipa_range(mmu, gpa, size, may_block);
+ }
+}
+
void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
{
int i;
@@ -1162,8 +1269,10 @@ void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
- if (kvm_s2_mmu_valid(mmu))
+ if (kvm_s2_mmu_valid(mmu)) {
+ mtree_destroy(&mmu->nested_revmap_mt);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
+ }
}
kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
@@ -1848,6 +1957,7 @@ void check_nested_vcpu_requests(struct kvm_vcpu *vcpu)
write_lock(&vcpu->kvm->mmu_lock);
if (mmu->pending_unmap) {
+ mtree_destroy(&mmu->nested_revmap_mt);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), true);
mmu->pending_unmap = false;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] KVM: arm64: nv: Accelerate canonical IPA unmapping with canonical s2 mmu maple tree
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-1-weilin.chang@arm.com>
Checking every nested mmu during canonical IPA unmapping is slow,
especially when there are many valid nested mmus. We can leverage the
unused maple tree in the canonical kvm_s2_mmu to accelerate this
process.
At stage-2 fault time, other than recording the reverse map, also add an
entry in canonical s2 mmu's maple tree, with the canonical IPA range as
the key, and the "nested s2 mmu this fault is happending to" encoded in
the entry.
With the new maple tree for acceleration's information, at canonical
IPA unmap time we can look into the tree to retrieve the nested mmus
affected by this unmap much quicker.
In terms of encoding the nested mmus in the entry, there are 62 bits
available for each entry (bits 1 and 0 are reserved by the maple tree).
Each bit represents a number of nested mmus base on the total number of
nested mmus, this value grows in power of 2, so for example:
total nested mmus: 1-62 -> each bit represents: 1 nested mmu
63-124 -> 2 nested mmus
125-248 -> 4 nested mmus
... ...
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/mmu.c | 5 +-
arch/arm64/kvm/nested.c | 166 ++++++++++++++++++++++++++++--
3 files changed, 163 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 1d0db7f268cc..06f83bb7ff1d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -321,6 +321,7 @@ struct kvm_arch {
struct kvm_s2_mmu *nested_mmus;
size_t nested_mmus_size;
int nested_mmus_next;
+ int mmus_per_bit_power;
/* Interrupt controller */
struct vgic_dist vgic;
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 6beb07d817c8..2b413d3dc790 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1009,6 +1009,8 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
if (kvm_is_nested_s2_mmu(kvm, mmu))
kvm_init_nested_s2_mmu(mmu);
+ mt_init(&mmu->nested_revmap_mt);
+
return 0;
out_destroy_pgtable:
@@ -1107,8 +1109,9 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
free_percpu(mmu->last_vcpu_ran);
}
+ mtree_destroy(&mmu->nested_revmap_mt);
+
if (kvm_is_nested_s2_mmu(kvm, mmu)) {
- mtree_destroy(&mmu->nested_revmap_mt);
kvm_init_nested_s2_mmu(mmu);
}
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 53392cc7dbae..c7d00cb40ba5 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -80,7 +80,7 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
{
struct kvm *kvm = vcpu->kvm;
struct kvm_s2_mmu *tmp;
- int num_mmus, ret = 0;
+ int num_mmus, power = 0, ret = 0;
if (test_bit(KVM_ARM_VCPU_HAS_EL2_E2H0, kvm->arch.vcpu_features) &&
!cpus_have_final_cap(ARM64_HAS_HCR_NV1))
@@ -131,6 +131,25 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
kvm->arch.nested_mmus_size = num_mmus;
+ /*
+ * Calculate how many s2 mmus are represented by each bit in the
+ * acceleration maple tree entries.
+ *
+ * power == 0 -> 1 s2 mmu
+ * power == 1 -> 2 s2 mmus
+ * power == 2 -> 4 s2 mmus
+ * power == 3 -> 8 s2 mmus
+ * etc.
+ *
+ * We use only the top 62 bits in the canonical s2 mmu maple tree
+ * entries, bits 0 and 1 are not used, since maple trees reserve values
+ * with bit patterns ending in 10 that are also smaller that 4096.
+ */
+ while (62 * (1 << power) < kvm->arch.nested_mmus_size)
+ power++;
+
+ kvm->arch.mmus_per_bit_power = power;
+
return 0;
}
@@ -780,6 +799,119 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
return s2_mmu;
}
+static int s2_mmu_to_accel_bit(struct kvm_s2_mmu *mmu)
+{
+ BUG_ON(&mmu->arch->mmu == mmu);
+
+ int index = mmu - mmu->arch->nested_mmus;
+ int power = mmu->arch->mmus_per_bit_power;
+
+ return (index >> power) + 2;
+}
+
+/* this returns the first s2 mmu from the span */
+static struct kvm_s2_mmu *accel_bit_to_s2_mmu(struct kvm *kvm, int bit)
+{
+ int power = kvm->arch.mmus_per_bit_power;
+ int index = (bit - 2) << power;
+
+ BUG_ON(index >= kvm->arch.nested_mmus_size);
+
+ return &kvm->arch.nested_mmus[index];
+}
+
+static void accel_clear_mmu_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
+ size_t size)
+{
+ struct maple_tree *mt = &mmu->arch->mmu.nested_revmap_mt;
+ int bit = s2_mmu_to_accel_bit(mmu);
+ void *entry, *new_entry;
+ gpa_t start = gpa;
+ gpa_t end = gpa + size - 1;
+
+ if (mmu->arch->mmus_per_bit_power > 0) {
+ /* sadly nothing we can do here... */
+ return;
+ }
+
+ MA_STATE(mas, mt, start, end);
+
+ entry = mas_find_range(&mas, end);
+ BUG_ON(!entry);
+
+ /*
+ * 1. Ranges smaller than the queried range should not exist, because
+ * for the same mmu, the same ranges are added in both the accel mt
+ * and the mmu's mt at fault time.
+ *
+ * 2. Ranges larger than the queried range could exist, since
+ * another mmu could have a range mapped on top.
+ * However in this case we don't know whether there are other
+ * smaller ranges in this larger range that belongs to this same
+ * mmu, so we can't just remove the bit.
+ */
+ if (mas.index == start && mas.last == end) {
+ new_entry = (void *)((unsigned long)entry & ~BIT(bit));
+ /*
+ * This naturally clears the range from the mt if
+ * new_entry == 0.
+ */
+ mas_store_gfp(&mas, new_entry, GFP_KERNEL_ACCOUNT);
+ }
+}
+
+static void accel_clear_mmu(struct kvm_s2_mmu *mmu)
+{
+ struct maple_tree *mt = &mmu->arch->mmu.nested_revmap_mt;
+ int bit = s2_mmu_to_accel_bit(mmu);
+ void *entry, *new_entry;
+
+ if (mmu->arch->mmus_per_bit_power > 0) {
+ /* sadly nothing we can do here... */
+ return;
+ }
+
+ MA_STATE(mas, mt, 0, ULONG_MAX);
+
+ mas_for_each(&mas, entry, ULONG_MAX) {
+ new_entry = (void *)((unsigned long)entry & ~BIT(bit));
+ /*
+ * This naturally clears the range from the mt if
+ * new_entry == 0.
+ */
+ mas_store_gfp(&mas, new_entry, GFP_KERNEL_ACCOUNT);
+ }
+}
+
+static int record_accel(struct kvm_s2_mmu *mmu, gpa_t gpa,
+ size_t map_size)
+{
+ struct maple_tree *mt = &mmu->arch->mmu.nested_revmap_mt;
+ gpa_t start = gpa;
+ gpa_t end = gpa + map_size - 1;
+ u64 entry, new_entry = 0;
+
+ MA_STATE(mas, mt, start, end);
+ entry = (u64)mas_find_range(&mas, end);
+
+ /*
+ * OR every overlapping range's entry, then create a
+ * range that spans all these ranges and store it.
+ */
+ while (entry && mas.index <= end) {
+ start = min(mas.index, start);
+ end = max(mas.last, end);
+ new_entry |= entry;
+ mas_erase(&mas);
+ entry = (u64)mas_find_range(&mas, end);
+ }
+
+ new_entry |= BIT(s2_mmu_to_accel_bit(mmu));
+ mas_set_range(&mas, start, end);
+
+ return mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
+}
+
int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
gpa_t fault_ipa, size_t map_size)
{
@@ -792,6 +924,11 @@ int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
MA_STATE(mas, mt, start, end);
+
+ r = record_accel(mmu, ipa, map_size);
+ if (r)
+ goto out;
+
entry = (u64)mas_find_range(&mas, end);
if (entry) {
@@ -827,7 +964,6 @@ void kvm_init_nested_s2_mmu(struct kvm_s2_mmu *mmu)
mmu->tlb_vttbr = VTTBR_CNP_BIT;
mmu->nested_stage2_enabled = false;
atomic_set(&mmu->refcnt, 0);
- mt_init(&mmu->nested_revmap_mt);
}
void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu)
@@ -1224,11 +1360,13 @@ static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
*/
if (entry & UNKNOWN_IPA) {
mtree_destroy(mt);
+ accel_clear_mmu(mmu);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu),
may_block);
return;
}
mas_erase(&mas);
+ accel_clear_mmu_range(mmu, mas.index, entry_size);
kvm_stage2_unmap_range(mmu, entry & NESTED_IPA_MASK, entry_size,
may_block);
/*
@@ -1243,17 +1381,27 @@ static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
void kvm_unmap_gfn_range_nested(struct kvm *kvm, gpa_t gpa, size_t size,
bool may_block)
{
- int i;
+ struct maple_tree *mt = &kvm->arch.mmu.nested_revmap_mt;
+ gpa_t start = gpa;
+ gpa_t end = gpa + size - 1;
+ u64 entry;
+ int bit, i = 0;
+ int power = kvm->arch.mmus_per_bit_power;
+ struct kvm_s2_mmu *mmu;
+ MA_STATE(mas, mt, start, end);
if (!kvm->arch.nested_mmus_size)
return;
- /* TODO: accelerate this using mt of canonical s2 mmu */
- for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
- struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+ entry = (u64)mas_find_range(&mas, end);
- if (kvm_s2_mmu_valid(mmu))
- unmap_mmu_ipa_range(mmu, gpa, size, may_block);
+ while (entry && mas.index <= end) {
+ for_each_set_bit(bit, (unsigned long *)&entry, 64) {
+ mmu = accel_bit_to_s2_mmu(kvm, bit);
+ for (i = 0; i < (1 << power); i++)
+ unmap_mmu_ipa_range(mmu + i, gpa, size, may_block);
+ }
+ entry = (u64)mas_find_range(&mas, end);
}
}
@@ -1274,6 +1422,7 @@ void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
}
}
+ mtree_destroy(&kvm->arch.mmu.nested_revmap_mt);
kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
}
@@ -1958,6 +2107,7 @@ void check_nested_vcpu_requests(struct kvm_vcpu *vcpu)
write_lock(&vcpu->kvm->mmu_lock);
if (mmu->pending_unmap) {
mtree_destroy(&mmu->nested_revmap_mt);
+ accel_clear_mmu(mmu);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), true);
mmu->pending_unmap = false;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] KVM: arm64: nv: Remove reverse map entries during TLBI handling
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-1-weilin.chang@arm.com>
When a guest hypervisor issues a TLBI for a specific IPA range, KVM
unmaps that range from all the effected shadow stage-2s. During this we
get the opportunity to remove the reverse map, and lower the probability
of creating polluted reverse map ranges at subsequent stage-2 faults.
However, the TLBI ranges are specified in nested IPA, so in order to
locate the affected ranges in the reverse map maple tree, which is a
mapping from canonical IPA to nested IPA, we can only iterate through
the entire tree and check each entry.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/include/asm/kvm_nested.h | 1 +
arch/arm64/kvm/nested.c | 29 +++++++++++++++++++++++++++++
arch/arm64/kvm/sys_regs.c | 3 +++
3 files changed, 33 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
index 4d09d567d7f9..376619cdc9d5 100644
--- a/arch/arm64/include/asm/kvm_nested.h
+++ b/arch/arm64/include/asm/kvm_nested.h
@@ -76,6 +76,7 @@ extern void kvm_s2_mmu_iterate_by_vmid(struct kvm *kvm, u16 vmid,
const union tlbi_info *info,
void (*)(struct kvm_s2_mmu *,
const union tlbi_info *));
+extern void kvm_remove_nested_revmap(struct kvm_s2_mmu *mmu, u64 addr, u64 size);
extern int kvm_record_nested_revmap(gpa_t gpa, struct kvm_s2_mmu *mmu,
gpa_t fault_gpa, size_t map_size);
extern void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index c7d00cb40ba5..125fa21ca2e7 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -912,6 +912,35 @@ static int record_accel(struct kvm_s2_mmu *mmu, gpa_t gpa,
return mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
}
+void kvm_remove_nested_revmap(struct kvm_s2_mmu *mmu, u64 addr, u64 size)
+{
+ /*
+ * Iterate through the mt of this mmu, remove all unpolluted canonical
+ * ipa ranges that maps to ranges that are strictly within
+ * [addr, addr + size).
+ */
+ struct maple_tree *mt = &mmu->nested_revmap_mt;
+ void *entry;
+ u64 nested_ipa, nested_ipa_end, addr_end = addr + size;
+ size_t revmap_size;
+
+ MA_STATE(mas, mt, 0, ULONG_MAX);
+
+ mas_for_each(&mas, entry, ULONG_MAX) {
+ if ((u64)entry & UNKNOWN_IPA)
+ continue;
+
+ revmap_size = mas.last - mas.index + 1;
+ nested_ipa = (u64)entry & NESTED_IPA_MASK;
+ nested_ipa_end = nested_ipa + revmap_size;
+
+ if (nested_ipa >= addr && nested_ipa_end <= addr_end) {
+ accel_clear_mmu_range(mmu, mas.index, revmap_size);
+ mas_erase(&mas);
+ }
+ }
+}
+
int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
gpa_t fault_ipa, size_t map_size)
{
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e1001544d4f4..c7af0eac9ee4 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -4006,6 +4006,7 @@ union tlbi_info {
static void s2_mmu_unmap_range(struct kvm_s2_mmu *mmu,
const union tlbi_info *info)
{
+ kvm_remove_nested_revmap(mmu, info->range.start, info->range.size);
/*
* The unmap operation is allowed to drop the MMU lock and block, which
* means that @mmu could be used for a different context than the one
@@ -4104,6 +4105,8 @@ static void s2_mmu_unmap_ipa(struct kvm_s2_mmu *mmu,
max_size = compute_tlb_inval_range(mmu, info->ipa.addr);
base_addr &= ~(max_size - 1);
+ kvm_remove_nested_revmap(mmu, base_addr, max_size);
+
/*
* See comment in s2_mmu_unmap_range() for why this is allowed to
* reschedule.
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] KVM: arm64: nv: Create nested IPA direct map to speed up reverse map removal
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-1-weilin.chang@arm.com>
Iterating through the whole reverse map to find which entries to remove
when handling guest hypervisor TLBIs is not efficient. Create a direct
map that goes from nested IPA to canonical IPA so that the canonical
IPA range affected by the TLBI can be quickly determined, then remove
the entries in the reverse map accordingly.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 3 +
arch/arm64/kvm/mmu.c | 2 +
arch/arm64/kvm/nested.c | 131 ++++++++++++++++++++----------
3 files changed, 95 insertions(+), 41 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 06f83bb7ff1d..6b0858805530 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -220,6 +220,9 @@ struct kvm_s2_mmu {
/* canonical IPA to nested IPA range lookup, protected by kvm.mmu_lock */
struct maple_tree nested_revmap_mt;
+ /* nested IPA to canonical IPA range lookup, protected by kvm.mmu_lock */
+ struct maple_tree nested_direct_mt;
+
#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
struct dentry *shadow_pt_debugfs_dentry;
#endif
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 2b413d3dc790..9f27a9669ec9 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1010,6 +1010,7 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
kvm_init_nested_s2_mmu(mmu);
mt_init(&mmu->nested_revmap_mt);
+ mt_init(&mmu->nested_direct_mt);
return 0;
@@ -1112,6 +1113,7 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
mtree_destroy(&mmu->nested_revmap_mt);
if (kvm_is_nested_s2_mmu(kvm, mmu)) {
+ mtree_destroy(&mmu->nested_direct_mt);
kvm_init_nested_s2_mmu(mmu);
}
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 125fa21ca2e7..4c96130abf82 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -45,13 +45,12 @@ struct vncr_tlb {
#define S2_MMU_PER_VCPU 2
/*
- * Per shadow S2 reverse map (IPA -> nested IPA range) maple tree payload
- * layout:
+ * Per shadow S2 reverse & direct map maple tree payload layout:
*
- * bits 55-12: nested IPA bits 55-12
- * bit 0: polluted, 1 for polluted, 0 for not
+ * bits 55-12: {nested, canonical} IPA bits 55-12
+ * bit 0: polluted, 1 for polluted, 0 for not, only used in reverse map
*/
-#define NESTED_IPA_MASK GENMASK_ULL(55, 12)
+#define ADDR_MASK GENMASK_ULL(55, 12)
#define UNKNOWN_IPA BIT(0)
void kvm_init_nested(struct kvm *kvm)
@@ -915,74 +914,118 @@ static int record_accel(struct kvm_s2_mmu *mmu, gpa_t gpa,
void kvm_remove_nested_revmap(struct kvm_s2_mmu *mmu, u64 addr, u64 size)
{
/*
- * Iterate through the mt of this mmu, remove all unpolluted canonical
- * ipa ranges that maps to ranges that are strictly within
- * [addr, addr + size).
+ * For all ranges in direct_mt that are completely covered by the range
+ * we are TLBIing [addr, addr + size), we remove the reverse map AND
+ * its corresponding direct map together, when these conditions are
+ * met:
+ *
+ * 1. The TLBI range completely covers the stored nested IPA range.
+ * 2. The reverse map is not polluted. This ensures the reverse map
+ * and the direct map are 1:1.
*/
- struct maple_tree *mt = &mmu->nested_revmap_mt;
- void *entry;
- u64 nested_ipa, nested_ipa_end, addr_end = addr + size;
- size_t revmap_size;
+ struct maple_tree *direct_mt = &mmu->nested_direct_mt;
+ struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
+ gpa_t nested_ipa_start = addr;
+ gpa_t nested_ipa_end = addr + size - 1;
+ u64 entry_ipa, entry_nested_ipa;
+ u64 ipa, ipa_end;
- MA_STATE(mas, mt, 0, ULONG_MAX);
+ MA_STATE(mas_nested_ipa, direct_mt, nested_ipa_start, nested_ipa_end);
+ entry_ipa = (u64)mas_find_range(&mas_nested_ipa, nested_ipa_end);
- mas_for_each(&mas, entry, ULONG_MAX) {
- if ((u64)entry & UNKNOWN_IPA)
- continue;
+ while (entry_ipa && mas_nested_ipa.index <= nested_ipa_end) {
+ ipa = entry_ipa & ADDR_MASK;
+ ipa_end = ipa + mas_nested_ipa.last - mas_nested_ipa.index;
- revmap_size = mas.last - mas.index + 1;
- nested_ipa = (u64)entry & NESTED_IPA_MASK;
- nested_ipa_end = nested_ipa + revmap_size;
+ /* Use ipa range to find the corresponding entry in revmap. */
+ MA_STATE(mas_ipa, revmap_mt, ipa, ipa_end);
+ entry_nested_ipa = (u64)mas_find_range(&mas_ipa, ipa_end);
- if (nested_ipa >= addr && nested_ipa_end <= addr_end) {
- accel_clear_mmu_range(mmu, mas.index, revmap_size);
- mas_erase(&mas);
+ /*
+ * Reverse and direct map are created together at s2 faults,
+ * thus every direct map range should also have a corresponding
+ * reverse map range, however that can be polluted.
+ */
+ BUG_ON(!entry_nested_ipa);
+
+ /* The two conditions outlined above. */
+ if (!(entry_nested_ipa & UNKNOWN_IPA) &&
+ mas_nested_ipa.index >= addr &&
+ mas_nested_ipa.last <= nested_ipa_end) {
+ /*
+ * If the reverse map isn't polluted, the direct and
+ * reverse map are expected to be 1:1, thus they must
+ * have the same size.
+ */
+ BUG_ON(mas_ipa.last - mas_ipa.index !=
+ mas_nested_ipa.last - mas_nested_ipa.index);
+
+ accel_clear_mmu_range(mmu, mas_ipa.index,
+ mas_ipa.last - mas_ipa.index + 1);
+ mas_erase(&mas_ipa);
+ mas_erase(&mas_nested_ipa);
}
+ entry_ipa = (u64)mas_find_range(&mas_nested_ipa, nested_ipa_end);
}
}
int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
gpa_t fault_ipa, size_t map_size)
{
- struct maple_tree *mt = &mmu->nested_revmap_mt;
- gpa_t start = ipa;
- gpa_t end = ipa + map_size - 1;
+ struct maple_tree *direct_mt = &mmu->nested_direct_mt;
+ struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
+ gpa_t ipa_start = ipa;
+ gpa_t ipa_end = ipa + map_size - 1;
+ gpa_t fault_ipa_end = fault_ipa + map_size - 1;
u64 entry, new_entry = 0;
int r = 0;
lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
- MA_STATE(mas, mt, start, end);
+ MA_STATE(mas_ipa, revmap_mt, ipa_start, ipa_end);
+ MA_STATE(mas_nested_ipa, direct_mt, fault_ipa, fault_ipa_end);
r = record_accel(mmu, ipa, map_size);
if (r)
goto out;
- entry = (u64)mas_find_range(&mas, end);
+ r = mas_store_gfp(&mas_nested_ipa, (void *)ipa, GFP_KERNEL_ACCOUNT);
+ /*
+ * In the case of direct map store failure, don't clean up
+ * record_accel()'s successfully installed accel mt entry. Keeping
+ * it is fine as it will just cause us to check a few more s2 mmus
+ * in the mmu notifier.
+ */
+ if (r)
+ goto out;
+
+ entry = (u64)mas_find_range(&mas_ipa, ipa_end);
if (entry) {
/* maybe just a perm update... */
- if (!(entry & UNKNOWN_IPA) && mas.index == start &&
- mas.last == end &&
- fault_ipa == (entry & NESTED_IPA_MASK))
+ if (!(entry & UNKNOWN_IPA) && mas_ipa.index == ipa_start &&
+ mas_ipa.last == ipa_end &&
+ fault_ipa == (entry & ADDR_MASK))
goto out;
/*
* Remove every overlapping range, then create a "polluted"
* range that spans all these ranges and store it.
*/
- while (entry && mas.index <= end) {
- start = min(mas.index, start);
- end = max(mas.last, end);
- mas_erase(&mas);
- entry = (u64)mas_find_range(&mas, end);
+ while (entry && mas_ipa.index <= ipa_end) {
+ ipa_start = min(mas_ipa.index, ipa_start);
+ ipa_end = max(mas_ipa.last, ipa_end);
+ mas_erase(&mas_ipa);
+ entry = (u64)mas_find_range(&mas_ipa, ipa_end);
}
new_entry |= UNKNOWN_IPA;
} else {
new_entry |= fault_ipa;
}
- mas_set_range(&mas, start, end);
- r = mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
+ mas_set_range(&mas_ipa, ipa_start, ipa_end);
+ r = mas_store_gfp(&mas_ipa, (void *)new_entry, GFP_KERNEL_ACCOUNT);
+ if (r)
+ mas_erase(&mas_nested_ipa);
out:
return r;
}
@@ -1371,13 +1414,14 @@ void kvm_nested_s2_wp(struct kvm *kvm)
static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
size_t unmap_size, bool may_block)
{
- struct maple_tree *mt = &mmu->nested_revmap_mt;
+ struct maple_tree *direct_mt = &mmu->nested_direct_mt;
+ struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
gpa_t start = gpa;
gpa_t end = gpa + unmap_size - 1;
u64 entry;
size_t entry_size;
- MA_STATE(mas, mt, gpa, end);
+ MA_STATE(mas, revmap_mt, gpa, end);
entry = (u64)mas_find_range(&mas, end);
while (entry && mas.index <= end) {
@@ -1388,15 +1432,18 @@ static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
* touches any polluted range.
*/
if (entry & UNKNOWN_IPA) {
- mtree_destroy(mt);
+ mtree_destroy(direct_mt);
+ mtree_destroy(revmap_mt);
accel_clear_mmu(mmu);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu),
may_block);
return;
}
+ /* not polluted, direct map and reverse map must be 1:1 */
+ mtree_erase(direct_mt, entry & ADDR_MASK);
mas_erase(&mas);
accel_clear_mmu_range(mmu, mas.index, entry_size);
- kvm_stage2_unmap_range(mmu, entry & NESTED_IPA_MASK, entry_size,
+ kvm_stage2_unmap_range(mmu, entry & ADDR_MASK, entry_size,
may_block);
/*
* Other maple tree operations during preemption could render
@@ -1447,6 +1494,7 @@ void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
if (kvm_s2_mmu_valid(mmu)) {
+ mtree_destroy(&mmu->nested_direct_mt);
mtree_destroy(&mmu->nested_revmap_mt);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
}
@@ -2135,6 +2183,7 @@ void check_nested_vcpu_requests(struct kvm_vcpu *vcpu)
write_lock(&vcpu->kvm->mmu_lock);
if (mmu->pending_unmap) {
+ mtree_destroy(&mmu->nested_direct_mt);
mtree_destroy(&mmu->nested_revmap_mt);
accel_clear_mmu(mmu);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), true);
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] crypto: atmel-ecc - add support for atecc608b
From: Thorsten Blum @ 2026-03-30 10:08 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Tested on hardware with an ATECC608B at 0x60. The device binds
successfully, passes the driver's sanity check, and registers the
ecdh-nist-p256 KPP algorithm.
The hardware ECDH path was also exercised using a minimal KPP test
module, covering private key generation, public key derivation, and
shared secret computation.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index b6a77c8d439c..5793e0c44113 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -371,6 +371,8 @@ static void atmel_ecc_remove(struct i2c_client *client)
static const struct of_device_id atmel_ecc_dt_ids[] = {
{
.compatible = "atmel,atecc508a",
+ }, {
+ .compatible = "atmel,atecc608b",
}, {
/* sentinel */
}
@@ -380,6 +382,7 @@ MODULE_DEVICE_TABLE(of, atmel_ecc_dt_ids);
static const struct i2c_device_id atmel_ecc_id[] = {
{ "atecc508a" },
+ { "atecc608b" },
{ }
};
MODULE_DEVICE_TABLE(i2c, atmel_ecc_id);
^ permalink raw reply related
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 10:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <1fbf5c54-8793-4585-be33-ded77019adb2@kernel.org>
On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 23/03/2026 12:13, Ulf Hansson wrote:
> > Hi Krzysztof,
> >
> > On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >>
> >> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
> >>> This series adds support for the power domains on Google GS101.
> >>>
> >>> There are a few differences compared to SoCs already supported by this
> >>> driver:
> >>> * register access does not work via plain ioremap() / readl() /
> >>> writel().
> >>> Instead, the regmap created by the PMU driver must be used (which
> >>> uses Arm SMCC calls under the hood).
> >>> * DTZPC: a call needs to be made before and after power domain off/on,
> >>> to inform the EL3 firmware of the request.
> >>> * power domains can and are fed by a regulator rail and therefore
> >>> regulator control needed be implemented.
> >>>
> >>> [...]
> >>
> >> Applied, thanks!
> >>
> >> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
> >> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
> >> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
> >> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
> >> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
> >> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
> >>
> >> Best regards,
> >
> > Usually I pick up the power-domain related changes for the DT bindings
> > and host them via an immutable branch called "dt". If needed, SOC
> > maintainers can pull it to apply/test the corresponding DTS changes.
> >
> > That said, I am open to whatever you think is best here. Perhaps it's
> > easier if you can drop the DT patches and provide your acks instead or
> > if you can share them via an immutable branch for me to pull?
>
>
> I did not pick up any pmdomain binding patches. I picked up only soc and
> according to cover letter there are no dependencies between anything here.
As I understand it, they are all related and some even depend on each
other. I think keeping all four DT patches together makes sense.
Although, as I said, if you think it's best to funnel them through
your tree, please do and then share them via an immutable branch, so I
can apply the pmdomain driver changes.
Kind regards
Uffe
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 10:17 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFrK3NLwaii-9FEmyaTzUAuVkMkLL3rWBQwQvT-M+PzEHA@mail.gmail.com>
On 30/03/2026 12:13, Ulf Hansson wrote:
> On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 23/03/2026 12:13, Ulf Hansson wrote:
>>> Hi Krzysztof,
>>>
>>> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>
>>>>
>>>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
>>>>> This series adds support for the power domains on Google GS101.
>>>>>
>>>>> There are a few differences compared to SoCs already supported by this
>>>>> driver:
>>>>> * register access does not work via plain ioremap() / readl() /
>>>>> writel().
>>>>> Instead, the regmap created by the PMU driver must be used (which
>>>>> uses Arm SMCC calls under the hood).
>>>>> * DTZPC: a call needs to be made before and after power domain off/on,
>>>>> to inform the EL3 firmware of the request.
>>>>> * power domains can and are fed by a regulator rail and therefore
>>>>> regulator control needed be implemented.
>>>>>
>>>>> [...]
>>>>
>>>> Applied, thanks!
>>>>
>>>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
>>>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
>>>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
>>>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
>>>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
>>>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
>>>>
>>>> Best regards,
>>>
>>> Usually I pick up the power-domain related changes for the DT bindings
>>> and host them via an immutable branch called "dt". If needed, SOC
>>> maintainers can pull it to apply/test the corresponding DTS changes.
>>>
>>> That said, I am open to whatever you think is best here. Perhaps it's
>>> easier if you can drop the DT patches and provide your acks instead or
>>> if you can share them via an immutable branch for me to pull?
>>
>>
>> I did not pick up any pmdomain binding patches. I picked up only soc and
>> according to cover letter there are no dependencies between anything here.
>
> As I understand it, they are all related and some even depend on each
I raised exactly that questions but no answers.
> other. I think keeping all four DT patches together makes sense.
Why? What is the dependency?
>
> Although, as I said, if you think it's best to funnel them through
> your tree, please do and then share them via an immutable branch, so I
> can apply the pmdomain driver changes.
soc must go via my tree, but there is no reason to take the pmdomain
binding patch. So I did not take.
But anyway, I just noticed that I dropped everything: this introduces
new warnings which were nowhere addressed or explained. So regardless
how this should go, please do not apply anything - it's broken and
author is silent.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
From: Ronald Claveau @ 2026-03-30 10:18 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ulf Hansson, Johannes Berg, van Spriel
In-Reply-To: <416d42a6-8d99-421c-91aa-e705f23576e2@linaro.org>
On 3/30/26 9:55 AM, Neil Armstrong wrote:
> On 3/26/26 10:59, Ronald Claveau wrote:
>> Add voltage regulator nodes describing the VIM4 power tree,
>> required by peripheral nodes such as the SD card controller.
>>
>> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 ++++++++++++
>> ++++++++++
>> 1 file changed, 90 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-
>> vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
>> index fffdab96b12eb..2450084d37642 100644
>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
>> @@ -6,6 +6,8 @@
>> /dts-v1/;
>> #include "amlogic-t7.dtsi"
>> +#include <dt-bindings/gpio/amlogic,t7-periphs-pinctrl.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> / {
>> model = "Khadas vim4";
>> @@ -45,6 +47,94 @@ xtal: xtal-clk {
>> #clock-cells = <0>;
>> };
>> + dc_in: regulator-dc-in {
>> + compatible = "regulator-fixed";
>> + regulator-name = "DC_IN";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + regulator-always-on;
>> + };
>> +
>> + sd_3v3: regulator-sdcard-3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "SD_3V3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + vin-supply = <&vddao_3v3>;
>> + gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
>> + regulator-boot-on;
>
>> + enable-active-low;
>
> This properly is invalid, please send follow up patch removing this,
>
> Thanks,
> Neil
>
> <snip>
Sure. I am on it.
Thanks,
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For i.MX7D/i.MX8M
From: Manivannan Sadhasivam @ 2026-03-30 10:18 UTC (permalink / raw)
To: Hongxing Zhu
Cc: Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Qiang Yu
In-Reply-To: <AS8PR04MB8833AE3B8D106CE446EF89E58C52A@AS8PR04MB8833.eurprd04.prod.outlook.com>
On Mon, Mar 30, 2026 at 09:02:57AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Manivannan Sadhasivam <mani@kernel.org>
> > Sent: 2026年3月30日 15:23
> > To: Hongxing Zhu <hongxing.zhu@nxp.com>
> > Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de; lpieralisi@kernel.org;
> > kwilczynski@kernel.org; robh@kernel.org; bhelgaas@google.com;
> > s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com;
> > linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > imx@lists.linux.dev; linux-kernel@vger.kernel.org; stable@vger.kernel.org;
> > Qiang Yu <qiang.yu@oss.qualcomm.com>
> > Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> > i.MX7D/i.MX8M
> >
> > + Qiang
> >
> > On Thu, Mar 19, 2026 at 05:18:23PM +0800, Richard Zhu wrote:
> > > The MSI trigger mechanism for endpoint devices connected to i.MX7D,
> > > i.MX8MM, and i.MX8MQ PCIe root complex ports depends on the MSI
> > > capability register settings in the root complex. Removing the MSI
> > > capability breaks MSI functionality for these endpoints.
> > >
> >
> > What is the relation between Root Port MSI and endpoint MSI? Endpoint MSIs
> > should be routed to the platform MSI controller (DWC i.MSI-RX or External like
> > GIC-ITS) independent of the Root Port MSI state.
> Hi Mani:
> Thank for your kindly concern.
> The MSI controller (DWC i.MSI-RX) on i.MX7D, i.MX8MM, and i.MX8MQ platforms
> requires the RC's MSI capability to remain enabled. Removing it breaks MSI
> routing from endpoints to the platform MSI controller.
>
I understand that MSI is broken on your hardware, but I was trying to understand
'why' specifically. Because, Root Port MSI capability doesn't have anything to
do with the endpoint MSIs. And since you mentioned that this issue happens only
on one platform, could be that the hardware designers have mistakenly wired the
Root Port's 'MSI Enable' to iMSI-RX's enable signal or something similar?
If so, we can introduce a flag 'dw_pcie_rp::keep_rp_msi_en' or something
similar, set it for affected SoCs and skip the capability removal in
pcie-designware-host.c
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Ronald Claveau @ 2026-03-30 10:21 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Ronald Claveau
Fix introduced invalid property for Khadas VIM4 sdcard regulator.
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603290828.5gt393t6-lkp@intel.com/
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 11bfbc99191b6..003b3bcdaf2bc 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -65,7 +65,6 @@ sd_3v3: regulator-sdcard-3v3 {
vin-supply = <&vddao_3v3>;
gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
regulator-boot-on;
- enable-active-low;
regulator-always-on;
};
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260330-fix-invalid-property-bbe54d933f71
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply related
* Re: [PATCH v13 30/48] KVM: arm64: Handle Realm PSCI requests
From: Suzuki K Poulose @ 2026-03-30 10:36 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-31-steven.price@arm.com>
On 18/03/2026 15:53, Steven Price wrote:
> The RMM needs to be informed of the target REC when a PSCI call is made
> with an MPIDR argument. Expose an ioctl to the userspace in case the PSCI
> is handled by it.
>
> [NOTE: A future version of the RMM specification is likely to remove the
> need for this ioctl.]
This will need to stay for the PSCI_CPU_ON case, where the host has to
acknowledge the onlining of a vCPU.
>
> Co-developed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
For the record, we can drop the UAPI following our discussions and
implicitly do the PSCI complete before REC_ENTER, similar to what
we do for the SET_RIPAS request. The VMM/KVM can treat the case
as a normal PSCI_CPU_ON request and return the result as in normal
VMs.
The target REC may ENTER before we complete the reporting, but we can
handle this error case (RMI_ERROR_REC) and return -EAGAIN to the
userspace.
Suzuki
> ---
> Changes since v12:
> * Chance return code for non-realms to -ENXIO to better represent that
> the ioctl is invalid for non-realms (checkpatch is insistent that
> "ENOSYS means 'invalid syscall nr' and nothing else").
> Changes since v11:
> * RMM->RMI renaming.
> Changes since v6:
> * Use vcpu_is_rec() rather than kvm_is_realm(vcpu->kvm).
> * Minor renaming/formatting fixes.
> ---
> arch/arm64/include/asm/kvm_rmi.h | 3 +++
> arch/arm64/kvm/arm.c | 25 +++++++++++++++++++++++++
> arch/arm64/kvm/psci.c | 30 ++++++++++++++++++++++++++++++
> arch/arm64/kvm/rmi.c | 14 ++++++++++++++
> 4 files changed, 72 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
> index 38208be3c602..1ee5ed0f5ab2 100644
> --- a/arch/arm64/include/asm/kvm_rmi.h
> +++ b/arch/arm64/include/asm/kvm_rmi.h
> @@ -117,6 +117,9 @@ int realm_map_non_secure(struct realm *realm,
> unsigned long size,
> enum kvm_pgtable_prot prot,
> struct kvm_mmu_memory_cache *memcache);
> +int realm_psci_complete(struct kvm_vcpu *source,
> + struct kvm_vcpu *target,
> + unsigned long status);
>
> static inline bool kvm_realm_is_private_address(struct realm *realm,
> unsigned long addr)
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 304fb1f2b3ff..61182eb0cf70 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1846,6 +1846,22 @@ static int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> return __kvm_arm_vcpu_set_events(vcpu, events);
> }
>
> +static int kvm_arm_vcpu_rmi_psci_complete(struct kvm_vcpu *vcpu,
> + struct kvm_arm_rmi_psci_complete *arg)
> +{
> + struct kvm_vcpu *target = kvm_mpidr_to_vcpu(vcpu->kvm, arg->target_mpidr);
> +
> + if (!target)
> + return -EINVAL;
> +
> + /*
> + * RMM v1.0 only supports PSCI_RET_SUCCESS or PSCI_RET_DENIED
> + * for the status. But, let us leave it to the RMM to filter
> + * for making this future proof.
> + */
> + return realm_psci_complete(vcpu, target, arg->psci_status);
> +}
> +
> long kvm_arch_vcpu_ioctl(struct file *filp,
> unsigned int ioctl, unsigned long arg)
> {
> @@ -1974,6 +1990,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>
> return kvm_arm_vcpu_finalize(vcpu, what);
> }
> + case KVM_ARM_VCPU_RMI_PSCI_COMPLETE: {
> + struct kvm_arm_rmi_psci_complete req;
> +
> + if (!vcpu_is_rec(vcpu))
> + return -ENXIO;
> + if (copy_from_user(&req, argp, sizeof(req)))
> + return -EFAULT;
> + return kvm_arm_vcpu_rmi_psci_complete(vcpu, &req);
> + }
> default:
> r = -EINVAL;
> }
> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> index 3b5dbe9a0a0e..a68f3c1878a5 100644
> --- a/arch/arm64/kvm/psci.c
> +++ b/arch/arm64/kvm/psci.c
> @@ -103,6 +103,12 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>
> reset_state->reset = true;
> kvm_make_request(KVM_REQ_VCPU_RESET, vcpu);
> + /*
> + * Make sure we issue PSCI_COMPLETE before the VCPU can be
> + * scheduled.
> + */
> + if (vcpu_is_rec(vcpu))
> + realm_psci_complete(source_vcpu, vcpu, PSCI_RET_SUCCESS);
>
> /*
> * Make sure the reset request is observed if the RUNNABLE mp_state is
> @@ -115,6 +121,11 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>
> out_unlock:
> spin_unlock(&vcpu->arch.mp_state_lock);
> + if (vcpu_is_rec(vcpu) && ret != PSCI_RET_SUCCESS) {
> + realm_psci_complete(source_vcpu, vcpu,
> + ret == PSCI_RET_ALREADY_ON ?
> + PSCI_RET_SUCCESS : PSCI_RET_DENIED);
> + }
> return ret;
> }
>
> @@ -142,6 +153,25 @@ static unsigned long kvm_psci_vcpu_affinity_info(struct kvm_vcpu *vcpu)
> /* Ignore other bits of target affinity */
> target_affinity &= target_affinity_mask;
>
> + if (vcpu_is_rec(vcpu)) {
> + struct kvm_vcpu *target_vcpu;
> +
> + /* RMM supports only zero affinity level */
> + if (lowest_affinity_level != 0)
> + return PSCI_RET_INVALID_PARAMS;
> +
> + target_vcpu = kvm_mpidr_to_vcpu(kvm, target_affinity);
> + if (!target_vcpu)
> + return PSCI_RET_INVALID_PARAMS;
> +
> + /*
> + * Provide the references of the source and target RECs to the
> + * RMM so that the RMM can complete the PSCI request.
> + */
> + realm_psci_complete(vcpu, target_vcpu, PSCI_RET_SUCCESS);
> + return PSCI_RET_SUCCESS;
> + }
> +
> /*
> * If one or more VCPU matching target affinity are running
> * then ON else OFF
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 30292814b1ec..e56c8af2ad61 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -353,6 +353,20 @@ static void free_rtt(phys_addr_t phys)
> kvm_account_pgtable_pages(phys_to_virt(phys), -1);
> }
>
> +int realm_psci_complete(struct kvm_vcpu *source, struct kvm_vcpu *target,
> + unsigned long status)
> +{
> + int ret;
> +
> + ret = rmi_psci_complete(virt_to_phys(source->arch.rec.rec_page),
> + virt_to_phys(target->arch.rec.rec_page),
> + status);
> + if (ret)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static int realm_rtt_create(struct realm *realm,
> unsigned long addr,
> int level,
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Krzysztof Kozlowski @ 2026-03-30 10:38 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot
In-Reply-To: <20260330-fix-invalid-property-v1-1-e829c4d806cb@aliel.fr>
On 30/03/2026 12:21, Ronald Claveau wrote:
> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>
> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>
Fixes commit?
Why there is no such change in recent next? Was it just merged?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Jian Hu @ 2026-03-30 10:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <20260327-rough-spry-hyrax-8236de@quoll>
On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>
>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
Thanks for your review.
This series is based on the clk-next branch (version v7.0-rc1).
Here are the check results without --strict:
$ ./scripts/checkpatch.pl
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch
total: 0 errors, 0 warnings, 8 lines checked
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch
total: 0 errors, 0 warnings, 46 lines checked
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch
total: 0 errors, 0 warnings, 149 lines checked
Here are the check results with --strict (I had also checked them with
this script before submitting these patches):
$ ./scripts/checkpatch.pl --strict
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch
total: 0 errors, 0 warnings, 0 checks, 8 lines checked
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl --strict
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch
total: 0 errors, 0 warnings, 0 checks, 46 lines checked
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl --strict
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch
total: 0 errors, 0 warnings, 0 checks, 149 lines checked
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch has no
obvious style problems and is ready for submission.
I have also run the script on the latest v7.0-rc5, and no warnings are
reported.
Could you tell me which version of the checkpatch script you are using?
If you are using a locally modified script, kindly let me know which
warnings I need to fix.
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] iommu/arm-smmu-v3: Add basic debugfs framework
From: Nicolin Chen @ 2026-03-30 10:46 UTC (permalink / raw)
To: Qinxin Xia
Cc: robin.murphy, will, jpb, linux-arm-kernel, iommu, wangzhou1,
prime.zeng, fanghao11, jonathan.cameron, wuyifan50, linuxarm
In-Reply-To: <20260328101706.3448655-2-xiaqinxin@huawei.com>
On Sat, Mar 28, 2026 at 06:17:02PM +0800, Qinxin Xia wrote:
> Add basic debugfs framework for ARM SMMUv3 driver.This creates the
Needs a space after "."
> +static int smmu_debugfs_capabilities_show(struct seq_file *seq, void *unused)
> +{
> + struct arm_smmu_device *smmu = seq->private;
> +
> + if (!smmu) {
> + seq_puts(seq, "SMMU not available\n");
> + return 0;
> + }
> +
> + seq_puts(seq, "SMMUv3 Capabilities:\n");
> + seq_printf(seq, " Stage1 Translation: %s\n",
> + smmu->features & ARM_SMMU_FEAT_TRANS_S1 ? "Yes" : "No");
> + seq_printf(seq, " Stage2 Translation: %s\n",
> + smmu->features & ARM_SMMU_FEAT_TRANS_S2 ? "Yes" : "No");
> + seq_printf(seq, " Coherent Walk: %s\n",
> + smmu->features & ARM_SMMU_FEAT_COHERENCY ? "Yes" : "No");
> + seq_printf(seq, " ATS Support: %s\n",
> + smmu->features & ARM_SMMU_FEAT_ATS ? "Yes" : "No");
> + seq_printf(seq, " PRI Support: %s\n",
> + smmu->features & ARM_SMMU_FEAT_PRI ? "Yes" : "No");
> + seq_printf(seq, " Stream Table Size: %d\n", 1 << smmu->sid_bits);
> + seq_printf(seq, " Command Queue Depth: %d\n",
> + 1 << smmu->cmdq.q.llq.max_n_shift);
> + seq_printf(seq, " Event Queue Depth: %d\n",
> + 1 << smmu->evtq.q.llq.max_n_shift);
Nit: should we do all sizes or all depths? Any good reason to mix
them here?
> +/**
> + * arm_smmu_debugfs_remove() - Clean up debugfs entries for an SMMU device
> + * @smmu: SMMU device
> + *
> + * This function removes the debugfs directories created by setup.
> + */
> +void arm_smmu_debugfs_remove(struct arm_smmu_device *smmu)
> +{
> + struct arm_smmu_debugfs *debugfs;
> +
> + scoped_guard(mutex, &arm_smmu_debugfs_lock) {
It could be just normal guard().
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 4d00d796f078..cbb3fccc501b 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -4904,6 +4904,15 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> /* Check for RMRs and install bypass STEs if any */
> arm_smmu_rmr_install_bypass_ste(smmu);
>
> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
> + char name[32];
This could be moved to the top, as iommu_device_sysfs_add() can use
it, whether CONFIG_ARM_SMMU_V3_DEBUGFS=y or =n.
> + snprintf(name, sizeof(name), "smmu3.%pa", &ioaddr);
And this could be moved after ioaddr gets a copy from res->start.
>
> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
> +struct arm_smmu_debugfs {
> + struct dentry *smmu_dir;
A personal preference: for new structures, maybe drop those tabs?
> /* An SMMUv3 instance */
> struct arm_smmu_device {
> struct device *dev;
> @@ -803,6 +813,11 @@ struct arm_smmu_device {
>
> struct rb_root streams;
> struct mutex streams_mutex;
> +
> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
> + /* DebugFS Info */
Doesn't seem very useful. I'd drop it.
> + struct arm_smmu_debugfs *debugfs;
> +#endif
Nicolin
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-30 10:48 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <9830ff89-a145-41d1-98e9-1412f497d3f2@amlogic.com>
On 30/03/2026 12:44, Jian Hu wrote:
>
> On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>>
>>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
>> Please run scripts/checkpatch.pl on the patches and fix reported
>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>> patches and (probably) fix more warnings. Some warnings can be ignored,
>> especially from --strict run, but the code here looks like it needs a
>> fix. Feel free to get in touch if the warning is not clear.
>
>
> Thanks for your review.
>
>
> This series is based on the clk-next branch (version v7.0-rc1).
>
>
> Here are the check results without --strict:
>
I checked before. Now I double checked:
b4 shazam...
git format-patch -3
scripts/checkpatch.pl 0*
Clearly a warning, also on v7.0-rc1.
So maybe you don't do it on the kernel you are claiming or just doing it
on different code than you sent.
Especially the second case would be a waste of my time to investigate
and read this patch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v13 31/48] KVM: arm64: WARN on injected undef exceptions
From: Suzuki K Poulose @ 2026-03-30 10:50 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-32-steven.price@arm.com>
On 18/03/2026 15:53, Steven Price wrote:
> The RMM doesn't allow injection of a undefined exception into a realm
> guest. Add a WARN to catch if this ever happens.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Changes since v6:
> * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)!
> ---
> arch/arm64/kvm/inject_fault.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index 6492397b73d7..613f223bc7a3 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu)
> */
> void kvm_inject_undefined(struct kvm_vcpu *vcpu)
> {
> + WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC");
> if (vcpu_el1_is_32bit(vcpu))
> inject_undef32(vcpu);
> else
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: André Draszik @ 2026-03-30 10:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <177409897339.266364.69715997034739052.b4-review@b4>
Hi Krzysztof,
On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote:
> On Wed, 18 Mar 2026 15:27:47 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> > diff --git a/Documentation/devicetree/bindings/power/pd-samsung.yaml b/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > index 9c2c51133457..3f1a2dc17862 100644
> > --- a/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > +++ b/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > @@ -44,11 +45,28 @@ properties:
> > power-domains:
> > maxItems: 1
> >
> > + samsung,dtzpc:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Distributed TrustZone Protection Control (DTZPC) node.
>
> For what purpose?
It is part of the domain.
Furthermore, TZ configuration is lost as part of power-domain power
cycle, so this allows a driver to take necessary actions (inform the
EL3 firmware). I believe this handle to be similar to e.g. the existing
samsung,sysreg
> Your patchset is organized in odd way - first patch for me, then not for
> me, then again two patches for me. Please keep it consistent. Or better,
> decouple since there are no dependencies according to cover letter.
I'll update the cover letter to describe the dependencies. 4 depends on 2,
and 2 depends on 1, hence the ordering.
Cheers,
Andre
^ permalink raw reply
* Re: [PATCH v13 32/48] arm64: Don't expose stolen time for realm guests
From: Suzuki K Poulose @ 2026-03-30 10:52 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-33-steven.price@arm.com>
On 18/03/2026 15:53, Steven Price wrote:
> It doesn't make much sense as a realm guest wouldn't want to trust the
> host. It will also need some extra work to ensure that KVM will only
> attempt to write into a shared memory region. So for now just disable
> it.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v7:
> * Update the documentation to add a note about stolen time being
> unavailable in a realm.
> ---
> Documentation/virt/kvm/api.rst | 3 +++
> arch/arm64/kvm/arm.c | 5 ++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index bc180c853faf..70911fe6d435 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -9240,6 +9240,9 @@ is supported, than the other should as well and vice versa. For arm64
> see Documentation/virt/kvm/devices/vcpu.rst "KVM_ARM_VCPU_PVTIME_CTRL".
> For x86 see Documentation/virt/kvm/x86/msr.rst "MSR_KVM_STEAL_TIME".
>
> +Note that steal time accounting is not available when a guest is running
> +within a Arm CCA realm (machine type KVM_VM_TYPE_ARM_REALM).
> +
> 8.25 KVM_CAP_S390_DIAG318
> -------------------------
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 61182eb0cf70..7d92ddb06460 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -469,7 +469,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> r = system_supports_mte();
> break;
> case KVM_CAP_STEAL_TIME:
> - r = kvm_arm_pvtime_supported();
> + if (kvm_is_realm(kvm))
> + r = 0;
> + else
> + r = kvm_arm_pvtime_supported();
Could this be handled in kvm_realm_ext_allowed() ?
Suzuki
> break;
> case KVM_CAP_ARM_EL1_32BIT:
> r = cpus_have_final_cap(ARM64_HAS_32BIT_EL1);
^ permalink raw reply
* Re: [PATCH v8 05/10] pmdomain: samsung: convert to using regmap
From: André Draszik @ 2026-03-30 10:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <177409897341.266364.2957933304869869135.b4-review@b4>
On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote:
> On Wed, 18 Mar 2026 15:27:50 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> > diff --git a/drivers/pmdomain/samsung/exynos-pm-domains.c b/drivers/pmdomain/samsung/exynos-pm-domains.c
> > index 5c3aa8983087..68b1e7ba8729 100644
> > --- a/drivers/pmdomain/samsung/exynos-pm-domains.c
> > +++ b/drivers/pmdomain/samsung/exynos-pm-domains.c
> > @@ -120,9 +140,26 @@ static int exynos_pd_probe(struct platform_device *pdev)
> > [ ... skip 20 lines ... ]
> > +
> > + reg_config.max_register = resource_size(res) - reg_config.reg_stride;
> > + pd->regmap = devm_regmap_init_mmio(dev, base, ®_config);
> > + if (IS_ERR(pd->regmap))
> > + return dev_err_probe(dev, PTR_ERR(base),
> > + "failed to init regmap\n");
>
> PTR_ERR(pd->regmap)
Thanks!
A.
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-30 10:53 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <ebc6da60-d49f-4a44-9ecb-3ae70413a248@kernel.org>
On 30/03/2026 12:48, Krzysztof Kozlowski wrote:
> On 30/03/2026 12:44, Jian Hu wrote:
>>
>> On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>>>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>>>
>>>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
>>> Please run scripts/checkpatch.pl on the patches and fix reported
>>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>>> patches and (probably) fix more warnings. Some warnings can be ignored,
>>> especially from --strict run, but the code here looks like it needs a
>>> fix. Feel free to get in touch if the warning is not clear.
>>
>>
>> Thanks for your review.
>>
>>
>> This series is based on the clk-next branch (version v7.0-rc1).
>>
>>
>> Here are the check results without --strict:
>>
>
> I checked before. Now I double checked:
>
> b4 shazam...
> git format-patch -3
> scripts/checkpatch.pl 0*
>
> Clearly a warning, also on v7.0-rc1.
>
> So maybe you don't do it on the kernel you are claiming or just doing it
> on different code than you sent.
>
It looks like it is b4 shazam problem which duplicates the Fixes tag. I
don't quite get why the tag is duplicated. I don't see anything on the
lists which would add wrong tag.
Well, that will be problem when applying, but nothing to be fixed here, so:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ 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