* Re: [PATCH v9 3/9] drm/bridge: fsl-ldb: Add support for i.MX94
From: Frank Li @ 2026-06-15 15:00 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-3-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:34PM +0300, Laurentiu Palcu wrote:
>
> i.MX94 series LDB controller shares the same LDB and LVDS control
> registers as i.MX8MP and i.MX93 but supports a higher maximum clock
> frequency.
>
> Add a 'max_clk_khz' member to the fsl_ldb_devdata structure in order to
> be able to set different max frequencies for other platforms.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/gpu/drm/bridge/fsl-ldb.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index bd03c36ee696c..b4959f654f2ac 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
> @@ -57,6 +57,7 @@ enum fsl_ldb_devtype {
> IMX6SX_LDB,
> IMX8MP_LDB,
> IMX93_LDB,
> + IMX94_LDB,
> };
>
> struct fsl_ldb_devdata {
> @@ -64,21 +65,31 @@ struct fsl_ldb_devdata {
> u32 lvds_ctrl;
> bool lvds_en_bit;
> bool single_ctrl_reg;
> + u32 max_clk_khz;
> };
>
> static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
> [IMX6SX_LDB] = {
> .ldb_ctrl = 0x18,
> .single_ctrl_reg = true,
> + .max_clk_khz = 80000,
> },
> [IMX8MP_LDB] = {
> .ldb_ctrl = 0x5c,
> .lvds_ctrl = 0x128,
> + .max_clk_khz = 80000,
> },
> [IMX93_LDB] = {
> .ldb_ctrl = 0x20,
> .lvds_ctrl = 0x24,
> .lvds_en_bit = true,
> + .max_clk_khz = 80000,
> + },
> + [IMX94_LDB] = {
> + .ldb_ctrl = 0x04,
> + .lvds_ctrl = 0x08,
> + .lvds_en_bit = true,
> + .max_clk_khz = 148500,
> },
> };
>
> @@ -274,7 +285,7 @@ fsl_ldb_mode_valid(struct drm_bridge *bridge,
> {
> struct fsl_ldb *fsl_ldb = to_fsl_ldb(bridge);
>
> - if (mode->clock > (fsl_ldb_is_dual(fsl_ldb) ? 160000 : 80000))
> + if (mode->clock > (fsl_ldb_is_dual(fsl_ldb) ? 2 : 1) * fsl_ldb->devdata->max_clk_khz)
> return MODE_CLOCK_HIGH;
>
> return MODE_OK;
> @@ -386,6 +397,8 @@ static const struct of_device_id fsl_ldb_match[] = {
> .data = &fsl_ldb_devdata[IMX8MP_LDB], },
> { .compatible = "fsl,imx93-ldb",
> .data = &fsl_ldb_devdata[IMX93_LDB], },
> + { .compatible = "fsl,imx94-ldb",
> + .data = &fsl_ldb_devdata[IMX94_LDB], },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, fsl_ldb_match);
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Handle Apple WFI State Loss
From: Will Deacon @ 2026-06-15 15:02 UTC (permalink / raw)
To: Yureka Lilian
Cc: Catalin Marinas, linux-arm-kernel, linux-kernel, asahi,
Sasha Finkelstein
In-Reply-To: <20260615-wfi-erratum-v2-1-59a73467f70d@cyberchaos.dev>
On Mon, Jun 15, 2026 at 02:21:36PM +0200, Yureka Lilian wrote:
> Apple Silicon CPUs can lose register state in WFI, leading to crashes
> in the idle loop early in the boot process.
> This applies to any previous Apple Silicon CPUs too, but is worked
> around by configuring the WFI mode in SYS_IMP_APL_CYC_OVRD sysreg
> during m1n1's chickens setup.
> This workaround no longer exists since M4.
>
> Add a workaround capability for replacing wfi and wfit with nop, and
> an erratum to enable it on the affected CPUs if the workaround using the
> sysreg is not already applied. Leave the decision whether the sysreg
> workaround can be used up to the earlier parts of the boot chain which
> already configure the Apple Silicon chicken bits.
>
> This alternative has to be applied in early boot, since otherwise some
> cores might enter the idle loop before apply_alternatives_all() is run.
>
> Reviewed-by: Sasha Finkelstein <k@chaosmail.tech>
> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
> ---
> Changes since v1:
> Restricted the erratum to EL2 only, since in EL1 we'd expect the
> hypervisor to trap WFI and handle the erratum.
>
> Tested on M4 and M4 Pro (which now sometimes nondeterministically
> crash later during boot).
> Successfully booted on M3 Max with the SYS_IMP_APL_CYC_OVRD
> workaround disabled in the bootloader, as well as A18 Pro (which,
> like M4 / M4 Pro, doesn't have SYS_IMP_APL_CYC_OVRD).
>
> There is probably a better place for the SYS_IMP_APL_CYC_OVRD
> defines, which I currently put in the middle of cpu_errata.c, but I
> wouldn't know where.
> ---
> arch/arm64/Kconfig | 12 ++++++++++++
> arch/arm64/include/asm/barrier.h | 19 ++++++++++++++++---
> arch/arm64/kernel/cpu_errata.c | 21 +++++++++++++++++++++
> arch/arm64/tools/cpucaps | 1 +
> 4 files changed, 50 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b3afe0688919..8c8ff069856f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -453,6 +453,18 @@ config AMPERE_ERRATUM_AC04_CPU_23
>
> If unsure, say Y.
>
> +config APPLE_ERRATUM_WFI_STATE
> + bool "Apple Silicon: WFI loses state"
> + default y
> + help
> + This option adds an alternative code sequence to work around some
> + Apple Silicon CPUs losing register state during wfi and wfit
> + instructions.
> +
> + As a workaround, the wfi and wfit instructions are replaced with nop
> + operations via the alternative framework if an affected CPU is
> + detected.
> +
> config ARM64_WORKAROUND_CLEAN_CACHE
> bool
>
> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index 9495c4441a46..f72eddc7c434 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -20,9 +20,22 @@
> #define wfe() asm volatile("wfe" : : : "memory")
> #define wfet(val) asm volatile("msr s0_3_c1_c0_0, %0" \
> : : "r" (val) : "memory")
> -#define wfi() asm volatile("wfi" : : : "memory")
> -#define wfit(val) asm volatile("msr s0_3_c1_c0_1, %0" \
> - : : "r" (val) : "memory")
> +#define wfi() \
> + do { \
> + asm volatile( \
> + ALTERNATIVE("wfi", \
> + "nop", \
> + ARM64_WORKAROUND_WFI_STATE) \
> + : : : "memory"); \
> + } while (0)
> +#define wfit(val) \
> + do { \
> + asm volatile( \
> + ALTERNATIVE("msr s0_3_c1_c0_1, %0", \
> + "nop", \
> + ARM64_WORKAROUND_WFI_STATE) \
> + : : "r" (val) : "memory"); \
> + } while (0)
How can you guarantee that we don't run one of these prior to patching?
I wonder if we're better off doing something like x86 and having an "idle="
cmdline option. which could choose between e.g. nop, wfe, wfi and yield, for
example? In fact, would wfe be a better choice than nop for you?
Will
^ permalink raw reply
* Re: [PATCH v9 4/9] dt-bindings: display: imx: Add i.MX94 DCIF
From: Frank Li @ 2026-06-15 15:01 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Philipp Zabel, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-clk,
imx, devicetree, linux-arm-kernel, linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-4-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:35PM +0300, Laurentiu Palcu wrote:
>
> DCIF is the i.MX94 Display Controller Interface which is used to
> drive a TFT LCD panel or connects to a display interface depending
> on the chip configuration.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
> .../bindings/display/imx/nxp,imx94-dcif.yaml | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml b/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml
> new file mode 100644
> index 0000000000000..8894e87666972
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2025 NXP
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/nxp,imx94-dcif.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX94 Display Control Interface (DCIF)
> +
> +maintainers:
> + - Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> +
> +description:
> + The Display Control Interface(DCIF) is a system master that fetches graphics
> + stored in memory and displays them on a TFT LCD panel or connects to a
> + display interface depending on the chip configuration.
> +
> +properties:
> + compatible:
> + const: nxp,imx94-dcif
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + items:
> + - description: CPU domain 0 (controlled by common registers group).
> + - description: CPU domain 1 (controlled by background layer registers group).
> + - description: CPU domain 2 (controlled by foreground layer registers group).
> +
> + interrupt-names:
> + items:
> + - const: common
> + - const: bg_layer
> + - const: fg_layer
> +
> + clocks:
> + maxItems: 3
> +
> + clock-names:
> + items:
> + - const: apb
> + - const: axi
> + - const: pix
> +
> + power-domains:
> + maxItems: 1
> +
> + port:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: Display Pixel Interface(DPI) output port
> +
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - power-domains
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + display-controller@4b120000 {
> + compatible = "nxp,imx94-dcif";
> + reg = <0x4b120000 0x300000>;
> + interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "common", "bg_layer", "fg_layer";
> + clocks = <&scmi_clk 69>, <&scmi_clk 70>, <&dispmix_csr 0>;
> + clock-names = "apb", "axi", "pix";
> + assigned-clocks = <&dispmix_csr 0>;
> + assigned-clock-parents = <&ldb_pll_pixel>;
> + power-domains = <&scmi_devpd 11>;
Nit: need extra empty line here
> + port {
> + dcif_out: endpoint {
Needn't label here for example
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> + remote-endpoint = <&ldb_in>;
> + };
> + };
> + };
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v9 2/9] drm/bridge: fsl-ldb: Get the next non-panel bridge
From: Frank Li @ 2026-06-15 15:02 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-2-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:33PM +0300, Laurentiu Palcu wrote:
> From: Liu Ying <victor.liu@nxp.com>
>
> The next bridge in bridge chain could be a panel bridge or a non-panel
> bridge. Use devm_drm_of_get_bridge() to replace the combination
> function calls of of_drm_find_panel() and devm_drm_panel_bridge_add()
> to get either a panel bridge or a non-panel bridge, instead of getting
> a panel bridge only.
>
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/gpu/drm/bridge/fsl-ldb.c | 31 ++++++++++++-------------------
> 1 file changed, 12 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index 9bfaa3f933709..bd03c36ee696c 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
> @@ -15,7 +15,6 @@
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_bridge.h>
> #include <drm/drm_of.h>
> -#include <drm/drm_panel.h>
>
> #define LDB_CTRL_CH0_ENABLE BIT(0)
> #define LDB_CTRL_CH0_DI_SELECT BIT(1)
> @@ -86,7 +85,6 @@ static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
> struct fsl_ldb {
> struct device *dev;
> struct drm_bridge bridge;
> - struct drm_bridge *panel_bridge;
> struct clk *clk;
> struct regmap *regmap;
> const struct fsl_ldb_devdata *devdata;
> @@ -119,7 +117,7 @@ static int fsl_ldb_attach(struct drm_bridge *bridge,
> {
> struct fsl_ldb *fsl_ldb = to_fsl_ldb(bridge);
>
> - return drm_bridge_attach(encoder, fsl_ldb->panel_bridge,
> + return drm_bridge_attach(encoder, fsl_ldb->bridge.next_bridge,
> bridge, flags);
> }
>
> @@ -296,9 +294,8 @@ static const struct drm_bridge_funcs funcs = {
> static int fsl_ldb_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *panel_node;
> struct device_node *remote1, *remote2;
> - struct drm_panel *panel;
> + struct drm_bridge *next_bridge;
> struct fsl_ldb *fsl_ldb;
> int dual_link;
>
> @@ -321,36 +318,32 @@ static int fsl_ldb_probe(struct platform_device *pdev)
> if (IS_ERR(fsl_ldb->regmap))
> return PTR_ERR(fsl_ldb->regmap);
>
> - /* Locate the remote ports and the panel node */
> + /* Locate the remote ports. */
> remote1 = of_graph_get_remote_node(dev->of_node, 1, 0);
> remote2 = of_graph_get_remote_node(dev->of_node, 2, 0);
> fsl_ldb->ch0_enabled = (remote1 != NULL);
> fsl_ldb->ch1_enabled = (remote2 != NULL);
> - panel_node = of_node_get(remote1 ? remote1 : remote2);
> of_node_put(remote1);
> of_node_put(remote2);
>
> - if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled) {
> - of_node_put(panel_node);
> - return dev_err_probe(dev, -ENXIO, "No panel node found");
> - }
> + if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled)
> + return dev_err_probe(dev, -ENXIO, "No next bridge node found");
>
> dev_dbg(dev, "Using %s\n",
> fsl_ldb_is_dual(fsl_ldb) ? "dual-link mode" :
> fsl_ldb->ch0_enabled ? "channel 0" : "channel 1");
>
> - panel = of_drm_find_panel(panel_node);
> - of_node_put(panel_node);
> - if (IS_ERR(panel))
> - return PTR_ERR(panel);
> -
> if (of_property_present(dev->of_node, "nxp,enable-termination-resistor"))
> fsl_ldb->use_termination_resistor = true;
>
> - fsl_ldb->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> - if (IS_ERR(fsl_ldb->panel_bridge))
> - return PTR_ERR(fsl_ldb->panel_bridge);
> + next_bridge = devm_drm_of_get_bridge(dev, dev->of_node,
> + fsl_ldb->ch0_enabled ? 1 : 2,
> + 0);
> + if (IS_ERR(next_bridge))
> + return dev_err_probe(dev, PTR_ERR(next_bridge),
> + "failed to get next bridge\n");
>
> + fsl_ldb->bridge.next_bridge = drm_bridge_get(next_bridge);
>
> if (fsl_ldb_is_dual(fsl_ldb)) {
> struct device_node *port1, *port2;
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
From: Fuad Tabba @ 2026-06-15 15:03 UTC (permalink / raw)
To: Will Deacon
Cc: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Sascha Bischoff, Andrew Jones
In-Reply-To: <ajAPNFDsQ63k_jAS@willie-the-truck>
On Mon, 15 Jun 2026 at 15:42, Will Deacon <will@kernel.org> wrote:
>
> On Mon, Jun 15, 2026 at 11:52:10AM +0100, Fuad Tabba wrote:
> > On Mon, 15 Jun 2026 at 11:05, Will Deacon <will@kernel.org> wrote:
> > >
> > > On Fri, Jun 12, 2026 at 12:34:14PM +0100, Fuad Tabba wrote:
> > > > When pKVM injects a synchronous exception into a protected guest, it
> > > > re-enters without restoring the guest's EL1 sysregs and writes the EL1
> > > > exception registers to hardware by hand: ESR_EL1 and ELR_EL1, but not
> > > > SPSR_EL1. enter_exception64() sets SPSR_EL1 (the interrupted PSTATE)
> > > > only in memory, so the guest's handler reads a stale SPSR_EL1 and
> > > > restores the wrong PSTATE on eret.
> > > >
> > > > Write SPSR_EL1 alongside the other exception registers.
> > > >
> > > > Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers")
> > > > Reported-by: sashiko <sashiko@sashiko.dev>
> > > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > > ---
> > > > arch/arm64/kvm/hyp/nvhe/sys_regs.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > index 8c3fbb413a06..1a7d5cd16d72 100644
> > > > --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > @@ -268,6 +268,7 @@ static void inject_sync64(struct kvm_vcpu *vcpu, u64 esr)
> > > >
> > > > write_sysreg_el1(esr, SYS_ESR);
> > > > write_sysreg_el1(read_sysreg_el2(SYS_ELR), SYS_ELR);
> > > > + write_sysreg_el1(read_sysreg_el2(SYS_SPSR), SYS_SPSR);
> > > > write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> > > > write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
> > > > }
> > >
> > > Is SPSR_EL1 not set in enter_exception64() using vcpu_cpsr(vcpu), which
> > > *is* set here? I'm just a bit wary of the report, as I'd have expected
> > > fireworks if we weren't initialising the guest's SPSR on the exception
> > > injection path.
> >
> > Yes, enter_exception64() sets SPSR_EL1, but only in memory:
> > __vcpu_write_spsr() takes the nVHE path and calls
> > __vcpu_assign_sys_reg(vcpu, SPSR_EL1, val), which writes
> > vcpu->arch.ctxt.sys_regs[SPSR_EL1] without touching the hardware
> > register.
> >
> > In the normal nVHE entry path that memory value reaches hardware via
> > __sysreg_restore_state_nvhe() before __guest_enter(). But
> > inject_sync64() runs inside the fixup_guest_exit() loop, which
> > re-enters the guest directly without a sysreg restore pass. ESR_EL1
> > and ELR_EL1 are already written to hardware by hand for this reason
> > but SPSR_EL1 was missed.
>
> Ah, I see. Does that mean that all the in-memory updates performed by
> enter_exception64() (e.g. the construction of the cpsr) are ignored too?
From looking at the code, no. inject_sync64() reads back the cpsr and
PC that enter_exception64() computed in memory and writes them to
hardware:
write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
So the guest re-enters with the right PSTATE. The only value left
stranded in memory is SPSR_EL1.
Cheers,
/fuad
>
> Will
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
From: Will Deacon @ 2026-06-15 15:10 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Sascha Bischoff, Andrew Jones
In-Reply-To: <CA+EHjTzL4GKw8RQrGnMq81Ohquo48_L4-MNJrCdGnBpMPR7XcA@mail.gmail.com>
On Mon, Jun 15, 2026 at 04:03:17PM +0100, Fuad Tabba wrote:
> On Mon, 15 Jun 2026 at 15:42, Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Jun 15, 2026 at 11:52:10AM +0100, Fuad Tabba wrote:
> > > On Mon, 15 Jun 2026 at 11:05, Will Deacon <will@kernel.org> wrote:
> > > >
> > > > On Fri, Jun 12, 2026 at 12:34:14PM +0100, Fuad Tabba wrote:
> > > > > When pKVM injects a synchronous exception into a protected guest, it
> > > > > re-enters without restoring the guest's EL1 sysregs and writes the EL1
> > > > > exception registers to hardware by hand: ESR_EL1 and ELR_EL1, but not
> > > > > SPSR_EL1. enter_exception64() sets SPSR_EL1 (the interrupted PSTATE)
> > > > > only in memory, so the guest's handler reads a stale SPSR_EL1 and
> > > > > restores the wrong PSTATE on eret.
> > > > >
> > > > > Write SPSR_EL1 alongside the other exception registers.
> > > > >
> > > > > Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers")
> > > > > Reported-by: sashiko <sashiko@sashiko.dev>
> > > > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > > > ---
> > > > > arch/arm64/kvm/hyp/nvhe/sys_regs.c | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > > index 8c3fbb413a06..1a7d5cd16d72 100644
> > > > > --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > > +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > > @@ -268,6 +268,7 @@ static void inject_sync64(struct kvm_vcpu *vcpu, u64 esr)
> > > > >
> > > > > write_sysreg_el1(esr, SYS_ESR);
> > > > > write_sysreg_el1(read_sysreg_el2(SYS_ELR), SYS_ELR);
> > > > > + write_sysreg_el1(read_sysreg_el2(SYS_SPSR), SYS_SPSR);
> > > > > write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> > > > > write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
> > > > > }
> > > >
> > > > Is SPSR_EL1 not set in enter_exception64() using vcpu_cpsr(vcpu), which
> > > > *is* set here? I'm just a bit wary of the report, as I'd have expected
> > > > fireworks if we weren't initialising the guest's SPSR on the exception
> > > > injection path.
> > >
> > > Yes, enter_exception64() sets SPSR_EL1, but only in memory:
> > > __vcpu_write_spsr() takes the nVHE path and calls
> > > __vcpu_assign_sys_reg(vcpu, SPSR_EL1, val), which writes
> > > vcpu->arch.ctxt.sys_regs[SPSR_EL1] without touching the hardware
> > > register.
> > >
> > > In the normal nVHE entry path that memory value reaches hardware via
> > > __sysreg_restore_state_nvhe() before __guest_enter(). But
> > > inject_sync64() runs inside the fixup_guest_exit() loop, which
> > > re-enters the guest directly without a sysreg restore pass. ESR_EL1
> > > and ELR_EL1 are already written to hardware by hand for this reason
> > > but SPSR_EL1 was missed.
> >
> > Ah, I see. Does that mean that all the in-memory updates performed by
> > enter_exception64() (e.g. the construction of the cpsr) are ignored too?
>
> From looking at the code, no. inject_sync64() reads back the cpsr and
> PC that enter_exception64() computed in memory and writes them to
> hardware:
>
> write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
>
> So the guest re-enters with the right PSTATE. The only value left
> stranded in memory is SPSR_EL1.
Ah, thanks. I had pissed that inject_sync64() calls __kvm_adjust_pc()
immediately after pending the exception. So you've convinced me:
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Christian Marangi @ 2026-06-15 15:11 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Daniel Golle, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Christian Marangi
Everything configured in phylink_config it's assumed to be set before
calling phylink_create() to permit correct parsing of all the different
modes and capabilities.
Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
probably due to an auto-rebase, placed the configuration of the INTERNAL
interface mode for the supported_interfaces for phylink_config right after
phylink_create() introducing a possible problem with supported interfaces
parsing.
While this doesn't currently create any problem/bug, move setting this bit
before phylink_create() to prevent any possible regression in future code
change in phylink core.
Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 7d771168b990..5d291e50a47b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -4960,6 +4960,11 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
if (MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628))
mac_ops = &rt5350_phylink_ops;
+ if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
+ id == MTK_GMAC2_ID)
+ __set_bit(PHY_INTERFACE_MODE_INTERNAL,
+ mac->phylink_config.supported_interfaces);
+
phylink = phylink_create(&mac->phylink_config,
of_fwnode_handle(mac->of_node),
phy_mode, mac_ops);
@@ -4970,11 +4975,6 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
mac->phylink = phylink;
- if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
- id == MTK_GMAC2_ID)
- __set_bit(PHY_INTERFACE_MODE_INTERNAL,
- mac->phylink_config.supported_interfaces);
-
SET_NETDEV_DEV(eth->netdev[id], eth->dev);
eth->netdev[id]->watchdog_timeo = 5 * HZ;
eth->netdev[id]->netdev_ops = &mtk_netdev_ops;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] dmaengine: sun6i-dma: Fix use-after-free in error handling paths
From: Jernej Škrabec @ 2026-06-15 15:13 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, samuel, mripard, arnd, Hongling Zeng
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng
In-Reply-To: <20260615022400.13454-1-zenghongling@kylinos.cn>
Dne ponedeljek, 15. junij 2026 ob 04:23:59 Srednjeevropski poletni čas je Hongling Zeng napisal(a):
> In error handling paths, the for loop frees v_lli in the loop body,
> then accesses v_lli->v_lli_next and v_lli->p_lli_next in the
> increment expression, which is use-after-free.
>
> Fix by saving both the next virtual and physical pointers before
> freeing the current node.
>
> Fixes: 555859308723 ("dmaengine: Add driver for Allwinner sun6i DMA")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> Suggested-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>
> ---
> Changes in v2:
> -Refactored the fix to avoid code duplication by creating a helper function
> sun6i_dma_free_lli_list() that handles LLI list cleanup
> -Add Suggested-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 26 ++++++++++++++------------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a9a254dbf8cb..02dd07001d5a 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -406,16 +406,12 @@ static inline void sun6i_dma_dump_lli(struct sun6i_vchan *vchan,
> v_lli->len, v_lli->para, v_lli->p_lli_next);
> }
>
> -static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
> +static void sun6i_dma_free_lli_list(struct sun6i_dma_dev *sdev,
> + struct sun6i_desc *txd)
> {
> - struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
> - struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vd->tx.chan->device);
> struct sun6i_dma_lli *v_lli, *v_next;
> dma_addr_t p_lli, p_next;
>
> - if (unlikely(!txd))
> - return;
> -
> p_lli = txd->p_lli;
> v_lli = txd->v_lli;
>
> @@ -428,7 +424,17 @@ static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
> v_lli = v_next;
> p_lli = p_next;
> }
> +}
>
> +static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
> +{
> + struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
> + struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vd->tx.chan->device);
> +
> + if (unlikely(!txd))
> + return;
> +
> + sun6i_dma_free_lli_list(sdev, txd);
> kfree(txd);
Why not also move txd handling? That way even more code can be put in one place.
Best regards,
Jernej
> }
>
> @@ -788,9 +794,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_slave_sg(
> return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>
> err_lli_free:
> - for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> - p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> - dma_pool_free(sdev->pool, v_lli, p_lli);
> + sun6i_dma_free_lli_list(sdev, txd);
> kfree(txd);
> return NULL;
> }
> @@ -869,9 +873,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_cyclic(
> return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>
> err_lli_free:
> - for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> - p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> - dma_pool_free(sdev->pool, v_lli, p_lli);
> + sun6i_dma_free_lli_list(sdev, txd);
> kfree(txd);
> return NULL;
> }
>
^ permalink raw reply
* Re: [PATCH v7 2/6] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
From: Andre Przywara @ 2026-06-15 15:15 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-coco, linux-arm-kernel,
linux-kernel
Cc: Catalin Marinas, Greg KH, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price, Suzuki K Poulose
In-Reply-To: <20260611130429.295516-3-aneesh.kumar@kernel.org>
Hi Aneesh,
thanks for doing this, we have thought about this for quite a while, but
no one dared to just bite the bullet...
On 6/11/26 15:04, Aneesh Kumar K.V (Arm) wrote:
> The SMCCC TRNG interface is a firmware-provided SMCCC service rather than a
> standalone platform device. Now that the SMCCC core has an SMCCC bus,
> create an arm-smccc-trng device for the discovered TRNG service and convert
> the hwrng driver to an SMCCC driver.
>
> The SMCCC id table preserves module autoloading for systems where the TRNG
> driver is built as a module.
>
> The sysfs device path changes from the old smccc_trng platform-device path
> to an arm-smccc device path. No known userspace dependency on the old path
> was found; a Debian Code Search lookup for the existing platform-device
> name/path did not find any users.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/include/asm/archrandom.h | 2 +-
> drivers/char/hw_random/arm_smccc_trng.c | 32 +++++++++-----
> drivers/firmware/smccc/smccc.c | 58 +++++++++++++++++++++----
> 3 files changed, 71 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/include/asm/archrandom.h b/arch/arm64/include/asm/archrandom.h
> index 8babfbe31f95..7605dd81bd1e 100644
> --- a/arch/arm64/include/asm/archrandom.h
> +++ b/arch/arm64/include/asm/archrandom.h
> @@ -12,7 +12,7 @@
>
> extern bool smccc_trng_available;
>
> -static inline bool __init smccc_probe_trng(void)
> +static inline bool smccc_probe_trng(void)
> {
> struct arm_smccc_res res;
>
> diff --git a/drivers/char/hw_random/arm_smccc_trng.c b/drivers/char/hw_random/arm_smccc_trng.c
> index dcb8e7f37f25..8f7f9d830cf2 100644
> --- a/drivers/char/hw_random/arm_smccc_trng.c
> +++ b/drivers/char/hw_random/arm_smccc_trng.c
> @@ -16,8 +16,10 @@
> #include <linux/device.h>
> #include <linux/hw_random.h>
> #include <linux/module.h>
> -#include <linux/platform_device.h>
> #include <linux/arm-smccc.h>
> +#include <linux/arm-smccc-bus.h>
> +
> +#include <asm/archrandom.h>
>
> #ifdef CONFIG_ARM64
> #define ARM_SMCCC_TRNG_RND ARM_SMCCC_TRNG_RND64
> @@ -94,29 +96,37 @@ static int smccc_trng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> return copied;
> }
>
> -static int smccc_trng_probe(struct platform_device *pdev)
> +static int smccc_trng_probe(struct arm_smccc_device *sdev)
> {
> struct hwrng *trng;
>
> - trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
> + /* validate the minimum version requirement */
> + if (!smccc_probe_trng())
> + return -ENODEV;
> +
> + trng = devm_kzalloc(&sdev->dev, sizeof(*trng), GFP_KERNEL);
> if (!trng)
> return -ENOMEM;
>
> trng->name = "smccc_trng";
> trng->read = smccc_trng_read;
>
> - return devm_hwrng_register(&pdev->dev, trng);
> + return devm_hwrng_register(&sdev->dev, trng);
> }
>
> -static struct platform_driver smccc_trng_driver = {
> - .driver = {
> - .name = "smccc_trng",
> - },
> - .probe = smccc_trng_probe,
> +static const struct arm_smccc_device_id smccc_trng_id_table[] = {
> + { .name = "arm-smccc-trng" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(arm_smccc, smccc_trng_id_table);
> +
> +static struct arm_smccc_driver smccc_trng_driver = {
> + .name = KBUILD_MODNAME,
> + .probe = smccc_trng_probe,
> + .id_table = smccc_trng_id_table,
> };
> -module_platform_driver(smccc_trng_driver);
> +module_arm_smccc_driver(smccc_trng_driver);
>
> -MODULE_ALIAS("platform:smccc_trng");
> MODULE_AUTHOR("Andre Przywara");
> MODULE_DESCRIPTION("Arm SMCCC TRNG firmware interface support");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index bdee057db2fd..a47696f3a5de 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -9,7 +9,8 @@
> #include <linux/init.h>
> #include <linux/arm-smccc.h>
> #include <linux/kernel.h>
> -#include <linux/platform_device.h>
> +#include <linux/arm-smccc-bus.h>
> +
> #include <asm/archrandom.h>
>
> static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
> @@ -81,16 +82,55 @@ bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid)
> }
> EXPORT_SYMBOL_GPL(arm_smccc_hypervisor_has_uuid);
>
> +struct smccc_device_info {
> + u32 func_id;
> + bool requires_smc;
> + const char *device_name;
> +};
> +
> +static const struct smccc_device_info smccc_devices[] __initconst = {
> + {
> + .func_id = ARM_SMCCC_TRNG_VERSION,
> + .requires_smc = false,
> + .device_name = "arm-smccc-trng",
> + },
> +};
> +
> +static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
> +{
> + unsigned long ret;
> + struct arm_smccc_res res;
> +
> + if (smccc_conduit == SMCCC_CONDUIT_NONE)
> + return false;
> +
> + if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
> + return false;
> +
> + arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
> + ret = res.a0;
Mostly a nit:
Why the assignment to a variable of the same type here? Wouldn't it be
cleaner to let "ret" be an "int"? Then you can save the cast below.
Or drop the assignment, and just cast res.a0 below directly.
In any case, I tested this in a KVM guest, and it worked flawlessly: the
device is created, works, and sysfs looks good, both with this file
compiled in (=y), and also as a module. Module autoloading also seems to
work.
So that's:
Tested-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre.
> +
> + if ((s32)ret == SMCCC_RET_NOT_SUPPORTED)
> + return false;
> +
> + return true;
> +}
> +
> static int __init smccc_devices_init(void)
> {
> - struct platform_device *pdev;
> -
> - if (smccc_trng_available) {
> - pdev = platform_device_register_simple("smccc_trng", -1,
> - NULL, 0);
> - if (IS_ERR(pdev))
> - pr_err("smccc_trng: could not register device: %ld\n",
> - PTR_ERR(pdev));
> + struct arm_smccc_device *sdev;
> + const struct smccc_device_info *smccc_dev;
> +
> + for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
> + smccc_dev = &smccc_devices[i];
> +
> + if (!smccc_probe_smccc_device(smccc_dev))
> + continue;
> +
> + sdev = arm_smccc_device_register(smccc_dev->device_name);
> + if (IS_ERR(sdev))
> + pr_err("%s: could not register device: %ld\n",
> + smccc_dev->device_name, PTR_ERR(sdev));
> }
>
> return 0;
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Maxime Chevallier @ 2026-06-15 15:27 UTC (permalink / raw)
To: Christian Marangi, Felix Fietkau, Lorenzo Bianconi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Russell King,
Daniel Golle, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260615151106.15438-1-ansuelsmth@gmail.com>
On 6/15/26 17:11, Christian Marangi wrote:
> Everything configured in phylink_config it's assumed to be set before
> calling phylink_create() to permit correct parsing of all the different
> modes and capabilities.
>
> Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
> internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
> probably due to an auto-rebase, placed the configuration of the INTERNAL
> interface mode for the supported_interfaces for phylink_config right after
> phylink_create() introducing a possible problem with supported interfaces
> parsing.
>
> While this doesn't currently create any problem/bug, move setting this bit
> before phylink_create() to prevent any possible regression in future code
> change in phylink core.
Agreed
>
> Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Handle Apple WFI State Loss
From: Sven Peter @ 2026-06-15 15:27 UTC (permalink / raw)
To: Will Deacon, Yureka Lilian
Cc: Catalin Marinas, linux-arm-kernel, linux-kernel, asahi,
Sasha Finkelstein
In-Reply-To: <ajAT9fWgOd9HY7ei@willie-the-truck>
On 15.06.26 17:02, Will Deacon wrote:
> On Mon, Jun 15, 2026 at 02:21:36PM +0200, Yureka Lilian wrote:
>> Apple Silicon CPUs can lose register state in WFI, leading to crashes
>> in the idle loop early in the boot process.
>> This applies to any previous Apple Silicon CPUs too, but is worked
>> around by configuring the WFI mode in SYS_IMP_APL_CYC_OVRD sysreg
>> during m1n1's chickens setup.
>> This workaround no longer exists since M4.
>>
>> Add a workaround capability for replacing wfi and wfit with nop, and
>> an erratum to enable it on the affected CPUs if the workaround using the
>> sysreg is not already applied. Leave the decision whether the sysreg
>> workaround can be used up to the earlier parts of the boot chain which
>> already configure the Apple Silicon chicken bits.
>>
>> This alternative has to be applied in early boot, since otherwise some
>> cores might enter the idle loop before apply_alternatives_all() is run.
>>
>> Reviewed-by: Sasha Finkelstein <k@chaosmail.tech>
>> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
>> ---
>> Changes since v1:
>> Restricted the erratum to EL2 only, since in EL1 we'd expect the
>> hypervisor to trap WFI and handle the erratum.
>>
>> Tested on M4 and M4 Pro (which now sometimes nondeterministically
>> crash later during boot).
>> Successfully booted on M3 Max with the SYS_IMP_APL_CYC_OVRD
>> workaround disabled in the bootloader, as well as A18 Pro (which,
>> like M4 / M4 Pro, doesn't have SYS_IMP_APL_CYC_OVRD).
>>
>> There is probably a better place for the SYS_IMP_APL_CYC_OVRD
>> defines, which I currently put in the middle of cpu_errata.c, but I
>> wouldn't know where.
>> ---
>> arch/arm64/Kconfig | 12 ++++++++++++
>> arch/arm64/include/asm/barrier.h | 19 ++++++++++++++++---
>> arch/arm64/kernel/cpu_errata.c | 21 +++++++++++++++++++++
>> arch/arm64/tools/cpucaps | 1 +
>> 4 files changed, 50 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index b3afe0688919..8c8ff069856f 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -453,6 +453,18 @@ config AMPERE_ERRATUM_AC04_CPU_23
>>
>> If unsure, say Y.
>>
>> +config APPLE_ERRATUM_WFI_STATE
>> + bool "Apple Silicon: WFI loses state"
>> + default y
>> + help
>> + This option adds an alternative code sequence to work around some
>> + Apple Silicon CPUs losing register state during wfi and wfit
>> + instructions.
>> +
>> + As a workaround, the wfi and wfit instructions are replaced with nop
>> + operations via the alternative framework if an affected CPU is
>> + detected.
>> +
>> config ARM64_WORKAROUND_CLEAN_CACHE
>> bool
>>
>> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
>> index 9495c4441a46..f72eddc7c434 100644
>> --- a/arch/arm64/include/asm/barrier.h
>> +++ b/arch/arm64/include/asm/barrier.h
>> @@ -20,9 +20,22 @@
>> #define wfe() asm volatile("wfe" : : : "memory")
>> #define wfet(val) asm volatile("msr s0_3_c1_c0_0, %0" \
>> : : "r" (val) : "memory")
>> -#define wfi() asm volatile("wfi" : : : "memory")
>> -#define wfit(val) asm volatile("msr s0_3_c1_c0_1, %0" \
>> - : : "r" (val) : "memory")
>> +#define wfi() \
>> + do { \
>> + asm volatile( \
>> + ALTERNATIVE("wfi", \
>> + "nop", \
>> + ARM64_WORKAROUND_WFI_STATE) \
>> + : : : "memory"); \
>> + } while (0)
>> +#define wfit(val) \
>> + do { \
>> + asm volatile( \
>> + ALTERNATIVE("msr s0_3_c1_c0_1, %0", \
>> + "nop", \
>> + ARM64_WORKAROUND_WFI_STATE) \
>> + : : "r" (val) : "memory"); \
>> + } while (0)
>
> How can you guarantee that we don't run one of these prior to patching?
>
> I wonder if we're better off doing something like x86 and having an "idle="
> cmdline option. which could choose between e.g. nop, wfe, wfi and yield, for
> example? In fact, would wfe be a better choice than nop for you?
I think that should also solve the issue of detecting if we're running
on bare metal and need this or if there's something that mitigates the
issue (e.g. M1-M3 where we can still enable that chicken bit or a
hypervisor that just traps wfi): Just let the bootloader decide and
inject that cmdline option.
Best,
Sven
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Daniel Golle @ 2026-06-15 15:33 UTC (permalink / raw)
To: Christian Marangi
Cc: Felix Fietkau, Lorenzo Bianconi, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260615151106.15438-1-ansuelsmth@gmail.com>
On Mon, Jun 15, 2026 at 05:11:00PM +0200, Christian Marangi wrote:
> Everything configured in phylink_config it's assumed to be set before
> calling phylink_create() to permit correct parsing of all the different
> modes and capabilities.
>
> Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
> internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
> probably due to an auto-rebase, placed the configuration of the INTERNAL
> interface mode for the supported_interfaces for phylink_config right after
> phylink_create() introducing a possible problem with supported interfaces
> parsing.
>
> While this doesn't currently create any problem/bug, move setting this bit
> before phylink_create() to prevent any possible regression in future code
> change in phylink core.
>
> Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
As no user-visible bug surfaces because of that it is questionable though if
the Fixes:-tag is justified.
^ permalink raw reply
* Re: [PATCH v1 0/6] perf vendor events intel: update
From: Ian Rogers @ 2026-06-15 15:37 UTC (permalink / raw)
To: Mi, Dapeng
Cc: Chun-Tse Shao, peterz, mingo, acme, namhyung, alexander.shishkin,
jolsa, adrian.hunter, james.clark, afaerber, mani,
linux-perf-users, linux-kernel, linux-arm-kernel, linux-actions
In-Reply-To: <0b6d58d5-f802-47dc-ae71-31c45184b738@linux.intel.com>
On Sun, Jun 14, 2026 at 6:32 PM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>
> LGTM. Thanks.
>
> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Reviewed-by: Ian Rogers <irogers@google.com>
The tigerlake update is just the version number. On the perfmon git
the change was removing zero fields:
https://github.com/intel/perfmon/commit/8353ffb63efcad6b6fac1a8c05d76e2d6317ae23
but zero fields are dropped from the perf JSON, resulting in no differences.
Thanks,
Ian
> On 6/10/2026 5:50 AM, Chun-Tse Shao wrote:
> > Sync with the latest perfmon events from:
> > https://github.com/intel/perfmon
> > by running the script:
> > https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py
> > and copying the resulting json and mapfile.csv changes into the perf
> > tree.
> >
> > Chun-Tse Shao (6):
> > perf vendor events intel: Update arrowlake events from 1.17 to 1.19
> > perf vendor events intel: Update emeraldrapids events from 1.23 to
> > 1.24
> > perf vendor events intel: Update graniterapids events from 1.18 to
> > 1.19
> > perf vendor events intel: Update lunarlake events from 1.22 to 1.25
> > perf vendor events intel: Update pantherlake events from 1.05 to 1.06
> > perf vendor events intel: Update tigerlake events from 1.18 to 1.19
> >
> > .../pmu-events/arch/x86/arrowlake/cache.json | 30 ++-
> > .../arch/x86/arrowlake/floating-point.json | 45 ++++
> > .../pmu-events/arch/x86/arrowlake/memory.json | 18 ++
> > .../arch/x86/arrowlake/pipeline.json | 129 +++++++++-
> > .../arch/x86/emeraldrapids/cache.json | 9 +
> > .../graniterapids/uncore-interconnect.json | 10 +
> > .../arch/x86/graniterapids/uncore-memory.json | 2 +-
> > .../pmu-events/arch/x86/lunarlake/cache.json | 2 +-
> > .../arch/x86/lunarlake/pipeline.json | 27 ++-
> > .../arch/x86/lunarlake/uncore-memory.json | 208 ++++++++++++++++-
> > tools/perf/pmu-events/arch/x86/mapfile.csv | 12 +-
> > .../arch/x86/pantherlake/counter.json | 5 +
> > .../arch/x86/pantherlake/pipeline.json | 29 ++-
> > .../x86/pantherlake/uncore-interconnect.json | 10 +
> > .../arch/x86/pantherlake/uncore-memory.json | 221 +++++++++++++++++-
> > 15 files changed, 728 insertions(+), 29 deletions(-)
> > create mode 100644 tools/perf/pmu-events/arch/x86/pantherlake/uncore-interconnect.json
> >
^ permalink raw reply
* Re: [PATCH v2] arm64: tlbflush: Don't broadcast if mm was only active on local cpu
From: Ryan Roberts @ 2026-06-15 15:41 UTC (permalink / raw)
To: Will Deacon
Cc: Linu Cherian, Catalin Marinas, Kevin Brodsky, Anshuman Khandual,
Yang Shi, Mark Rutland, Huang Ying, linux-arm-kernel,
linux-kernel, shameerali.kolothum.thodi
In-Reply-To: <ajAPnahwTe1OHQDp@willie-the-truck>
On 15/06/2026 15:43, Will Deacon wrote:
> On Mon, Jun 15, 2026 at 12:21:19PM +0100, Ryan Roberts wrote:
>> On 14/06/2026 12:04, Will Deacon wrote:
>>> On Sat, May 23, 2026 at 07:17:10PM +0530, Linu Cherian wrote:
>>>> From: Ryan Roberts <ryan.roberts@arm.com>
>>>>
>>>> Testing with 7.1-rc4 :
>>>> +-----------------------+---------------------------------------------------+-------------+
>>>> | Benchmark | Result Class | Improvement|
>>>> +=======================+===================================================+=============+
>>>> | perf/syscall | fork (ops/sec) | (I) 3.25% |
>>>> +-----------------------+---------------------------------------------------+-------------+
>>>> | pts/memtier-benchmark | Protocol: Redis Clients: 100 Ratio: 1:5 (Ops/sec) | (I) 2.70% |
>>>> | | Protocol: Redis Clients: 100 Ratio: 5:1 (Ops/sec) | (I) 2.13% |
>>>> +-----------------------+---------------------------------------------------+-------------+
>>>
>>> I think we need a much more comprehensive set of benchmarks before we can
>>> begin to consider a change like this.
>>
>> I believe that Linu ran a wider set of benchmarks and didn't find any
>> regressions. These are just the ones that show improvement (Linu, please correct
>> me and/or provide details).
>
> I think it's important to show the ones that suffer as well... and also
> look at different configurations (e.g. preemptible settings) and different
> environments (e.g. native vs in a VM).
>
>> Additionally Huang Ying did some testing against the RFC and reported 4.5%
>> improvement with Redis:
>>
>> https://lore.kernel.org/linux-arm-kernel/87segumv6w.fsf@DESKTOP-5N7EMDA
>
> To be clear: I'm not disputing that some benchmarks appear to show a small
> boost from this series. I'm just worried that's not the whole story.
>
>>>> arch/arm64/include/asm/mmu.h | 12 +++
>>>> arch/arm64/include/asm/mmu_context.h | 2 +
>>>> arch/arm64/include/asm/tlbflush.h | 127 +++++++++++++++++++++------
>>>> arch/arm64/mm/context.c | 30 ++++++-
>>>> 4 files changed, 141 insertions(+), 30 deletions(-)
>>>
>>> Doesn't this break BTM/SVM with the SMMU? I think that's a non-starter
>>> even if you can provide some more compelling numbers.
>>
>> AIUI, we don't support BTM upstream - the SMMU uses private ASIDs and implements
>> MMU notifiers to forward the TLBIs via its command queue interface.
>>
>> I was also under the impression that supporting BTM upsteam was not desired;
>> Please correct me if that's not accurate or if you're aware of plans to add
>> support. I've been (coincidentlly) looking at some other stuff that could
>> benefit from BTM but had concluded it wouldn't be an acceptable approach upstream.
>>
>> If we did ever want to add SMMU BTM support though, I think it would be simple
>> enough to add an interface to allow the SMMU to disable the optimization (i.e.
>> force active_cpu to ACTIVE_CPU_MULTIPLE)?
>
> We used to have some initial BTM support in the SMMUv3 driver but the
> main problem was finding an upstream driver/soc that can use it properly
> and so it was ultimately removed in d38c28dbefee ("iommu/arm-smmu-v3: Put
> the SVA mmu notifier in the smmu_domain") because it was getting in the
> way of wider driver rework and we couldn't test it.
>
> However, there *is* work to re-enable it on top of that rework (and other
> changes):
>
> https://lore.kernel.org/linux-iommu/20250319173202.78988-6-shameerali.kolothum.thodi@huawei.com/
>
> although I don't know if Shameer intends to repost that...
Thanks for the pointers; That's very interesting feedback. I'll take a closer
look :)
>
>>>> +static inline bool flush_tlb_user_pre(struct mm_struct *mm, tlbf_t flags)
>>>> +{
>>>> + unsigned int self, active;
>>>> + bool local;
>>>> +
>>>> + migrate_disable();
>>>> +
>>>> + if (flags & TLBF_NOBROADCAST) {
>>>> + dsb(nshst);
>>>> + return true;
>>>> + }
>>>
>>> Why does the NOBROADCAST case need migration disabled? It didn't before...
>>
>> The existing semantic for TLBF_BOBROADCAST is that it emits a local TLBI on
>> whatever CPU we happen to be executing on. It's used for lazily fixing up
>> spurious faults (i.e. hitting RO TLB entries when the PTE has been relaxed to
>> RW). So it's still functionally correct if the thread migrates CPU between
>> taking the fault and issuing the local TLBI - in the worst case it just leads to
>> another spurious fault.
>>
>> For this new case, we need to ensure we don't get migrated between reading
>> active_cpu and issuing the local TLBI, otherwise we would only issue a local
>> TLBI when a broadcast was required.
>
> Sounds like those two users probably need separating out, then?
Ahh, I see; I'll admit I hadn't actually reviewed the new integration part. I
agree - NOBROADCAST is different to to this. This is an optimization for the
"not NOBROADCAST" case. We need to avoid disabling migration in the NOBROADCAST
case.
>
>>>> + self = smp_processor_id();
>>>> +
>>>> + /*
>>>> + * The load of mm->context.active_cpu must not be reordered before the
>>>> + * store to the pgtable that necessitated this flush. This ensures that
>>>> + * if the value read is our cpu id, then no other cpu can have seen the
>>>> + * old pgtable value and therefore does not need this old value to be
>>>> + * flushed from its tlb. But we don't want to upgrade the dsb(ishst),
>>>> + * needed to make the pgtable updates visible to the walker, to a
>>>> + * dsb(ish) by default. So speculatively load without a barrier and if
>>>> + * it indicates our cpu id, then upgrade the barrier and re-load.
>>>> + */
>>>> + active = READ_ONCE(mm->context.active_cpu);
>>>> + if (active == self) {
>>>> + dsb(ish);
>>>> + active = READ_ONCE(mm->context.active_cpu);
>>>> + } else {
>>>> + dsb(ishst);
>>>> + }
>>>
>>> Why can't you just do:
>>>
>>> dsb(ishst);
>>> active = READ_ONCE(mm->context.active_cpu);
>>>
>>> ?
>>
>> Prior to this optimization, we always issued a dsb(ishst) here. Catalin
>> suggested the same simplification against the RFC. I believe Linu tried it but
>> saw regressions; Hopefully Linu can provide the details.
>
> I don't follow...
>
> The old code always did dsb(ishst). The proposed code here does either
> dsb(ish) or dsb(ishst). How can that possibly be faster?
Ugh, sorry - I read your suggestion as unconditionally issuing a dsb(ish).
Ignore my previous answer, and now I'll demonstrate my total lack of
understanding of barriers instead...
As the comment says, "The load of mm->context.active_cpu must not be reordered
before the store to the pgtable that necessitated this flush". I thought that a
dsb(ishst) would only provide ordering between stores. Don't we need the
dsb(ish) to prevent the load from being reordered before the store?
>
>>>> + local = active == self;
>>>> + if (!local)
>>>> + migrate_enable();
>>>> +
>>>> + return local;
>>>> +}
>>>> +
>>>> +static inline void flush_tlb_user_post(bool local)
>>>> +{
>>>> + if (local)
>>>> + migrate_enable();
>>>> +}
>>>
>>> I was under the impression that disabling/enabling migration was an
>>> expensive thing to do, so I'd really want to see some more numbers to
>>> justify this (including from inside a VM) and allow us to consider the
>>> trade-offs properly. It's also not at all clear to me that it's safe
>>> from such a low-level TLB invalidation helper.
>>
>> I had assumed it wasn't very expensive, but perhaps I'm wrong. I know
>> preempt_enable() can be expensive because it has to test to see if it needs to
>> reschedule. But I assumed for disabling/enabling migration, it would just be a
>> counter and the scheduler would check that it's zero before considing moving the
>> task to another run queue. (But I have practically zero understanding of the
>> scheduler so I'll assume I'm wrong...).
>
> I'm not an expert here either, but reading the code shows that it has
> a preempt guard along with additional book-keeping.
>
>> Instead of disabling migration, perhaps we could re-check active_cpu after
>> issuing the local tlbi - if it's now reporting "multiple" we must have been
>> migrated and we need to upgrade to a braodcast TLBI?
>
> That's an interesting idea, although I suppose it means the
> post-invalidation DSB needs to be ISH for the local case to check the
> active_cpu safely?
Another idea could be to use PeterZ's "kernel mode restartable sequence" thingy,
then we can detect migration and retry? There a thread briefly talking about
doing something similar to avoid disabling preemption in the this_cpu_ ops, but
not sure if it went anywhere.
>
>>>> * TLB Invalidation
>>>> * ================
>>>> @@ -408,12 +482,20 @@ static inline void flush_tlb_all(void)
>>>> static inline void flush_tlb_mm(struct mm_struct *mm)
>>>> {
>>>> unsigned long asid;
>>>> + bool local;
>>>>
>>>> - dsb(ishst);
>>>> + local = flush_tlb_user_pre(mm, TLBF_NONE);
>>>> asid = __TLBI_VADDR(0, ASID(mm));
>>>> - __tlbi(aside1is, asid);
>>>> - __tlbi_user(aside1is, asid);
>>>> - __tlbi_sync_s1ish(mm);
>>>> + if (local) {
>>>> + __tlbi(aside1, asid);
>>>> + __tlbi_user(aside1, asid);
>>>> + dsb(nsh);
>>>> + } else {
>>>> + __tlbi(aside1is, asid);
>>>> + __tlbi_user(aside1is, asid);
>>>> + __tlbi_sync_s1ish(mm);
>>>> + }
>>>> + flush_tlb_user_post(local);
>>>
>>> I think you've changed this since Ryan's original patch, but why are you
>>> only calling __tlbi_sync_s1ish() for the !local case? Doesn't that break
>>> the erratum workaround when running as a VM if the vCPU is migrated?
>>
>> Hmm. So from the guest kernel's perspective, it has concluded that it only needs
>> to target the local (v)CPU. Since the errata only affect boardcast TLBIs, it
>> concludes there is no need to issue the workarounds. But since it's a VM, the HW
>> will upgrade the local TLBIs to broadcast TLBIs, but will not magically
>> re-instate the workarounds. I guess the simplest solution would be to disable
>> the optimization when either workaround is enabled.
>
> That's what I was thinking, but Mark seems to think it's ok. I'll reply
> to him on the other part of the thread.
>
>> Perhaps this is all getting a bit too complex for not enough benefit...
>
> I don't think the complexity is unmanageable, but I'm not yet convinced
> that this offers any real benefit overall.
I'll talk with Linu and see if we can present a clearer view.
Thanks,
Ryan
>
> Will
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: display: allwinner: Split H616 DE33 layer reg space
From: Jernej Škrabec @ 2026-06-15 15:47 UTC (permalink / raw)
To: wens, Krzysztof Kozlowski
Cc: samuel, mripard, maarten.lankhorst, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, mturquette, sboyd, dri-devel, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <86943057-f5b4-4fae-9172-45f13814494f@kernel.org>
Dne ponedeljek, 15. junij 2026 ob 06:28:54 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
> On 14/06/2026 16:08, Jernej Škrabec wrote:
> > Dne ponedeljek, 25. maj 2026 ob 14:10:38 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
> >> On 24/05/2026 23:33, Chen-Yu Tsai wrote:
> >>> Hi,
> >>>
> >>> (resent from new email)
> >>>
> >>> On Thu, May 14, 2026 at 2:04 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>>
> >>>> On Sat, May 09, 2026 at 09:00:14PM +0200, Jernej Skrabec wrote:
> >>>>> From: Jernej Skrabec <jernej.skrabec@gmail.com>
> >>>>>
> >>>>> As it turns out, current H616 DE33 binding was written based on
> >>>>> incomplete understanding of DE33 design. Namely, planes are shared
> >>>>> resource and not tied to specific mixer, which was the case for previous
> >>>>> generations of Display Engine (DE3 and earlier).
> >>>>>
> >>>>> This means that current DE33 binding doesn't properly reflect HW and
> >>>>> using it would mean that second mixer (used for second display output)
> >>>>> can't be supported.
> >>>>>
> >>>>> Remove layer register space, which will be represented with additional
> >>>>> node, and replace it with phandle, which will point to that new, shared
> >>>>> node. That way, all mixers can share same layers.
> >>>>>
> >>>>> There is no user of this binding yet, so changes can be made safely,
> >>>>> without breaking any backward compatibility.
> >>>>
> >>>> There is user. git grep gives me:
> >>>> drivers/gpu/drm/sun4i/sun8i_mixer.c
> >>>>
> >>>> which means this is a released ABI. As I understood, the old code was
> >>>
> >>> We held off on merging the DT changes so that we could rework this.
> >>> I can't find the actual request though. It was probably over IRC.
> >>>
> >>>> working fine but just did not support all use cases. Why this cannot be
> >>>> kept backwards compatible?
> >>>
> >>> AFAIK the "planes" block is shared between two display mixers. As the
> >>> commit message explains, this prevents using the second mixer, since
> >>> only one of them can claim and map the register space. And on the H700
> >>> (which is the same die as the H616 discussed here but with more exposed
> >>> interfaces), there could actually be a use case for the second mixer.
> >>
> >> It explains why you want to make the changes but not why you cannot keep
> >> it backwards compatible.
> >
> > I guess it can be backward compatible, but I don't think it makes sense.
> > Yes, original driver implemented original DT bindings, but there is no node
> > which uses that binding. If there is no user of that, why would driver
>
> Did you check all out of tree users of the ABI? All vendor kernels,
> forks and all of them for which the ABI was made for?
Since when do we care about out of tree users? I understand that drivers
must support old device tree files. Once they work, compatibility must
be carried forward. But that's not the case here.
In any case, vendor kernels have completely different DT structure. This
was developed independently from them. Take a look at [1] how BSP DT looks
like, specifically Display Engine node.
Of course there are some distros which grab WIP patches from mailing lists
soon after they are available. For example, I know that Armbian carried old
WIP patches which used old ABI. However, such distros generally don't care
about exact solution and ditch patches as soon as proper solution is merged
upstream or even when better WIP patches come around. DT files in such
distros get updated alongside kernel, they are not hidden in firmware.
Best regards,
Jernej
[1] https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/arch/arm64/boot/dts/sunxi/sun50iw9p1.dtsi#L1315-L1339
>
> If there is no single downstream/out of tree kernel using this ABI, then
> of course you do not need to consider it. I don't know how would you
> prove that but I am open for suggestions.
>
> > need to support it nevertheless? Supporting only actually used DT binding
> > allows for better code architecture, as there is no need to support second,
> > unused path. It also simplifies testing, since developer doesn't need to
> > test both paths if code is changed in that area.
> >
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [RFC PATCH] KVM: Ignore MMU notifiers for guest_memfd-only memslots
From: Alexandru Elisei @ 2026-06-15 15:52 UTC (permalink / raw)
To: pbonzini, kvm, linux-kernel, maz, oupton, suzuki.poulose, kvmarm,
linux-arm-kernel, seanjc, david.hildenbrand, mark.rutland
For guest_memfd-only memslots (kvm_memslot_is_gmem_only() is true), the
memory provider for the virtual machine is the guest_memfd file, not the
userspace mapping. Faults are resolved using the guest_memfd page cache,
and the permissions for the secondary MMU mapping depends exclusively on
the memslot (i.e, if the memslot is read-only). How userspace happens to
have the memory mmaped at fault time, or even if the memory is mapped at
all into userspace, is not taken into consideration.
guest_memfd memory is not evictable, is not movable and there's no backing
storage. Once memory is allocated for an offset in guest_memfd file, the
offset will not change, and that memory is not freed unless userspace
explicitly punches a hole in the file. As a result, memory reclaim, page
migration, page aging and dirty page tracking for the userspace mapping
serve little purpose.
Despite this, KVM's MMU notifiers still modify the secondary MMU page
tables, similar to ordinary memslots, only for the same memory to be
remapped next time a guest accesses it. Make the disconnect between the
user mapping and the secondary MMU page tables explicit by ignoring the MMU
notifiers for guest_memfd-only memslots.
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
The only theoretical instance where the MMU notifiers are invoked for the
userspace mapping of a guest_memfd-only memslot that I was able to find was
automatic NUMA balancing with a non-NULL NUMA policy for the guest_memfd
file. I wasn't able to test it in practice. Also my knowledge of MM is very
limited, so there might be other cases where it happens, or I might be
wrong and today the MMU notifiers are never invoked.
Either way, when and if it happens, having memory unmapped from the
seconday MMU in the case of guest_memfd-only memslot is at most a
performance issue (it causes unnecessary guest faults), but I wanted to
start a conversation about this because having memory that stays mapped at
stage 2 (unless userspace explicitly unmaps it from the VM) is needed for a
Arm feature (called SPE, Statistical Profiling Extension) that I'm working
to upstream. This patch aims to provide the guarantee that memory won't be
unmapped from the secondary MMU behind the VMMs back, which is what happens
for non guest_memfd memslots.
virt/kvm/kvm_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 881f92d7a469..8c4158996928 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -592,6 +592,10 @@ static __always_inline kvm_mn_ret_t kvm_handle_hva_range(struct kvm *kvm,
unsigned long hva_start, hva_end;
slot = container_of(node, struct kvm_memory_slot, hva_node[slots->node_idx]);
+
+ if (kvm_slot_has_gmem(slot) && kvm_memslot_is_gmem_only(slot))
+ continue;
+
hva_start = max_t(unsigned long, range->start, slot->userspace_addr);
hva_end = min_t(unsigned long, range->end,
slot->userspace_addr + (slot->npages << PAGE_SHIFT));
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next v7 12/12] net: airoha: add phylink support
From: Benjamin Larsson @ 2026-06-15 16:07 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-13-ansuelsmth@gmail.com>
Hi.
On 15/06/2026 14:29, Christian Marangi wrote:
> Add phylink support for each GDM port. For GDM1 add the internal interface
> mode as the only supported mode. For GDM2/3/4 add the required
> configuration of the PCS to make the external PHY or attached SFP cage
> work.
>
> These needs to be defined in the GDM port node using the pcs-handle
> property.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/ethernet/airoha/Kconfig | 1 +
> drivers/net/ethernet/airoha/airoha_eth.c | 161 +++++++++++++++++++++-
> drivers/net/ethernet/airoha/airoha_eth.h | 3 +
> drivers/net/ethernet/airoha/airoha_regs.h | 12 ++
> 4 files changed, 176 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/Kconfig b/drivers/net/ethernet/airoha/Kconfig
> index ad3ce501e7a5..38dcc76e5998 100644
> --- a/drivers/net/ethernet/airoha/Kconfig
> +++ b/drivers/net/ethernet/airoha/Kconfig
> @@ -20,6 +20,7 @@ config NET_AIROHA
> depends on NET_DSA || !NET_DSA
> select NET_AIROHA_NPU
> select PAGE_POOL
> + select PHYLINK
> help
> This driver supports the gigabit ethernet MACs in the
> Airoha SoC family.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5f1a118875fb..9a42fb991bd7 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -8,6 +8,7 @@
> #include <linux/of_reserved_mem.h>
> #include <linux/platform_device.h>
> #include <linux/tcp.h>
> +#include <linux/pcs/pcs.h>
> #include <linux/u64_stats_sync.h>
> #include <net/dst_metadata.h>
> #include <net/page_pool/helpers.h>
> @@ -1810,6 +1811,14 @@ static int airoha_dev_open(struct net_device *netdev)
> u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
> struct airoha_qdma *qdma = dev->qdma;
>
> + err = phylink_of_phy_connect(dev->phylink, netdev->dev.of_node, 0);
> + if (err) {
> + netdev_err(netdev, "could not attach PHY: %d\n", err);
> + return err;
> + }
> +
> + phylink_start(dev->phylink);
> +
> netif_tx_start_all_queues(netdev);
> err = airoha_set_vip_for_gdm_port(dev, true);
> if (err)
> @@ -1907,6 +1916,9 @@ static int airoha_dev_stop(struct net_device *netdev)
> }
> }
>
> + phylink_stop(dev->phylink);
> + phylink_disconnect_phy(dev->phylink);
> +
> return 0;
> }
>
> @@ -3168,6 +3180,151 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> return false;
> }
>
> +/* Nothing to do in MAC, everything is handled in PCS */
> +static void airoha_mac_config(struct phylink_config *config, unsigned int mode,
> + const struct phylink_link_state *state)
> +{
> +}
> +
> +static void airoha_mac_link_up(struct phylink_config *config, struct phy_device *phy,
> + unsigned int mode, phy_interface_t interface,
> + int speed, int duplex, bool tx_pause, bool rx_pause)
> +{
> + struct airoha_gdm_dev *dev = container_of(config, struct airoha_gdm_dev,
> + phylink_config);
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> + u32 frag_size_tx, frag_size_rx;
> + u32 mask, val;
> +
> + /* TX/RX frag is configured only for GDM4 */
> + if (port->id != AIROHA_GDM4_IDX)
> + return;
> +
> + switch (speed) {
> + case SPEED_10000:
> + case SPEED_5000:
> + frag_size_tx = 8;
> + frag_size_rx = 8;
> + break;
> + case SPEED_2500:
> + frag_size_tx = 2;
> + frag_size_rx = 1;
> + break;
> + default:
> + frag_size_tx = 1;
> + frag_size_rx = 0;
> + }
> +
> + /* Configure TX/RX frag based on speed */
> + if (dev->nbq == 1) {
> + mask = GDMA4_SGMII1_TX_FRAG_SIZE_MASK;
Can the naming be consistently GDM4 without the A?
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH] clk: zynq: handle kasprintf() failure in periph_clk registration
From: Brian Masney @ 2026-06-15 16:07 UTC (permalink / raw)
To: William Theesfeld
Cc: Michael Turquette, Stephen Boyd, Michal Simek, linux-clk,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260601203500.658135-1-william@theesfeld.net>
On Mon, Jun 01, 2026 at 04:35:00PM -0400, William Theesfeld wrote:
> zynq_clk_register_periph_clk() ignores the return value of the two
> kasprintf() calls used to build the mux and divider clock names, and
> passes the resulting (possibly NULL) pointers straight into
> clk_register_mux(), clk_register_divider() and clk_register_gate() as
> the clock '"'name'"' argument. On allocation failure that name later
> gets dereferenced by the clock framework (e.g. in debugfs name
> formatting), causing a NULL-pointer dereference.
>
> Check both kasprintf() returns. On failure unwind any allocated name
> buffer and the spinlock, then fall through to the existing err label
> which sets clks[] to ERR_PTR(-ENOMEM). Freeing the spinlock on the
> error path is correct here because no clk_register_*() call has had
> a chance to take ownership of it; the success path intentionally
> hands it off to the registered clocks.
>
> The neighbouring zynq_clk_register_fclk() in the same file already
> uses this per-allocation goto-label cleanup pattern; this change
> brings periph_clk into line with it.
>
> Signed-off-by: William Theesfeld <william@theesfeld.net>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
From: Vincent Mailhol @ 2026-06-15 16:08 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Richard Henderson, Matt Turner, Magnus Lindholm,
linux-alpha, Vineet Gupta, linux-snps-arc, Russell King,
linux-arm-kernel, Catalin Marinas, Will Deacon, Huacai Chen,
WANG Xuerui, loongarch, Thomas Bogendoerfer, linux-mips,
James E.J. Bottomley, Helge Deller, linux-parisc,
Madhavan Srinivasan, Michael Ellerman, linuxppc-dev,
Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev, linux-s390,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Jonathan Corbet, Shuah Khan, linux-doc
DPS [1] defines GPT partition type UUIDs for OS partitions and
attributes that control whether such partitions should be
automatically discovered. The specification states that:
The OS can discover and mount the necessary file systems with a
non-existent or incomplete /etc/fstab file and without the root=
kernel command line option.
DPS is already implemented in systemd-gpt-auto-generator [2], which,
when embedded in an initrd, indeed allows automatic detection of the
root filesystem through its partition type UUID.
This series adds this discovery feature directly into the kernel so
that people who are not using systemd or not using an initrd can still
benefit from it. The implementation follows the same model as
systemd-gpt-auto-generator:
- GPT partition type UUIDs are used for automatic discovery policy
only. No root=PARTTYPEUUID=xxx cmdline option or similar syntax is
added.
- The root= cmdline option takes precedence. This prevents unexpected
behaviour.
- Only the disk with the active EFI System Partition is scanned, as
required by DPS. The disk is identified through the Boot Loader
Interface LoaderDevicePartUUID EFI variable.
The DPS no-auto attribute is also implemented, giving another option for
the user to disable this auto discovery. However, the DPS read-only
attribute is intentionally not enforced. The kernel already mounts the
root filesystem read-only by default unless the command line requests
rw, and user space remains responsible for deciding whether a discovered
root should later be remounted read-write based on DPS metadata and
local policy. The other partition type UUIDs (home, swap, var...) are
also out of scope for the same reason: user space remains responsible
for mounting anything other than the root partition.
Patch 1 adds the ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID capability and
the hidden CONFIG_DPS_ROOT_AUTO_DISCOVERY Kconfig symbol used to signal
whether the feature is available. Patches 2 to 12 declare the
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID capability for the supported
architectures and define their architecture-specific root partition type
UUID values in asm/dps_root.h.
Patches 13 to 16 make the GPT partition type UUID and the no-auto
attribute available during early block lookup.
Patch 17 is a small code refactor that prepares for patch 18, which
updates the root mount path so that, when root= is omitted, the kernel
reads LoaderDevicePartUUID and uses the early block lookup
infrastructure to discover the DPS root partition on that disk.
Finally, patch 19 documents this automatic root discovery feature.
Tested with GRUB, which implements the LoaderDevicePartUUID EFI variable
in its bli module [3]. With this, I was able to boot a kernel with a
completely empty cmdline and no initrd.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
[2] systemd-gpt-auto-generator
Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
[3] GRUB -- §16.2 bli
Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Vincent Mailhol (19):
init: add DPS root partition type UUID capability
alpha: define DPS root partition type UUID
arc: define DPS root partition type UUID
arm: define DPS root partition type UUID
arm64: define DPS root partition type UUID
loongarch: define DPS root partition type UUID
mips: define DPS root partition type UUIDs
parisc: define DPS root partition type UUID
powerpc: define DPS root partition type UUIDs
riscv: define DPS root partition type UUIDs
s390: define DPS root partition type UUIDs
x86: define DPS root partition type UUIDs
block: store GPT partition type UUID
block: add early_lookup_bdev_by_type_uuid()
block: store GPT attributes as a raw value
block: don't discover partition with DPS no-auto GPT attribute
init: factor out root device lookup into lookup_root_device()
init: discover root by DPS partition type UUID
docs: document discoverable root partitions
Documentation/admin-guide/discoverable-root.rst | 33 +++++++++
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/kernel-parameters.txt | 5 ++
arch/alpha/Kconfig | 1 +
arch/alpha/include/asm/dps_root.h | 8 +++
arch/arc/Kconfig | 1 +
arch/arc/include/asm/dps_root.h | 8 +++
arch/arm/Kconfig | 1 +
arch/arm/include/asm/dps_root.h | 8 +++
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dps_root.h | 8 +++
arch/loongarch/Kconfig | 1 +
arch/loongarch/include/asm/dps_root.h | 8 +++
arch/mips/Kconfig | 1 +
arch/mips/include/asm/dps_root.h | 20 ++++++
arch/parisc/Kconfig | 1 +
arch/parisc/include/asm/dps_root.h | 8 +++
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/dps_root.h | 16 +++++
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/dps_root.h | 12 ++++
arch/s390/Kconfig | 1 +
arch/s390/include/asm/dps_root.h | 12 ++++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/dps_root.h | 12 ++++
block/blk.h | 1 +
block/early-lookup.c | 68 +++++++++++++++++-
block/partitions/core.c | 2 +
block/partitions/efi.c | 3 +
block/partitions/efi.h | 11 ++-
include/linux/blk_types.h | 1 +
include/linux/blkdev.h | 5 ++
include/linux/root_dev.h | 6 ++
init/Kconfig | 6 ++
init/do_mounts.c | 94 ++++++++++++++++++++++++-
35 files changed, 355 insertions(+), 12 deletions(-)
---
base-commit: 36808d5e983985bbda87e01059cccc071fe3ec8d
change-id: 20260611-discoverable-root_partitions-bdacbada570d
Best regards,
--
Vincent Mailhol <mailhol@kernel.org>
^ permalink raw reply
* [PATCH 04/19] arm: define DPS root partition type UUID
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Russell King, linux-arm-kernel
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for ARM and select
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/dps_root.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 73e6647bea46..deedb5d808fb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM
select ARCH_HAS_DMA_ALLOC if MMU
select ARCH_HAS_DMA_OPS
select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
diff --git a/arch/arm/include/asm/dps_root.h b/arch/arm/include/asm/dps_root.h
new file mode 100644
index 000000000000..e9f0f24bcac2
--- /dev/null
+++ b/arch/arm/include/asm/dps_root.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_ARM_DPS_ROOT_H
+#define _ASM_ARM_DPS_ROOT_H
+
+#define DPS_ROOT_PARTITION_TYPE_UUID "69dad710-2ce4-4e3c-b16c-21a1d49abed3"
+
+#endif /* _ASM_ARM_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 05/19] arm64: define DPS root partition type UUID
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for arm64 and select
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dps_root.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fe60738e5943..190f8dde63b2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -26,6 +26,7 @@ config ARM64
select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DMA_OPS if XEN
select ARCH_HAS_DMA_PREP_COHERENT
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
diff --git a/arch/arm64/include/asm/dps_root.h b/arch/arm64/include/asm/dps_root.h
new file mode 100644
index 000000000000..7344f9a52343
--- /dev/null
+++ b/arch/arm64/include/asm/dps_root.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_ARM64_DPS_ROOT_H
+#define _ASM_ARM64_DPS_ROOT_H
+
+#define DPS_ROOT_PARTITION_TYPE_UUID "b921b045-1df0-41c3-af44-4c6f280d3fae"
+
+#endif /* _ASM_ARM64_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v1 11/11] KVM: arm64: Implement lazy vCPU state sync for non-protected guests
From: Vincent Donnefort @ 2026-06-15 16:25 UTC (permalink / raw)
To: tabba
Cc: Marc Zyngier, Oliver Upton, Will Deacon, Catalin Marinas,
Quentin Perret, Sebastian Ene, Per Larsen, Suzuki K Poulose,
Zenghui Yu, Joey Gouly, Steffen Eiden, Mark Rutland,
Jonathan Cameron, Hyunwoo Kim, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <20260612065925.755562-12-tabba@google.com>
On Fri, Jun 12, 2026 at 07:59:25AM +0100, tabba@google.com wrote:
> pKVM copies a non-protected guest's register context between the host
> and the hypervisor on every world switch, even when the host never
> inspects it. Defer the copy: on entry, flush the host context into the
> hyp vCPU only when the host marked it dirty (PKVM_HOST_STATE_DIRTY); on
> exit, leave it in the hyp vCPU and copy it back only when the host needs
> it, via a __pkvm_vcpu_sync_state hypercall on trap handling or at vcpu
> put. A protected guest's context is copied as before, since lazy sync
> only helps where the host is trusted to see the guest's registers.
>
> The PC is the exception: it is copied back on every exit so the
> kvm_exit tracepoint reports the guest's real exit PC rather than the
> value left by the previous sync.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
> arch/arm64/include/asm/kvm_asm.h | 1 +
> arch/arm64/include/asm/kvm_host.h | 2 +
> arch/arm64/kvm/arm.c | 7 +++
> arch/arm64/kvm/handle_exit.c | 22 ++++++++
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 88 ++++++++++++++++++++++++++++--
> 5 files changed, 115 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index 043495f7fc78..6e1135b3ded4 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -113,6 +113,7 @@ enum __kvm_host_smccc_func {
> __KVM_HOST_SMCCC_FUNC___pkvm_finalize_teardown_vm,
> __KVM_HOST_SMCCC_FUNC___pkvm_vcpu_load,
> __KVM_HOST_SMCCC_FUNC___pkvm_vcpu_put,
> + __KVM_HOST_SMCCC_FUNC___pkvm_vcpu_sync_state,
> __KVM_HOST_SMCCC_FUNC___pkvm_tlb_flush_vmid,
>
> MARKER(__KVM_HOST_SMCCC_FUNC_MAX)
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index a49042bfa801..1ef660774adc 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -1113,6 +1113,8 @@ struct kvm_vcpu_arch {
> /* SError pending for nested guest */
> #define NESTED_SERROR_PENDING __vcpu_single_flag(sflags, BIT(8))
>
> +/* pKVM host vcpu state is dirty, needs resync (nVHE-only) */
nit: with hVHE, I guess we can just drop that nVHE-only?
> +#define PKVM_HOST_STATE_DIRTY __vcpu_single_flag(iflags, BIT(4))
>
> /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
> #define vcpu_sve_pffr(vcpu) (kern_hyp_va((vcpu)->arch.sve_state) + \
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index c9f36932c980..a5c54e37778b 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -734,6 +734,10 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
> if (is_protected_kvm_enabled()) {
> kvm_call_hyp(__vgic_v3_save_aprs, &vcpu->arch.vgic_cpu.vgic_v3);
> kvm_call_hyp_nvhe(__pkvm_vcpu_put);
> +
> + /* __pkvm_vcpu_put implies a sync of the state */
> + if (!kvm_vm_is_protected(vcpu->kvm))
> + vcpu_set_flag(vcpu, PKVM_HOST_STATE_DIRTY);
> }
>
> kvm_vcpu_put_debug(vcpu);
> @@ -961,6 +965,9 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> return ret;
>
> if (is_protected_kvm_enabled()) {
> + /* Start with the vcpu in a dirty state */
> + if (!kvm_vm_is_protected(vcpu->kvm))
> + vcpu_set_flag(vcpu, PKVM_HOST_STATE_DIRTY);
> ret = pkvm_create_hyp_vm(kvm);
> if (ret)
> return ret;
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 54aedf93c78b..dccc3786548b 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -422,6 +422,21 @@ static int handle_trap_exceptions(struct kvm_vcpu *vcpu)
> {
> int handled;
>
> + /*
> + * If we run a non-protected VM when protection is enabled
> + * system-wide, resync the state from the hypervisor and mark
> + * it as dirty on the host side if it wasn't dirty already
> + * (which could happen if preemption has taken place).
> + */
> + if (is_protected_kvm_enabled() && !kvm_vm_is_protected(vcpu->kvm)) {
> + preempt_disable();
nit: since we are introducing guard() with that series, this one could be
guard(preempt)().
> + if (!(vcpu_get_flag(vcpu, PKVM_HOST_STATE_DIRTY))) {
> + kvm_call_hyp_nvhe(__pkvm_vcpu_sync_state);
> + vcpu_set_flag(vcpu, PKVM_HOST_STATE_DIRTY);
> + }
> + preempt_enable();
> + }
> +
> /*
> * See ARM ARM B1.14.1: "Hyp traps on instructions
> * that fail their condition code check"
> @@ -489,6 +504,13 @@ int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
> /* For exit types that need handling before we can be preempted */
> void handle_exit_early(struct kvm_vcpu *vcpu, int exception_index)
> {
> + /*
> + * We just exited, so the state is clean from a hypervisor
> + * perspective.
> + */
> + if (is_protected_kvm_enabled())
> + vcpu_clear_flag(vcpu, PKVM_HOST_STATE_DIRTY);
> +
> if (ARM_SERROR_PENDING(exception_index)) {
> if (this_cpu_has_cap(ARM64_HAS_RAS_EXTN)) {
> u64 disr = kvm_vcpu_get_disr(vcpu);
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 23e644c24a03..02383b372258 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -139,6 +139,49 @@ static void sync_hyp_vgic_state(struct pkvm_hyp_vcpu *hyp_vcpu)
> host_cpu_if->vgic_lr[i] = hyp_cpu_if->vgic_lr[i];
> }
>
> +
> +static void __copy_vcpu_state(const struct kvm_vcpu *from_vcpu,
> + struct kvm_vcpu *to_vcpu)
> +{
> + int i;
> +
> + to_vcpu->arch.ctxt.regs = from_vcpu->arch.ctxt.regs;
> + to_vcpu->arch.ctxt.spsr_abt = from_vcpu->arch.ctxt.spsr_abt;
> + to_vcpu->arch.ctxt.spsr_und = from_vcpu->arch.ctxt.spsr_und;
> + to_vcpu->arch.ctxt.spsr_irq = from_vcpu->arch.ctxt.spsr_irq;
> + to_vcpu->arch.ctxt.spsr_fiq = from_vcpu->arch.ctxt.spsr_fiq;
> + to_vcpu->arch.ctxt.fp_regs = from_vcpu->arch.ctxt.fp_regs;
> +
> + /*
> + * Copy the sysregs, but don't mess with the timer state which
> + * is directly handled by EL1 and is expected to be preserved.
> + * enum vcpu_sysreg is sparse: VNCR-mapped registers take values
> + * derived from their VNCR page offset, so the timer registers do
> + * not form a contiguous numeric range and must be skipped by name.
> + */
> + for (i = 1; i < NR_SYS_REGS; i++) {
> + switch (i) {
> + case CNTVOFF_EL2:
> + case CNTV_CVAL_EL0:
> + case CNTV_CTL_EL0:
> + case CNTP_CVAL_EL0:
> + case CNTP_CTL_EL0:
> + continue;
> + }
> + to_vcpu->arch.ctxt.sys_regs[i] = from_vcpu->arch.ctxt.sys_regs[i];
> + }
> +}
> +
> +static void __sync_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
> +{
> + __copy_vcpu_state(&hyp_vcpu->vcpu, hyp_vcpu->host_vcpu);
> +}
> +
> +static void __flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
> +{
> + __copy_vcpu_state(hyp_vcpu->host_vcpu, &hyp_vcpu->vcpu);
> +}
nit: Could that be flush/sync_hyp_vcpu_state? as everything this is called
"state" and we already have flush_debug_state() below ?
> +
> static void flush_debug_state(struct pkvm_hyp_vcpu *hyp_vcpu)
> {
> struct kvm_vcpu *host_vcpu = hyp_vcpu->host_vcpu;
> @@ -168,7 +211,17 @@ static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
> fpsimd_sve_flush();
> flush_debug_state(hyp_vcpu);
>
> - hyp_vcpu->vcpu.arch.ctxt = host_vcpu->arch.ctxt;
> + /*
> + * If we deal with a non-protected guest and the state is potentially
> + * dirty (from a host perspective), copy the state back into the hyp
> + * vcpu.
> + */
> + if (!pkvm_hyp_vcpu_is_protected(hyp_vcpu)) {
> + if (vcpu_get_flag(host_vcpu, PKVM_HOST_STATE_DIRTY))
> + __flush_hyp_vcpu(hyp_vcpu);
> + } else {
> + hyp_vcpu->vcpu.arch.ctxt = host_vcpu->arch.ctxt;
> + }
>
> hyp_vcpu->vcpu.arch.mdcr_el2 = host_vcpu->arch.mdcr_el2;
> hyp_vcpu->vcpu.arch.hcr_el2 &= ~(HCR_TWI | HCR_TWE);
> @@ -191,9 +244,11 @@ static void sync_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
> fpsimd_sve_sync(&hyp_vcpu->vcpu);
> sync_debug_state(hyp_vcpu);
>
> - host_vcpu->arch.ctxt = hyp_vcpu->vcpu.arch.ctxt;
> -
> - host_vcpu->arch.hcr_el2 = hyp_vcpu->vcpu.arch.hcr_el2;
> + if (pkvm_hyp_vcpu_is_protected(hyp_vcpu))
> + host_vcpu->arch.ctxt = hyp_vcpu->vcpu.arch.ctxt;
> + else
> + /* Keep the PC current for the kvm_exit tracepoint (lazy ctxt sync). */
> + host_vcpu->arch.ctxt.regs.pc = hyp_vcpu->vcpu.arch.ctxt.regs.pc;
>
> host_vcpu->arch.fault = hyp_vcpu->vcpu.arch.fault;
>
> @@ -227,8 +282,30 @@ static void handle___pkvm_vcpu_put(struct kvm_cpu_context *host_ctxt)
> {
> struct pkvm_hyp_vcpu *hyp_vcpu = pkvm_get_loaded_hyp_vcpu();
>
> - if (hyp_vcpu)
> + if (hyp_vcpu) {
> + struct kvm_vcpu *host_vcpu = hyp_vcpu->host_vcpu;
> +
> + if (!pkvm_hyp_vcpu_is_protected(hyp_vcpu) &&
> + !vcpu_get_flag(host_vcpu, PKVM_HOST_STATE_DIRTY)) {
> + __sync_hyp_vcpu(hyp_vcpu);
> + }
> +
> pkvm_put_hyp_vcpu(hyp_vcpu);
> + }
> +}
> +
> +static void handle___pkvm_vcpu_sync_state(struct kvm_cpu_context *host_ctxt)
> +{
> + struct pkvm_hyp_vcpu *hyp_vcpu;
> +
> + if (!is_protected_kvm_enabled())
> + return;
Since "KVM: arm64: Remove is_protected_kvm_enabled() checks from hypercalls" we
got rid of those is_protected_kvm_enabled() for pKVM-only HVCs. (also, it is
declared in the pKVM-only section of the HVCs)
> +
> + hyp_vcpu = pkvm_get_loaded_hyp_vcpu();
> + if (!hyp_vcpu || pkvm_hyp_vcpu_is_protected(hyp_vcpu))
> + return;
> +
> + __sync_hyp_vcpu(hyp_vcpu);
> }
>
> static struct kvm_vcpu *__get_host_hyp_vcpus(struct kvm_vcpu *arg,
> @@ -859,6 +936,7 @@ static const hcall_t host_hcall[] = {
> HANDLE_FUNC(__pkvm_finalize_teardown_vm),
> HANDLE_FUNC(__pkvm_vcpu_load),
> HANDLE_FUNC(__pkvm_vcpu_put),
> + HANDLE_FUNC(__pkvm_vcpu_sync_state),
> HANDLE_FUNC(__pkvm_tlb_flush_vmid),
> };
>
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH net-next v7 11/12] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC
From: Benjamin Larsson @ 2026-06-15 16:31 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-12-ansuelsmth@gmail.com>
Hi.
On 15/06/2026 14:29, Christian Marangi wrote:
> Add PCS driver for Airoha AN7581 SoC for Ethernet/PON/PCIe/USB SERDES
> and permit usage of external PHY or connected SFP cage. Supported modes
> are USXGMII, 10G-BASER, 2500BASE-X, 1000BASE-X and SGMII.
>
> The driver probe and register the various needed registers and register as
> a PCS provider for fwnode usage.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/pcs/Kconfig | 2 +
> drivers/net/pcs/Makefile | 2 +
> drivers/net/pcs/airoha/Kconfig | 12 +
> drivers/net/pcs/airoha/Makefile | 7 +
> drivers/net/pcs/airoha/pcs-airoha-common.c | 1318 ++++++++++++
> drivers/net/pcs/airoha/pcs-airoha.h | 1309 ++++++++++++
> drivers/net/pcs/airoha/pcs-an7581.c | 2093 ++++++++++++++++++++
> 7 files changed, 4743 insertions(+)
> create mode 100644 drivers/net/pcs/airoha/Kconfig
> create mode 100644 drivers/net/pcs/airoha/Makefile
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha-common.c
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha.h
> create mode 100644 drivers/net/pcs/airoha/pcs-an7581.c
Most likely there will be pcs drivers for the EN7523 platform also. Can
the common code for an7581 have an7581 in the name instead of airoha?
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH v10 4/6] clk: Add KUnit tests for assigned-clock-sscs
From: Brian Masney @ 2026-06-15 16:40 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sudeep Holla, Cristian Marussi, Sebin Francis,
linux-kernel, linux-clk, devicetree, arm-scmi, linux-arm-kernel,
Peng Fan
In-Reply-To: <20260612-clk-v10-v10-4-eb92484eda38@nxp.com>
On Fri, Jun 12, 2026 at 04:46:26PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add KUnit test coverage for the assigned-clock-sscs DT property that
> configures spread spectrum on clocks before they are used.
>
> Extend the existing test infrastructure to support spread spectrum:
> - Add struct clk_spread_spectrum field to clk_dummy_context and a
> clk_dummy_set_spread_spectrum callback
> - Wire set_spread_spectrum into all dummy clock ops
> - Extend clk_assigned_rates_register_clk and test parameter struct
> to propagate initial SSCS values
>
> Add a new separate test suite clk_assigned_sscs with three categories:
>
> 1. clk_assigned_sscs_assigns_one — verifies that a single
> assigned-clock-sscs entry correctly configures spread spectrum
> on one clock, testing both provider and consumer paths
>
> 2. clk_assigned_sscs_assigns_multiple — verifies that multiple
> assigned-clock-sscs entries configure spread spectrum on two
> clocks, testing both provider and consumer paths
>
> 3. clk_assigned_sscs_skips — verifies that malformed DT properties
> are correctly skipped without error: missing assigned-clocks,
> zero-valued SSCS, and null phandles, tested for both provider
> and consumer scenarios
>
> New DT overlays are added for all test scenarios:
> - kunit_clk_assigned_sscs_one{,consumer} — single valid entry
> - kunit_clk_assigned_sscs_multiple{,consumer} — two valid entries
> - kunit_clk_assigned_sscs_without{,consumer} — missing assigned-clocks
> - kunit_clk_assigned_sscs_zero{,consumer} — all-zero SSCS values
> - kunit_clk_assigned_sscs_null{,consumer} — null phandle
>
> Co-developed-by: Brian Masney <bmasney@redhat.com>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Looks good to me.
It's probably not appropriate for me to also put a Reviewed-by here.
Brian
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: clock: clocking-wizard: Make s_axi_aclk optional for static-config
From: Conor Dooley @ 2026-06-15 16:42 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-clk, linux-kernel, git, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Michal Simek,
devicetree, linux-arm-kernel
In-Reply-To: <20260615034845.3320286-4-shubhrajyoti.datta@amd.com>
[-- Attachment #1: Type: text/plain, Size: 77 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
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