* Re: [PATCH 09/18] KVM: arm64: vgic-v5: Limit support to 64 PPIs
From: Joey Gouly @ 2026-04-17 16:10 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260415115559.2227718-10-maz@kernel.org>
On Wed, Apr 15, 2026 at 12:55:50PM +0100, Marc Zyngier wrote:
> Although we have some code supporting 128 PPIs, the only supported
> configuration is 64 PPIs. There is no way to test the 128 PPI code,
> so it is bound to bitrot very quickly.
>
> Given that KVM/arm64's goal has always been to stick to non-IMPDEF
> behaviours, drop the 128 PPI support. Someone motivated enough and
> with very strong arguments can always bring it back -- it's all in
> the git history.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> ---
> arch/arm64/kvm/hyp/vgic-v5-sr.c | 82 ++++++---------------------
> arch/arm64/kvm/sys_regs.c | 17 +++---
> arch/arm64/kvm/vgic/vgic-kvm-device.c | 9 +--
> 3 files changed, 26 insertions(+), 82 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/vgic-v5-sr.c b/arch/arm64/kvm/hyp/vgic-v5-sr.c
> index 47e6bcd437029..6d69dfe89a96c 100644
> --- a/arch/arm64/kvm/hyp/vgic-v5-sr.c
> +++ b/arch/arm64/kvm/hyp/vgic-v5-sr.c
> @@ -30,10 +30,9 @@ void __vgic_v5_save_ppi_state(struct vgic_v5_cpu_if *cpu_if)
> {
> /*
> * The following code assumes that the bitmap storage that we have for
> - * PPIs is either 64 (architected PPIs, only) or 128 bits (architected &
> - * impdef PPIs).
> + * PPIs is either 64 (architected PPIs, only).
> */
> - BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS % 64);
> + BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS != 64);
>
> bitmap_write(host_data_ptr(vgic_v5_ppi_state)->activer_exit,
> read_sysreg_s(SYS_ICH_PPI_ACTIVER0_EL2), 0, 64);
> @@ -49,22 +48,6 @@ void __vgic_v5_save_ppi_state(struct vgic_v5_cpu_if *cpu_if)
> cpu_if->vgic_ppi_priorityr[6] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR6_EL2);
> cpu_if->vgic_ppi_priorityr[7] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR7_EL2);
>
> - if (VGIC_V5_NR_PRIVATE_IRQS == 128) {
> - bitmap_write(host_data_ptr(vgic_v5_ppi_state)->activer_exit,
> - read_sysreg_s(SYS_ICH_PPI_ACTIVER1_EL2), 64, 64);
> - bitmap_write(host_data_ptr(vgic_v5_ppi_state)->pendr,
> - read_sysreg_s(SYS_ICH_PPI_PENDR1_EL2), 64, 64);
> -
> - cpu_if->vgic_ppi_priorityr[8] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR8_EL2);
> - cpu_if->vgic_ppi_priorityr[9] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR9_EL2);
> - cpu_if->vgic_ppi_priorityr[10] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR10_EL2);
> - cpu_if->vgic_ppi_priorityr[11] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR11_EL2);
> - cpu_if->vgic_ppi_priorityr[12] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR12_EL2);
> - cpu_if->vgic_ppi_priorityr[13] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR13_EL2);
> - cpu_if->vgic_ppi_priorityr[14] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR14_EL2);
> - cpu_if->vgic_ppi_priorityr[15] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR15_EL2);
> - }
> -
> /* Now that we are done, disable DVI */
> write_sysreg_s(0, SYS_ICH_PPI_DVIR0_EL2);
> write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
> @@ -74,9 +57,6 @@ void __vgic_v5_restore_ppi_state(struct vgic_v5_cpu_if *cpu_if)
> {
> DECLARE_BITMAP(pendr, VGIC_V5_NR_PRIVATE_IRQS);
>
> - /* We assume 64 or 128 PPIs - see above comment */
> - BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS % 64);
> -
> /* Enable DVI so that the guest's interrupt config takes over */
> write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_dvir, 0, 64),
> SYS_ICH_PPI_DVIR0_EL2);
> @@ -108,50 +88,20 @@ void __vgic_v5_restore_ppi_state(struct vgic_v5_cpu_if *cpu_if)
> write_sysreg_s(cpu_if->vgic_ppi_priorityr[7],
> SYS_ICH_PPI_PRIORITYR7_EL2);
>
> - if (VGIC_V5_NR_PRIVATE_IRQS == 128) {
> - /* Enable DVI so that the guest's interrupt config takes over */
> - write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_dvir, 64, 64),
> - SYS_ICH_PPI_DVIR1_EL2);
> -
> - write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_activer, 64, 64),
> - SYS_ICH_PPI_ACTIVER1_EL2);
> - write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_enabler, 64, 64),
> - SYS_ICH_PPI_ENABLER1_EL2);
> - write_sysreg_s(bitmap_read(pendr, 64, 64),
> - SYS_ICH_PPI_PENDR1_EL2);
> -
> - write_sysreg_s(cpu_if->vgic_ppi_priorityr[8],
> - SYS_ICH_PPI_PRIORITYR8_EL2);
> - write_sysreg_s(cpu_if->vgic_ppi_priorityr[9],
> - SYS_ICH_PPI_PRIORITYR9_EL2);
> - write_sysreg_s(cpu_if->vgic_ppi_priorityr[10],
> - SYS_ICH_PPI_PRIORITYR10_EL2);
> - write_sysreg_s(cpu_if->vgic_ppi_priorityr[11],
> - SYS_ICH_PPI_PRIORITYR11_EL2);
> - write_sysreg_s(cpu_if->vgic_ppi_priorityr[12],
> - SYS_ICH_PPI_PRIORITYR12_EL2);
> - write_sysreg_s(cpu_if->vgic_ppi_priorityr[13],
> - SYS_ICH_PPI_PRIORITYR13_EL2);
> - write_sysreg_s(cpu_if->vgic_ppi_priorityr[14],
> - SYS_ICH_PPI_PRIORITYR14_EL2);
> - write_sysreg_s(cpu_if->vgic_ppi_priorityr[15],
> - SYS_ICH_PPI_PRIORITYR15_EL2);
> - } else {
> - write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
> -
> - write_sysreg_s(0, SYS_ICH_PPI_ACTIVER1_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_ENABLER1_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_PENDR1_EL2);
> -
> - write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR8_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR9_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR10_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR11_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR12_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR13_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR14_EL2);
> - write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR15_EL2);
> - }
> + write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
> +
> + write_sysreg_s(0, SYS_ICH_PPI_ACTIVER1_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_ENABLER1_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_PENDR1_EL2);
> +
> + write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR8_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR9_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR10_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR11_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR12_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR13_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR14_EL2);
> + write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR15_EL2);
> }
>
> void __vgic_v5_save_state(struct vgic_v5_cpu_if *cpu_if)
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 4ef13ac0703df..eba3ef793097d 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -724,6 +724,7 @@ static bool access_gicv5_ppi_enabler(struct kvm_vcpu *vcpu,
> {
> unsigned long *mask = vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask;
> struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
> + unsigned long reg = p->regval;
> int i;
>
> /* We never expect to get here with a read! */
> @@ -731,21 +732,17 @@ static bool access_gicv5_ppi_enabler(struct kvm_vcpu *vcpu,
> return undef_access(vcpu, p, r);
>
> /*
> - * If we're only handling architected PPIs and the guest writes to the
> - * enable for the non-architected PPIs, we just return as there's
> - * nothing to do at all. We don't even allocate the storage for them in
> - * this case.
> + * As we're only handling architected PPIs, the guest writes to the
> + * enable for the non-architected PPIs just return as there's
> + * nothing to do at all. We don't even allocate the storage for them.
> */
> - if (VGIC_V5_NR_PRIVATE_IRQS == 64 && p->Op2 % 2)
> + if (p->Op2 % 2)
> return true;
>
> /*
> - * Merge the raw guest write into out bitmap at an offset of either 0 or
> - * 64, then and it with our PPI mask.
> + * Merge the raw guest write into out bitmap, anded with our PPI mask.
> */
> - bitmap_write(cpu_if->vgic_ppi_enabler, p->regval, 64 * (p->Op2 % 2), 64);
> - bitmap_and(cpu_if->vgic_ppi_enabler, cpu_if->vgic_ppi_enabler, mask,
> - VGIC_V5_NR_PRIVATE_IRQS);
> + bitmap_and(cpu_if->vgic_ppi_enabler, ®, mask, VGIC_V5_NR_PRIVATE_IRQS);
>
> /*
> * Sync the change in enable states to the vgic_irqs. We consider all
> diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
> index a96c77dccf353..90be99443df3b 100644
> --- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
> +++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
> @@ -730,18 +730,15 @@ static int vgic_v5_get_userspace_ppis(struct kvm_device *dev,
> guard(mutex)(&dev->kvm->arch.config_lock);
>
> /*
> - * We either support 64 or 128 PPIs. In the former case, we need to
> - * return 0s for the second 64 bits as we have no storage backing those.
> + * We only support 64 PPIs, so, we need to return 0s for the
> + * second 64 bits as we have no storage backing those.
> */
> ret = put_user(bitmap_read(gicv5_vm->userspace_ppis, 0, 64), uaddr);
> if (ret)
> return ret;
> uaddr++;
>
> - if (VGIC_V5_NR_PRIVATE_IRQS == 128)
> - ret = put_user(bitmap_read(gicv5_vm->userspace_ppis, 64, 128), uaddr);
> - else
> - ret = put_user(0, uaddr);
> + ret = put_user(0, uaddr);
>
> return ret;
> }
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH bpf-next v2] arm32, bpf: Reject BPF-to-BPF calls and callbacks in the JIT
From: Puranjay Mohan @ 2026-04-17 16:15 UTC (permalink / raw)
To: Emil Tsalapatis
Cc: bpf, linux-arm-kernel, Jonas Rebmann, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Song Liu, Russell King,
kernel
In-Reply-To: <DHVJQQK6L83L.13DDK8BJXQFXG@etsalapatis.com>
On Fri, Apr 17, 2026 at 4:48 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
>
> On Fri Apr 17, 2026 at 10:33 AM EDT, Puranjay Mohan wrote:
> > The ARM32 BPF JIT does not support BPF-to-BPF function calls
> > (BPF_PSEUDO_CALL) or callbacks (BPF_PSEUDO_FUNC), but it does
> > not reject them either.
> >
> > When a program with subprograms is loaded (e.g. libxdp's XDP
> > dispatcher uses __noinline__ subprograms, or any program using
> > callbacks like bpf_loop or bpf_for_each_map_elem), the verifier
> > invokes bpf_jit_subprogs() which calls bpf_int_jit_compile()
> > for each subprogram.
> >
> > For BPF_PSEUDO_CALL, since ARM32 does not reject it, the JIT
> > silently emits code using the wrong address computation:
> >
> > func = __bpf_call_base + imm
> >
> > where imm is a pc-relative subprogram offset, producing a bogus
> > function pointer.
> >
> > For BPF_PSEUDO_FUNC, the ldimm64 handler ignores src_reg and
> > loads the immediate as a normal 64-bit value without error.
> >
> > In both cases, build_body() reports success and a JIT image is
> > allocated. ARM32 lacks the jit_data/extra_pass mechanism needed
> > for the second JIT pass in bpf_jit_subprogs(). On the second
> > pass, bpf_int_jit_compile() performs a full fresh compilation,
> > allocating a new JIT binary and overwriting prog->bpf_func. The
> > first allocation is never freed. bpf_jit_subprogs() then detects
> > the function pointer changed and aborts with -ENOTSUPP, but the
> > original JIT binary has already been leaked. Each program
> > load/unload cycle leaks one JIT binary allocation, as reported
> > by kmemleak:
> >
> > unreferenced object 0xbf0a1000 (size 4096):
> > backtrace:
> > bpf_jit_binary_alloc+0x64/0xfc
> > bpf_int_jit_compile+0x14c/0x348
> > bpf_jit_subprogs+0x4fc/0xa60
> >
> > Fix this by rejecting both BPF_PSEUDO_CALL in the BPF_CALL
> > handler and BPF_PSEUDO_FUNC in the BPF_LD_IMM64 handler, falling
> > through to the existing 'notyet' path. This causes build_body()
> > to fail before any JIT binary is allocated, so
> > bpf_int_jit_compile() returns the original program unjitted.
> > bpf_jit_subprogs() then sees !prog->jited and cleanly falls
> > back to the interpreter with no leak.
>
> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
>
> The Fixes tag is a bit unrelated since it's for x64 but the original
> commit that adds the file (ddecdfcea0ae8 ?) is so far back it probably
> doesn't matter.
That fixes tag commit has verifier changes too:
-- 8< --
+ }
+ }
+ for (i = 0; i <= env->subprog_cnt; i++) {
+ old_bpf_func = func[i]->bpf_func;
+ tmp = bpf_int_jit_compile(func[i]);
+ if (tmp != func[i] || func[i]->bpf_func != old_bpf_func) {
+ verbose(env, "JIT doesn't support bpf-to-bpf calls\n");
+ err = -EFAULT;
+ goto out_free;
+ }
+ cond_resched();
+ }
+
-- >8 --
This call to bpf_int_jit_compile() is where the memory leak was
introduced, before this commit, there was no memory leak.
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Conor Dooley @ 2026-04-17 16:22 UTC (permalink / raw)
To: Jianhua Lin
Cc: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel, linux-media,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu
In-Reply-To: <20260417100519.1043-2-jianhua.lin@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 3203 bytes --]
On Fri, Apr 17, 2026 at 06:05:17PM +0800, Jianhua Lin wrote:
> Add the compatible string for the JPEG decoder block found in the
> MediaTek MT8189 SoC.
>
> Compared to previous generation ICs, the MT8189 JPEG decoder requires
> 34-bit IOVA address space support and only needs a single clock
> ("jpgdec") instead of two. Therefore, it is added as a standalone
> compatible string without falling back to older SoCs.
>
> Update the binding schema to include the new compatible string and add
> an `allOf` block with conditional checks. This enforces the single clock
> requirement for MT8189 while preserving the two-clock requirement
> ("jpgdec-smi", "jpgdec") for older SoCs.
>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> index a4aacd3eb189..fd895688a038 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> @@ -15,10 +15,10 @@ description: |-
> properties:
> compatible:
> oneOf:
> - - items:
> - - enum:
> - - mediatek,mt8173-jpgdec
> - - mediatek,mt2701-jpgdec
> + - enum:
> + - mediatek,mt2701-jpgdec
> + - mediatek,mt8173-jpgdec
> + - mediatek,mt8189-jpgdec
> - items:
> - enum:
> - mediatek,mt7623-jpgdec
> @@ -32,13 +32,20 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> maxItems: 2
> - minItems: 2
>
> clock-names:
> - items:
> - - const: jpgdec-smi
> - - const: jpgdec
> + oneOf:
> + - items:
> + - const: jpgdec
> + - items:
> + - const: jpgdec-smi
> + - const: jpgdec
> +
> + mediatek,larb:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: a phandle to the smi_larb node.
This should be restricted to only the new platform.
>
> power-domains:
> maxItems: 1
> @@ -60,6 +67,31 @@ required:
> - power-domains
> - iommus
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: mediatek,mt8189-jpgdec
> + then:
> + properties:
> + clocks:
> + minItems: 1
> + maxItems: 1
Constraints that duplicate the outtermost ones don't need to
be/shouldn't be repeated here. You only need the maxItems here and the
minItems in the else.
pw-bot: changes-requested
Cheers,
COnor.
> + clock-names:
> + minItems: 1
> + maxItems: 1
> + required:
> + - mediatek,larb
> + else:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 2
> + clock-names:
> + minItems: 2
> + maxItems: 2
> +
> additionalProperties: false
>
> examples:
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Cristian Ciocaltea @ 2026-04-17 16:34 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <2000470.6tgchFWduM@phil>
Hi Heiko,
On 4/17/26 2:32 PM, Heiko Stuebner wrote:
> Hi Cristian,
>
> the comments below apply sort of to all patches in that series.
>
> Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> The board exposes the GPIO4_C6 line to control the voltage bias on the
>> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
>> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>>
>> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
>> property and drop the line from the vcc_5v0_hdmi regulator to allow
>> adjusting the bias when transitioning between TMDS and FRL operating
>> modes.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> index 749f0a54b478..93ae37699366 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> @@ -140,10 +140,7 @@ regulator-state-mem {
>>
>> vcc_5v0_hdmi: regulator-vcc-5v0-hdmi {
>> compatible = "regulator-fixed";
>> - enable-active-high;
>> - gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
>> - pinctrl-names = "default";
>> - pinctrl-0 = <&hdmi_con_en>;
>> + regulator-always-on;
>> regulator-min-microvolt = <5000000>;
>> regulator-max-microvolt = <5000000>;
>> regulator-name = "vcc_5v0_hdmi";
>
> I think this regulator was sort of a complete hack, to set that
> gpio to some sort of default state, by declaring it as hdmi-pwr-supply.
>
> Only 2 rk3576 boards seem, to use that hack, so I think as that "regulator"
> is completely functionless now, the whole thing could be removed?
Ack, let's just drop it.
>
>
>> @@ -231,6 +228,8 @@ &gpu {
>> };
>>
>> &hdmi {
>> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
>> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>
> this should be sorted the other way around I think.
>
> Also please provide a pinctrl-names property too. If for whatever reason
> the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
> board DTs are staying in the "old" compatible mode until they are adapted.
Just to make sure I fully understand, the convention is that
pinctrl-names = "default";
should be always provided, even when the node overrides an existing pinctrl-0
property?
E.g. in rk3576.dtsi we have:
hdmi: hdmi@27da0000 {
...
pinctrl-names = "default";
pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
...
}
Hence I omitted pinctrl-names which doesn't change and just appended
&hdmi_frl_en to pinctrl-0's original value.
>
>
>> status = "okay";
>> };
>>
>> @@ -655,7 +654,7 @@ &pcie0 {
>>
>> &pinctrl {
>> hdmi {
>> - hdmi_con_en: hdmi-con-en {
>> + hdmi_frl_en: hdmi-frl-en {
>
> pinctrl names should ideally match the naming in schematics, for example the
> "HDMI0_TX_ON_H" for jaguar and tiger. This makes it way easier to> go from DT
> to schematics and back.
I opted for a more descriptive name that could be used consistently across all
boards, given that not all schematics are publicly available.
You make a fair point though, we should probably stick with the pretty terrible
hdmi[N]_tx_on_h naming instead.
Thanks,
Cristian
^ permalink raw reply
* [PATCH v3 0/8] Add VIM4 MCU/FAN support
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
The Khadas VIM4 board features a different MCU variant compared to
previous VIM boards.
While it shares the same I2C-based communication model,
it differs in some ways:
- A distinct register map with its own volatile/writeable register set
- A fan control with 0–100 levels instead of the 0–3 levels previously
- A fan power supply gated through a regulator
This series adds support for this new variant by:
1. Refactoring the khadas-mcu MFD driver to use per-variant data
structures (regmap config, cells, fan platform data),
and adding the khadas,vim4-mcu compatible string.
2. Extending the fan thermal driver to retrieve the fan register
and maximum level from platform_data,
and to optionally manage a power regulator for the fan supply.
3. Adding the corresponding DTS node for the VIM4, wiring the MCU to
the I2C AO_A bus and exposing it as a thermal cooling device.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v3:
- PATCH 1: adding comment on vim4 compatible saying it is not discoverable,
thanks to Rob's and Neil's feedback.
- Link to v2: https://lore.kernel.org/r/20260403-add-mcu-fan-khadas-vim4-v2-0-70536b22439a@aliel.fr
Changes in v2:
- PATCH 5: Add regulator_disable on suspend thanks to Neil's feedback.
- Link to v1: https://lore.kernel.org/r/20260402-add-mcu-fan-khadas-vim4-v1-0-2b12eb4ac7b0@aliel.fr
---
Ronald Claveau (8):
dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
dt-bindings: i2c: amlogic: Add compatible for T7 SOC
mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
mfd: khadas-mcu: Add support for VIM4 MCU variant
thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
arm64: dts: amlogic: t7: Add i2c pinctrl node
arm64: dts: amlogic: t7: Add i2c controller node
arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
.../bindings/i2c/amlogic,meson6-i2c.yaml | 13 ++-
.../devicetree/bindings/mfd/khadas,mcu.yaml | 5 +
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 20 ++++
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++---
drivers/thermal/khadas_mcu_fan.c | 49 ++++++++--
include/linux/mfd/khadas-mcu.h | 39 +++++++-
7 files changed, 222 insertions(+), 23 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH v3 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
The Khadas VIM4 MCU register is slightly different
from previous boards' MCU.
This board also features a switchable power source for its fan.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 084960fd5a1fd..a80718f7595ce 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- khadas,mcu # MCU revision is discoverable
+ - khadas,vim4-mcu # Different MCU variant, not discoverable
"#cooling-cells": # Only needed for boards having FAN control feature
const: 2
@@ -25,6 +26,10 @@ properties:
reg:
maxItems: 1
+ fan-supply:
+ description: Phandle to the regulator that powers the fan.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
required:
- compatible
- reg
--
2.49.0
^ permalink raw reply related
* [PATCH v3 3/8] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Introduce a per-variant configuration structure (khadas_mcu_data)
holding the regmap config and MFD cells,
selected at probe time via the of_device_id match data.
This makes adding other variants straightforward.
Also introduce khadas_mcu_fan_pdata to pass fan register address and
maximum level to the fan sub-driver, removing the hardcoded constants.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
include/linux/mfd/khadas-mcu.h | 39 +++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/khadas-mcu.h b/include/linux/mfd/khadas-mcu.h
index a99ba2ed0e4e0..75e275d3fa8d9 100644
--- a/include/linux/mfd/khadas-mcu.h
+++ b/include/linux/mfd/khadas-mcu.h
@@ -70,6 +70,13 @@
#define KHADAS_MCU_WOL_INIT_START_REG 0x87 /* WO */
#define KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG 0x88 /* WO */
+/* VIM4 specific registers */
+#define KHADAS_MCU_VIM4_REST_CONF_REG 0x2c /* WO - reset EEPROM */
+#define KHADAS_MCU_VIM4_LED_ON_RAM_REG 0x89 /* WO - LED volatile */
+#define KHADAS_MCU_VIM4_FAN_CTRL_REG 0x8a /* WO */
+#define KHADAS_MCU_VIM4_WDT_EN_REG 0x8b /* WO */
+#define KHADAS_MCU_VIM4_SYS_RST_REG 0x91 /* WO */
+
enum {
KHADAS_BOARD_VIM1 = 0x1,
KHADAS_BOARD_VIM2,
@@ -82,10 +89,38 @@ enum {
* struct khadas_mcu - Khadas MCU structure
* @device: device reference used for logs
* @regmap: register map
+ * @data: pointer to variant-specific config
*/
struct khadas_mcu {
- struct device *dev;
- struct regmap *regmap;
+ struct device *dev;
+ struct regmap *regmap;
+ const struct khadas_mcu_data *data;
+};
+
+/**
+ * struct khadas_mcu_data - per-variant configuration
+ * @regmap_config: regmap configuration
+ * @cells: MFD sub-devices
+ * @ncells: number of sub-devices
+ * @fan_cells: MFD fan sub-devices
+ * @nfan_cells: number of fan sub-devices
+ */
+struct khadas_mcu_data {
+ const struct regmap_config *regmap_config;
+ const struct mfd_cell *cells;
+ int ncells;
+ const struct mfd_cell *fan_cells;
+ int nfan_cells;
+};
+
+/**
+ * struct khadas_mcu_fan_pdata - fan sub-driver configuration
+ * @fan_reg: register address to write the fan level
+ * @max_level: maximum fan level
+ */
+struct khadas_mcu_fan_pdata {
+ unsigned int fan_reg;
+ unsigned int max_level;
};
#endif /* MFD_KHADAS_MCU_H */
--
2.49.0
^ permalink raw reply related
* [PATCH v3 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Add the T7 SOC compatible which fallback to AXG compatible.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
index c4cc8af182807..7b59b60b62e5b 100644
--- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
@@ -16,10 +16,15 @@ allOf:
properties:
compatible:
- enum:
- - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
- - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
- - amlogic,meson-axg-i2c # AXG and compatible SoCs
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,t7-i2c
+ - const: amlogic,meson-axg-i2c
+ - enum:
+ - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
+ - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
+ - amlogic,meson-axg-i2c # AXG and compatible SoCs
reg:
maxItems: 1
--
2.49.0
^ permalink raw reply related
* [PATCH v3 4/8] mfd: khadas-mcu: Add support for VIM4 MCU variant
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Refactor probe() to use per-variant khadas_mcu_data
instead of hardcoded globals.
Add dedicated regmap configuration and device data for the VIM4 MCU,
with its own volatile/writeable registers.
Add the fan control register
(0–100 levels vs 0–3 for previous supported boards).
Add a new compatible string "khadas,vim4-mcu".
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 95 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
index ba981a7886921..b36b3b3ab73c0 100644
--- a/drivers/mfd/khadas-mcu.c
+++ b/drivers/mfd/khadas-mcu.c
@@ -75,15 +75,91 @@ static const struct regmap_config khadas_mcu_regmap_config = {
.cache_type = REGCACHE_MAPLE,
};
+static const struct khadas_mcu_fan_pdata khadas_mcu_fan_pdata = {
+ .fan_reg = KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
+ .max_level = 3,
+};
+
static struct mfd_cell khadas_mcu_fan_cells[] = {
/* VIM1/2 Rev13+ and VIM3 only */
- { .name = "khadas-mcu-fan-ctrl", },
+ {
+ .name = "khadas-mcu-fan-ctrl",
+ .platform_data = &khadas_mcu_fan_pdata,
+ .pdata_size = sizeof(khadas_mcu_fan_pdata),
+ },
};
static struct mfd_cell khadas_mcu_cells[] = {
{ .name = "khadas-mcu-user-mem", },
};
+static const struct khadas_mcu_data khadas_mcu_data = {
+ .regmap_config = &khadas_mcu_regmap_config,
+ .cells = khadas_mcu_cells,
+ .ncells = ARRAY_SIZE(khadas_mcu_cells),
+ .fan_cells = khadas_mcu_fan_cells,
+ .nfan_cells = ARRAY_SIZE(khadas_mcu_fan_cells),
+};
+
+static bool khadas_mcu_vim4_reg_volatile(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case KHADAS_MCU_PWR_OFF_CMD_REG:
+ case KHADAS_MCU_VIM4_REST_CONF_REG:
+ case KHADAS_MCU_WOL_INIT_START_REG:
+ case KHADAS_MCU_VIM4_LED_ON_RAM_REG:
+ case KHADAS_MCU_VIM4_FAN_CTRL_REG:
+ case KHADAS_MCU_VIM4_WDT_EN_REG:
+ case KHADAS_MCU_VIM4_SYS_RST_REG:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool khadas_mcu_vim4_reg_writeable(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case KHADAS_MCU_VERSION_0_REG:
+ case KHADAS_MCU_VERSION_1_REG:
+ case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
+ return false;
+ default:
+ return true;
+ }
+}
+
+static const struct regmap_config khadas_mcu_vim4_regmap_config = {
+ .reg_bits = 8,
+ .reg_stride = 1,
+ .val_bits = 8,
+ .max_register = KHADAS_MCU_VIM4_SYS_RST_REG,
+ .volatile_reg = khadas_mcu_vim4_reg_volatile,
+ .writeable_reg = khadas_mcu_vim4_reg_writeable,
+ .cache_type = REGCACHE_MAPLE,
+};
+
+static const struct khadas_mcu_fan_pdata khadas_vim4_fan_pdata = {
+ .fan_reg = KHADAS_MCU_VIM4_FAN_CTRL_REG,
+ .max_level = 0x64,
+};
+
+static const struct mfd_cell khadas_mcu_vim4_cells[] = {
+ {
+ .name = "khadas-mcu-fan-ctrl",
+ .platform_data = &khadas_vim4_fan_pdata,
+ .pdata_size = sizeof(khadas_vim4_fan_pdata),
+ },
+};
+
+static const struct khadas_mcu_data khadas_vim4_mcu_data = {
+ .regmap_config = &khadas_mcu_vim4_regmap_config,
+ .cells = NULL,
+ .ncells = 0,
+ .fan_cells = khadas_mcu_vim4_cells,
+ .nfan_cells = ARRAY_SIZE(khadas_mcu_vim4_cells),
+};
+
static int khadas_mcu_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
@@ -94,28 +170,35 @@ static int khadas_mcu_probe(struct i2c_client *client)
if (!ddata)
return -ENOMEM;
+ ddata->data = i2c_get_match_data(client);
+ if (!ddata->data)
+ return -EINVAL;
+
i2c_set_clientdata(client, ddata);
ddata->dev = dev;
- ddata->regmap = devm_regmap_init_i2c(client, &khadas_mcu_regmap_config);
+ ddata->regmap = devm_regmap_init_i2c(client,
+ ddata->data->regmap_config);
if (IS_ERR(ddata->regmap)) {
ret = PTR_ERR(ddata->regmap);
dev_err(dev, "Failed to allocate register map: %d\n", ret);
return ret;
}
- ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
- khadas_mcu_cells,
- ARRAY_SIZE(khadas_mcu_cells),
- NULL, 0, NULL);
- if (ret)
- return ret;
+ if (ddata->data->cells && ddata->data->ncells) {
+ ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
+ ddata->data->cells,
+ ddata->data->ncells,
+ NULL, 0, NULL);
+ if (ret)
+ return ret;
+ }
if (of_property_present(dev->of_node, "#cooling-cells"))
return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
- khadas_mcu_fan_cells,
- ARRAY_SIZE(khadas_mcu_fan_cells),
+ ddata->data->fan_cells,
+ ddata->data->nfan_cells,
NULL, 0, NULL);
return 0;
@@ -123,7 +206,8 @@ static int khadas_mcu_probe(struct i2c_client *client)
#ifdef CONFIG_OF
static const struct of_device_id khadas_mcu_of_match[] = {
- { .compatible = "khadas,mcu", },
+ { .compatible = "khadas,mcu", .data = &khadas_mcu_data },
+ { .compatible = "khadas,vim4-mcu", .data = &khadas_vim4_mcu_data },
{},
};
MODULE_DEVICE_TABLE(of, khadas_mcu_of_match);
--
2.49.0
^ permalink raw reply related
* [PATCH v3 7/8] arm64: dts: amlogic: t7: Add i2c controller node
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Add the T7 i2c controller node used by the Khadas VIM4
for MCU communication.
Use amlogic,meson-axg-i2c as fallback compatible.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index e96fe10b251a0..560c9dce35266 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -711,6 +711,16 @@ pwm_ao_cd: pwm@60000 {
status = "disabled";
};
+ i2c_m_ao_a: i2c@76000 {
+ compatible = "amlogic,t7-i2c", "amlogic,meson-axg-i2c";
+ reg = <0x0 0x76000 0x0 0x48>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 330 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc_periphs CLKID_SYS_I2C_AO_A>;
+ status = "disabled";
+ };
+
sd_emmc_a: mmc@88000 {
compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
reg = <0x0 0x88000 0x0 0x800>;
--
2.49.0
^ permalink raw reply related
* [PATCH v3 6/8] arm64: dts: amlogic: t7: Add i2c pinctrl node
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Add the T7 pinctrl used by the Khadas VIM4 for MCU communication.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed623..e96fe10b251a0 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -376,6 +376,16 @@ mux {
};
};
+ i2c0_ao_d_pins: i2c0-ao-d {
+ mux {
+ groups = "i2c0_ao_sck_d",
+ "i2c0_ao_sda_d";
+ function = "i2c0_ao";
+ bias-disable;
+ drive-strength-microamp = <3000>;
+ };
+ };
+
pwm_a_pins: pwm-a {
mux {
groups = "pwm_a";
--
2.49.0
^ permalink raw reply related
* [PATCH v3 5/8] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Replace the hardcoded MAX_LEVEL constant and fan register
with values read from platform_data (fan_reg, max_level),
as new MCUs need different values.
Optionally acquire and enable a "fan" regulator supply
at probe time and on resume,
so boards that gate fan power through a regulator are handled.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/thermal/khadas_mcu_fan.c | 49 +++++++++++++++++++++++++++++++++++-----
1 file changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/khadas_mcu_fan.c
index d35e5313bea41..24559bf65de46 100644
--- a/drivers/thermal/khadas_mcu_fan.c
+++ b/drivers/thermal/khadas_mcu_fan.c
@@ -13,13 +13,15 @@
#include <linux/regmap.h>
#include <linux/sysfs.h>
#include <linux/thermal.h>
-
-#define MAX_LEVEL 3
+#include <linux/regulator/consumer.h>
struct khadas_mcu_fan_ctx {
struct khadas_mcu *mcu;
+ unsigned int fan_reg;
unsigned int level;
+ unsigned int max_level;
struct thermal_cooling_device *cdev;
+ struct regulator *power;
};
static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
@@ -27,8 +29,7 @@ static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
{
int ret;
- ret = regmap_write(ctx->mcu->regmap, KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
- level);
+ ret = regmap_write(ctx->mcu->regmap, ctx->fan_reg, level);
if (ret)
return ret;
@@ -40,7 +41,9 @@ static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
- *state = MAX_LEVEL;
+ struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
+
+ *state = ctx->max_level;
return 0;
}
@@ -61,7 +64,7 @@ khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
{
struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
- if (state > MAX_LEVEL)
+ if (state > ctx->max_level)
return -EINVAL;
if (state == ctx->level)
@@ -83,11 +86,32 @@ static int khadas_mcu_fan_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct khadas_mcu_fan_ctx *ctx;
int ret;
+ const struct khadas_mcu_fan_pdata *pdata = dev_get_platdata(&pdev->dev);
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+
ctx->mcu = mcu;
+ ctx->fan_reg = pdata->fan_reg;
+ ctx->max_level = pdata->max_level;
+
+ ctx->power = devm_regulator_get_optional(dev->parent, "fan");
+ if (IS_ERR(ctx->power)) {
+ if (PTR_ERR(ctx->power) == -ENODEV)
+ ctx->power = NULL;
+ else
+ return PTR_ERR(ctx->power);
+ }
+
+ if (ctx->power) {
+ ret = regulator_enable(ctx->power);
+ if (ret) {
+ dev_err(dev, "Failed to enable fan power supply: %d\n", ret);
+ return ret;
+ }
+ }
+
platform_set_drvdata(pdev, ctx);
cdev = devm_thermal_of_cooling_device_register(dev->parent,
@@ -124,12 +148,25 @@ static int khadas_mcu_fan_suspend(struct device *dev)
ctx->level = level_save;
+ if (ctx->power) {
+ ret = regulator_disable(ctx->power);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
static int khadas_mcu_fan_resume(struct device *dev)
{
struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
+ int ret;
+
+ if (ctx->power) {
+ ret = regulator_enable(ctx->power);
+ if (ret)
+ return ret;
+ }
return khadas_mcu_fan_set_level(ctx, ctx->level);
}
--
2.49.0
^ permalink raw reply related
* [PATCH v3 8/8] arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Enable and configure i2c MCU node to get fan working on Khadas VIM4.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 69d6118ba57e7..5d7f5390f3a66 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -157,6 +157,19 @@ wifi32k: wifi32k {
};
};
+&i2c_m_ao_a {
+ status = "okay";
+ pinctrl-0 = <&i2c0_ao_d_pins>;
+ pinctrl-names = "default";
+
+ khadas_mcu: system-controller@18 {
+ compatible = "khadas,vim4-mcu";
+ reg = <0x18>;
+ fan-supply = <&vcc5v>;
+ #cooling-cells = <2>;
+ };
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_pins>;
--
2.49.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: cpufreq: add mt8189 cpufreq hw dt-bindings
From: Conor Dooley @ 2026-04-17 16:40 UTC (permalink / raw)
To: Binbin Shi
Cc: Rafael J . Wysocki, Viresh Kumar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Hector Yuan, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, vince-wl.liu
In-Reply-To: <20260417080648.3692438-1-binbin.shi@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
On Fri, Apr 17, 2026 at 04:06:17PM +0800, Binbin Shi wrote:
> Add mt8189 cpufreq hw compatible in dt-bindings.
Why's this not compatible with the existing device? You've got no driver
change with this so I can't even guess as why. The incompatibility should
be explained in the commit message.
pw-bot: changes-requested
Cheers,
Conor.
>
> Signed-off-by: Binbin Shi <binbin.shi@mediatek.com>
> ---
> .../devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> index d0aecde2b89b..cff52fffc6b8 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> @@ -16,7 +16,9 @@ description:
>
> properties:
> compatible:
> - const: mediatek,cpufreq-hw
> + enum:
> + - mediatek,cpufreq-hw
> + - mediatek,mt8189-cpufreq-hw
>
> reg:
> minItems: 1
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v17 24/24] KVM: selftests: Add guest_memfd testcase to fault-in on !mmap()'d memory
From: Sean Christopherson @ 2026-04-17 16:47 UTC (permalink / raw)
To: Zenghui Yu
Cc: Paolo Bonzini, Marc Zyngier, Oliver Upton, kvm, linux-arm-kernel,
kvmarm, linux-kernel, Ira Weiny, Gavin Shan, Shivank Garg,
Vlastimil Babka, Xiaoyao Li, David Hildenbrand, Fuad Tabba,
Ackerley Tng, Tao Chan, James Houghton
In-Reply-To: <0064952b-048c-455d-ad89-e27e5cb82591@linux.dev>
On Mon, Mar 30, 2026, Zenghui Yu wrote:
> On 7/30/25 6:54 AM, Sean Christopherson wrote:
> > Add a guest_memfd testcase to verify that a vCPU can fault-in guest_memfd
> > memory that supports mmap(), but that is not currently mapped into host
> > userspace and/or has a userspace address (in the memslot) that points at
> > something other than the target guest_memfd range. Mapping guest_memfd
> > memory into the guest is supposed to operate completely independently from
> > any userspace mappings.
> > + vm = __vm_create_shape_with_one_vcpu(VM_SHAPE_DEFAULT, &vcpu, 1, guest_code);
> > +
> > + TEST_ASSERT(vm_check_cap(vm, KVM_CAP_GUEST_MEMFD_MMAP),
> > + "Default VM type should always support guest_memfd mmap()");
> > +
> > + size = vm->page_size;
> > + fd = vm_create_guest_memfd(vm, size, GUEST_MEMFD_FLAG_MMAP);
>
> This test fails on arm64 when vm->page_size is 4k and host's page_size
> is 64k:
>
> [root@localhost kvm]# ./guest_memfd_test
> Random seed: 0x6b8b4567
> __vm_create: mode='PA-bits:40, VA-bits:48, 4K pages' type='0', pages='660'
> ==== Test Assertion Failure ====
> include/kvm_util.h:683: fd >= 0
> pid=889 tid=889 errno=22 - Invalid argument
> 1 0x000000000040262b: vm_create_guest_memfd at kvm_util.h:683
> 2 (inlined by) test_guest_memfd_guest at guest_memfd_test.c:450
> 3 (inlined by) main at guest_memfd_test.c:491
> 4 0x00007fff8f56af3b: ?? ??:0
> 5 0x00007fff8f56b007: ?? ??:0
> 6 0x0000000000402a2f: _start at ??:?
> KVM_CREATE_GUEST_MEMFD failed, rc: -1 errno: 22 (Invalid argument)
Does this fix things for you? If so, I'll send a proper patch.
diff --git a/tools/testing/selftests/kvm/guest_memfd_test.c b/tools/testing/selftests/kvm/guest_memfd_test.c
index ec7644aae999..c682bda722f9 100644
--- a/tools/testing/selftests/kvm/guest_memfd_test.c
+++ b/tools/testing/selftests/kvm/guest_memfd_test.c
@@ -510,9 +510,15 @@ static void test_guest_memfd_guest(void)
"Default VM type should support INIT_SHARED, supported flags = 0x%x",
vm_check_cap(vm, KVM_CAP_GUEST_MEMFD_FLAGS));
+ /*
+ * Use the guest's page size for all accesses, e.g. to avoid having to
+ * map multiple pages, but create the guest_memfd instance with the max
+ * of the host or guest page size, as KVM requires gmem files to be
+ * aligned to the host page size.
+ */
size = vm->page_size;
- fd = vm_create_guest_memfd(vm, size, GUEST_MEMFD_FLAG_MMAP |
- GUEST_MEMFD_FLAG_INIT_SHARED);
+ fd = vm_create_guest_memfd(vm, max(size, page_size), GUEST_MEMFD_FLAG_MMAP |
+ GUEST_MEMFD_FLAG_INIT_SHARED);
vm_set_user_memory_region2(vm, slot, KVM_MEM_GUEST_MEMFD, gpa, size, NULL, fd, 0);
mem = kvm_mmap(size, PROT_READ | PROT_WRITE, MAP_SHARED, fd);
^ permalink raw reply related
* Re: [PATCH 01/14] KVM: arm64: Donate MMIO to the hypervisor
From: Mostafa Saleh @ 2026-04-17 17:18 UTC (permalink / raw)
To: Vincent Donnefort
Cc: Sebastian Ene, alexandru.elisei, kvmarm, linux-arm-kernel,
linux-kernel, android-kvm, catalin.marinas, dbrazdil, joey.gouly,
kees, mark.rutland, maz, oupton, perlarsen, qperret, rananta,
suzuki.poulose, tabba, tglx, bgrzesik, will, yuzenghui
In-Reply-To: <acJpy7unwLbRahPL@google.com>
On Tue, Mar 24, 2026 at 10:39 AM Vincent Donnefort
<vdonnefort@google.com> wrote:
>
> On Tue, Mar 10, 2026 at 12:49:20PM +0000, Sebastian Ene wrote:
> > From: Mostafa Saleh <smostafa@google.com>
> >
> > Add a function to donate MMIO to the hypervisor so IOMMU hypervisor
> > drivers can use that to protect the MMIO of IOMMU.
> > The initial attempt to implement this was to have a new flag to
> > "___pkvm_host_donate_hyp" to accept MMIO. However that had many problems,
> > it was quite intrusive for host/hyp to check/set page state to make it
> > aware of MMIO and to encode the state in the page table in that case.
> > Which is called in paths that can be sensitive to performance (FFA, VMs..)
> >
> > As donating MMIO is very rare, and we don’t need to encode the full
> > state, it’s reasonable to have a separate function to do this.
> > It will init the host s2 page table with an invalid leaf with the owner ID
> > to prevent the host from mapping the page on faults.
>
> I am not sure I agree here:
>
> * Differentiating between MMIO and Memory is just a fast binary search into the
> memory regions.
>
> * host_donate_hyp isn't a fast path even for memory regions anyway.
>
> * Having common functions for changing ownership is more and more helpful (see the
> SME dvmsync workaround).
>
> * There's nothing preventing from having a range here which is safely handled
> already by host_donate_hyp()
>
I am working on v6 now. I'm not convinced that's a good enough reason
to have full-fledged MMIO state tracking, it will be unncessary
complicated and quite intrusive.
It might be useful when supporting device assignment where VMs can own
MMIO, otherwise, I'd try to avoid it.
Thanks,
Mostafa
> >
> > Also, prevent kvm_pgtable_stage2_unmap() from removing owner ID from
> > stage-2 PTEs, as this can be triggered from recycle logic under memory
> > pressure. There is no code relying on this, as all ownership changes is
> > done via kvm_pgtable_stage2_set_owner()
> >
> > For error path in IOMMU drivers, add a function to donate MMIO back
> > from hyp to host.
> >
> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > ---
> > arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 2 +
> > arch/arm64/kvm/hyp/nvhe/mem_protect.c | 90 +++++++++++++++++++
> > arch/arm64/kvm/hyp/pgtable.c | 9 +-
> > 3 files changed, 94 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> > index 5f9d56754e39..8b617e6fc0e0 100644
> > --- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> > +++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> > @@ -31,6 +31,8 @@ enum pkvm_component_id {
> > };
> >
> > extern unsigned long hyp_nr_cpus;
> > +int __pkvm_host_donate_hyp_mmio(u64 pfn);
> > +int __pkvm_hyp_donate_host_mmio(u64 pfn);
> >
> > int __pkvm_prot_finalize(void);
> > int __pkvm_host_share_hyp(u64 pfn);
> > diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> > index 38f66a56a766..0808367c52e5 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> > @@ -784,6 +784,96 @@ int __pkvm_host_unshare_hyp(u64 pfn)
> > return ret;
> > }
> >
> > +int __pkvm_host_donate_hyp_mmio(u64 pfn)
> > +{
> > + u64 phys = hyp_pfn_to_phys(pfn);
> > + void *virt = __hyp_va(phys);
> > + int ret;
> > + kvm_pte_t pte;
> > +
> > + if (addr_is_memory(phys))
> > + return -EINVAL;
> > +
> > + host_lock_component();
> > + hyp_lock_component();
> > +
> > + ret = kvm_pgtable_get_leaf(&host_mmu.pgt, phys, &pte, NULL);
> > + if (ret)
> > + goto unlock;
> > +
> > + if (pte && !kvm_pte_valid(pte)) {
> > + ret = -EPERM;
> > + goto unlock;
> > + }
> > +
> > + ret = kvm_pgtable_get_leaf(&pkvm_pgtable, (u64)virt, &pte, NULL);
> > + if (ret)
> > + goto unlock;
> > + if (pte) {
> > + ret = -EBUSY;
> > + goto unlock;
> > + }
> > +
> gg> + ret = pkvm_create_mappings_locked(virt, virt + PAGE_SIZE, PAGE_HYP_DEVICE);
> > gg+ if (ret)
> > + goto unlock;
> > + /*
> > + * We set HYP as the owner of the MMIO pages in the host stage-2, for:
> > + * - host aborts: host_stage2_adjust_range() would fail for invalid non zero PTEs.
> > + * - recycle under memory pressure: host_stage2_unmap_dev_all() would call
> > + * kvm_pgtable_stage2_unmap() which will not clear non zero invalid ptes (counted).
> > + * - other MMIO donation: Would fail as we check that the PTE is valid or empty.
> > + */
> > + WARN_ON(host_stage2_try(kvm_pgtable_stage2_set_owner, &host_mmu.pgt, phys,
> > + PAGE_SIZE, &host_s2_pool, PKVM_ID_HYP));
> > +unlock:
> > + hyp_unlock_component();
> > + host_unlock_component();
> > +
> > + return ret;
> > +}
> > +
> > +int __pkvm_hyp_donate_host_mmio(u64 pfn)
> > +{
> > + u64 phys = hyp_pfn_to_phys(pfn);
> > + u64 virt = (u64)__hyp_va(phys);
> > + size_t size = PAGE_SIZE;
> > + int ret;
> > + kvm_pte_t pte;
> > +
> > + if (addr_is_memory(phys))
> > + return -EINVAL;
> > +
> > + host_lock_component();
> > + hyp_lock_component();
> > +
> > + ret = kvm_pgtable_get_leaf(&pkvm_pgtable, (u64)virt, &pte, NULL);
> > + if (ret)
> > + goto unlock;
> > + if (!kvm_pte_valid(pte)) {
> > + ret = -ENOENT;
> > + goto unlock;
> > + }
> > +
> > + ret = kvm_pgtable_get_leaf(&host_mmu.pgt, phys, &pte, NULL);
> > + if (ret)
> > + goto unlock;
> > +
> > + if (FIELD_GET(KVM_INVALID_PTE_OWNER_MASK, pte) != PKVM_ID_HYP) {
> > + ret = -EPERM;
> > + goto unlock;
> > + }
> > +
> > + WARN_ON(kvm_pgtable_hyp_unmap(&pkvm_pgtable, virt, size) != size);
> > + WARN_ON(host_stage2_try(kvm_pgtable_stage2_set_owner, &host_mmu.pgt, phys,
> > + PAGE_SIZE, &host_s2_pool, PKVM_ID_HOST));
> > +unlock:
> > + hyp_unlock_component();
> > + host_unlock_component();
> > +
> > + return ret;
> > +}
> > +
> > int __pkvm_host_donate_hyp(u64 pfn, u64 nr_pages)
> > {
> > u64 phys = hyp_pfn_to_phys(pfn);
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 9b480f947da2..d954058e63ff 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm64/kvm/hyp/pgtable.c
> > @@ -1152,13 +1152,8 @@ static int stage2_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
> > kvm_pte_t *childp = NULL;
> > bool need_flush = false;
> >
> > - if (!kvm_pte_valid(ctx->old)) {
> > - if (stage2_pte_is_counted(ctx->old)) {
> > - kvm_clear_pte(ctx->ptep);
> > - mm_ops->put_page(ctx->ptep);
> > - }
> > - return 0;
> > - }
> > + if (!kvm_pte_valid(ctx->old))
> > + return stage2_pte_is_counted(ctx->old) ? -EPERM : 0;
> >
> > if (kvm_pte_table(ctx->old, ctx->level)) {
> > childp = kvm_pte_follow(ctx->old, mm_ops);
> > --
> > 2.53.0.473.g4a7958ca14-goog
> >
^ permalink raw reply
* Re: [PATCH v4 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Stefan Dösinger @ 2026-04-17 17:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <0d80dcbe-cb46-45e5-821a-de5299d6a663@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]
Hi Arnd,
Thanks for your comments.
> Am 17.04.2026 um 11:59 schrieb Arnd Bergmann <arnd@arndb.de>:
>
> On Thu, Apr 16, 2026, at 22:19, Stefan Dösinger wrote:
>>
>> The reason why I add the serial1=uart1 alias is to keep console=ttyAMA1
>> stable regardless of the other enabled UARTs. UART0, as the name
>> implies, has a lower MMIO address, but uart1 is the one that usually has
>> the boot output and console.
>
> I'm not sure I'm following here. You generally want to either make
> sure the alias matches whatever number is printed on the product
> if there are multiple numbered ports, or you just use 'serial0'
> as the only alias if there is only one port.
Not all boards have their uart pins labeled, but those that do have the pins that connect to the UART at 0x01408000 named UART1RX/UART1TX. Most boards have only one though. I have seen a picture of only one that has UART0 and UART1. I could not test that board myself yet.
My original reason is one of developer convenience: If I have
uart0=serial@131000{
reg = <0x00131000 0x1000>;
...
status = "disabled";
};
uart1=serial@1408000{
reg = <0x01408000 0x1000>;
...
status = "okay";
};
cmdline="... console=ttyAMA{0/1} ..."
changing uart0.status between disabled and okay (e.g. to experiment with uart0 and pinctrl) required changing the command line to match. I found that pretty annoying and the aliases seemed like the best way to avoid this.
Either way I am open to do whatever. I can keep the current naming for the reasons stated above, I can name serial@1408000 "uart0" and leave the others without an alias or I can drop the alias altogether.
> Either way, the alias should go into the board specific file, not
> the general SoC file, as a board might be using a different
> set of UARTs.
That works for me, I'll move them. The aliases will most likely be the same for all boards based on this chipset, meaning duplicate code, but matching the alias to the board labels makes sense to me.
> Since you know the addresses of the other uart instances, I would
> suggest you add all of them at the same time.
Will do.
I'll hold off for a bit before I resend the patches to see if some other comments come up.
Cheers,
Stefan
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 5/6] net: stmmac: move PHY handling out of __stmmac_open()/release()
From: Andrew Lunn @ 2026-04-17 17:30 UTC (permalink / raw)
To: Alexander Stein
Cc: Russell King (Oracle), Maxime Chevallier, Heiner Kallweit,
Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, Maxime Coquelin,
netdev, Paolo Abeni
In-Reply-To: <13939918.O9o76ZdvQC@steina-w>
> Thanks for conforming this for another PHY. What I'm wondering right now:
> Why is the PHY stopped in the first place? We are just changing the MTU, no?
It is not too uncommon to see an MTU change destroying everything and
rebuilding it, especially when it was retrofitted into an older driver
which had fixed MTU.
> I have a proof of concept running, but it needs more cleanup due
> to code duplication.
You probably also want to take a look at the ethtool code for
configuring rings. Oh, it is even worse:
int stmmac_reinit_ringparam(struct net_device *dev, u32 rx_size, u32 tx_size)
{
struct stmmac_priv *priv = netdev_priv(dev);
int ret = 0;
if (netif_running(dev))
stmmac_release(dev);
priv->dma_conf.dma_rx_size = rx_size;
priv->dma_conf.dma_tx_size = tx_size;
if (netif_running(dev))
ret = stmmac_open(dev);
return ret;
}
So not even using __stmmac_release() or __stmmac_open(), and leaving
you with a dead interface if there is not enough memory to allocate
the rings.
These paths should really share the same code.
Andrew
^ permalink raw reply
* Re: [PATCH v6 01/30] mm: Introduce kpkeys
From: David Hildenbrand (Arm) @ 2026-04-17 17:38 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: linux-kernel, Andrew Morton, Andy Lutomirski, Catalin Marinas,
Dave Hansen, Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Lorenzo Stoakes, Marc Zyngier, Mark Brown,
Matthew Wilcox, Maxwell Bland, Mike Rapoport (IBM),
Peter Zijlstra, Pierre Langlois, Quentin Perret, Rick Edgecombe,
Ryan Roberts, Thomas Gleixner, Vlastimil Babka, Will Deacon,
Yang Shi, Yeoreum Yun, linux-arm-kernel, linux-mm, x86
In-Reply-To: <913002a5-e002-4001-ad19-037102d1f97d@arm.com>
On 4/17/26 17:59, Kevin Brodsky wrote:
> On 17/04/2026 16:37, David Hildenbrand (Arm) wrote:
>> On 2/27/26 18:54, Kevin Brodsky wrote:
>>> kpkeys is a simple framework to enable the use of protection keys
>>> (pkeys) to harden the kernel itself. This patch introduces the basic
>>> API in <linux/kpkeys.h>: a couple of functions to set and restore
>>> the pkey register and macros to define guard objects.
>>>
>>> kpkeys introduces a new concept on top of pkeys: the kpkeys level.
>>> Each level is associated to a set of permissions for the pkeys
>>> managed by the kpkeys framework. kpkeys_set_level(lvl) sets those
>>> permissions according to lvl, and returns the original pkey
>>> register, to be later restored by kpkeys_restore_pkey_reg(). To
>>> start with, only KPKEYS_LVL_DEFAULT is available, which is meant
>>> to grant RW access to KPKEYS_PKEY_DEFAULT (i.e. all memory since
>>> this is the only available pkey for now).
>>>
>>> Because each architecture implementing pkeys uses a different
>>> representation for the pkey register, and may reserve certain pkeys
>>> for specific uses, support for kpkeys must be explicitly indicated
>>> by selecting ARCH_HAS_KPKEYS and defining the following functions in
>>> <asm/kpkeys.h>, in addition to the macros provided in
>>> <asm-generic/kpkeys.h>:
>>>
>>> - arch_kpkeys_set_level()
>>> - arch_kpkeys_restore_pkey_reg()
>>> - arch_kpkeys_enabled()
>> Another thing: why not simply drop the "arch_" stuff from these helpers?
>
> The first two are not meant to be directly called, they're the
> arch-specific implementation of kpkeys_set_level() and
> kpkeys_restore_pkey_reg(), and those generic functions handle some
> generic logic.
>
> arch_kpkeys_enabled() is directly used in generic code, so I suppose it
> could be renamed to kpkeys_enabled()? It's actually implemented in an
> arch header so I wasn't too sure about it.
I was skimming over patch #13 and spotted:
+void·__init·kpkeys_hardened_pgtables_init(void)
+{
+› if·(!arch_kpkeys_enabled())
+› › return;
+
+› static_branch_enable(&kpkeys_hardened_pgtables_key);
+}
The arch_* there can just go IMHO.
I'd also do it for the two ones used by the GUARD macros. If we don't
expect common code wrappers (arch_kpkeys_enabled() vs. kpkeys_enabled),
then the arch_ is unnecessary information -- IMHO
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] crypto: tstmgr - guard xxhash tests
From: Hamza Mahfooz @ 2026-04-17 17:42 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, David S. Miller, Maxime Coquelin, Alexandre Torgue,
linux-stm32, linux-arm-kernel, linux-kernel, Jeff Barnes,
Paul Monson
In-Reply-To: <aeCnNsNrK5o2JcMu@gondor.apana.org.au>
On Thu, Apr 16, 2026 at 05:09:10PM +0800, Herbert Xu wrote:
> On second thought, fips_allowed should not mean that an algorithm
> must be present.
>
> So we should change it such that an -ENOENT is not fatal, or at least
> when it's called from tcrypt.
>
It appears that commit 6318fbe26e67 ("crypto: testmgr - Hide ENOENT
errors better"), already does exactly that and it appears to resolve the
issue that I'm seeing. So, is there any reason it can't be backported to
stable?
^ permalink raw reply
* Re: [PATCH net] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Breno Leitao @ 2026-04-17 17:46 UTC (permalink / raw)
To: Daniel Golle
Cc: Chester A. Unal, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Christian Marangi,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek,
Frank Wunderlich, John Crispin
In-Reply-To: <79dc0ec5b6be698b14cb66339d6f63033ca2934a.1776397542.git.daniel@makrotopia.org>
On Fri, Apr 17, 2026 at 04:55:57AM +0100, Daniel Golle wrote:
> @@ -3404,6 +3449,9 @@ EXPORT_SYMBOL_GPL(mt7530_probe_common);
> void
> mt7530_remove_common(struct mt7530_priv *priv)
> {
> + if (priv->bus)
> + cancel_delayed_work_sync(&priv->stats_work);
> +
Shouldn't you cancel the work later, after dsa_unregister_switch()?
I am wondering if the following race cannot happen:
mt7530_remove_common() someone reading /proc/net/dev
cancel_delayed_work_sync()
/* returns: work neither pending
nor executing - true at this
instant */
mt7530_get_stats64()
mod_delayed_work(...)
/* work is queued again */
dsa_unregister_switch()
return
^ permalink raw reply
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Cristian Ciocaltea @ 2026-04-17 17:55 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <2297365.1BCLMh4Saa@phil>
Hi Heiko,
On 4/17/26 2:34 PM, Heiko Stuebner wrote:
> Hi Cristan,
>
> Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>
> [...]
>
>> Cristian Ciocaltea (40):
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
>
> I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
> sense, because these patches really are mostly identical :-)
Yeah, apologies for the large number of patches, I went this way to allow
per-board reviews. As previously noted, I tried to identify the GPIO pins from
multiple sources, so I'm not entirely sure about the accuracy in every case.
Would it be preferable to squash the patches per SoC and board vendor, instead?
Thanks,
Cristian
^ permalink raw reply
* [RFC PATCH 0/4] fix FF-A call failed with pKVM when ff-a driver is built-in
From: Yeoreum Yun @ 2026-04-17 17:57 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, peterhuewe, jarkko, jgg, sudeep.holla, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will,
Yeoreum Yun
commit 0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall")
changed the initcall level of ffa_init() to rootfs_initcall to address
an issue where IMA could not properly recognize the TPM device
when FF-A driver is built as built-in.
However, this introduces another problem: pKVM fails to handle FF-A calls
because it cannot trap the FFA_VERSION call invoked by ffa_init().
To ensure the TPM device is recognized when present in the system,
it is preferable to invoke ima_init() at a later stage.
Deferred probing is resolved by deferred_probe_initcall(),
which runs at the late_initcall level.
Therefore, introduce an LSM initcall at late_initcall_sync and
move ima_init() to this level.
With this change, revert the initcall level of ffa_init() back to
device_initcall. Additionally, to handle the case where ffa_init() runs
before kvm_init(), check whether pKVM has been initialized during ffa_init().
If not, defer initialization to prevent failures of FF-A calls
due to the inability to trap FFA_VERSION and FFA_RXTX_MAP in pKVM.
This patch is based on v7.0
Yeoreum Yun (4):
security: ima: move ima_init into late_initcall_sync
tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
firmware: arm_ffa: revert ffa_init() initcall level to device_initcall
firmware: arm_ffa: check pkvm initailised when initailise ffa driver
arch/arm64/kvm/arm.c | 1 +
drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
drivers/firmware/arm_ffa/driver.c | 14 +++++++++++++-
include/linux/lsm_hooks.h | 2 ++
security/integrity/ima/ima_main.c | 2 +-
security/lsm_init.c | 13 +++++++++++--
6 files changed, 31 insertions(+), 19 deletions(-)
base-commit: 028ef9c96e96197026887c0f092424679298aae8
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply
* [RFC PATCH 1/4] security: ima: move ima_init into late_initcall_sync
From: Yeoreum Yun @ 2026-04-17 17:57 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, peterhuewe, jarkko, jgg, sudeep.holla, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will,
Yeoreum Yun
In-Reply-To: <20260417175759.3191279-1-yeoreum.yun@arm.com>
To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
the TPM driver must be built as built-in and
must be probed before the IMA subsystem is initialized.
However, when the TPM device operates over the FF-A protocol using
the CRB interface, probing fails and returns -EPROBE_DEFER if
the tpm_crb_ffa device — an FF-A device that provides the communication
interface to the tpm_crb driver — has not yet been probed.
To ensure the TPM device operating over the FF-A protocol with
the CRB interface is probed before IMA initialization,
the following conditions must be met:
1. The corresponding ffa_device must be registered,
which is done via ffa_init().
2. The tpm_crb_driver must successfully probe this device via
tpm_crb_ffa_init().
3. The tpm_crb driver using CRB over FF-A can then
be probed successfully. (See crb_acpi_add() and
tpm_crb_ffa_init() for reference.)
Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
all registered with device_initcall, which means crb_acpi_driver_init() may
be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
When this occurs, probing the TPM device is deferred.
However, the deferred probe can happen after the IMA subsystem
has already been initialized, since IMA initialization is performed
during late_initcall, and deferred_probe_initcall() is performed
at the same level.
To resolve this, move ima_init() into late_inicall_sync level
so that let IMA not miss TPM PCR value when generating boot_aggregate
log though TPM device presents in the system.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
include/linux/lsm_hooks.h | 2 ++
security/integrity/ima/ima_main.c | 2 +-
security/lsm_init.c | 13 +++++++++++--
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index d48bf0ad26f4..88fe105b7f00 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -166,6 +166,7 @@ enum lsm_order {
* @initcall_fs: LSM callback for fs_initcall setup, optional
* @initcall_device: LSM callback for device_initcall() setup, optional
* @initcall_late: LSM callback for late_initcall() setup, optional
+ * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
*/
struct lsm_info {
const struct lsm_id *id;
@@ -181,6 +182,7 @@ struct lsm_info {
int (*initcall_fs)(void);
int (*initcall_device)(void);
int (*initcall_late)(void);
+ int (*initcall_late_sync)(void);
};
#define DEFINE_LSM(lsm) \
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 1d6229b156fb..ace280fa3212 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -1320,5 +1320,5 @@ DEFINE_LSM(ima) = {
.order = LSM_ORDER_LAST,
.blobs = &ima_blob_sizes,
/* Start IMA after the TPM is available */
- .initcall_late = init_ima,
+ .initcall_late_sync = init_ima,
};
diff --git a/security/lsm_init.c b/security/lsm_init.c
index 573e2a7250c4..4e5c59beb82a 100644
--- a/security/lsm_init.c
+++ b/security/lsm_init.c
@@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
* security_initcall_late - Run the LSM late initcalls
*/
static int __init security_initcall_late(void)
+{
+ return lsm_initcall(late);
+}
+late_initcall(security_initcall_late);
+
+/**
+ * security_initcall_late_sync - Run the LSM late initcalls sync
+ */
+static int __init security_initcall_late_sync(void)
{
int rc;
- rc = lsm_initcall(late);
+ rc = lsm_initcall(late_sync);
lsm_pr_dbg("all enabled LSMs fully activated\n");
call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
return rc;
}
-late_initcall(security_initcall_late);
+late_initcall_sync(security_initcall_late_sync);
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
* [RFC PATCH 2/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Yeoreum Yun @ 2026-04-17 17:57 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, peterhuewe, jarkko, jgg, sudeep.holla, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will,
Yeoreum Yun
In-Reply-To: <20260417175759.3191279-1-yeoreum.yun@arm.com>
commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
However, as IMA init function is changed to late_initcall_sync level.
So, this change isn't required anymore.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
index 99f1c1e5644b..025c4d4b17ca 100644
--- a/drivers/char/tpm/tpm_crb_ffa.c
+++ b/drivers/char/tpm/tpm_crb_ffa.c
@@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
*/
int tpm_crb_ffa_init(void)
{
- int ret = 0;
-
- if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
- ret = ffa_register(&tpm_crb_ffa_driver);
- if (ret) {
- tpm_crb_ffa = ERR_PTR(-ENODEV);
- return ret;
- }
- }
-
if (!tpm_crb_ffa)
- ret = -ENOENT;
+ return -ENOENT;
if (IS_ERR_VALUE(tpm_crb_ffa))
- ret = -ENODEV;
+ return -ENODEV;
- return ret;
+ return 0;
}
EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
@@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
.id_table = tpm_crb_ffa_device_id,
};
-#ifdef MODULE
module_ffa_driver(tpm_crb_ffa_driver);
-#endif
MODULE_AUTHOR("Arm");
MODULE_DESCRIPTION("TPM CRB FFA driver");
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
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