* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 16:22 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <20260527151414.184823-1-wahrenst@gmx.net>
Hi Frank,
Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> which is placed on phyCORE-i.MX93 SOM.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
could you please take care of this patch?
> ---
>
> Changes in V2:
> - rebase patch
> - add Krzysztof's Reviewed-by
>
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index d905a0777f93..20bbbd310d2f 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> CONFIG_QCA808X_PHY=m
> CONFIG_REALTEK_PHY=y
> CONFIG_ROCKCHIP_PHY=y
> +CONFIG_DP83822_PHY=m
> CONFIG_DP83867_PHY=y
> CONFIG_DP83869_PHY=m
> CONFIG_DP83TG720_PHY=m
^ permalink raw reply
* Re: [PATCH v2 4/5] KVM: arm64: Omit tag sync on stage-2 mappings of the zero page
From: Marc Zyngier @ 2026-06-05 16:18 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, will, catalin.marinas,
Ard Biesheuvel, Kevin Brodsky, Mark Brown, stable
In-Reply-To: <20260604151151.150377-11-ardb+git@google.com>
On Thu, 04 Jun 2026 16:11:56 +0100,
Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Commit
>
> f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged")
>
> removed the PG_mte_tagged flag from the zero page, but missed a KVM code
> path that may set this flag on the zero page when it is used in a
> stage-2 CoW mapping of anonymous memory.
>
> So disregard the zero page explicitly in sanitise_mte_tags().
>
> Fixes: f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged")
> Cc: <stable@vger.kernel.org> # 5.10.x
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/kvm/mmu.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index d089c107d9b7..445d6cf035c9 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1479,6 +1479,11 @@ static void sanitise_mte_tags(struct kvm *kvm, kvm_pfn_t pfn,
> if (!kvm_has_mte(kvm))
> return;
>
> + if (is_zero_pfn(pfn)) {
> + WARN_ON_ONCE(nr_pages != 1);
> + return;
> + }
> +
> if (folio_test_hugetlb(folio)) {
> /* Hugetlb has MTE flags set on head page only */
> if (folio_try_hugetlb_mte_tagging(folio)) {
Reviewed-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 4/7] dt-bindings: input: sun4i-lradc-keys: Add A100/A133 compatible
From: Conor Dooley @ 2026-06-05 16:11 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-arm-kernel, linux-sunxi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans de Goede, Dmitry Torokhov, Andre Przywara, Jun Yan,
Lukas Schmid, J. Neuschäfer, Eric Biggers, Michal Simek,
Luca Weiss, Sven Peter, Maxime Ripard, devicetree, linux-kernel,
linux-input
In-Reply-To: <20260605070923.3045073-5-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 13/14] net: stmmac: tc956x: add TC956x/QPS615 support
From: Maxime Chevallier @ 2026-06-05 16:05 UTC (permalink / raw)
To: Alex Elder, andrew+netdev, davem, edumazet, kuba, pabeni,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh
Cc: Daniel Thompson, mohd.anwar, a0987203069, alexandre.torgue, ast,
boon.khai.ng, chenchuangyu, chenhuacai, daniel, hawk, hkallweit1,
inochiama, john.fastabend, julianbraha, livelycarpet87,
mcoquelin.stm32, me, prabhakar.mahadev-lad.rj, richardcochran,
rohan.g.thomas, sdf, siyanteng, weishangjuan, wens, netdev, bpf,
linux-arm-msm, devicetree, linux-gpio, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260605010022.968612-14-elder@riscstar.com>
Hi Alex,
On 6/5/26 03:00, Alex Elder wrote:
> From: Daniel Thompson <daniel@riscstar.com>
>
> Toshiba TC956x is an Ethernet AVB/TSN bridge and is essentially a
> small and highly-specialized SoC. TC956x includes an "eMAC" subsystem
> that can be accessed, along with several other peripherals, via two
> PCIe endpoint functions. There is a main driver for the endpoint that
> decomposes things and creates auxiliary bus devices to model the SoC.
>
> The eMAC consists of a Designware XGMAC, XPCS and PMA. Each eMAC is
> supported by an MSIGEN that bridges TC956x level interrupts to PCIe
> MSIs.
>
> Add a driver for the eMAC/MSIGEN combination.
>
> Co-developed-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> ---
[...]
> +static int tc956x_lookup_max_speed(phy_interface_t phy_interface)
> +{
> + switch (phy_interface) {
> + case PHY_INTERFACE_MODE_SGMII:
The SGMII definition we use in the kernel is the Cisco SGMII de-facto
standard that only supports 10/100/1000M. Some vendors use flavours with
names such as HS-SGMII and such, that's basically SGMII clocked at 2.5G
with aneg disabled. It kinda becomes 2500BaseX then.
So all in all, we don't support 2500M on SGMII.
> + case PHY_INTERFACE_MODE_2500BASEX:
> + return SPEED_2500;
> +
> + default:
> + return -EOPNOTSUPP;
> + }
Maxime
^ permalink raw reply
* Re: [PATCH bpf-next v2 8/8] selftests/bpf: add tests to validate KASAN on JIT programs
From: Alexis Lothoré @ 2026-06-05 16:01 UTC (permalink / raw)
To: Yonghong Song, Alexis Lothoré (eBPF Foundation),
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Jiri Olsa, John Fastabend, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <13b87293-5237-43d3-9f91-33c13041cb43@linux.dev>
On Fri Jun 5, 2026 at 5:47 PM CEST, Yonghong Song wrote:
[...]
> [root@arch-fb-vm1 bpf]# ./test_progs -n 164
> test_kasan:PASS:alloc test ctx 0 nsec
> gzopen /boot/config-7.1.0-rc5-gec86c8156bd6: No such file or directory
> test_kasan:PASS:open prog 0 nsec
> test_kasan:PASS:find rnd_hi32 prog 0 nsec
> ...
> All error logs:
> test_kasan:PASS:alloc test ctx 0 nsec
> gzopen /boot/config-7.1.0-rc5-gec86c8156bd6: No such file or directory
> test_kasan:PASS:open prog 0 nsec
> test_kasan:PASS:find rnd_hi32 prog 0 nsec
> test_kasan:PASS:load prog 0 nsec
> test_kasan:PASS:open kernel logs 0 nsec
> test_kasan:PASS:get map 0 nsec
> test_kasan:PASS:set map 0 nsec
> run_subtest_with_size_and_location:PASS:find test prog 0 nsec
> run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
> run_subtest_with_size_and_location:PASS:run prog 0 nsec
> run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
> run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
> #164/1 kasan/st_1_not_on_stack:FAIL
[...]
> #164 kasan:FAIL
>
> I checked the subtest 164/1,
>
> For
>
> ret = check_kasan_report_in_kernel_logs(klog_buffer, ctx,
> test->is_write, access_size);
> if (on_stack || test->expect_no_report)
> ASSERT_NEQ(ret, 0, "no report should be generated");
> else
> ASSERT_OK(ret, "report should be generated");
>
> the ret is equal to 1 as klog_buffer is empty. This caused the failure.
Are you seeing any kasan report when you manually check your kernel
logs, or not at all ? If not at all, are you using the "CI" defconfig ?
cat tools/testing/selftests/bpf/{config,config.vm,config.x86_64} > .config && make olddefconfig
If not, would you mind sharing your defconfig ?
Thanks,
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH RFC v2] drm/rockchip: vop2: Add clock rate mode check
From: Alexey Charkov @ 2026-06-05 15:58 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel, kernel
In-Reply-To: <20260409-vop2-clk-rate-check-v2-1-b207cfc427d7@collabora.com>
On Fri, Apr 10, 2026 at 2:37 AM Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> The display might offer modes, which exceed the maximum clock rate of a
> video output. This usually happens for displays that offer refresh rates
> above 60 Hz. This results in no picture (or a broken one) being displayed
> without manual intervention. Fix this by teaching the driver about the
> maximum achievable clock rates for each video port.
>
> The information about the maximum clock rates for each video channel and
> the tip about multiple pixels being processed per clock were provided by
> Andy Yan and roughly checked against the information available in the
> datasheet (which specifies limits like "2560x1600@60Hz with 10-bit"
> instead of a specific pixel rate).
>
> For the video ports supporting a 600 MHz input clock, there is some
> logic to handle up to 4 pixels in parallel when needed resulting in
> the extra multiplier.
>
> Suggested-by: Andy Yan <andy.yan@rock-chips.com>
> Link: https://lore.kernel.org/linux-rockchip/1528d788.186b.19d08ed974c.Coremail.andyshrk@163.com/
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> I've kept the RFC tag, as I'm not sure about the 4x parallel pixel
> processing. IIUIC all of the video ports with a maximum of 600 MHz
> input clock support it, considering they can go to 4K @ 120Hz,
> which is above 1.2GHz while Andy mentioned a max. support clock rate
> of 600 MHz.
> ---
> Changes in v2:
> - Link to v1: https://lore.kernel.org/r/20260217-vop2-clk-rate-check-v1-1-989b569119ba@collabora.com
> - based on v7.0-rc7
> - rename max_clock_rate into max_pixel_clock_rate to distinguish from
> input clock
> - update max clock rates to the numbers provided by Andy Yan with
> extra 4x multiplier for 4K 120Hz VPs
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 +
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 10 ++++++++++
> 3 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index a195f5c819a2..35a0edda5375 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1434,6 +1434,9 @@ static enum drm_mode_status vop2_crtc_mode_valid(struct drm_crtc *crtc,
> if (mode->hdisplay > vp->data->max_output.width)
> return MODE_BAD_HVALUE;
>
> + if (mode->clock > vp->data->max_pixel_clock_rate / 1000)
> + return MODE_CLOCK_HIGH;
> +
> return MODE_OK;
> }
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> index 9124191899ba..fd46913f3346 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> @@ -225,6 +225,7 @@ struct vop2_video_port_data {
> u16 gamma_lut_len;
> u16 cubic_lut_len;
> struct vop_rect max_output;
> + u32 max_pixel_clock_rate;
> const u8 pre_scan_max_dly[4];
> unsigned int offset;
> /**
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index f3950e8476a7..6ae3d506c476 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -559,18 +559,21 @@ static const struct vop2_video_port_data rk3568_vop_video_ports[] = {
> .gamma_lut_len = 1024,
> .cubic_lut_len = 9 * 9 * 9,
> .max_output = { 4096, 2304 },
> + .max_pixel_clock_rate = 600000000U,
> .pre_scan_max_dly = { 69, 53, 53, 42 },
> .offset = 0xc00,
> }, {
> .id = 1,
> .gamma_lut_len = 1024,
> .max_output = { 2048, 1536 },
> + .max_pixel_clock_rate = 200000000U,
> .pre_scan_max_dly = { 40, 40, 40, 40 },
> .offset = 0xd00,
> }, {
> .id = 2,
> .gamma_lut_len = 1024,
> .max_output = { 1920, 1080 },
> + .max_pixel_clock_rate = 150000000U,
> .pre_scan_max_dly = { 40, 40, 40, 40 },
> .offset = 0xe00,
> },
> @@ -775,6 +778,7 @@ static const struct vop2_video_port_data rk3576_vop_video_ports[] = {
> .gamma_lut_len = 1024,
> .cubic_lut_len = 9 * 9 * 9, /* 9x9x9 */
> .max_output = { 4096, 2304 },
> + .max_pixel_clock_rate = 600000000U * 4,
Hi Sebastian,
I've tested it on a bunch of different displays with RK3576 while also
giving VP0 an unlimited PLL to work with (and also expanding its rates
table for each of the displays' EDID preferred pixel clocks), and I'm
pretty sure this should be * 2 here, rather than * 4. That would also
align with ".pixel_rate = 2" just below.
In its current form, some of the advanced displays with 240 Hz modes
by default choose modes leading to visual artifacts indicative of
overclocking strain of the graphics pipeline.
The rest look plausible, so with that change please feel free to include:
Tested-by: Alexey Charkov <alchark@flipper.net> # RK3576
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH bpf-next v2 5/8] bpf, x86: emit KASAN checks into x86 JITed programs
From: Alexis Lothoré @ 2026-06-05 15:50 UTC (permalink / raw)
To: Yonghong Song, Alexis Lothoré (eBPF Foundation),
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Jiri Olsa, John Fastabend, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <78009c06-4233-4e0a-88ec-33eba10ad8b3@linux.dev>
Hi Yonghong,
On Fri Jun 5, 2026 at 4:54 PM CEST, Yonghong Song wrote:
>
[...]
>> if (BPF_MODE(insn->code) == BPF_PROBE_MEMSX ||
>> BPF_MODE(insn->code) == BPF_MEMSX)
>> @@ -2592,13 +2622,13 @@ static int do_jit(struct bpf_verifier_env *env, struct bpf_prog *bpf_prog, int *
>> fallthrough;
>> case BPF_STX | BPF_ATOMIC | BPF_W:
>> case BPF_STX | BPF_ATOMIC | BPF_DW:
>> + bool is64 = BPF_SIZE(insn->code) == BPF_DW;
>> + u32 real_src_reg = src_reg;
>> + u32 real_dst_reg = dst_reg;
>
> With llvm23, I got the following build failure:
>
> /home/yhs/work/bpf-next/arch/x86/net/bpf_jit_comp.c:2625:4: error:
> label followed by a declaration is a C23 extension [-Werror,-Wc23-extensions]
> 2625 | bool is64 = BPF_SIZE(insn->code) == BPF_DW;
> | ^
> 1 error generated.
>
> The below is a fix:
Thanks for the test, the report and the fix. So this warning looks
specific to llvm23, as CI does not trigger it with LLVM21. I'll bring
the fix in in the next revision.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: net: add Realtek r8169 family PCIe Ethernet
From: Heiner Kallweit @ 2026-06-05 15:48 UTC (permalink / raw)
To: ricardo, nic_swsd, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260605-rk3588-dts-rtl-eth-describe-dt-alias-v3-1-8a8857b39daf@pardini.net>
On 05.06.2026 13:49, Ricardo Pardini via B4 Relay wrote:
> From: Ricardo Pardini <ricardo@pardini.net>
>
> Add a binding for fixed/soldered Realtek PCIe Ethernet controllers
> driven by the r8169 driver (RTL8125/8126/8127/8168 and variants).
>
> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
> compatibles documented in their own bindings (e.g. microchip,lan95xx)
> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
> these PCI function nodes can be validated.
>
The of node seems to be created by of_pci_make_dev_node(). But this
function is called for bridges only in pci_bus_add_device().
So where is the node created in your case? Did you test node creation?
> Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
> ---
> .../devicetree/bindings/net/realtek,r8169.yaml | 54 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/realtek,r8169.yaml b/Documentation/devicetree/bindings/net/realtek,r8169.yaml
> new file mode 100644
> index 0000000000000..6923211ff4c93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek,r8169.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/realtek,r8169.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek r8169 family PCIe Ethernet Controllers
> +
> +maintainers:
> + - Heiner Kallweit <hkallweit1@gmail.com>
> +
> +description:
> + PCI function node properties for fixed/soldered Realtek Ethernet
> + controllers driven by the r8169 driver.
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - pci10ec,8125 # RTL8125 2.5GbE
> + - pci10ec,8126 # RTL8126 5GbE
> + - pci10ec,8127 # RTL8127
> + - pci10ec,8161 # RTL8168 variant
> + - pci10ec,8162 # RTL8168 variant
> + - pci10ec,8168 # RTL8168/8111 GbE
This list reflects just some of the PCI id's handled by r8169.
Any specific reason for this exact selection?
> +
> + reg:
> + maxItems: 1
> +
> + local-mac-address: true
> + mac-address: true
> + nvmem-cells: true
> + nvmem-cell-names: true
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet@0,0 {
> + compatible = "pci10ec,8125";
> + reg = <0x10000 0 0 0 0>;
> + local-mac-address = [00 00 00 00 00 00];
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b539be153f6a4..6341de4fadb6c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -134,6 +134,7 @@ M: Heiner Kallweit <hkallweit1@gmail.com>
> M: nic_swsd@realtek.com
> L: netdev@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/net/realtek,r8169.yaml
> F: drivers/net/ethernet/realtek/r8169*
>
> 8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
>
^ permalink raw reply
* Re: [PATCH bpf-next v2 8/8] selftests/bpf: add tests to validate KASAN on JIT programs
From: Yonghong Song @ 2026-06-05 15:47 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation), Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Song Liu, Jiri Olsa,
John Fastabend, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Shuah Khan, Maxime Coquelin,
Alexandre Torgue, Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <20260604-kasan-v2-8-c066e627fda8@bootlin.com>
On 6/4/26 1:22 PM, Alexis Lothoré (eBPF Foundation) wrote:
> Add a basic KASAN test runner that loads and test-run programs that can
> trigger memory management bugs. The test captures kernel logs and ensure
> that the expected KASAN splat is emitted by searching for the
> corresponding first lines in the report, hence validated that the needed
> instrumentation has been inserted by the JIT compiler before the
> relevant memory accesses.
>
> The runner covers different cases and settings: in the nominal case, it
> validates kasan reports on basic instructions (on all supported accesses
> sizes) but also when report _should not_ be emitted (eg: for accesses on
> program stack). The runner also comes with a few specialized tests that
> are then not executed for all sizes/locations. A few of those tests
> depends on cpuv4 (load_acquire and store_release).
>
> # ./test_progs -a kasan
> #164/1 kasan/st_1_not_on_stack:OK
> #164/2 kasan/st_1_on_stack:OK
> #164/3 kasan/st_2_not_on_stack:OK
> #164/4 kasan/st_2_on_stack:OK
> #164/5 kasan/st_4_not_on_stack:OK
> #164/6 kasan/st_4_on_stack:OK
> #164/7 kasan/st_8_not_on_stack:OK
> #164/8 kasan/st_8_on_stack:OK
> #164/9 kasan/stx_1_not_on_stack:OK
> #164/10 kasan/stx_1_on_stack:OK
> #164/11 kasan/stx_2_not_on_stack:OK
> #164/12 kasan/stx_2_on_stack:OK
> #164/13 kasan/stx_4_not_on_stack:OK
> #164/14 kasan/stx_4_on_stack:OK
> #164/15 kasan/stx_8_not_on_stack:OK
> #164/16 kasan/stx_8_on_stack:OK
> #164/17 kasan/ldx_1_not_on_stack:OK
> #164/18 kasan/ldx_1_on_stack:OK
> #164/19 kasan/ldx_2_not_on_stack:OK
> #164/20 kasan/ldx_2_on_stack:OK
> #164/21 kasan/ldx_4_not_on_stack:OK
> #164/22 kasan/ldx_4_on_stack:OK
> #164/23 kasan/ldx_8_not_on_stack:OK
> #164/24 kasan/ldx_8_on_stack:OK
> #164/25 kasan/simple_atomic_4_not_on_stack:OK
> #164/26 kasan/simple_atomic_4_on_stack:OK
> #164/27 kasan/simple_atomic_8_not_on_stack:OK
> #164/28 kasan/simple_atomic_8_on_stack:OK
> #164/29 kasan/load_acquire_1_not_on_stack:SKIP
> #164/30 kasan/load_acquire_1_on_stack:SKIP
> #164/31 kasan/load_acquire_2_not_on_stack:SKIP
> #164/32 kasan/load_acquire_2_on_stack:SKIP
> #164/33 kasan/load_acquire_4_not_on_stack:SKIP
> #164/34 kasan/load_acquire_4_on_stack:SKIP
> #164/35 kasan/load_acquire_8_not_on_stack:SKIP
> #164/36 kasan/load_acquire_8_on_stack:SKIP
> #164/37 kasan/store_release_1_not_on_stack:SKIP
> #164/38 kasan/store_release_1_on_stack:SKIP
> #164/39 kasan/store_release_2_not_on_stack:SKIP
> #164/40 kasan/store_release_2_on_stack:SKIP
> #164/41 kasan/store_release_4_not_on_stack:SKIP
> #164/42 kasan/store_release_4_on_stack:SKIP
> #164/43 kasan/store_release_8_not_on_stack:SKIP
> #164/44 kasan/store_release_8_on_stack:SKIP
> #164/45 kasan/ldx_patched:OK
> #164/46 kasan/stack_and_non_stack:OK
> #164 kasan:OK (SKIP: 16/46)
> Summary: 1/30 PASSED, 16 SKIPPED, 0 FAILED
On my qemu run, I got a bunch of failures like below:
[root@arch-fb-vm1 bpf]# ./test_progs -n 164
test_kasan:PASS:alloc test ctx 0 nsec
gzopen /boot/config-7.1.0-rc5-gec86c8156bd6: No such file or directory
test_kasan:PASS:open prog 0 nsec
test_kasan:PASS:find rnd_hi32 prog 0 nsec
...
All error logs:
test_kasan:PASS:alloc test ctx 0 nsec
gzopen /boot/config-7.1.0-rc5-gec86c8156bd6: No such file or directory
test_kasan:PASS:open prog 0 nsec
test_kasan:PASS:find rnd_hi32 prog 0 nsec
test_kasan:PASS:load prog 0 nsec
test_kasan:PASS:open kernel logs 0 nsec
test_kasan:PASS:get map 0 nsec
test_kasan:PASS:set map 0 nsec
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/1 kasan/st_1_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/3 kasan/st_2_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/5 kasan/st_4_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/7 kasan/st_8_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/9 kasan/stx_1_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/11 kasan/stx_2_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/13 kasan/stx_4_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/15 kasan/stx_8_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/17 kasan/ldx_1_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/19 kasan/ldx_2_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/21 kasan/ldx_4_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/23 kasan/ldx_8_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/25 kasan/simple_atomic_4_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/27 kasan/simple_atomic_8_not_on_stack:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/45 kasan/ldx_patched:FAIL
run_subtest_with_size_and_location:PASS:find test prog 0 nsec
run_subtest_with_size_and_location:PASS:fetch loaded program info 0 nsec
run_subtest_with_size_and_location:PASS:run prog 0 nsec
run_subtest_with_size_and_location:PASS:read kernel logs 0 nsec
run_subtest_with_size_and_location:FAIL:report should be generated unexpected error: 1 (errno 11)
#164/46 kasan/stack_and_non_stack:FAIL
#164 kasan:FAIL
I checked the subtest 164/1,
For
ret = check_kasan_report_in_kernel_logs(klog_buffer, ctx,
test->is_write, access_size);
if (on_stack || test->expect_no_report)
ASSERT_NEQ(ret, 0, "no report should be generated");
else
ASSERT_OK(ret, "report should be generated");
the ret is equal to 1 as klog_buffer is empty. This caused the failure.
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> Changes in v2:
> - simplify tests by just manually poisoning test areas with a dedicated
> kfunc
> - introduce one prog per covered instruction family
> - make sure that tests do not consume kernel logs (use /dev/kmgs rather
> than klogctl)
> - add tests for stack accesses:
> - marking correctly set when there are diverging verifier states
> leading to different memory types
> - marking kept in sync with prog when it is patched
> ---
> tools/testing/selftests/bpf/prog_tests/kasan.c | 356 +++++++++++++++++++
> tools/testing/selftests/bpf/progs/kasan.c | 382 +++++++++++++++++++++
> .../testing/selftests/bpf/test_kmods/bpf_testmod.c | 22 ++
> 3 files changed, 760 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/kasan.c b/tools/testing/selftests/bpf/prog_tests/kasan.c
> new file mode 100644
> index 000000000000..adf61e230ec9
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/kasan.c
> @@ -0,0 +1,356 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +#include <bpf/bpf.h>
> +#include <errno.h>
> +#include <fcntl.h>
> +#include <linux/if_ether.h>
> +#include <unistd.h>
> +#include <test_progs.h>
> +#include <unpriv_helpers.h>
> +#include "kasan.skel.h"
> +
> +#define SUBTEST_NAME_MAX_LEN 128
> +#define PROG_NAME_MAX_LEN 128
> +
> +#define MAX_LOG_SIZE (8 * 1024)
> +#define READ_CHUNK_SIZE 256
> +
> +#define KASAN_PATTERN_SLAB_UAF "BUG: KASAN: slab-use-after-free " \
> + "in bpf_prog_%02x%02x%02x%02x%02x%02x%02x%02x_%s"
> +#define KASAN_PATTERN_REPORT "%s of size %d at addr"
> +
> +static char klog_buffer[MAX_LOG_SIZE];
> +
> +struct test_spec {
> + char *prog_type;
> + bool is_write;
> + bool only_32_or_64;
> + bool needs_load_acq_store_rel;
> + bool skip_multi_size_testing;
> + bool skip_on_stack_testing;
> + int run_size;
> + bool expect_no_report;
expect_no_report is not set in the code. The only usage is in
if (on_stack || test->expect_no_report)
ASSERT_NEQ(ret, 0, "no report should be generated");
else
ASSERT_OK(ret, "report should be generated");
> + bool rnd_hi32;
> +};
> +
> +struct kasan_write_val {
> + __u8 data_1;
> + __u16 data_2;
> + __u32 data_4;
> + __u64 data_8;
> +};
> +
>
[...]
^ permalink raw reply
* Re: [PATCH net-next v2 03/14] net: pcs: pcs-xpcs-regmap: support XPCS memory-mapped MDIO bus via regmap
From: Maxime Chevallier @ 2026-06-05 15:35 UTC (permalink / raw)
To: Alex Elder, andrew+netdev, davem, edumazet, kuba, pabeni,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh
Cc: Daniel Thompson, mohd.anwar, a0987203069, alexandre.torgue, ast,
boon.khai.ng, chenchuangyu, chenhuacai, daniel, hawk, hkallweit1,
inochiama, john.fastabend, julianbraha, livelycarpet87,
mcoquelin.stm32, me, prabhakar.mahadev-lad.rj, richardcochran,
rohan.g.thomas, sdf, siyanteng, weishangjuan, wens, netdev, bpf,
linux-arm-msm, devicetree, linux-gpio, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260605010022.968612-4-elder@riscstar.com>
Hi Alex,
On 6/5/26 03:00, Alex Elder wrote:
> From: Daniel Thompson <daniel@riscstar.com>
>
> In some DesignWare XPCS implementatons the memory-mapped MDIO bus is
> allocated to a register window that does not align to a page boundary.
> This makes iomapping the registers problematic.
>
> For example the Toshiba TC9564 (a PCIe Ethernet-AVB/TSN bridge) provides
> an "eMAC" subsystem with the XPCS base address cuddled up to XGMAC
> registers.
>
> Let's introduce helpers to allow the driver that owns the eMAC to register
> an XPCS using is regmap for the memory-mapped MDIO bus.
>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> ---
> MAINTAINERS | 2 +
> drivers/net/pcs/Makefile | 4 +-
> drivers/net/pcs/pcs-xpcs-regmap.c | 219 ++++++++++++++++++++++++++++
> include/linux/pcs/pcs-xpcs-regmap.h | 20 +++
> 4 files changed, 243 insertions(+), 2 deletions(-)
> create mode 100644 drivers/net/pcs/pcs-xpcs-regmap.c
> create mode 100644 include/linux/pcs/pcs-xpcs-regmap.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eb8cdcc76324f..2aa6ea012c848 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25931,8 +25931,10 @@ F: drivers/net/ethernet/synopsys/
> SYNOPSYS DESIGNWARE ETHERNET XPCS DRIVER
> L: netdev@vger.kernel.org
> S: Orphan
> +F: drivers/net/pcs/pcs-xpcs-regmap.c
> F: drivers/net/pcs/pcs-xpcs.c
> F: drivers/net/pcs/pcs-xpcs.h
> +F include/linux/pcs/pcs-xpcs-regmap.h
> F: include/linux/pcs/pcs-xpcs.h
>
> SYNOPSYS DESIGNWARE HDMI RX CONTROLLER DRIVER
> diff --git a/drivers/net/pcs/Makefile b/drivers/net/pcs/Makefile
> index 4f7920618b900..565f1b63fce0b 100644
> --- a/drivers/net/pcs/Makefile
> +++ b/drivers/net/pcs/Makefile
> @@ -1,8 +1,8 @@
> # SPDX-License-Identifier: GPL-2.0
> # Makefile for Linux PCS drivers
>
> -pcs_xpcs-$(CONFIG_PCS_XPCS) := pcs-xpcs.o pcs-xpcs-plat.o \
> - pcs-xpcs-nxp.o pcs-xpcs-wx.o
> +pcs_xpcs-$(CONFIG_PCS_XPCS) := pcs-xpcs.o pcs-xpcs-nxp.o pcs-xpcs-regmap.o \
> + pcs-xpcs-plat.o pcs-xpcs-wx.o
>
> obj-$(CONFIG_PCS_XPCS) += pcs_xpcs.o
> obj-$(CONFIG_PCS_LYNX) += pcs-lynx.o
> diff --git a/drivers/net/pcs/pcs-xpcs-regmap.c b/drivers/net/pcs/pcs-xpcs-regmap.c
> new file mode 100644
> index 0000000000000..55cd05d09c7db
> --- /dev/null
> +++ b/drivers/net/pcs/pcs-xpcs-regmap.c
> @@ -0,0 +1,219 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Synopsys DesignWare XPCS regmap helpers
> + *
> + * Copyright (C) 2026 RISCstar Solutions.
> + * Copyright (C) 2024 Serge Semin
> + */
> +
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/mdio.h>
> +#include <linux/pcs/pcs-xpcs.h>
> +#include <linux/pcs/pcs-xpcs-regmap.h>
> +#include <linux/regmap.h>
> +
> +#include "pcs-xpcs.h"
> +
> +/* Page select register for the indirect MMIO CSRs access */
> +#define DW_VR_CSR_VIEWPORT 0xff
> +
> +struct dw_xpcs_regmap {
> + struct device *dev;
> + struct mii_bus *bus;
> + struct regmap *regmap;
> + bool reg_indir;
> +};
> +
> +static ptrdiff_t xpcs_regmap_addr_format(int dev, int reg)
> +{
> + return FIELD_PREP(0x1f0000, dev) | FIELD_PREP(0xffff, reg);
> +}
> +
> +static u16 xpcs_regmap_addr_page(ptrdiff_t csr)
> +{
> + return FIELD_GET(0x1fff00, csr);
> +}
> +
> +static ptrdiff_t xpcs_regmap_addr_offset(ptrdiff_t csr)
> +{
> + return FIELD_GET(0xff, csr);
> +}
> +
> +static int xpcs_regmap_read_reg_indirect(struct dw_xpcs_regmap *pxpcs, int dev,
> + int reg)
> +{
> + ptrdiff_t csr, ofs;
> + unsigned int val;
> + u16 page;
> + int res;
> +
> + csr = xpcs_regmap_addr_format(dev, reg);
> + page = xpcs_regmap_addr_page(csr);
> + ofs = xpcs_regmap_addr_offset(csr);
> +
> + res = regmap_write(pxpcs->regmap, DW_VR_CSR_VIEWPORT, page);
> + if (res < 0)
> + return res;
> +
> + res = regmap_read(pxpcs->regmap, ofs, &val);
> + if (res < 0)
> + return res;
> +
> + return val & 0xffff;
> +}
> +
> +static int xpcs_regmap_write_reg_indirect(struct dw_xpcs_regmap *pxpcs, int dev,
> + int reg, u16 val)
> +{
> + ptrdiff_t csr, ofs;
> + u16 page;
> + int res;
> +
> + csr = xpcs_regmap_addr_format(dev, reg);
> + page = xpcs_regmap_addr_page(csr);
> + ofs = xpcs_regmap_addr_offset(csr);
> +
> + res = regmap_write(pxpcs->regmap, DW_VR_CSR_VIEWPORT, page);
> + if (res < 0)
> + return res;
> +
> + return regmap_write(pxpcs->regmap, ofs, val);
> +}
> +
> +static int xpcs_regmap_read_reg_direct(struct dw_xpcs_regmap *pxpcs, int dev,
> + int reg)
> +{
> + unsigned int val;
> + ptrdiff_t csr;
> + int res;
> +
> + csr = xpcs_regmap_addr_format(dev, reg);
> + res = regmap_read(pxpcs->regmap, csr, &val);
> + if (res < 0)
> + return res;
> +
> + return val & 0xffff;
> +}
> +
> +static int xpcs_regmap_write_reg_direct(struct dw_xpcs_regmap *pxpcs, int dev,
> + int reg, u16 val)
> +{
> + ptrdiff_t csr = xpcs_regmap_addr_format(dev, reg);
> +
> + return regmap_write(pxpcs->regmap, csr, val);
> +}
> +
> +static int xpcs_regmap_read_c22(struct mii_bus *bus, int addr, int reg)
> +{
> + struct dw_xpcs_regmap *pxpcs = bus->priv;
> +
> + if (addr != 0)
> + return -ENODEV;
> +
> + if (pxpcs->reg_indir)
> + return xpcs_regmap_read_reg_indirect(pxpcs, MDIO_MMD_VEND2, reg);
> + else
> + return xpcs_regmap_read_reg_direct(pxpcs, MDIO_MMD_VEND2, reg);
> +}
> +
> +static int xpcs_regmap_write_c22(struct mii_bus *bus, int addr, int reg, u16 val)
> +{
> + struct dw_xpcs_regmap *pxpcs = bus->priv;
> +
> + if (addr != 0)
> + return -ENODEV;
> +
> + if (pxpcs->reg_indir)
> + return xpcs_regmap_write_reg_indirect(pxpcs, MDIO_MMD_VEND2, reg, val);
> + else
> + return xpcs_regmap_write_reg_direct(pxpcs, MDIO_MMD_VEND2, reg, val);
> +}
> +
> +static int xpcs_regmap_read_c45(struct mii_bus *bus, int addr, int dev, int reg)
> +{
> + struct dw_xpcs_regmap *pxpcs = bus->priv;
> +
> + if (addr != 0)
> + return -ENODEV;
> +
> + if (pxpcs->reg_indir)
> + return xpcs_regmap_read_reg_indirect(pxpcs, dev, reg);
> + else
> + return xpcs_regmap_read_reg_direct(pxpcs, dev, reg);
> +}
> +
> +static int xpcs_regmap_write_c45(struct mii_bus *bus, int addr, int dev,
> + int reg, u16 val)
> +{
> + struct dw_xpcs_regmap *pxpcs = bus->priv;
> +
> + if (addr != 0)
> + return -ENODEV;
> +
> + if (pxpcs->reg_indir)
> + return xpcs_regmap_write_reg_indirect(pxpcs, dev, reg, val);
> + else
> + return xpcs_regmap_write_reg_direct(pxpcs, dev, reg, val);
> +}
> +
> +static void devm_xpcs_regmap_destroy(void *data)
> +{
> + struct dw_xpcs *xpcs = data;
> +
> + xpcs_destroy(xpcs);
> +}
> +
> +struct dw_xpcs *devm_xpcs_regmap_register(struct device *dev,
> + const struct xpcs_regmap_config *config)
> +{
> + static atomic_t id = ATOMIC_INIT(-1);
> + struct dw_xpcs_regmap *pxpcs;
> + struct dw_xpcs *xpcs;
> + int ret;
> +
> + pxpcs = devm_kzalloc(dev, sizeof(*pxpcs), GFP_KERNEL);
> + if (!pxpcs)
> + return ERR_PTR(-ENOMEM);
> +
> + pxpcs->dev = dev;
> + pxpcs->regmap = config->regmap;
> + pxpcs->reg_indir = config->reg_indir;
Looking at the overall series, is there any reason for this flag ?
Looks like the reg_indir=false path isn't used at all in this series.
Maybe just drop it and let anyone add it back should the need arise ?
Maxime
^ permalink raw reply
* [PATCH 1/2] KVM: arm64: Replace memslot_is_logging() with kvm_slot_dirty_track_enabled()
From: Wei-Lin Chang @ 2026-06-05 15:32 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Gavin Shan, Wei-Lin Chang
In-Reply-To: <20260605153248.2412064-1-weilin.chang@arm.com>
When checking whether a memslot has dirty logging enabled, the
KVM_MEM_LOG_DIRTY_PAGES flag is the source of truth. Previously we were
using memslot_is_logging() which only tests dirty bitmap and did not
consider dirty ring. This was not detected because
KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP was introduced together with KVM
arm64 dirty ring, and users need to enable it to ensure dirty
information is not lost for the case of VGIC LPI/ITS table changes.
Fix this by using kvm_slot_dirty_track_enabled() instead which checks
KVM_MEM_LOG_DIRTY_PAGES.
Note that memslot_is_logging() also treats a memslot as not logging if
KVM_MEM_READONLY is set, hence a memslot with both dirty logging and
read only would be seen as not logging for memslot_is_logging(), but
logging for kvm_slot_dirty_track_enabled(). This allows a read only
mapping of size > PAGE_SIZE to be built when memslot_is_logging() is
used, leading to a better read performance compared to
kvm_slot_dirty_track_enabled(). However memslots that have both
KVM_MEM_LOG_DIRTY_PAGES and KVM_MEM_READONLY set do not really make
sense as dirty logging is essentially nop for a read only memslot, so
this shouldn't affect real workloads much.
Fixes: 9cb1096f8590 ("KVM: arm64: Enable ring-based dirty memory tracking")
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
It took me a long investigation to acquire the context needed to
understand this change, however the reason for this problem not being
detected is an educated guess. Please let me know if this is wrong or
if there are other issues, thanks!
arch/arm64/kvm/mmu.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 4da9281312eb..06c46124d3e7 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -161,11 +161,6 @@ static int kvm_mmu_split_huge_pages(struct kvm *kvm, phys_addr_t addr,
return ret;
}
-static bool memslot_is_logging(struct kvm_memory_slot *memslot)
-{
- return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
-}
-
/**
* kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8
* @kvm: pointer to kvm structure.
@@ -1748,7 +1743,7 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
{
short vma_shift;
- if (memslot_is_logging(s2fd->memslot)) {
+ if (kvm_slot_dirty_track_enabled(s2fd->memslot)) {
s2vi->max_map_size = PAGE_SIZE;
vma_shift = PAGE_SHIFT;
} else {
@@ -1953,7 +1948,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
*prot = KVM_PGTABLE_PROT_R;
if (s2vi->map_writable && (s2vi->device ||
- !memslot_is_logging(s2fd->memslot) ||
+ !kvm_slot_dirty_track_enabled(s2fd->memslot) ||
kvm_is_write_fault(s2fd->vcpu)))
*prot |= KVM_PGTABLE_PROT_W;
@@ -2084,7 +2079,7 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
* and a write fault needs to collapse a block entry into a table.
*/
memcache = get_mmu_memcache(s2fd->vcpu);
- if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
+ if (!perm_fault || (kvm_slot_dirty_track_enabled(s2fd->memslot) &&
kvm_is_write_fault(s2fd->vcpu))) {
ret = topup_mmu_memcache(s2fd->vcpu, memcache);
if (ret)
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] KVM: arm64: Remove superfluous aligning of gfn for dirty logging
From: Wei-Lin Chang @ 2026-06-05 15:32 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Gavin Shan, Wei-Lin Chang
In-Reply-To: <20260605153248.2412064-1-weilin.chang@arm.com>
Stage-2 mapping size is forced to PAGE_SIZE when dirty logging is
enabled for a memslot, therefore we don't need to align it down to
a possibly larger vma size or THP adjusted size, they won't happen.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/mmu.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 06c46124d3e7..d1f6ff7c2943 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2050,13 +2050,12 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
/*
* Mark the page dirty only if the fault is handled successfully,
- * making sure we adjust the canonical IPA if the mapping size has
- * been updated (via a THP upgrade, for example).
+ * mapping size is forced to PAGE_SIZE if dirty logging is enabled,
+ * so we don't have to adjust the canonical IPA here.
*/
if (writable && !ret) {
- phys_addr_t ipa = gfn_to_gpa(get_canonical_gfn(s2fd, s2vi));
- ipa &= ~(mapping_size - 1);
- mark_page_dirty_in_slot(kvm, s2fd->memslot, gpa_to_gfn(ipa));
+ gfn_t canonical_gfn = get_canonical_gfn(s2fd, s2vi);
+ mark_page_dirty_in_slot(kvm, s2fd->memslot, canonical_gfn);
}
if (ret != -EAGAIN)
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] KVM: arm64: Small dirty logging fixes/cleanups
From: Wei-Lin Chang @ 2026-06-05 15:32 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Gavin Shan, Wei-Lin Chang
Hi,
These are two minor fixes/cleanups I found when reading the code.
Although the diff are small the first patch has some implications.
Please view the patches for more detail.
Thanks,
Wei-Lin Chang (2):
KVM: arm64: Replace memslot_is_logging() with
kvm_slot_dirty_track_enabled()
KVM: arm64: Remove superfluous aligning of gfn for dirty logging
arch/arm64/kvm/mmu.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: dma: fsl-edma: add dma-channel-mask property description
From: Frank Li @ 2026-06-05 15:32 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Joy Zou, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Peng Fan, Ye Li, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <cf7b4c03-e1f4-4439-8077-2f8677bb2cea@gmail.com>
On Fri, Jun 05, 2026 at 03:44:23AM -0700, Laurentiu Mihalcea wrote:
>
>
> On 2/11/2026 1:28 AM, Joy Zou wrote:
> > Add documentation for the dma-channel-mask property in the fsl-edma
> > binding. This property uses an inverted bit definition: bit value 0
> > indicates the channel is available, while bit value 1 indicates
> > unavailable.
> >
> > That was already used widely for i.MX8, i.MX9. Correcting the definition
> > will break backward compatibility. This reversal only impacts the eDMA
> > dts node and driver, and doesn't impact DMA consumer. Therefore,
> > keep the inverted definition.
> >
> > Also add a note at the top of the binding to highlight this inverted
> > definition to prevent confusion.
> >
> > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> Hi,
>
> I believe this patch hasn't been picked up yet even though it's been ACK'd by one of the
> DT binding maintainers.
>
> Frank Li, can you please take it into your tree?
I ping vnod in irc yesterday, let wait for few days, if he don't pick, I
will pick it.
Frank
>
>
> Thanks,
> Laurentiu
^ permalink raw reply
* Re: [PATCH v4 5/5] phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP
From: Frank Li @ 2026-06-05 15:30 UTC (permalink / raw)
To: Xu Yang
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jun Li, linux-phy, imx, linux-arm-kernel,
linux-kernel, Xu Yang
In-Reply-To: <20260605-imx8mp-usb-phy-improvement-v4-5-b2ddf2f3862c@nxp.com>
On Fri, Jun 05, 2026 at 07:13:06PM +0800, Xu Yang wrote:
> From: Xu Yang <xu.yang_2@nxp.com>
>
> On i.MX8MP, the USB PHY has a dedicated power domain that was previously
> never powered off at runtime. With the introduction of runtime PM support,
> the power domain will be powered off if the device is runtime suspended,
> which breaks USB wakeup functionality.
Does it need depend on if device enable wakeup?
Frank
>
> To preserve wakeup functionality, mark the PHY power domain as runtime
> always-on for i.MX8MP platform. To limit the behavior to i.MX8MP, add a
> new imx95_usb_phy_ops for i.MX95 and introduce usb_phy_is_imx8mp() helper
> to identify i.MX8MP PHY instance.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
> ---
> Changes in v4:
> - no changes
> Changes in v3:
> - new patch
> ---
> drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index e24f46d7924b..c8b93ae2035f 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -9,6 +9,7 @@
> #include <linux/of.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> #include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> #include <linux/regmap.h>
> @@ -660,13 +661,20 @@ static const struct phy_ops imx8mp_usb_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static const struct phy_ops imx95_usb_phy_ops = {
> + .init = imx8mp_usb_phy_init,
> + .power_on = imx8mq_phy_power_on,
> + .power_off = imx8mq_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> static const struct of_device_id imx8mq_usb_phy_of_match[] = {
> {.compatible = "fsl,imx8mq-usb-phy",
> .data = &imx8mq_usb_phy_ops,},
> {.compatible = "fsl,imx8mp-usb-phy",
> .data = &imx8mp_usb_phy_ops,},
> {.compatible = "fsl,imx95-usb-phy",
> - .data = &imx8mp_usb_phy_ops,},
> + .data = &imx95_usb_phy_ops,},
> { }
> };
> MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
> @@ -679,6 +687,11 @@ static const struct regmap_config imx_cr_regmap_config = {
> .max_register = 0x7,
> };
>
> +static bool usb_phy_is_imx8mp(const void *data)
> +{
> + return data == &imx8mp_usb_phy_ops;
> +}
> +
> static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> {
> struct phy_provider *phy_provider;
> @@ -723,6 +736,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (!phy_ops)
> return -EINVAL;
>
> + if (usb_phy_is_imx8mp(phy_ops))
> + dev_pm_genpd_rpm_always_on(dev, true);
> +
> imx_phy->phy = devm_phy_create(dev, NULL, phy_ops);
> if (IS_ERR(imx_phy->phy))
> return PTR_ERR(imx_phy->phy);
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: Replace scratch PTE atomically when allocating arena pages
From: patchwork-bot+netdevbpf @ 2026-06-05 15:30 UTC (permalink / raw)
To: Tejun Heo
Cc: void, arighi, changwoo, ast, andrii, daniel, martin.lau, memxor,
peterz, catalin.marinas, will, tglx, mingo, bp, dave.hansen, akpm,
david, rppt, emil, sched-ext, bpf, x86, linux-arm-kernel,
linux-mm, linux-kernel
In-Reply-To: <20260601183728.1800490-1-tj@kernel.org>
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Mon, 1 Jun 2026 08:37:28 -1000 you wrote:
> apply_range_set_cb() maps the pages for a new arena allocation and returned
> -EBUSY when the target PTE was already populated. Kernel-fault recovery
> leaves the per-arena scratch page in unallocated arena PTEs, so a later
> bpf_arena_alloc_pages() over such a page hits that -EBUSY, and every
> subsequent allocation of it fails the same way. Allocation must install the
> real page over scratch instead.
>
> [...]
Here is the summary with links:
- [bpf-next] bpf: Replace scratch PTE atomically when allocating arena pages
https://git.kernel.org/bpf/bpf-next/c/f64c723741c9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4 4/5] phy: fsl-imx8mq-usb: add control register regmap
From: Frank Li @ 2026-06-05 15:28 UTC (permalink / raw)
To: Xu Yang
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jun Li, linux-phy, imx, linux-arm-kernel,
linux-kernel, Xu Yang
In-Reply-To: <20260605-imx8mp-usb-phy-improvement-v4-4-b2ddf2f3862c@nxp.com>
On Fri, Jun 05, 2026 at 07:13:05PM +0800, Xu Yang wrote:
> From: Xu Yang <xu.yang_2@nxp.com>
>
> The CR port is a simple 16-bit data/address parallel port that is
> accessed through 32-bit MMIO registers for on-chip access to the
> control registers inside the USB 3.0 femtoPHY. Add control register
> regmap and export these registers by debugfs to help PHY's diagnostic.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> Changes in v4:
> - improve commit message as Haibo's suggestion
> Changes in v3:
> - drop Frank's tag because it includes other changes
> - new patch
> ---
> drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 27aa696f5dd4..e24f46d7924b 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -1,5 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0+
> -/* Copyright (c) 2017 NXP. */
> +/* Copyright 2017-2026 NXP. */
>
> #include <linux/bitfield.h>
> #include <linux/clk.h>
> @@ -11,6 +11,7 @@
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/regmap.h>
> #include <linux/usb/typec_mux.h>
>
> #define PHY_CTRL0 0x0
> @@ -56,6 +57,8 @@
> #define PHY_CTRL6_ALT_CLK_EN BIT(1)
> #define PHY_CTRL6_ALT_CLK_SEL BIT(0)
>
> +#define PHY_CRCTL 0x30
> +
> #define PHY_TUNE_DEFAULT 0xffffffff
>
> #define TCA_CLK_RST 0x00
> @@ -119,6 +122,7 @@ struct imx8mq_usb_phy {
> void __iomem *base;
> struct regulator *vbus;
> struct tca_blk *tca;
> + struct regmap *cr_regmap;
> u32 pcs_tx_swing_full;
> u32 pcs_tx_deemph_3p5db;
> u32 tx_vref_tune;
> @@ -667,6 +671,14 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
>
> +static const struct regmap_config imx_cr_regmap_config = {
> + .name = "cr",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0x7,
> +};
> +
> static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> {
> struct phy_provider *phy_provider;
> @@ -696,6 +708,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (IS_ERR(imx_phy->base))
> return PTR_ERR(imx_phy->base);
>
> + imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
> + &imx_cr_regmap_config);
> + if (IS_ERR(imx_phy->cr_regmap)) {
> + dev_warn(dev, "Fail to init debug register regmap\n");
> + imx_phy->cr_regmap = NULL;
> + }
> +
> ret = devm_pm_runtime_set_active_enabled(dev);
> if (ret)
> return dev_err_probe(dev, ret, "Failed to enable runtime PM\n");
> @@ -731,6 +750,9 @@ static int imx8mq_usb_phy_runtime_suspend(struct device *dev)
> {
> struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
>
> + if (imx_phy->cr_regmap)
> + regcache_cache_only(imx_phy->cr_regmap, true);
> +
I think this common problem, is possible to change
regmap_read_debugfs(), let it call runtime_pm_get(), there are already
have runtime_pm in regmap field.
So you debug fs always to get update value, instead cached value?
Frank
> clk_disable_unprepare(imx_phy->alt_clk);
> clk_disable_unprepare(imx_phy->clk);
>
> @@ -752,6 +774,9 @@ static int imx8mq_usb_phy_runtime_resume(struct device *dev)
> return ret;
> }
>
> + if (imx_phy->cr_regmap)
> + regcache_cache_only(imx_phy->cr_regmap, false);
> +
> return 0;
> }
>
>
> --
> 2.34.1
>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: arm for v7.2 (#1)
From: Gregory CLEMENT @ 2026-06-05 15:27 UTC (permalink / raw)
To: Arnd Bergmann, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
Hi,
Here is the first pull request for arm for mvebu for v7.2.
Gregory
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-arm-7.2-1
for you to fetch changes up to bf4ad3be0679460585ab17dbcf298d085cf23429:
ARM: orion5x: update board check in mss2_pci_init() to use the DT (2026-06-01 10:26:30 +0200)
----------------------------------------------------------------
mvebu arm for 7.2 (part 1)
Orion5x: Replace machine_is_mss2() with of_machine_is_compatible() in mss2_pci_init()
mvebu_v5_defconfig: Remove stale MACH_LINKSTATION_LSCHL reference
Armada 370: Simplify of_node_put calls and drop redundant NULL checks
----------------------------------------------------------------
Ethan Nelson-Moore (2):
arm: mvebu_v5_defconfig: remove stale MACH_LINKSTATION_LSCHL reference
ARM: orion5x: update board check in mss2_pci_init() to use the DT
Martin Kaiser (2):
ARM: mvebu: drop unnecessary NULL check
ARM: mvebu: simplify of_node_put calls
arch/arm/configs/mvebu_v5_defconfig | 1 -
arch/arm/mach-mvebu/coherency.c | 9 ++-------
arch/arm/mach-orion5x/board-mss2.c | 4 ++--
3 files changed, 4 insertions(+), 10 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v7.2 (#1)
From: Gregory CLEMENT @ 2026-06-05 15:20 UTC (permalink / raw)
To: Arnd Bergmann, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
Hi,
Here is the first pull request for dt64 for mvebu for v7.2.
Gregory
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt64-7.2-1
for you to fetch changes up to 5dd98e0389545b302b0c46cef2264b5b09c01677:
arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent (2026-06-01 10:04:36 +0200)
----------------------------------------------------------------
mvebu dt64 for 7.2 (part 1)
Mark EIP97 as dma-coherent for Armada 3720
----------------------------------------------------------------
Aleksander Jan Bajkowski (1):
arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* Re: [PATCH v4 3/5] phy: fsl-imx8mq-usb: add runtime PM support
From: Frank Li @ 2026-06-05 15:14 UTC (permalink / raw)
To: Xu Yang
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jun Li, linux-phy, imx, linux-arm-kernel,
linux-kernel, Xu Yang
In-Reply-To: <20260605-imx8mp-usb-phy-improvement-v4-3-b2ddf2f3862c@nxp.com>
On Fri, Jun 05, 2026 at 07:13:04PM +0800, Xu Yang wrote:
> From: Xu Yang <xu.yang_2@nxp.com>
>
> Add runtime PM to ensure the PHY is properly powered and clocked during
> register access, preventing potential system hangs.
>
> It guards register access in the following scenarios:
> - PHY operations: init() and power_on/off() callbacks are guarded by
> phy core
> - Type-C orientation switching when PHY/Controller are suspended which
> needs explicitly care
> - Future PHY control port register regmap debugfs access
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
> ---
> Changes in v4:
> - replace guard() with PM_RUNTIME_ACQUIRE()
> Changes in v3:
> - new patch
> ---
> drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 62 +++++++++++++++++++++---------
> 1 file changed, 43 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 591ddf346061..27aa696f5dd4 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -9,6 +9,7 @@
> #include <linux/of.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> #include <linux/usb/typec_mux.h>
>
> @@ -136,17 +137,15 @@ static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
> {
> struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
> struct tca_blk *tca = imx_phy->tca;
> - int ret;
>
> if (tca->orientation == orientation)
> return 0;
>
> - ret = clk_prepare_enable(imx_phy->clk);
> - if (ret)
> - return ret;
> + PM_RUNTIME_ACQUIRE(&imx_phy->phy->dev, pm);
> + if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> + return -ENXIO;
>
> tca_blk_orientation_set(tca, orientation);
> - clk_disable_unprepare(imx_phy->clk);
>
> return 0;
> }
> @@ -620,16 +619,6 @@ static int imx8mq_phy_power_on(struct phy *phy)
> if (ret)
> return ret;
>
> - ret = clk_prepare_enable(imx_phy->clk);
> - if (ret)
> - return ret;
> -
> - ret = clk_prepare_enable(imx_phy->alt_clk);
> - if (ret) {
> - clk_disable_unprepare(imx_phy->clk);
> - return ret;
> - }
> -
> /* Disable rx term override */
> value = readl(imx_phy->base + PHY_CTRL6);
> value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
> @@ -648,8 +637,6 @@ static int imx8mq_phy_power_off(struct phy *phy)
> value |= PHY_CTRL6_RXTERM_OVERRIDE_SEL;
> writel(value, imx_phy->base + PHY_CTRL6);
>
> - clk_disable_unprepare(imx_phy->alt_clk);
> - clk_disable_unprepare(imx_phy->clk);
> regulator_disable(imx_phy->vbus);
>
> return 0;
> @@ -686,6 +673,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct imx8mq_usb_phy *imx_phy;
> const struct phy_ops *phy_ops;
> + int ret;
>
> imx_phy = devm_kzalloc(dev, sizeof(*imx_phy), GFP_KERNEL);
> if (!imx_phy)
> @@ -693,13 +681,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, imx_phy);
>
> - imx_phy->clk = devm_clk_get(dev, "phy");
> + imx_phy->clk = devm_clk_get_enabled(dev, "phy");
> if (IS_ERR(imx_phy->clk)) {
> dev_err(dev, "failed to get imx8mq usb phy clock\n");
> return PTR_ERR(imx_phy->clk);
> }
>
> - imx_phy->alt_clk = devm_clk_get_optional(dev, "alt");
> + imx_phy->alt_clk = devm_clk_get_optional_enabled(dev, "alt");
when driver remove, devm will disable clock, which may cause refcound
wrong if device already suspend by runtime pm
> if (IS_ERR(imx_phy->alt_clk))
> return dev_err_probe(dev, PTR_ERR(imx_phy->alt_clk),
> "Failed to get alt clk\n");
> @@ -708,6 +696,10 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (IS_ERR(imx_phy->base))
> return PTR_ERR(imx_phy->base);
>
> + ret = devm_pm_runtime_set_active_enabled(dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to enable runtime PM\n");
> +
You have not set auto suspend, so runtime_suspend will never entry.
Frank
> phy_ops = of_device_get_match_data(dev);
> if (!phy_ops)
> return -EINVAL;
> @@ -735,11 +727,43 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> return PTR_ERR_OR_ZERO(phy_provider);
> }
>
> +static int imx8mq_usb_phy_runtime_suspend(struct device *dev)
> +{
> + struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(imx_phy->alt_clk);
> + clk_disable_unprepare(imx_phy->clk);
> +
> + return 0;
> +}
> +
> +static int imx8mq_usb_phy_runtime_resume(struct device *dev)
> +{
> + struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_prepare_enable(imx_phy->clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(imx_phy->alt_clk);
> + if (ret) {
> + clk_disable_unprepare(imx_phy->clk);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static DEFINE_RUNTIME_DEV_PM_OPS(imx8mq_usb_phy_pm_ops, imx8mq_usb_phy_runtime_suspend,
> + imx8mq_usb_phy_runtime_resume, NULL);
> +
> static struct platform_driver imx8mq_usb_phy_driver = {
> .probe = imx8mq_usb_phy_probe,
> .driver = {
> .name = "imx8mq-usb-phy",
> .of_match_table = imx8mq_usb_phy_of_match,
> + .pm = pm_ptr(&imx8mq_usb_phy_pm_ops),
> .suppress_bind_attrs = true,
> }
> };
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Frank Li @ 2026-06-05 15:11 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260605113621.1479-2-laurentiumihalcea111@gmail.com>
On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>
> The names of the carveout regions are derived using the names of the
> reserved memory devicetree nodes, which are referenced using the
> "memory-region" property. This adds a restriction on the names of said
> devicetree nodes, often bearing specific names such as: "vdevbuffer",
> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> specification's recommendation, which states that the devicetree node
> names should be generic.
Addition notes for dt reviever:
binding check can't restrict memory node naming because no specific
compatible string for it. So there are hidden ABI by node name here.
use memory-region-name can eliminate such hidden ABI.
>
> Fix this by documenting an additional, optional property:
> "memory-region-names". This way, the carveout names can use the values
> passed via "memory-region-names", while keeping the devicetree node
> names of the reserved memory regions generic.
>
> There are no restrictions imposed on the values of the strings passed via
> the new property since the software allows any name to be used, with some
> names (e.g. "vdev%dbuffer", "vdev%dvring%d", "rsc-table") bearing a
> special meaning.
>
> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index c18f71b64889..8e3e6676a95e 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -62,6 +62,10 @@ properties:
> minItems: 1
> maxItems: 32
>
> + memory-region-names:
> + minItems: 1
> + maxItems: 32
> +
> power-domains:
> minItems: 2
> maxItems: 8
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2] phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing pm_runtime_disable() on probe error path
From: Frank Li @ 2026-06-05 15:04 UTC (permalink / raw)
To: Felix Gu
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Liu Ying, linux-phy, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260605-lvds-v2-1-3ce7539d1104@gmail.com>
On Fri, Jun 05, 2026 at 07:57:20PM +0800, Felix Gu wrote:
> If mixel_lvds_phy_reset() fails in probe after pm_runtime_enable(),
> the function returns directly without calling pm_runtime_disable(),
> leaving runtime PM permanently enabled for the device.
>
> Fix this by using devm_pm_runtime_enable() so that cleanup is
> automatic on any probe failure or driver unbind. This also allows
> removing the manual err label and the .remove callback.
>
> Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support")
> Acked-by: Liu Ying <victor.liu@nxp.com>
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Changes in v2:
> - Change the patch's subject prefix requested by Liu Ying.
> - Add Liu Ying's Acked-by.
> - Link to v1: https://patch.msgid.link/20260604-lvds-v1-1-b8e1ff1bdee7@gmail.com
>
> To: Vinod Koul <vkoul@kernel.org>
> To: Neil Armstrong <neil.armstrong@linaro.org>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> To: Pengutronix Kernel Team <kernel@pengutronix.de>
> To: Fabio Estevam <festevam@gmail.com>
> To: Liu Ying <victor.liu@nxp.com>
> Cc: linux-phy@lists.infradead.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c | 24 +++++++-----------------
> 1 file changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> index ece357443521..c662f91e598c 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> @@ -345,7 +345,9 @@ static int mixel_lvds_phy_probe(struct platform_device *pdev)
>
> dev_set_drvdata(dev, priv);
>
> - pm_runtime_enable(dev);
> + ret = devm_pm_runtime_enable(dev);
> + if (ret)
> + return ret;
>
> ret = mixel_lvds_phy_reset(dev);
> if (ret) {
> @@ -355,17 +357,15 @@ static int mixel_lvds_phy_probe(struct platform_device *pdev)
>
> for (i = 0; i < PHY_NUM; i++) {
> lvds_phy = devm_kzalloc(dev, sizeof(*lvds_phy), GFP_KERNEL);
> - if (!lvds_phy) {
> - ret = -ENOMEM;
> - goto err;
> - }
> + if (!lvds_phy)
> + return -ENOMEM;
>
> phy = devm_phy_create(dev, NULL, &mixel_lvds_phy_ops);
> if (IS_ERR(phy)) {
> ret = PTR_ERR(phy);
> dev_err(dev, "failed to create PHY for channel%d: %d\n",
> i, ret);
> - goto err;
> + return ret;
> }
>
> lvds_phy->phy = phy;
> @@ -379,19 +379,10 @@ static int mixel_lvds_phy_probe(struct platform_device *pdev)
> if (IS_ERR(phy_provider)) {
> ret = PTR_ERR(phy_provider);
> dev_err(dev, "failed to register PHY provider: %d\n", ret);
> - goto err;
> + return ret;
> }
>
> return 0;
> -err:
> - pm_runtime_disable(dev);
> -
> - return ret;
> -}
> -
> -static void mixel_lvds_phy_remove(struct platform_device *pdev)
> -{
> - pm_runtime_disable(&pdev->dev);
> }
>
> static int __maybe_unused mixel_lvds_phy_runtime_suspend(struct device *dev)
> @@ -432,7 +423,6 @@ MODULE_DEVICE_TABLE(of, mixel_lvds_phy_of_match);
>
> static struct platform_driver mixel_lvds_phy_driver = {
> .probe = mixel_lvds_phy_probe,
> - .remove = mixel_lvds_phy_remove,
> .driver = {
> .pm = &mixel_lvds_phy_pm_ops,
> .name = "mixel-lvds-phy",
>
> ---
> base-commit: a225caacc36546a09586e3ece36c0313146e7da9
> change-id: 20260604-lvds-d67cb619df17
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
>
^ permalink raw reply
* Re: [PATCH v14 23/44] arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE
From: Steven Price @ 2026-06-05 15:02 UTC (permalink / raw)
To: Aneesh Kumar K.V, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, 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, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <yq5ay0hfspok.fsf@kernel.org>
On 19/05/2026 10:40, Aneesh Kumar K.V wrote:
> Steven Price <steven.price@arm.com> writes:
>
> ...
>
>> +void kvm_realm_unmap_range(struct kvm *kvm, unsigned long start,
>> + unsigned long size, bool unmap_private,
>> + bool may_block)
>> +{
>> + unsigned long end = start + size;
>> + struct realm *realm = &kvm->arch.realm;
>> +
>> + if (!kvm_realm_is_created(kvm))
>> + return;
>> +
>> + end = min(BIT(realm->ia_bits - 1), end);
>> +
>> + realm_unmap_shared_range(kvm, start, end, may_block);
>> + if (unmap_private)
>> + realm_unmap_private_range(kvm, start, end, may_block);
>> +}
>> +
>
> kvm_gmem_invalidate_begin() indicates a private-only invalidation. How
> is that supported?
Because we treat the private and shared spaces are aliasing we don't
really support a "private-only" invalidation. So the shared space will
be invalidated as well. Something has gone wrong if we've ended up with
the 'same' IPA being used in both the private and shared spaces.
Private has to be treated slightly specially because removing a private
mapping is observable by the guest (the page can't be reinserted without
the guest agreeing and the contents being wiped). For shared mappings
the page can simply be refaulted.
That said, I'll look into Wei-Lin's suggestion to use
kvm_gfn_range_filter which would allow all three combinations of
private-only, shared-only and private+shared.
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v14 22/44] arm64: RMI: Handle realm enter/exit
From: Steven Price @ 2026-06-05 15:02 UTC (permalink / raw)
To: Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <e6cb82fc-a8be-49d3-8fa3-0107c8ab97f7@redhat.com>
On 28/05/2026 05:38, Gavin Shan wrote:
> Hi Steve,
>
> On 5/13/26 11:17 PM, Steven Price wrote:
>> Entering a realm is done using a SMC call to the RMM. On exit the
>> exit-codes need to be handled slightly differently to the normal KVM
>> path so define our own functions for realm enter/exit and hook them
>> in if the guest is a realm guest.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> Reviewed-by: Gavin Shan <gshan@redhat.com>
>> ---
>> Chanegs since v13:
>> * The RMM is now required to provide an ESR value with the correct
>> information to emulate MMIO, so we no longer need to hardcode 0s in
>> rec_exit_sys_reg().
>> * The PSCI changes mean that there is a potential race when turning on
>> a VCPU which can cause a RMI_ERROR_REC return. Exit to user space
>> with -EAGAIN in this case.
>> Changes since v12:
>> * Call guest_state_{enter,exit}_irqoff() around rmi_rec_enter().
>> * Add handling of the IRQ exception case where IRQs need to be briefly
>> enabled before exiting guest timing.
>> Changes since v8:
>> * Introduce kvm_rec_pre_enter() called before entering an atomic
>> section to handle operations that might require memory allocation
>> (specifically completing a RIPAS change introduced in a later patch).
>> * Updates to align with upstream changes to hpfar_el2 which now
>> (ab)uses
>> HPFAR_EL2_NS as a valid flag.
>> * Fix exit reason when racing with PSCI shutdown to return
>> KVM_EXIT_SHUTDOWN rather than KVM_EXIT_UNKNOWN.
>> Changes since v7:
>> * A return of 0 from kvm_handle_sys_reg() doesn't mean the register has
>> been read (although that can never happen in the current code). Tidy
>> up the condition to handle any future refactoring.
>> Changes since v6:
>> * Use vcpu_err() rather than pr_err/kvm_err when there is an associated
>> vcpu to the error.
>> * Return -EFAULT for KVM_EXIT_MEMORY_FAULT as per the documentation for
>> this exit type.
>> * Split code handling a RIPAS change triggered by the guest to the
>> following patch.
>> Changes since v5:
>> * For a RIPAS_CHANGE request from the guest perform the actual RIPAS
>> change on next entry rather than immediately on the exit. This allows
>> the VMM to 'reject' a RIPAS change by refusing to continue
>> scheduling.
>> Changes since v4:
>> * Rename handle_rme_exit() to handle_rec_exit()
>> * Move the loop to copy registers into the REC enter structure from the
>> to rec_exit_handlers callbacks to kvm_rec_enter(). This fixes a bug
>> where the handler exits to user space and user space wants to modify
>> the GPRS.
>> * Some code rearrangement in rec_exit_ripas_change().
>> Changes since v2:
>> * realm_set_ipa_state() now provides an output parameter for the
>> top_iap that was changed. Use this to signal the VMM with the correct
>> range that has been transitioned.
>> * Adapt to previous patch changes.
>> ---
>> arch/arm64/include/asm/kvm_rmi.h | 4 +
>> arch/arm64/kvm/Makefile | 2 +-
>> arch/arm64/kvm/arm.c | 26 ++++-
>> arch/arm64/kvm/rmi-exit.c | 186 +++++++++++++++++++++++++++++++
>> arch/arm64/kvm/rmi.c | 42 +++++++
>> 5 files changed, 254 insertions(+), 6 deletions(-)
>> create mode 100644 arch/arm64/kvm/rmi-exit.c
>>
>> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/
>> asm/kvm_rmi.h
>> index d99bf4fc3c39..feb534a6678e 100644
>> --- a/arch/arm64/include/asm/kvm_rmi.h
>> +++ b/arch/arm64/include/asm/kvm_rmi.h
>> @@ -84,6 +84,10 @@ void kvm_destroy_realm(struct kvm *kvm);
>> void kvm_realm_destroy_rtts(struct kvm *kvm);
>> void kvm_destroy_rec(struct kvm_vcpu *vcpu);
>> +int kvm_rec_enter(struct kvm_vcpu *vcpu);
>> +int kvm_rec_pre_enter(struct kvm_vcpu *vcpu);
>> +int handle_rec_exit(struct kvm_vcpu *vcpu, int rec_run_status);
>> +
>> static inline bool kvm_realm_is_private_address(struct realm *realm,
>> unsigned long addr)
>> {
>> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> index ed3cf30eb06e..4a2d52fdb6a2 100644
>> --- a/arch/arm64/kvm/Makefile
>> +++ b/arch/arm64/kvm/Makefile
>> @@ -16,7 +16,7 @@ CFLAGS_handle_exit.o += -Wno-override-init
>> kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
>> inject_fault.o va_layout.o handle_exit.o config.o \
>> guest.o debug.o reset.o sys_regs.o stacktrace.o \
>> - vgic-sys-reg-v3.o fpsimd.o pkvm.o rmi.o \
>> + vgic-sys-reg-v3.o fpsimd.o pkvm.o rmi.o rmi-exit.o \
>> arch_timer.o trng.o vmid.o emulate-nested.o nested.o at.o \
>> vgic/vgic.o vgic/vgic-init.o \
>> vgic/vgic-irqfd.o vgic/vgic-v2.o \
>> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
>> index 21d9dfdb1ea0..ed88a203b892 100644
>> --- a/arch/arm64/kvm/arm.c
>> +++ b/arch/arm64/kvm/arm.c
>> @@ -1331,6 +1331,9 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> if (ret > 0)
>> ret = check_vcpu_requests(vcpu);
>> + if (ret > 0 && vcpu_is_rec(vcpu))
>> + ret = kvm_rec_pre_enter(vcpu);
>> +
>> /*
>> * Preparing the interrupts to be injected also
>> * involves poking the GIC, which must be done in a
>> @@ -1378,7 +1381,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> trace_kvm_entry(*vcpu_pc(vcpu));
>> guest_timing_enter_irqoff();
>> - ret = kvm_arm_vcpu_enter_exit(vcpu);
>> + if (vcpu_is_rec(vcpu))
>> + ret = kvm_rec_enter(vcpu);
>> + else
>> + ret = kvm_arm_vcpu_enter_exit(vcpu);
>> vcpu->mode = OUTSIDE_GUEST_MODE;
>> vcpu->stat.exits++;
>> @@ -1424,7 +1430,9 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> * context synchronization event) is necessary to ensure that
>> * pending interrupts are taken.
>> */
>> - if (ARM_EXCEPTION_CODE(ret) == ARM_EXCEPTION_IRQ) {
>> + if (ARM_EXCEPTION_CODE(ret) == ARM_EXCEPTION_IRQ ||
>> + (vcpu_is_rec(vcpu) &&
>> + vcpu->arch.rec.run->exit.exit_reason == RMI_EXIT_IRQ)) {
>> local_irq_enable();
>> isb();
>> local_irq_disable();
>
> The condition could be posssibly imprecise because ARM_EXCEPTION_CODE(ret)
> can be ARM_EXCEPTION_IRQ even for a REC. So the precise condition would be:
>
> if ((!vcpu_is_rec(vcpu) && ARM_EXCEPTION_CODE(ret) ==
> ARM_EXCEPTION_IRQ) ||
> (vcpu_is_rec(vcpu) && vcpu->arch.rec.run->exit.exit_reason
> == RMI_EXIT_IRQ)) {
Good point - I guess this wouldn't have shown up in testing because
there's no harm (other than performance) in the ISB.
>> @@ -1436,8 +1444,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> trace_kvm_exit(ret, kvm_vcpu_trap_get_class(vcpu),
>> *vcpu_pc(vcpu));
>> - /* Exit types that need handling before we can be preempted */
>> - handle_exit_early(vcpu, ret);
>> + if (!vcpu_is_rec(vcpu)) {
>> + /*
>> + * Exit types that need handling before we can be
>> + * preempted
>> + */
>> + handle_exit_early(vcpu, ret);
>> + }
>> kvm_nested_sync_hwstate(vcpu);
>> @@ -1462,7 +1475,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu
>> *vcpu)
>> ret = ARM_EXCEPTION_IL;
>> }
>> - ret = handle_exit(vcpu, ret);
>> + if (vcpu_is_rec(vcpu))
>> + ret = handle_rec_exit(vcpu, ret);
>> + else
>> + ret = handle_exit(vcpu, ret);
>> }
>> /* Tell userspace about in-kernel device output levels */
>> diff --git a/arch/arm64/kvm/rmi-exit.c b/arch/arm64/kvm/rmi-exit.c
>> new file mode 100644
>> index 000000000000..e7c51b6cf6ce
>> --- /dev/null
>> +++ b/arch/arm64/kvm/rmi-exit.c
>> @@ -0,0 +1,186 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2023 ARM Ltd.
>> + */
>> +
>> +#include <linux/kvm_host.h>
>> +#include <kvm/arm_hypercalls.h>
>> +#include <kvm/arm_psci.h>
>> +
>> +#include <asm/rmi_smc.h>
>> +#include <asm/kvm_emulate.h>
>> +#include <asm/kvm_rmi.h>
>> +#include <asm/kvm_mmu.h>
>> +
>> +typedef int (*exit_handler_fn)(struct kvm_vcpu *vcpu);
>> +
>> +static int rec_exit_reason_notimpl(struct kvm_vcpu *vcpu)
>> +{
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> +
>> + vcpu_err(vcpu, "Unhandled exit reason from realm (ESR: %#llx)\n",
>> + rec->run->exit.esr);
>> + return -ENXIO;
>> +}
>> +
>
> s/rec->run->exit.esr/kvm_vcpu_get_esr(vcpu), rec->run->exit.esr has been
> copied to the storage space pointed by kvm_vcpu_get_esr() in its caller.
Ack
>> +static int rec_exit_sync_dabt(struct kvm_vcpu *vcpu)
>> +{
>> + return kvm_handle_guest_abort(vcpu);
>> +}
>> +
>> +static int rec_exit_sync_iabt(struct kvm_vcpu *vcpu)
>> +{
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> +
>> + vcpu_err(vcpu, "Unhandled instruction abort (ESR: %#llx).\n",
>> + rec->run->exit.esr);
>> + return -ENXIO;
>> +}
>> +
>
> s/rec->run->exit.esr/kvm_vcpu_get_esr(vcpu)
Ack
>> +static int rec_exit_sys_reg(struct kvm_vcpu *vcpu)
>> +{
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> + unsigned long esr = kvm_vcpu_get_esr(vcpu);
>> + int rt = kvm_vcpu_sys_get_rt(vcpu);
>> + bool is_write = (esr & ESR_ELx_SYS64_ISS_DIR_MASK) ==
>> ESR_ELx_SYS64_ISS_DIR_WRITE;
>> + int ret;
>> +
>> + if (is_write)
>> + vcpu_set_reg(vcpu, rt, rec->run->exit.gprs[rt]);
>> +
>> + ret = kvm_handle_sys_reg(vcpu);
>> + if (!is_write)
>> + rec->run->enter.gprs[rt] = vcpu_get_reg(vcpu, rt);
>> +
>> + return ret;
>> +}
>> +
>> +static exit_handler_fn rec_exit_handlers[] = {
>> + [0 ... ESR_ELx_EC_MAX] = rec_exit_reason_notimpl,
>> + [ESR_ELx_EC_SYS64] = rec_exit_sys_reg,
>> + [ESR_ELx_EC_DABT_LOW] = rec_exit_sync_dabt,
>> + [ESR_ELx_EC_IABT_LOW] = rec_exit_sync_iabt
>> +};
>> +
>> +static int rec_exit_psci(struct kvm_vcpu *vcpu)
>> +{
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> + int i;
>> +
>> + for (i = 0; i < REC_RUN_GPRS; i++)
>> + vcpu_set_reg(vcpu, i, rec->run->exit.gprs[i]);
>> +
>> + return kvm_smccc_call_handler(vcpu);
>> +}
>> +
>> +static int rec_exit_ripas_change(struct kvm_vcpu *vcpu)
>> +{
>> + struct kvm *kvm = vcpu->kvm;
>> + struct realm *realm = &kvm->arch.realm;
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> + unsigned long base = rec->run->exit.ripas_base;
>> + unsigned long top = rec->run->exit.ripas_top;
>> + unsigned long ripas = rec->run->exit.ripas_value;
>> +
>> + if (!kvm_realm_is_private_address(realm, base) ||
>> + !kvm_realm_is_private_address(realm, top - 1)) {
>> + vcpu_err(vcpu, "Invalid RIPAS_CHANGE for %#lx - %#lx, ripas:
>> %#lx\n",
>> + base, top, ripas);
>> + /* Set RMI_REJECT bit */
>> + rec->run->enter.flags = REC_ENTER_FLAG_RIPAS_RESPONSE;
>> + return -EINVAL;
>> + }
>
> I doubt if the flag (REC_ENTER_FLAG_RIPAS_RESPONSE) will be handed over
> to RMM
> since the negative return value forces we're exiting to VMM like QEMU where
> how this problematic case can be handled is TBD.
It's perhaps a bit non-obvious but enter.flags is cleared on the exit.
So even if we return to the VMM the flags will be kept for the next entry.
I agree it is somewhat TBD exactly how this case should be handled -
there's a bunch of "VM did something stupid" cases like this that are a
bit problematic.
Thanks,
Steve
>> +
>> + /* Exit to VMM, the actual RIPAS change is done on next entry */
>> + kvm_prepare_memory_fault_exit(vcpu, base, top - base, false, false,
>> + ripas == RMI_RAM);
>> +
>> + /*
>> + * KVM_EXIT_MEMORY_FAULT requires an return code of -EFAULT, see the
>> + * API documentation
>> + */
>> + return -EFAULT;
>> +}
>> +
>> +static void update_arch_timer_irq_lines(struct kvm_vcpu *vcpu)
>> +{
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> +
>> + __vcpu_assign_sys_reg(vcpu, CNTV_CTL_EL0, rec->run->exit.cntv_ctl);
>> + __vcpu_assign_sys_reg(vcpu, CNTV_CVAL_EL0, rec->run-
>> >exit.cntv_cval);
>> + __vcpu_assign_sys_reg(vcpu, CNTP_CTL_EL0, rec->run->exit.cntp_ctl);
>> + __vcpu_assign_sys_reg(vcpu, CNTP_CVAL_EL0, rec->run-
>> >exit.cntp_cval);
>> +
>> + kvm_realm_timers_update(vcpu);
>> +}
>> +
>> +/*
>> + * Return > 0 to return to guest, < 0 on error, 0 (and set
>> exit_reason) on
>> + * proper exit to userspace.
>> + */
>> +int handle_rec_exit(struct kvm_vcpu *vcpu, int rec_run_ret)
>> +{
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> + u8 esr_ec = ESR_ELx_EC(rec->run->exit.esr);
>> + unsigned long status, index;
>> +
>> + status = RMI_RETURN_STATUS(rec_run_ret);
>> + index = RMI_RETURN_INDEX(rec_run_ret);
>> +
>> + /*
>> + * If a PSCI_SYSTEM_OFF request raced with a vcpu executing, we
>> might
>> + * see the following status code and index indicating an attempt
>> to run
>> + * a REC when the RD state is SYSTEM_OFF. In this case, we just
>> need to
>> + * return to user space which can deal with the system event or
>> will try
>> + * to run the KVM VCPU again, at which point we will no longer
>> attempt
>> + * to enter the Realm because we will have a sleep request
>> pending on
>> + * the VCPU as a result of KVM's PSCI handling.
>> + */
>> + if (status == RMI_ERROR_REALM) {
>> + vcpu->run->exit_reason = KVM_EXIT_SHUTDOWN;
>> + return 0;
>> + }
>> +
>> + /*
>> + * If a VCPU has been turned on, but the REC state hasn't been
>> updated
>> + * we may experience RMI_ERROR_REC. Exit to the userspace with -
>> EAGAIN
>> + * for a retry.
>> + */
>> + if (status == RMI_ERROR_REC)
>> + return -EAGAIN;
>> + if (rec_run_ret)
>> + return -ENXIO;
>> +
>> + vcpu->arch.fault.esr_el2 = rec->run->exit.esr;
>> + vcpu->arch.fault.far_el2 = rec->run->exit.far;
>> + /* HPFAR_EL2 is only valid for RMI_EXIT_SYNC */
>> + vcpu->arch.fault.hpfar_el2 = 0;
>> +
>> + update_arch_timer_irq_lines(vcpu);
>> +
>> + /* Reset the emulation flags for the next run of the REC */
>> + rec->run->enter.flags = 0;
>> +
>> + switch (rec->run->exit.exit_reason) {
>> + case RMI_EXIT_SYNC:
>> + /*
>> + * HPFAR_EL2_NS is hijacked to indicate a valid HPFAR value,
>> + * see __get_fault_info()
>> + */
>> + vcpu->arch.fault.hpfar_el2 = rec->run->exit.hpfar |
>> HPFAR_EL2_NS;
>> + return rec_exit_handlers[esr_ec](vcpu);
>> + case RMI_EXIT_IRQ:
>> + case RMI_EXIT_FIQ:
>> + case RMI_EXIT_SERROR:
>> + return 1;
>> + case RMI_EXIT_PSCI:
>> + return rec_exit_psci(vcpu);
>> + case RMI_EXIT_RIPAS_CHANGE:
>> + return rec_exit_ripas_change(vcpu);
>> + }
>> +
>> + kvm_pr_unimpl("Unsupported exit reason: %u\n",
>> + rec->run->exit.exit_reason);
>> + vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
>> + return 0;
>> +}
>> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
>> index 353a5ca45e78..d8a5fb12db2d 100644
>> --- a/arch/arm64/kvm/rmi.c
>> +++ b/arch/arm64/kvm/rmi.c
>> @@ -173,6 +173,48 @@ static int realm_ensure_created(struct kvm *kvm)
>> return -ENXIO;
>> }
>> +/*
>> + * kvm_rec_pre_enter - Complete operations before entering a REC
>> + *
>> + * Some operations require work to be completed before entering a
>> realm. That
>> + * work may require memory allocation so cannot be done in the
>> kvm_rec_enter()
>> + * call.
>> + *
>> + * Return: 1 if we should enter the guest
>> + * 0 if we should exit to userspace
>> + * < 0 if we should exit to userspace, where the return value
>> indicates
>> + * an error
>> + */
>> +int kvm_rec_pre_enter(struct kvm_vcpu *vcpu)
>> +{
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> +
>> + if (kvm_realm_state(vcpu->kvm) != REALM_STATE_ACTIVE)
>> + return -EINVAL;
>> +
>> + switch (rec->run->exit.exit_reason) {
>> + case RMI_EXIT_HOST_CALL:
>> + for (int i = 0; i < REC_RUN_GPRS; i++)
>> + rec->run->enter.gprs[i] = vcpu_get_reg(vcpu, i);
>> + break;
>> + }
>> +
>> + return 1;
>> +}
>> +
>> +int noinstr kvm_rec_enter(struct kvm_vcpu *vcpu)
>> +{
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> + int ret;
>> +
>> + guest_state_enter_irqoff();
>> + ret = rmi_rec_enter(virt_to_phys(rec->rec_page),
>> + virt_to_phys(rec->run));
>> + guest_state_exit_irqoff();
>> +
>> + return ret;
>> +}
>> +
>> static int kvm_create_rec(struct kvm_vcpu *vcpu)
>> {
>> struct user_pt_regs *vcpu_regs = vcpu_gp_regs(vcpu);
>
> Thanks,
> Gavin
>
^ permalink raw reply
* Re: [PATCH v14 20/44] arm64: RMI: Support for the VGIC in realms
From: Steven Price @ 2026-06-05 15:02 UTC (permalink / raw)
To: Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <5ea74b6a-a51a-415e-b53f-5ece9829dee8@redhat.com>
On 28/05/2026 05:07, Gavin Shan wrote:
> Hi Steve,
>
> On 5/13/26 11:17 PM, Steven Price wrote:
>> The RMM provides emulation of a VGIC to the realm guest. With RMM v2.0
>> the registers are passed in the system registers so this works similar
>> to a normal guest, but kvm_arch_vcpu_put() need reordering to early out,
>> and realm guests don't support GICv2 even if the host does.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes from v12:
>> * GIC registers are now passed in the system registers rather than via
>> rec_entry/rec_exit which removes most of the changes.
>> Changes from v11:
>> * Minor changes to align with the previous patches. Note that the VGIC
>> handling will change with RMM v2.0.
>> Changes from v10:
>> * Make sure we sync the VGIC v4 state, and only populate valid lrs from
>> the list.
>> Changes from v9:
>> * Copy gicv3_vmcr from the RMM at the same time as gicv3_hcr rather
>> than having to handle that as a special case.
>> Changes from v8:
>> * Propagate gicv3_hcr to from the RMM.
>> Changes from v5:
>> * Handle RMM providing fewer GIC LRs than the hardware supports.
>> ---
>> arch/arm64/kvm/arm.c | 11 ++++++++---
>> arch/arm64/kvm/vgic/vgic-init.c | 2 +-
>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
>> index 93d34762db91..21d9dfdb1ea0 100644
>> --- a/arch/arm64/kvm/arm.c
>> +++ b/arch/arm64/kvm/arm.c
>> @@ -786,19 +786,24 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>> kvm_call_hyp_nvhe(__pkvm_vcpu_put);
>> }
>> + kvm_timer_vcpu_put(vcpu);
>> + kvm_vgic_put(vcpu);
>> +
>> + vcpu->cpu = -1;
>> +
>> + if (vcpu_is_rec(vcpu))
>> + return;
>> +
>
> For a REC, kvm_vcpu_{load, put}_debug() becomes unbalanced in
> kvm_arch_vcpu_{load, put}().
> kvm_vcpu_load_debug() is called in kvm_arch_vcpu_load(), but
> kvm_vcpu_put_debug() won't
> be called in kvm_arch_vcpu_put() after this whole series is applied.
Good catch. Yes that's not quite right.
Thanks,
Steve
>> kvm_vcpu_put_debug(vcpu);
>> kvm_arch_vcpu_put_fp(vcpu);
>> if (has_vhe())
>> kvm_vcpu_put_vhe(vcpu);
>> - kvm_timer_vcpu_put(vcpu);
>> - kvm_vgic_put(vcpu);
>> kvm_vcpu_pmu_restore_host(vcpu);
>> if (vcpu_has_nv(vcpu))
>> kvm_vcpu_put_hw_mmu(vcpu);
>> kvm_arm_vmid_clear_active();
>> vcpu_clear_on_unsupported_cpu(vcpu);
>> - vcpu->cpu = -1;
>> }
>> static void __kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu)
>> diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/
>> vgic-init.c
>> index 933983bb2005..a9db963dfd23 100644
>> --- a/arch/arm64/kvm/vgic/vgic-init.c
>> +++ b/arch/arm64/kvm/vgic/vgic-init.c
>> @@ -81,7 +81,7 @@ int kvm_vgic_create(struct kvm *kvm, u32 type)
>> * the proper checks already.
>> */
>> if (type == KVM_DEV_TYPE_ARM_VGIC_V2 &&
>> - !kvm_vgic_global_state.can_emulate_gicv2)
>> + (!kvm_vgic_global_state.can_emulate_gicv2 || kvm_is_realm(kvm)))
>> return -ENODEV;
>> /*
>
> Thanks,
> Gavin
>
^ 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