* Re: [PATCH v2 3/8] KVM: arm64: Factor out reusable vCPU reset helpers
From: Vincent Donnefort @ 2026-06-19 13:29 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, kvmarm, linux-arm-kernel,
linux-kernel, Catalin Marinas, Will Deacon, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Quentin Perret,
Sebastian Ene, Hyunwoo Kim
In-Reply-To: <20260619070719.812227-4-tabba@google.com>
On Fri, Jun 19, 2026 at 08:07:14AM +0100, Fuad Tabba wrote:
> Pull the reusable pieces out of kvm_reset_vcpu(): expose the reset
> PSTATE values in kvm_arm.h, and split the core register reset and the
> PSCI-driven reset into kvm_reset_vcpu_core() and kvm_reset_vcpu_psci().
> A follow-up series reuses these to reset protected vCPUs at EL2.
>
> No functional change intended.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> ---
> arch/arm64/include/asm/kvm_arm.h | 12 ++++++
> arch/arm64/include/asm/kvm_emulate.h | 57 ++++++++++++++++++++++++++
> arch/arm64/kvm/reset.c | 60 ++--------------------------
> 3 files changed, 72 insertions(+), 57 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 3f9233b5a130..aba4ec09acd2 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -348,4 +348,16 @@
> { PSR_AA32_MODE_UND, "32-bit UND" }, \
> { PSR_AA32_MODE_SYS, "32-bit SYS" }
>
> +/*
> + * ARMv8 Reset Values
> + */
> +#define VCPU_RESET_PSTATE_EL1 (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | \
> + PSR_F_BIT | PSR_D_BIT)
> +
> +#define VCPU_RESET_PSTATE_EL2 (PSR_MODE_EL2h | PSR_A_BIT | PSR_I_BIT | \
> + PSR_F_BIT | PSR_D_BIT)
> +
> +#define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
> + PSR_AA32_I_BIT | PSR_AA32_F_BIT)
> +
> #endif /* __ARM64_KVM_ARM_H__ */
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 80b30fead3d1..2385d8855fcf 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -704,4 +704,61 @@ static inline void vcpu_set_hcrx(struct kvm_vcpu *vcpu)
> vcpu->arch.hcrx_el2 |= HCRX_EL2_EnASR;
> }
> }
> +
> +/* Reset a vcpu's core registers. */
> +static inline void kvm_reset_vcpu_core(struct kvm_vcpu *vcpu)
> +{
> + u32 pstate;
> +
> + if (vcpu_el1_is_32bit(vcpu))
> + pstate = VCPU_RESET_PSTATE_SVC;
> + else if (vcpu_has_nv(vcpu))
> + pstate = VCPU_RESET_PSTATE_EL2;
> + else
> + pstate = VCPU_RESET_PSTATE_EL1;
> +
> + /* Reset core registers */
> + memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
> + memset(&vcpu->arch.ctxt.fp_regs, 0, sizeof(vcpu->arch.ctxt.fp_regs));
> + vcpu->arch.ctxt.spsr_abt = 0;
> + vcpu->arch.ctxt.spsr_und = 0;
> + vcpu->arch.ctxt.spsr_irq = 0;
> + vcpu->arch.ctxt.spsr_fiq = 0;
> + vcpu_gp_regs(vcpu)->pstate = pstate;
> +}
> +
> +/* PSCI reset handling for a vcpu. */
> +static inline void kvm_reset_vcpu_psci(struct kvm_vcpu *vcpu,
> + struct vcpu_reset_state *reset_state)
> +{
> + unsigned long target_pc = reset_state->pc;
> +
> + /* Gracefully handle Thumb2 entry point */
> + if (vcpu_mode_is_32bit(vcpu) && (target_pc & 1)) {
> + target_pc &= ~1UL;
> + vcpu_set_thumb(vcpu);
> + }
> +
> + /* Propagate caller endianness */
> + if (reset_state->be)
> + kvm_vcpu_set_be(vcpu);
> +
> + *vcpu_pc(vcpu) = target_pc;
> +
> + /*
> + * We may come from a state where either a PC update was
> + * pending (SMC call resulting in PC being increpented to
> + * skip the SMC) or a pending exception. Make sure we get
> + * rid of all that, as this cannot be valid out of reset.
> + *
> + * Note that clearing the exception mask also clears PC
> + * updates, but that's an implementation detail, and we
> + * really want to make it explicit.
> + */
> + vcpu_clear_flag(vcpu, PENDING_EXCEPTION);
> + vcpu_clear_flag(vcpu, EXCEPT_MASK);
> + vcpu_clear_flag(vcpu, INCREMENT_PC);
> + vcpu_set_reg(vcpu, 0, reset_state->r0);
> +}
> +
> #endif /* __ARM64_KVM_EMULATE_H__ */
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index b963fd975aac..10eb7249aa9e 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -34,18 +34,6 @@
> static u32 __ro_after_init kvm_ipa_limit;
> unsigned int __ro_after_init kvm_host_sve_max_vl;
>
> -/*
> - * ARMv8 Reset Values
> - */
> -#define VCPU_RESET_PSTATE_EL1 (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | \
> - PSR_F_BIT | PSR_D_BIT)
> -
> -#define VCPU_RESET_PSTATE_EL2 (PSR_MODE_EL2h | PSR_A_BIT | PSR_I_BIT | \
> - PSR_F_BIT | PSR_D_BIT)
> -
> -#define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
> - PSR_AA32_I_BIT | PSR_AA32_F_BIT)
> -
> unsigned int __ro_after_init kvm_sve_max_vl;
>
> int __init kvm_arm_init_sve(void)
> @@ -191,7 +179,6 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> {
> struct vcpu_reset_state reset_state;
> bool loaded;
> - u32 pstate;
>
> spin_lock(&vcpu->arch.mp_state_lock);
> reset_state = vcpu->arch.reset_state;
> @@ -210,21 +197,8 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> kvm_vcpu_reset_sve(vcpu);
> }
>
> - if (vcpu_el1_is_32bit(vcpu))
> - pstate = VCPU_RESET_PSTATE_SVC;
> - else if (vcpu_has_nv(vcpu))
> - pstate = VCPU_RESET_PSTATE_EL2;
> - else
> - pstate = VCPU_RESET_PSTATE_EL1;
> -
> /* Reset core registers */
> - memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
> - memset(&vcpu->arch.ctxt.fp_regs, 0, sizeof(vcpu->arch.ctxt.fp_regs));
> - vcpu->arch.ctxt.spsr_abt = 0;
> - vcpu->arch.ctxt.spsr_und = 0;
> - vcpu->arch.ctxt.spsr_irq = 0;
> - vcpu->arch.ctxt.spsr_fiq = 0;
> - vcpu_gp_regs(vcpu)->pstate = pstate;
> + kvm_reset_vcpu_core(vcpu);
>
> /* Reset system registers */
> kvm_reset_sys_regs(vcpu);
> @@ -233,36 +207,8 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> * Additional reset state handling that PSCI may have imposed on us.
> * Must be done after all the sys_reg reset.
> */
> - if (reset_state.reset) {
> - unsigned long target_pc = reset_state.pc;
> -
> - /* Gracefully handle Thumb2 entry point */
> - if (vcpu_mode_is_32bit(vcpu) && (target_pc & 1)) {
> - target_pc &= ~1UL;
> - vcpu_set_thumb(vcpu);
> - }
> -
> - /* Propagate caller endianness */
> - if (reset_state.be)
> - kvm_vcpu_set_be(vcpu);
> -
> - *vcpu_pc(vcpu) = target_pc;
> -
> - /*
> - * We may come from a state where either a PC update was
> - * pending (SMC call resulting in PC being increpented to
> - * skip the SMC) or a pending exception. Make sure we get
> - * rid of all that, as this cannot be valid out of reset.
> - *
> - * Note that clearing the exception mask also clears PC
> - * updates, but that's an implementation detail, and we
> - * really want to make it explicit.
> - */
> - vcpu_clear_flag(vcpu, PENDING_EXCEPTION);
> - vcpu_clear_flag(vcpu, EXCEPT_MASK);
> - vcpu_clear_flag(vcpu, INCREMENT_PC);
> - vcpu_set_reg(vcpu, 0, reset_state.r0);
> - }
> + if (reset_state.reset)
> + kvm_reset_vcpu_psci(vcpu, &reset_state);
>
> /* Reset timer */
> kvm_timer_vcpu_reset(vcpu);
> --
> 2.55.0.rc0.738.g0c8ab3ebcc-goog
>
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
From: Takashi Iwai @ 2026-06-19 13:27 UTC (permalink / raw)
To: Sean Wang
Cc: Sergey Senozhatsky, Marcel Holtmann, Luiz Augusto von Dentz,
Mark-yw Chen, Sean Wang, Tomasz Figa, linux-bluetooth,
linux-kernel, linux-arm-kernel, linux-mediatek, stable
In-Reply-To: <CAGp9LzpBUReZtrTEKgUr-+yvB+3tcs5hw7ziC4WaMRFNa2AYpg@mail.gmail.com>
On Wed, 10 Jun 2026 08:52:31 +0200,
Sean Wang wrote:
>
> Hi,
>
> On Tue, Jun 9, 2026 at 7:19 AM Sergey Senozhatsky
> <senozhatsky@chromium.org> wrote:
> >
> > Every once in a while we see a hung btmtksdio_flush() task:
> >
> > INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
> > __cancel_work_timer+0x3f4/0x460
> > cancel_work_sync+0x1c/0x2c
> > btmtksdio_flush+0x2c/0x40
> > hci_dev_open_sync+0x10c4/0x2190
> > [..]
> >
> > It all boils down to incorrect time_is_before_jiffies() usage in
> > btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected
> > to be terminated if running for longer than 5*HZ. However the
> > timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)
> > evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
> > timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)
> > means that:
> > - before the 5-second timeout: the condition is `int_status || false`,
> > so it loops as long as there are pending interrupts.
> > - after the 5-second timeout: the condition becomes `int_status || true`,
> > which is always true.
> >
> > When the loop becomes infinite btmtksdio_txrx_work() loop never
> > terminates and never releases the SDIO host.
> >
> > Fix loop termination condition to actually enforce a 5*HZ timeout.
> >
> > Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> > ---
> > drivers/bluetooth/btmtksdio.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> > index 5b0fab7b89b5..c6f80c419e90 100644
> > --- a/drivers/bluetooth/btmtksdio.c
> > +++ b/drivers/bluetooth/btmtksdio.c
> > @@ -620,7 +620,7 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> > if (btmtksdio_rx_packet(bdev, rx_size) < 0)
> > bdev->hdev->stat.err_rx++;
> > }
> > - } while (int_status || time_is_before_jiffies(txrx_timeout));
> > + } while (int_status && time_is_after_jiffies(txrx_timeout));
>
> yes, loop continues only while there is interrupt work and the timeout
> deadline is still in the future
I stumbled on this while backporting to distro kernels, and I wonder
whether this change is correct.
IIUC, this essentially makes the loop exiting right after the first
cycle; the patch changed from time_is_before_jiffies() to *_after_*(),
not only the logical OR to AND, and *_after_*() returns false, so the
whole condition becomes false, too.
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH v2 2/8] KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code
From: Vincent Donnefort @ 2026-06-19 13:26 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, kvmarm, linux-arm-kernel,
linux-kernel, Catalin Marinas, Will Deacon, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Quentin Perret,
Sebastian Ene, Hyunwoo Kim
In-Reply-To: <20260619070719.812227-3-tabba@google.com>
On Fri, Jun 19, 2026 at 08:07:13AM +0100, Fuad Tabba wrote:
> The vcpu_{read,write}_sys_reg() accessors are host-only, so helpers
> built on them such as kvm_vcpu_set_be()/kvm_vcpu_is_be() cannot be
> shared with hyp code. exception.c already wraps them in
> __vcpu_{read,write}_sys_reg(), which pick the host- or hyp-side accessor
> via has_vhe() and so are valid in any context.
>
> Move those wrappers to kvm_emulate.h as kvm_vcpu_{read,write}_sys_reg()
> and switch the callers over, so a follow-up series can share that
> emulation code at EL2.
>
> No functional change intended.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> ---
> arch/arm64/include/asm/kvm_emulate.h | 22 +++++++++++++++---
> arch/arm64/kvm/hyp/exception.c | 34 ++++++++--------------------
> 2 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 5bf3d7e1d92c..80b30fead3d1 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -506,6 +506,22 @@ static inline unsigned long kvm_vcpu_get_mpidr_aff(struct kvm_vcpu *vcpu)
> return __vcpu_sys_reg(vcpu, MPIDR_EL1) & MPIDR_HWID_BITMASK;
> }
>
> +static inline u64 kvm_vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, int reg)
> +{
> + if (has_vhe())
> + return vcpu_read_sys_reg(vcpu, reg);
> +
> + return __vcpu_sys_reg(vcpu, reg);
> +}
> +
> +static inline void kvm_vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg)
> +{
> + if (has_vhe())
> + vcpu_write_sys_reg(vcpu, val, reg);
> + else
> + __vcpu_assign_sys_reg(vcpu, reg, val);
> +}
> +
> static inline void kvm_vcpu_set_be(struct kvm_vcpu *vcpu)
> {
> if (vcpu_mode_is_32bit(vcpu)) {
> @@ -516,9 +532,9 @@ static inline void kvm_vcpu_set_be(struct kvm_vcpu *vcpu)
>
> r = vcpu_has_nv(vcpu) ? SCTLR_EL2 : SCTLR_EL1;
>
> - sctlr = vcpu_read_sys_reg(vcpu, r);
> + sctlr = kvm_vcpu_read_sys_reg(vcpu, r);
> sctlr |= SCTLR_ELx_EE;
> - vcpu_write_sys_reg(vcpu, sctlr, r);
> + kvm_vcpu_write_sys_reg(vcpu, sctlr, r);
> }
> }
>
> @@ -533,7 +549,7 @@ static inline bool kvm_vcpu_is_be(struct kvm_vcpu *vcpu)
> r = is_hyp_ctxt(vcpu) ? SCTLR_EL2 : SCTLR_EL1;
> bit = vcpu_mode_priv(vcpu) ? SCTLR_ELx_EE : SCTLR_EL1_E0E;
>
> - return vcpu_read_sys_reg(vcpu, r) & bit;
> + return kvm_vcpu_read_sys_reg(vcpu, r) & bit;
> }
>
> static inline unsigned long vcpu_data_guest_to_host(struct kvm_vcpu *vcpu,
> diff --git a/arch/arm64/kvm/hyp/exception.c b/arch/arm64/kvm/hyp/exception.c
> index bef40ddb16db..2cb68dc7d441 100644
> --- a/arch/arm64/kvm/hyp/exception.c
> +++ b/arch/arm64/kvm/hyp/exception.c
> @@ -20,22 +20,6 @@
> #error Hypervisor code only!
> #endif
>
> -static inline u64 __vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, int reg)
> -{
> - if (has_vhe())
> - return vcpu_read_sys_reg(vcpu, reg);
> -
> - return __vcpu_sys_reg(vcpu, reg);
> -}
> -
> -static inline void __vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg)
> -{
> - if (has_vhe())
> - vcpu_write_sys_reg(vcpu, val, reg);
> - else
> - __vcpu_assign_sys_reg(vcpu, reg, val);
> -}
> -
> static void __vcpu_write_spsr(struct kvm_vcpu *vcpu, unsigned long target_mode,
> u64 val)
> {
> @@ -101,14 +85,14 @@ static void enter_exception64(struct kvm_vcpu *vcpu, unsigned long target_mode,
>
> switch (target_mode) {
> case PSR_MODE_EL1h:
> - vbar = __vcpu_read_sys_reg(vcpu, VBAR_EL1);
> - sctlr = __vcpu_read_sys_reg(vcpu, SCTLR_EL1);
> - __vcpu_write_sys_reg(vcpu, *vcpu_pc(vcpu), ELR_EL1);
> + vbar = kvm_vcpu_read_sys_reg(vcpu, VBAR_EL1);
> + sctlr = kvm_vcpu_read_sys_reg(vcpu, SCTLR_EL1);
> + kvm_vcpu_write_sys_reg(vcpu, *vcpu_pc(vcpu), ELR_EL1);
> break;
> case PSR_MODE_EL2h:
> - vbar = __vcpu_read_sys_reg(vcpu, VBAR_EL2);
> - sctlr = __vcpu_read_sys_reg(vcpu, SCTLR_EL2);
> - __vcpu_write_sys_reg(vcpu, *vcpu_pc(vcpu), ELR_EL2);
> + vbar = kvm_vcpu_read_sys_reg(vcpu, VBAR_EL2);
> + sctlr = kvm_vcpu_read_sys_reg(vcpu, SCTLR_EL2);
> + kvm_vcpu_write_sys_reg(vcpu, *vcpu_pc(vcpu), ELR_EL2);
> break;
> default:
> /* Don't do that */
> @@ -185,7 +169,7 @@ static void enter_exception64(struct kvm_vcpu *vcpu, unsigned long target_mode,
> */
> static unsigned long get_except32_cpsr(struct kvm_vcpu *vcpu, u32 mode)
> {
> - u32 sctlr = __vcpu_read_sys_reg(vcpu, SCTLR_EL1);
> + u32 sctlr = kvm_vcpu_read_sys_reg(vcpu, SCTLR_EL1);
> unsigned long old, new;
>
> old = *vcpu_cpsr(vcpu);
> @@ -281,7 +265,7 @@ static void enter_exception32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset)
> {
> unsigned long spsr = *vcpu_cpsr(vcpu);
> bool is_thumb = (spsr & PSR_AA32_T_BIT);
> - u32 sctlr = __vcpu_read_sys_reg(vcpu, SCTLR_EL1);
> + u32 sctlr = kvm_vcpu_read_sys_reg(vcpu, SCTLR_EL1);
> u32 return_address;
>
> *vcpu_cpsr(vcpu) = get_except32_cpsr(vcpu, mode);
> @@ -305,7 +289,7 @@ static void enter_exception32(struct kvm_vcpu *vcpu, u32 mode, u32 vect_offset)
> if (sctlr & (1 << 13))
> vect_offset += 0xffff0000;
> else /* always have security exceptions */
> - vect_offset += __vcpu_read_sys_reg(vcpu, VBAR_EL1);
> + vect_offset += kvm_vcpu_read_sys_reg(vcpu, VBAR_EL1);
>
> *vcpu_pc(vcpu) = vect_offset;
> }
> --
> 2.55.0.rc0.738.g0c8ab3ebcc-goog
>
^ permalink raw reply
* Re: [PATCH v2 1/8] KVM: arm64: Extract MPIDR computation into a shared header
From: Vincent Donnefort @ 2026-06-19 13:24 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, kvmarm, linux-arm-kernel,
linux-kernel, Catalin Marinas, Will Deacon, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Quentin Perret,
Sebastian Ene, Hyunwoo Kim
In-Reply-To: <20260619070719.812227-2-tabba@google.com>
On Fri, Jun 19, 2026 at 08:07:12AM +0100, Fuad Tabba wrote:
> Extract the vCPU MPIDR computation embedded in reset_mpidr() into a
> kvm_calculate_mpidr() inline in sys_regs.h, so it can be computed
> without duplicating the logic. A follow-up series reuses it to reset
> protected vCPUs at EL2.
>
> No functional change intended.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> ---
> arch/arm64/kvm/sys_regs.c | 14 +-------------
> arch/arm64/kvm/sys_regs.h | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 33c921df19b5..674fabe1d40d 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -976,21 +976,9 @@ static u64 reset_actlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
>
> static u64 reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
> {
> - u64 mpidr;
> + u64 mpidr = kvm_calculate_mpidr(vcpu);
>
> - /*
> - * Map the vcpu_id into the first three affinity level fields of
> - * the MPIDR. We limit the number of VCPUs in level 0 due to a
> - * limitation to 16 CPUs in that level in the ICC_SGIxR registers
> - * of the GICv3 to be able to address each CPU directly when
> - * sending IPIs.
> - */
> - mpidr = (vcpu->vcpu_id & 0x0f) << MPIDR_LEVEL_SHIFT(0);
> - mpidr |= ((vcpu->vcpu_id >> 4) & 0xff) << MPIDR_LEVEL_SHIFT(1);
> - mpidr |= ((vcpu->vcpu_id >> 12) & 0xff) << MPIDR_LEVEL_SHIFT(2);
> - mpidr |= (1ULL << 31);
> vcpu_write_sys_reg(vcpu, mpidr, MPIDR_EL1);
> -
> return mpidr;
> }
>
> diff --git a/arch/arm64/kvm/sys_regs.h b/arch/arm64/kvm/sys_regs.h
> index 2a983664220c..bd56a45abbf9 100644
> --- a/arch/arm64/kvm/sys_regs.h
> +++ b/arch/arm64/kvm/sys_regs.h
> @@ -222,6 +222,25 @@ find_reg(const struct sys_reg_params *params, const struct sys_reg_desc table[],
> return __inline_bsearch((void *)pval, table, num, sizeof(table[0]), match_sys_reg);
> }
>
> +static inline u64 kvm_calculate_mpidr(const struct kvm_vcpu *vcpu)
> +{
> + u64 mpidr;
> +
> + /*
> + * Map the vcpu_id into the first three affinity level fields of
> + * the MPIDR. We limit the number of VCPUs in level 0 due to a
> + * limitation to 16 CPUs in that level in the ICC_SGIxR registers
> + * of the GICv3 to be able to address each CPU directly when
> + * sending IPIs.
> + */
> + mpidr = (vcpu->vcpu_id & 0x0f) << MPIDR_LEVEL_SHIFT(0);
> + mpidr |= ((vcpu->vcpu_id >> 4) & 0xff) << MPIDR_LEVEL_SHIFT(1);
> + mpidr |= ((vcpu->vcpu_id >> 12) & 0xff) << MPIDR_LEVEL_SHIFT(2);
> + mpidr |= (1ULL << 31);
> +
> + return mpidr;
> +}
> +
> const struct sys_reg_desc *get_reg_by_id(u64 id,
> const struct sys_reg_desc table[],
> unsigned int num);
> --
> 2.55.0.rc0.738.g0c8ab3ebcc-goog
>
^ permalink raw reply
* [PATCH v2 2/2] arm: dts: xilinx: Add support for MYIR MYS-7Z020-V2 board
From: Liu Yu @ 2026-06-19 13:23 UTC (permalink / raw)
To: Michal Simek
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-arm-kernel, Liu Yu
In-Reply-To: <20260619132355.1776-1-f78fk@live.com>
Add device tree support for the MYIR MYS-7Z020-V2 board based on
the Xilinx Zynq-7000 XC7Z020 SoC.
The board supports:
- UART serial console
- MicroSD card interface
- Gigabit Ethernet
- QSPI NOR flash
- GPIO-based user LEDs and push-button
Link: https://www.myirtech.com/list.asp?id=708
Signed-off-by: Liu Yu <f78fk@live.com>
---
arch/arm/boot/dts/xilinx/Makefile | 1 +
.../arm/boot/dts/xilinx/zynq-mys-7z020-v2.dts | 232 ++++++++++++++++++
2 files changed, 233 insertions(+)
create mode 100644 arch/arm/boot/dts/xilinx/zynq-mys-7z020-v2.dts
diff --git a/arch/arm/boot/dts/xilinx/Makefile b/arch/arm/boot/dts/xilinx/Makefile
index 9233e539b192..6c59116013f1 100644
--- a/arch/arm/boot/dts/xilinx/Makefile
+++ b/arch/arm/boot/dts/xilinx/Makefile
@@ -3,6 +3,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-cc108.dtb \
zynq-ebaz4205.dtb \
zynq-microzed.dtb \
+ zynq-mys-7z020-v2.dtb \
zynq-parallella.dtb \
zynq-zc702.dtb \
zynq-zc706.dtb \
diff --git a/arch/arm/boot/dts/xilinx/zynq-mys-7z020-v2.dts b/arch/arm/boot/dts/xilinx/zynq-mys-7z020-v2.dts
new file mode 100644
index 000000000000..b55133133e2f
--- /dev/null
+++ b/arch/arm/boot/dts/xilinx/zynq-mys-7z020-v2.dts
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 Liu Yu <f78fk@live.com>
+ */
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "zynq-7000.dtsi"
+
+/ {
+ model = "MYIR MYS-7Z020-V2 Board";
+ compatible = "myir,mys-7z020-v2", "xlnx,zynq-7000";
+
+ aliases {
+ ethernet0 = &gem0;
+ mmc0 = &sdhci0;
+ serial0 = &uart1;
+ spi0 = &qspi;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ key-user {
+ label = "USR";
+ gpios = <&gpio0 50 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_PROG1>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ led-blue {
+ label = "led_blue";
+ gpios = <&gpio0 115 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-green {
+ label = "led_green";
+ gpios = <&gpio0 114 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-red {
+ label = "led_red";
+ gpios = <&gpio0 116 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ usr-led1 {
+ label = "usr_led1";
+ gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ usr-led2 {
+ label = "usr_led2";
+ gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x40000000>;
+ };
+};
+
+&clkc {
+ ps-clk-frequency = <33333333>;
+};
+
+&gem0 {
+ phy-mode = "rgmii-id";
+ phy-handle = <ðernet_phy>;
+
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet_phy: ethernet-phy@7 {
+ reg = <0x7>;
+ };
+ };
+};
+
+&gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio0_default>;
+};
+
+&pinctrl0 {
+ pinctrl_gpio0_default: gpio0-default {
+ mux {
+ function = "gpio0";
+ groups = "gpio0_0_grp", "gpio0_9_grp", "gpio0_50_grp";
+ };
+ conf {
+ groups = "gpio0_0_grp", "gpio0_9_grp", "gpio0_50_grp";
+ slew-rate = <0>;
+ io-standard = <1>;
+ };
+ conf-pull-up {
+ pins = "MIO0", "MIO9", "MIO50";
+ bias-pull-up;
+ };
+ };
+
+ pinctrl_sdhci0_default: sdhci0-default {
+ mux {
+ groups = "sdio0_2_grp";
+ function = "sdio0";
+ };
+ mux-cd {
+ groups = "gpio0_46_grp";
+ function = "sdio0_cd";
+ };
+ conf {
+ groups = "sdio0_2_grp";
+ slew-rate = <0>;
+ io-standard = <1>;
+ bias-disable;
+ };
+ conf-cd {
+ pins = "MIO46";
+ bias-pull-up;
+ slew-rate = <0>;
+ io-standard = <1>;
+ };
+ };
+
+ pinctrl_uart1_default: uart1-default {
+ mux {
+ groups = "uart1_10_grp";
+ function = "uart1";
+ };
+ conf {
+ groups = "uart1_10_grp";
+ slew-rate = <0>;
+ io-standard = <1>;
+ };
+ conf-rx {
+ pins = "MIO49";
+ bias-high-impedance;
+ };
+ conf-tx {
+ pins = "MIO48";
+ bias-disable;
+ };
+ };
+};
+
+&qspi {
+ num-cs = <1>;
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <50000000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "qspi-boot";
+ reg = <0x0 0x80000>;
+ };
+
+ partition@80000 {
+ label = "qspi-bootenv";
+ reg = <0x80000 0x20000>;
+ };
+
+ partition@a0000 {
+ label = "qspi-bitstream";
+ reg = <0xa0000 0x460000>;
+ };
+
+ partition@500000 {
+ label = "qspi-kernel";
+ reg = <0x500000 0x480000>;
+ };
+
+ partition@980000 {
+ label = "qspi-devicetree";
+ reg = <0x980000 0x10000>;
+ };
+
+ partition@990000 {
+ label = "qspi-rootfs";
+ reg = <0x990000 0x600000>;
+ };
+
+ partition@f90000 {
+ label = "data";
+ reg = <0xf90000 0x70000>;
+ };
+ };
+ };
+};
+
+&sdhci0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sdhci0_default>;
+ disable-wp;
+
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1_default>;
+
+ status = "okay";
+};
+
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: soc: xilinx: Add MYIR MYS-7Z020-V2 board
From: Liu Yu @ 2026-06-19 13:23 UTC (permalink / raw)
To: Michal Simek
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-arm-kernel, Liu Yu
In-Reply-To: <20260619132355.1776-1-f78fk@live.com>
Add compatible string for the MYIR MYS-7Z020-V2 board, based on
the Xilinx Zynq-7000 XC7Z020 SoC.
Signed-off-by: Liu Yu <f78fk@live.com>
---
Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
index c9f99e0df2b3..72a84b628da3 100644
--- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
+++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
@@ -23,6 +23,7 @@ properties:
- digilent,zynq-zybo
- digilent,zynq-zybo-z7
- ebang,ebaz4205
+ - myir,mys-7z020-v2
- myir,zynq-zturn-v5
- myir,zynq-zturn
- xlnx,zynq-cc108
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] arm: dts: xilinx: Add MYIR MYS-7Z020-V2 board support
From: Liu Yu @ 2026-06-19 13:23 UTC (permalink / raw)
To: Michal Simek
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-arm-kernel, Liu Yu
In-Reply-To: <20260619102214.223121-1-f78fk@live.com>
This series adds basic device tree and binding documentation support
for the MYIR MYS-7Z020-V2 development board, which is based on the
Xilinx Zynq-7000 (XC7Z020) SoC.
The first patch introduces the device tree file enabling essential
hardware support such as the serial console, MicroSD, Gigabit Ethernet,
QSPI flash, and user LEDs/buttons. The second patch adds the corresponding
compatible string to the Xilinx SoC bindings documentation.
Changes in v2:
- Add missing pinmux configuration (sdio0_cd) for MIO46 to correctly
route the hardware SD card detect signal, resolving the automated
review warning.
Liu Yu (2):
dt-bindings: soc: xilinx: Add MYIR MYS-7Z020-V2 board
arm: dts: xilinx: Add support for MYIR MYS-7Z020-V2 board
.../bindings/soc/xilinx/xilinx.yaml | 1 +
arch/arm/boot/dts/xilinx/Makefile | 1 +
.../arm/boot/dts/xilinx/zynq-mys-7z020-v2.dts | 232 ++++++++++++++++++
3 files changed, 234 insertions(+)
create mode 100644 arch/arm/boot/dts/xilinx/zynq-mys-7z020-v2.dts
--
2.43.0
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Catalin Marinas @ 2026-06-19 13:19 UTC (permalink / raw)
To: Harry Yoo
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <b1502a60-09a1-4699-886b-93d041de7023@kernel.org>
On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
> On 6/12/26 1:44 PM, Dev Jain wrote:
> > Introduce a boot option to tag only at allocation time of the objects. This
> > reduces KASAN MTE overhead, the tradeoff being reduced ability of
> > catching bugs.
>
> I think most of overhead when enabling MTE comes from loading and
> validing tags for every memory access (either in SYNC or ASYNC mode),
> rather than from storing tags.
I guess it depends on the workload. Lots of allocations for short-lived
buffers (e.g. network traffic) may notice the additional tagging more
than the actual tag checking.
Of course, it would be nice to get some numbers from those who have
access to MTE capable hardware.
> > Now, when a memory object will be freed, it will retain the random tag it
> > had at allocation time. This compromises on catching UAF bugs, till the
> > time the object is not reallocated, at which point it will have a new
> > random tag.
> >
> > Hence, not catching "use-after-free-before-reallocation" and not catching
> > "double-free" will be the compromise for reduced KASAN overhead.
>
> I doubt users who care about security enough to enable HW_TAGS KASAN
> are willing to compromise on security just to save a few instructions
> to store tags in the free path.
>
> To me, it looks like too much of a compromise on security for little
> performance gain.
I don't think there's much compromise on security for use-after-free.
The buffer will be re-tagged later so use-after-realloc should be
caught, especially if we ensure that a different tag will be used (I
don't think Dev's patches do this).
Of course, if you want MTE as a debug/bug-finding feature, tagging on
both allocation and freeing is highly recommended. This patchset is
aimed for those wanting to run MTE in production and squeeze a bit more
performance out of it (with the compromise of not detecting
use-after-free, only prevent access after re-allocation).
--
Catalin
^ permalink raw reply
* [PATCH v3 net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Wayen Yan @ 2026-06-19 13:12 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
- channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
- channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
- channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
- channel 3: clears bit 24..31 (channel 3 only) - correct by accident
While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
mask parameter, the loop still incorrectly clears queues within the
same channel beyond queue 7.
Even though this is functionally harmless (the register resets to 0
and is only ever cleared, never set — so clearing extra bits is a
no-op), the loop bound is semantically wrong and should be fixed for
correctness and clarity.
Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Wayen Yan <win847@gmail.com>
---
Changes in v3:
- Rebase on top of current net tree (Lorenzo pointed out v2 was
not based on latest net HEAD).
- No code changes from v2.
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 64dde6464f..47fb32517a 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2395,7 +2395,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *netdev,
struct airoha_gdm_dev *dev = netdev_priv(netdev);
int i;
- for (i = 0; i < AIROHA_NUM_TX_RING; i++)
+ for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
airoha_qdma_clear(dev->qdma, REG_QUEUE_CLOSE_CFG(channel),
TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 8/8] KVM: arm64: Implement lazy vCPU state sync for non-protected guests
From: Vincent Donnefort @ 2026-06-19 13:12 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, kvmarm, linux-arm-kernel,
linux-kernel, Catalin Marinas, Will Deacon, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Quentin Perret,
Sebastian Ene, Hyunwoo Kim
In-Reply-To: <20260619070719.812227-9-tabba@google.com>
On Fri, Jun 19, 2026 at 08:07:19AM +0100, Fuad Tabba 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.
>
> PC and PSTATE are the exception: they are copied back on every exit so
> the kvm_exit tracepoint reports the guest's real exit PC, and the run
> loop's vcpu_mode_is_bad_32bit() and SError-masking checks evaluate the
> guest's current PSTATE rather than the value left by the previous sync.
>
> handle_exit_early() can also inject an SError, which writes the guest
> context (ESR_EL1) outside the trap-handling path. For a non-protected
> guest it therefore syncs the context from the hyp vCPU and marks it
> dirty, as handle_trap_exceptions() does, so the injection reaches the
> hyp vCPU on re-entry rather than being dropped.
>
> 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 | 30 +++++++++++
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 86 ++++++++++++++++++++++++++++--
> 5 files changed, 121 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 2faa60df847d..caa39ee5125f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -1068,6 +1068,8 @@ struct kvm_vcpu_arch {
> #define INCREMENT_PC __vcpu_single_flag(iflags, BIT(1))
> /* Target EL/MODE (not a single flag, but let's abuse the macro) */
> #define EXCEPT_MASK __vcpu_single_flag(iflags, GENMASK(3, 1))
> +/* Host-set: the hyp flushes the non-protected vCPU state in on entry */
> +#define PKVM_HOST_STATE_DIRTY __vcpu_single_flag(iflags, BIT(4))
>
> /* Helpers to encode exceptions with minimum fuss */
> #define __EXCEPT_MASK_VAL unpack_vcpu_flag(EXCEPT_MASK)
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 3732ee9eb0d4..4e89558d8027 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -733,6 +733,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);
> @@ -964,6 +968,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..8963621bcdd1 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -422,6 +422,20 @@ 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)) {
> + 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);
> + }
> + }
> +
Could we remove this update here and let handle_exit_early() do the sync
regardless of the SError injection? One of the main point of handle_exit_early()
is to do things under !prempt().
> /*
> * See ARM ARM B1.14.1: "Hyp traps on instructions
> * that fail their condition code check"
> @@ -489,6 +503,22 @@ 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)
> {
> + bool inject_serror = ARM_SERROR_PENDING(exception_index) ||
> + ARM_EXCEPTION_CODE(exception_index) == ARM_EXCEPTION_EL1_SERROR;
> +
> + /*
> + * An SError injected below writes the host ctxt; for a non-protected
> + * guest, sync from the hyp vCPU and keep it dirty so it isn't dropped.
> + */
> + if (is_protected_kvm_enabled()) {
Should we test !kvm_vm_is_protected(vcpu->kvm) here, as the
PKVM_HOST_STATE_DIRTY is only updated for p-guests everywhere else?
> + vcpu_clear_flag(vcpu, PKVM_HOST_STATE_DIRTY);
> +
> + if (inject_serror && !kvm_vm_is_protected(vcpu->kvm)) {
> + kvm_call_hyp_nvhe(__pkvm_vcpu_sync_state);
> + vcpu_set_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);
[...]
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: defconfig: Drop unused Ethernet vendors
From: Krzysztof Kozlowski @ 2026-06-19 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Will Deacon,
Arnd Bergmann, Alexandre Belloni, Linus Walleij, Drew Fustini,
soc
In-Reply-To: <CAMuHMdVH6-5ZAjTyF3m=wF5-XiSDqwcgRhZWxJv6y0FoCnk4MA@mail.gmail.com>
On 19/06/2026 12:12, Geert Uytterhoeven wrote:
>> +# CONFIG_NET_VENDOR_ACTIONS is not set
>> +# CONFIG_NET_VENDOR_ADAPTEC is not set
>> +# CONFIG_NET_VENDOR_AGERE is not set
>> +# CONFIG_NET_VENDOR_ALACRITECH is not set
>> +# CONFIG_NET_VENDOR_ALLWINNER is not set
>
> [...]
>
> I am not sure this new policy is a good idea: none of this affects
I would not call it new policy. Just an idea which got accepted. :)
> actual kernel size, but it does increase defconfig size, and churn.
> E.g. for the m68k defconfig, I dropped all these disablements
> several years ago.
>
> I don't use menufconfig, so just my 2€c...
I understand, feedback accepted. Patch got merged, so you know...
To share my point: I don't edit defconfig by hand but through
menuconfig+savedefconfig, thus size of defconfig is acceptable to me
price to pay for smaller menuconfig choices.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
From: Will Deacon @ 2026-06-19 13:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Will Deacon, Arnd Bergmann, Nick Desaulniers, Steffen Eiden,
Andreas Grapentin, Catalin Marinas, Dave Martin, Mark Rutland,
Marc Zyngier
The arm64 UAPI exposes '__uint128_t' types in the members of
'struct user_fpsimd_state', 'struct user_pac_address_keys' and in the
signal frame via 'struct fpsimd_context'. Since the alignment of such
a type appears to be non-portable (16 bytes on arm64, 8 bytes on s390),
prefer the '__u128' typedef from uapi/linux/types.h, which makes the
alignment explicit and allows the definitions to be reused by other
host architectures.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Cc: Steffen Eiden <seiden@linux.ibm.com>
Cc: Andreas Grapentin <gra@linux.ibm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Martin <dave.martin@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
---
This aims to help a little with the s390/arm64 KVM series at:
https://lore.kernel.org/r/20260529155050.2902245-1-seiden@linux.ibm.com
by allowing the relevant parts of the arm64 UAPI to be used directly by
s390 rather than copied and modified.
I think it's a straightforward change, but the only thing that makes me
pause for thought is whether there are toolchains out there which accept
__uint128_t but not __int128. Then again, if that crops up as an issue
we can probably just tweak the typedef we have in uapi/linux/types.h.
arch/arm64/include/uapi/asm/ptrace.h | 12 ++++++------
arch/arm64/include/uapi/asm/sigcontext.h | 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index 6fed93fb2536..15649a253a57 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -93,7 +93,7 @@ struct user_pt_regs {
};
struct user_fpsimd_state {
- __uint128_t vregs[32];
+ __u128 vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
@@ -258,14 +258,14 @@ struct user_pac_mask {
/* pointer authentication keys (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS) */
struct user_pac_address_keys {
- __uint128_t apiakey;
- __uint128_t apibkey;
- __uint128_t apdakey;
- __uint128_t apdbkey;
+ __u128 apiakey;
+ __u128 apibkey;
+ __u128 apdakey;
+ __u128 apdbkey;
};
struct user_pac_generic_keys {
- __uint128_t apgakey;
+ __u128 apgakey;
};
/* ZA state (NT_ARM_ZA) */
diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
index e29bf3e2d0cc..d250ca7a1d46 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -78,7 +78,7 @@ struct fpsimd_context {
struct _aarch64_ctx head;
__u32 fpsr;
__u32 fpcr;
- __uint128_t vregs[32];
+ __u128 vregs[32];
};
/*
@@ -266,8 +266,8 @@ struct gcs_context {
* - ---- -----------
* REGS the entire SVE context
*
- * ZREGS __uint128_t[SVE_NUM_ZREGS][vq] all Z-registers
- * ZREG __uint128_t[vq] individual Z-register Zn
+ * ZREGS __u128[SVE_NUM_ZREGS][vq] all Z-registers
+ * ZREG __u128[vq] individual Z-register Zn
*
* PREGS uint16_t[SVE_NUM_PREGS][vq] all P-registers
* PREG uint16_t[vq] individual P-register Pn
--
2.55.0.rc0.738.g0c8ab3ebcc-goog
^ permalink raw reply related
* [PATCH v3 54/78] drm/meson: encoder_cvbs: Switch to atomic_create_state
From: Maxime Ripard @ 2026-06-19 12:24 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Maxime Ripard, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20260619-drm-no-more-bridge-reset-v3-0-ff399263111b@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Kevin Hilman <khilman@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/meson/meson_encoder_cvbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.c b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
index 8b26a0031cde..22cacb1660c4 100644
--- a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
@@ -213,11 +213,11 @@ static const struct drm_bridge_funcs meson_encoder_cvbs_bridge_funcs = {
.atomic_enable = meson_encoder_cvbs_atomic_enable,
.atomic_disable = meson_encoder_cvbs_atomic_disable,
.atomic_check = meson_encoder_cvbs_atomic_check,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
- .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_create_state = drm_atomic_helper_bridge_create_state,
};
int meson_encoder_cvbs_probe(struct meson_drm *priv)
{
struct drm_device *drm = priv->drm;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/5] docs: media: add documentation for media client usage stats
From: Mauro Carvalho Chehab @ 2026-06-19 13:06 UTC (permalink / raw)
To: Detlev Casanova
Cc: Mauro Carvalho Chehab, Nicolas Dufresne, Benjamin Gaignard,
Philipp Zabel, Ezequiel Garcia, Heiko Stuebner, linux-media,
linux-kernel, linux-rockchip, kernel, linux-arm-kernel,
Christopher Healy
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-2-d298e98ce06a@collabora.com>
On Wed, Jun 17, 2026 at 02:10:57PM -0400, Detlev Casanova wrote:
> From: Christopher Healy <healych@amazon.com>
>
> Document the media fdinfo interface for per-file-descriptor usage
> statistics exposed by stateless V4L2 codec drivers via
> /proc/<pid>/fdinfo/<fd>.
>
> This interface is designed for stateless (request API based) codec
> devices where the kernel driver has per-job visibility into hardware
> execution. Stateful codecs cannot support all of this because their
> firmware manages job scheduling opaquely.
>
> The specification defines media- prefixed keys for engine utilization
> time, and operating frequency, following the same conventions as the DRM
> fdinfo mechanism documented in drm-usage-stats.rst.
>
> More fields can be added later.
>
> Signed-off-by: Christopher Healy <healych@amazon.com>
> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
> ---
> .../userspace-api/media/drivers/index.rst | 1 +
> .../media/drivers/media-usage-stats.rst | 85 ++++++++++++++++++++++
Please notice that sysfs/procfs APIs are usually documented at
Documentation/ABI/, using a machine-readable format[1]. Still, we do want
it also at media uAPI. So, please add it there as well on your next spin.
[1] As those are new, Documentation/ABI/testing/ is probably the best place.
> 2 files changed, 86 insertions(+)
>
> diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst
> index 02967c9b18d6..61879738836c 100644
> --- a/Documentation/userspace-api/media/drivers/index.rst
> +++ b/Documentation/userspace-api/media/drivers/index.rst
> @@ -34,6 +34,7 @@ For more details see the file COPYING in the source distribution of Linux.
> imx-uapi
> mali-c55
> max2175
> + media-usage-stats
> npcm-video
> omap3isp-uapi
> thp7312
> diff --git a/Documentation/userspace-api/media/drivers/media-usage-stats.rst b/Documentation/userspace-api/media/drivers/media-usage-stats.rst
> new file mode 100644
> index 000000000000..d3dc07002f62
> --- /dev/null
> +++ b/Documentation/userspace-api/media/drivers/media-usage-stats.rst
> @@ -0,0 +1,85 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +.. _media-usage-stats:
> +
> +==========================
> +Media client usage stats
> +==========================
> +
> +Stateless V4L2 codec drivers can optionally expose per-file-descriptor usage
> +statistics via ``/proc/<pid>/fdinfo/<fd>``. This is analogous to the DRM fdinfo
> +mechanism documented in :ref:`drm-client-usage-stats`, but uses the ``media-``
> +key prefix for V4L2 media devices.
> +
> +This interface is specific to stateless (request API based) codec devices,
> +including both decoders and encoders. With stateless codecs, the kernel driver
> +explicitly submits each frame to the hardware and receives a completion
> +interrupt, providing a clean per-job boundary that can be attributed to the
> +submitting file descriptor.
> +
> +Stateful codec devices cannot support this interface because their firmware
> +manages job scheduling internally. The kernel driver submits bitstream data
> +but has no visibility into per-frame hardware execution timing.
> +
> +Implementation
> +==============
> +
> +The V4L2 core provides the plumbing: drivers implement the ``show_fdinfo``
> +callback in ``struct v4l2_file_operations``, and the core wires it into the
> +kernel ``struct file_operations`` so that ``/proc/<pid>/fdinfo/<fd>`` output
> +includes the driver-provided keys.
> +
> +File format specification
> +=========================
> +
> +- File shall contain one key value pair per one line of text.
> +- Colon character (``:``) must be used to delimit keys and values.
> +- All standardised keys shall be prefixed with ``media-``.
> +- Driver-specific keys shall be prefixed with ``driver_name-``.
> +
> +Mandatory keys
> +--------------
> +
> +- media-driver: <valstr>
> +
> + String shall contain the name of the media driver.
> +
> +- media-type: <valstr>
> +
> + String shall identify the type of media engine exposed through this file
> + descriptor. Standard values are ``decoder`` and ``encoder``.
> +
> +Utilization keys
> +----------------
> +
> +- media-engine-usage: <uint> ns
> +
> + Time in nanoseconds that the hardware engine spent busy processing work
> + belonging to this file descriptor. The engine being measured is identified
> + by the ``media-type`` key.
> +
> + Values are not required to be constantly monotonic if it makes the driver
> + implementation easier, but are required to catch up with the previously
> + reported larger value within a reasonable period.
> +
> +Frequency keys
> +--------------
> +
> +- media-maxfreq: <uint> Hz
> +
> + Maximum operating frequency of the main engine clock.
> +
> +- media-curfreq: <uint> Hz
> +
> + Current operating frequency of the main engine clock.
> +
> +Example output
> +==============
> +
> +::
> +
> + media-driver: hantro-vpu
> + media-type: decoder
> + media-engine-usage: 123456789 ns
> + media-maxfreq: 600000000 Hz
> + media-curfreq: 600000000 Hz
>
> --
> 2.54.0
>
--
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v2 3/5] media: v4l2-core: Add v4l2-stats interface
From: Hans Verkuil @ 2026-06-19 13:05 UTC (permalink / raw)
To: Detlev Casanova, Mauro Carvalho Chehab, Nicolas Dufresne,
Benjamin Gaignard, Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
linux-arm-kernel
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-3-d298e98ce06a@collabora.com>
On 17/06/2026 20:10, Detlev Casanova wrote:
> Provide helpers for media drivers to set fdinfo data and print the
> key:value pairs in a standard way.
>
> User drivers can set stats values with helpers like:
> - v4l2_stats_update_hw_usage
> - v4l2_stats_set_media_dev_type
>
> And also call the show helpers from their show_fdinfo callback with:
> - v4l2_stats_show -- Shows the values set previously
> - v4l2_stats_show_clock -- Shows the main clock state.
>
> The show_clock helper is used instead of updating a clock value in
> v4l2_stats for the following reasons:
> - Clocks are at the device level, this is not a per-fd information
> - This avoids having clock references in v4l2-core
> - Drivers can use different approaches to manage clocks
> (e.g.: bulk_data or not: A set helper wouldn't please all drivers)
> - Arguably, clocks could be exposed elsewhere (like a debugfs), but we
> want something close to what DRM does and centralizing information has
> its advantages for userspace tooling.
>
> In DRM the key:value pair format for clocks is documented and each driver
> can write them directly based on that.
> In this case, provide a helper and document the format.
>
> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
> ---
> drivers/media/v4l2-core/Makefile | 2 +-
> drivers/media/v4l2-core/v4l2-dev.c | 2 ++
> drivers/media/v4l2-core/v4l2-fh.c | 3 ++
> drivers/media/v4l2-core/v4l2-stats.c | 65 ++++++++++++++++++++++++++++++++++++
> include/media/v4l2-fh.h | 2 ++
> include/media/v4l2-stats.h | 44 ++++++++++++++++++++++++
> 6 files changed, 117 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
> index 329f0eadce99..20e1ab74ac09 100644
> --- a/drivers/media/v4l2-core/Makefile
> +++ b/drivers/media/v4l2-core/Makefile
> @@ -9,7 +9,7 @@ ccflags-y += -I$(srctree)/drivers/media/tuners
> tuner-objs := tuner-core.o
>
> videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
> - v4l2-event.o v4l2-subdev.o v4l2-common.o \
> + v4l2-event.o v4l2-subdev.o v4l2-common.o v4l2-stats.o \
> v4l2-ctrls-core.o v4l2-ctrls-api.o \
> v4l2-ctrls-request.o v4l2-ctrls-defs.o
>
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
> index 3878fa2ff73e..3e7a6876dffd 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -486,6 +486,8 @@ static void v4l2_show_fdinfo(struct seq_file *m, struct file *filp)
> {
> struct video_device *vdev = video_devdata(filp);
>
> + seq_printf(m, "media-driver:\t%s\n", vdev->v4l2_dev->name);
> +
> if (vdev->fops->show_fdinfo)
> vdev->fops->show_fdinfo(m, filp);
> }
> diff --git a/drivers/media/v4l2-core/v4l2-fh.c b/drivers/media/v4l2-core/v4l2-fh.c
> index b184bed8aca9..1b655672c718 100644
> --- a/drivers/media/v4l2-core/v4l2-fh.c
> +++ b/drivers/media/v4l2-core/v4l2-fh.c
> @@ -17,6 +17,7 @@
> #include <media/v4l2-event.h>
> #include <media/v4l2-ioctl.h>
> #include <media/v4l2-mc.h>
> +#include <media/v4l2-stats.h>
>
> void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
> {
> @@ -38,6 +39,7 @@ void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
> INIT_LIST_HEAD(&fh->subscribed);
> fh->sequence = -1;
> mutex_init(&fh->subscribe_lock);
> + v4l2_stats_init(&fh->stats);
> }
> EXPORT_SYMBOL_GPL(v4l2_fh_init);
>
> @@ -88,6 +90,7 @@ void v4l2_fh_exit(struct v4l2_fh *fh)
> v4l2_event_unsubscribe_all(fh);
> mutex_destroy(&fh->subscribe_lock);
> fh->vdev = NULL;
> + v4l2_stats_exit(&fh->stats);
> }
> EXPORT_SYMBOL_GPL(v4l2_fh_exit);
>
> diff --git a/drivers/media/v4l2-core/v4l2-stats.c b/drivers/media/v4l2-core/v4l2-stats.c
> new file mode 100644
> index 000000000000..93e64ef2e7bb
> --- /dev/null
> +++ b/drivers/media/v4l2-core/v4l2-stats.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * v4l2-stats.c
> + *
> + * V4L2 statistics management.
> + *
> + * Maintain a per-file handle list of statistics about the hardware and handle
> + * exposing it in the fdinfo.
> + *
> + * Copyright (C) 2026 Collabora.
> + *
> + * Contact: Detlev Casanova <detlev.casanova@collabora.com>
> + */
> +
> +#include <linux/types.h>
> +#include <linux/seq_file.h>
> +#include <linux/clk.h>
> +#include <media/v4l2-stats.h>
> +
> +static const char * const dev_type_name[] = {
> + [MEDIA_DEV_TYPE_V4L2] = "media",
> + [MEDIA_DEV_TYPE_V4L2_STATELESS_ENCODER] = "encoder",
> + [MEDIA_DEV_TYPE_V4L2_STATELESS_DECODER] = "decoder",
> +};
> +
> +void v4l2_stats_init(struct v4l2_stats *stats)
> +{
> + stats->hw_usage_time = 0;
> + stats->media_dev_type = MEDIA_DEV_TYPE_V4L2;
> +}
> +
> +void v4l2_stats_exit(struct v4l2_stats *stats)
> +{
> +}
> +
> +void v4l2_stats_update_hw_usage(struct v4l2_stats *stats, u64 usage_time)
> +{
> + stats->hw_usage_time += usage_time;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_stats_update_hw_usage);
> +
> +void v4l2_stats_set_media_dev_type(struct v4l2_stats *stats, enum v4l2_media_dev_type type)
> +{
> + if (type >= MEDIA_DEV_TYPE_COUNT)
> + return;
> +
> + stats->media_dev_type = type;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_stats_set_media_dev_type);
> +
> +void v4l2_stats_show(struct v4l2_stats *stats, struct seq_file *m)
> +{
> + seq_printf(m, "media-type:\t%s\n", dev_type_name[stats->media_dev_type]);
> + seq_printf(m, "media-engine-usage:\t%llu ns\n", stats->hw_usage_time);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_stats_show);
> +
> +void v4l2_stats_show_clock(struct seq_file *m, struct clk *clk)
> +{
> + seq_printf(m, "media-maxfreq:\t%lu Hz\n",
> + clk_get_rate(clk));
> + seq_printf(m, "media-curfreq:\t%lu Hz\n",
> + clk_get_rate(clk));
> +}
> +EXPORT_SYMBOL_GPL(v4l2_stats_show_clock);
> diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
> index aad4b3689d7e..ae6688722bee 100644
> --- a/include/media/v4l2-fh.h
> +++ b/include/media/v4l2-fh.h
> @@ -17,6 +17,7 @@
> #include <linux/kconfig.h>
> #include <linux/list.h>
> #include <linux/videodev2.h>
> +#include <media/v4l2-stats.h>
>
> struct video_device;
> struct v4l2_ctrl_handler;
> @@ -43,6 +44,7 @@ struct v4l2_fh {
> struct list_head list;
> struct video_device *vdev;
> struct v4l2_ctrl_handler *ctrl_handler;
> + struct v4l2_stats stats;
> enum v4l2_priority prio;
>
> /* Events */
> diff --git a/include/media/v4l2-stats.h b/include/media/v4l2-stats.h
> new file mode 100644
> index 000000000000..d580933c4181
> --- /dev/null
> +++ b/include/media/v4l2-stats.h
> @@ -0,0 +1,44 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * v4l2-stats.h
> + *
> + * V4L2 statistics management.
> + *
> + * Maintain a per-file handle list of statistics about the hardware and handle
> + * exposing it in the fdinfo.
> + *
> + * Copyright (C) 2026 Collabora.
> + *
> + * Contact: Detlev Casanova <detlev.casanova@collabora.com>
> + */
> +#ifndef V4L2_STATS_H
> +#define V4L2_STATS_H
> +
> +#include <linux/types.h>
> +
> +struct clk;
> +struct seq_file;
> +
> +enum v4l2_media_dev_type {
> + MEDIA_DEV_TYPE_V4L2 = 0,
> + MEDIA_DEV_TYPE_V4L2_STATELESS_ENCODER,
> + MEDIA_DEV_TYPE_V4L2_STATELESS_DECODER,
> +
> + MEDIA_DEV_TYPE_COUNT,
I'm a bit unhappy about introducing yet another type. Do we need it?
> +};
> +
> +struct v4l2_stats {
Poor name, and it conflicts with ISP statistics.
How about v4l2_pdinfo? And v4l2-fdinfo.h etc. That avoids any confusion and
also clearly says what this is about.
> + u64 hw_usage_time;
> + enum v4l2_media_dev_type media_dev_type;
This should be the first field.
> +};
> +
> +void v4l2_stats_init(struct v4l2_stats *stats);
> +void v4l2_stats_exit(struct v4l2_stats *stats);
> +
> +void v4l2_stats_update_hw_usage(struct v4l2_stats *stats, u64 usage_time);
> +void v4l2_stats_set_media_dev_type(struct v4l2_stats *stats, enum v4l2_media_dev_type type);
> +
> +void v4l2_stats_show(struct v4l2_stats *stats, struct seq_file *m);
> +void v4l2_stats_show_clock(struct seq_file *m, struct clk *clk);
> +
> +#endif /* V4L2_STATS_H */
>
Regards,
Hans
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Catalin Marinas @ 2026-06-19 13:04 UTC (permalink / raw)
To: Harry Yoo
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <2a7d21fa-28c1-446c-97f5-2513f29157d3@kernel.org>
On Thu, Jun 18, 2026 at 11:05:43PM +0900, Harry Yoo wrote:
> On 6/18/26 10:35 PM, Harry Yoo wrote:
> > On 6/12/26 1:44 PM, Dev Jain wrote:
> >> Introduce a boot option to tag only at allocation time of the objects. This
> >> reduces KASAN MTE overhead, the tradeoff being reduced ability of
> >> catching bugs.
> >
> > I think most of overhead when enabling MTE comes from loading and
> > validing tags for every memory access (either in SYNC or ASYNC mode),
> > rather than from storing tags.
>
> Is there any reason not to use STGM instead of STG + DC GVA when
> setting/clearing tags for large sizes when we know they are properly
> aligned?
STGM is intended for copying tags when paired with LDGM. Have you seen
hardware where STGM is faster than STG or DC GVA? For properly aligned
buffers, I'd expect DC GVA to behave at least on par with STGM.
--
Catalin
^ permalink raw reply
* [PATCH] ARM: s3c: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files
From: Thomas Huth @ 2026-06-19 12:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peter Griffin, linux-kernel
Cc: linux-samsung-soc, linux-arm-kernel, Alim Akhtar, Russell King
From: Thomas Huth <thuth@redhat.com>
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize now
on the __ASSEMBLER__ macro that is provided by the compilers.
This is a completely mechanical patch (done with a simple "sed -i"
statement).
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
Note: This patch has been split from an earlier patch of mine
to ease reviewing.
arch/arm/mach-s3c/map-base.h | 2 +-
include/linux/serial_s3c.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c/map-base.h b/arch/arm/mach-s3c/map-base.h
index 463a995b399bc..beb58e6f12e16 100644
--- a/arch/arm/mach-s3c/map-base.h
+++ b/arch/arm/mach-s3c/map-base.h
@@ -20,7 +20,7 @@
#define S3C_ADDR_BASE 0xF6000000
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#define S3C_ADDR(x) ((void __iomem __force *)S3C_ADDR_BASE + (x))
#else
#define S3C_ADDR(x) (S3C_ADDR_BASE + (x))
diff --git a/include/linux/serial_s3c.h b/include/linux/serial_s3c.h
index 102aa33d956c4..f54cb6e23f85e 100644
--- a/include/linux/serial_s3c.h
+++ b/include/linux/serial_s3c.h
@@ -269,7 +269,7 @@
#define APPLE_S5L_UTRSTAT_RXTO BIT(9)
#define APPLE_S5L_UTRSTAT_ALL_FLAGS GENMASK(9, 3)
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <linux/serial_core.h>
@@ -294,7 +294,7 @@ struct s3c2410_uartcfg {
unsigned long ufcon; /* value of ufcon for port */
};
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
#endif /* __ASM_ARM_REGS_SERIAL_H */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/5] docs: media: add documentation for media client usage stats
From: Hans Verkuil @ 2026-06-19 12:58 UTC (permalink / raw)
To: Detlev Casanova, Mauro Carvalho Chehab, Nicolas Dufresne,
Benjamin Gaignard, Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
linux-arm-kernel, Christopher Healy
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-2-d298e98ce06a@collabora.com>
Hi Detlev,
Interesting, I had never heard of fdinfo, so if nothing else, I learned something new!
On 17/06/2026 20:10, Detlev Casanova wrote:
> From: Christopher Healy <healych@amazon.com>
>
> Document the media fdinfo interface for per-file-descriptor usage
> statistics exposed by stateless V4L2 codec drivers via
> /proc/<pid>/fdinfo/<fd>.
>
> This interface is designed for stateless (request API based) codec
> devices where the kernel driver has per-job visibility into hardware
> execution. Stateful codecs cannot support all of this because their
> firmware manages job scheduling opaquely.
>
> The specification defines media- prefixed keys for engine utilization
> time, and operating frequency, following the same conventions as the DRM
> fdinfo mechanism documented in drm-usage-stats.rst.
>
> More fields can be added later.
>
> Signed-off-by: Christopher Healy <healych@amazon.com>
> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
> ---
> .../userspace-api/media/drivers/index.rst | 1 +
> .../media/drivers/media-usage-stats.rst | 85 ++++++++++++++++++++++
> 2 files changed, 86 insertions(+)
>
> diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst
> index 02967c9b18d6..61879738836c 100644
> --- a/Documentation/userspace-api/media/drivers/index.rst
> +++ b/Documentation/userspace-api/media/drivers/index.rst
> @@ -34,6 +34,7 @@ For more details see the file COPYING in the source distribution of Linux.
> imx-uapi
> mali-c55
> max2175
> + media-usage-stats
> npcm-video
> omap3isp-uapi
> thp7312
> diff --git a/Documentation/userspace-api/media/drivers/media-usage-stats.rst b/Documentation/userspace-api/media/drivers/media-usage-stats.rst
> new file mode 100644
> index 000000000000..d3dc07002f62
> --- /dev/null
> +++ b/Documentation/userspace-api/media/drivers/media-usage-stats.rst
> @@ -0,0 +1,85 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +.. _media-usage-stats:
> +
> +==========================
> +Media client usage stats
stats -> statistics
But are these really statistics? Isn't it just the current status?
In many ways this feature looks to me similar to what VIDIOC_LOG_STATUS does,
except in a nicer format. When VIDIOC_LOG_STATUS was first added, fdinfo
didn't exist yet.
And I wouldn't call it 'Media client': it's specific to stateless V4L2
codec drivers.
> +==========================
> +
> +Stateless V4L2 codec drivers can optionally expose per-file-descriptor usage
> +statistics via ``/proc/<pid>/fdinfo/<fd>``. This is analogous to the DRM fdinfo
> +mechanism documented in :ref:`drm-client-usage-stats`, but uses the ``media-``
> +key prefix for V4L2 media devices.
> +
> +This interface is specific to stateless (request API based) codec devices,
> +including both decoders and encoders. With stateless codecs, the kernel driver
> +explicitly submits each frame to the hardware and receives a completion
> +interrupt, providing a clean per-job boundary that can be attributed to the
> +submitting file descriptor.
> +
> +Stateful codec devices cannot support this interface because their firmware
> +manages job scheduling internally. The kernel driver submits bitstream data
> +but has no visibility into per-frame hardware execution timing.
> +
> +Implementation
> +==============
> +
> +The V4L2 core provides the plumbing: drivers implement the ``show_fdinfo``
> +callback in ``struct v4l2_file_operations``, and the core wires it into the
> +kernel ``struct file_operations`` so that ``/proc/<pid>/fdinfo/<fd>`` output
> +includes the driver-provided keys.
> +
> +File format specification
> +=========================
> +
> +- File shall contain one key value pair per one line of text.
> +- Colon character (``:``) must be used to delimit keys and values.
> +- All standardised keys shall be prefixed with ``media-``.
> +- Driver-specific keys shall be prefixed with ``driver_name-``.
> +
> +Mandatory keys
> +--------------
> +
> +- media-driver: <valstr>
I'd pick 'v4l2-driver'. Since 'media-driver' is too generic for this
since that encompasses also DVB/CEC/RC drivers.
> +
> + String shall contain the name of the media driver.
'V4L2 stateless codec driver'
> +
> +- media-type: <valstr>
Poor name.
> +
> + String shall identify the type of media engine exposed through this file
> + descriptor. Standard values are ``decoder`` and ``encoder``.
I think I would use 'stateless-decoder' and 'stateless-encoder'. It's more
specific than de/encoder since that can be stateful as well.
So I am missing the big picture here: right now this patch adds support for
this for stateless codecs, but what happens in the future if this is also
added for regular video capture devices, ISPs, etc.?
The naming here matters, it has to have some sort of scheme so it can be
extended to other types of drivers. So a 'media' prefix is too generic,
and it also looks like it refers to the /dev/mediaX device.
> +
> +Utilization keys
> +----------------
> +
> +- media-engine-usage: <uint> ns
'Media Engine': very vague.
> +
> + Time in nanoseconds that the hardware engine spent busy processing work
Cumulative since creating the file handle? Or since the last read?
> + belonging to this file descriptor. The engine being measured is identified
> + by the ``media-type`` key.
> +
> + Values are not required to be constantly monotonic if it makes the driver
> + implementation easier, but are required to catch up with the previously
> + reported larger value within a reasonable period.
Does this make sense for codecs?
I can tell that this is heavily influenced by the drm documentation, but that
does not necessarily translate to V4L2.
> +
> +Frequency keys
> +--------------
> +
> +- media-maxfreq: <uint> Hz
> +
> + Maximum operating frequency of the main engine clock.
> +
> +- media-curfreq: <uint> Hz
> +
> + Current operating frequency of the main engine clock.
'Main engine clock'?
> +
> +Example output
> +==============
> +
> +::
> +
> + media-driver: hantro-vpu
> + media-type: decoder
> + media-engine-usage: 123456789 ns
> + media-maxfreq: 600000000 Hz
> + media-curfreq: 600000000 Hz
>
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: Cristian Marussi @ 2026-06-19 12:51 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Cristian Marussi, Christian Brauner, linux-kernel,
linux-arm-kernel, arm-scmi, linux-fsdevel, linux-doc,
sudeep.holla, james.quinlan, f.fainelli, vincent.guittot,
etienne.carriere, peng.fan, michal.simek, d-gole, jic23,
elif.topuz, lukasz.luba, philip.radford, souvik.chakravarty,
leitao, kas, puranjay, usama.arif, kernel-team
In-Reply-To: <0025b907-27b9-4a51-b78f-f8ad413644d0@kernel.org>
On Fri, Jun 19, 2026 at 12:16:58PM +0200, David Hildenbrand (Arm) wrote:
>
> >> Is the configuration aspect limited to enabling selected events, or is there
> >> more that can be configured?
Hi,
> >>
> >
> > The needed configuration is:
> >
> > - global Telemetry enable (tlm_enable)
> > - global common update_interval (current_update_interval)
>
> Okay, so simple global properties.
>
> > - per-DE enable/disable (des/0x<NNNN>/enable)
> > - per-DE timestamping enable/disable (des/0x<NNNN>/tstamp_enable)
> >
> > ... then there are a couple of handy catch-all entries:
> > all_des_enable, all_des_tstamp_enable
>
> Okay, so fairly trivial configs.
Yes mostly on/off switches or single values config.
> >
> > Note that all the existent DEs are discovered at runtime dynamically via
> > SCMI in the background at init/probe and then never change: i.e.
> > the tree is statically created upon discovery, user cannot
> > create/destroy or symlink files at will, nor the backend platform FW
> > running the SCMI server can pop-up new DataEvents after the initial
> > enumeration.
>
> That makes sense.
>
> >
> > All the above configs can also be pre-defined in the FW (at built time)
> > as being default boot-on with predefined values, like a specific
> > boot-on update interval, so that you could have a system in which really
> > you dont need to configure anything...everything is on and you just
> > read data. (unless you want to change config of course...)
>
> Okay, so the initial value of some parameters might not be "disabled" etc.
Yes at the protocol layer I take care to lookup all of this states at
init so that the initial states are consistent with what exposed...
>
> I guess, from a user space perspective, reading should be allowed by everyone
> but writing should be limited to root?
>
Yes it is currently world readable and only root has write access by default,
BUT in this latest V4 I added (as asked by some internal team) handling of the
usual uid/gid/umask mount options so that a privileged user can change the ownership
policy at mount time. (not supporting anyway FS_USERNS_MOUNT since it does not
make sense to support containers for SCMI Telemetry)
> >
> > There is more stuff that indeed is configurable per the SCMI spec
> > but these additional params are hidden into the SCMI Telemetry protocol
> > layer (the initial patches in this series) and NOT made available to
> > the driver/users of the protocol (like the SCMI FS driver that sits on
> > top)
>
> Do you assume that there will get significantly more config options added in the
> future for user space to configure?
No, I dont think so...the only planned extensions were to support more
performant read access mechanisms, i.e. direct mmap'ability of FW/Kernel
SCMI Telemetry shared memory areas...BUT that will immediately dump all
the bulk of the lower layer protocol work into the tools domain...and
we're not ready to do so...beside having one more thing, the tool, to keep
in sync with possible future spec changes (unless exposing even more stuff
like tlm mem-areas accessors to the UAPI...that would be painful kernel
side and not desired AFAIU...)
>
> >
> > IOW, this humonguos series (~8k lines) is only partially composed by
> > the Filesystem driver (~3k): the bulk of the Telemetry logic and SCMI
> > message exchanges are contained in the SCMI Protocol stack which has
> > been extended to support the Telemerty protocol at first
> > (the 'firmware: arm_scmi:' initial patches).
> >
> > This latter common support is exposed by the SCMI stack for the SCMI
> > drivers to use via custom per-protocol operations (not an orginal name :P)
> > exposed in include/linux/scmi_protocol.h
> >
> > So when you write into FS to configure smth, you end up calling an internal
> > tlm_proto_ops that in turn will cause an SCMI message to be sent
> > (in some cases say to enable a DE or set the update interval)
>
> Makes sense.
>
> >
> > When you read something, you end up calling another Telemetry operation
> > that in turn returns you the DataEvent value you were looking for...how
> > this is retrieved via SCMI in the background is transparent to the
> > FS driver because, again, these details are buried into the protocol
> > layer. Talking about reads, you can:
> >
> > - read a single value from des/0x<NNNN>/value
> > - read ALL the currently enabled DE in a bulk read via des_bulk_read
> >
> > ...most of the other entries in the tree are simply RO properties of the DEs
> > that have been discovered at enumeration time.
>
> Is this bulk-reading relevant for performance or just a "nice to have" ?
>
I suppose depends on your usage pattern: it is definitely relevant
because the main collection mechanism are shared memory areas (SHMTIs)
between the platform firmware and the Kernel: such areas being accessed
from 2 differnt worlds concurrently come with a SCMI-specified
synchro/consistency mechanism based simply on a pair of sequence numbers
placed at the start and at the end of the SHMTI, so that the FW increases
such magic numbers in a well-known way before and after updating the SHMTI
values, so that the kernel can detect (without any interlocking mechanism)
if a platform write happened in the middle of its reads...
...so if you read one single DE 64bit value, under the hood the kernel
would have had to really perform at leats 3 reads from the SHMTI to check
the consistecy of that single read...
... while if you do a bulk_read the overhead due to the consistecy
checks gets 'spread' across a number of DEs because the kernel will snapshot
the whole SHMTIs (potentially KBytes) between the 2 consistency reads
...the good side effect of all of this is that I can leverage such
sequence number to optimize reads..i.e. do NOT even try to read anything
if the new sequnce number is unchanged from the last one I cached on the
last successfull read of this value...
So at the end I would say it is NOT simply a nice to have BUT it is
certainly only the first step towards a more performant alternative access
(like with mmaps)...it depends on the usage pattern...I am not sure what
mechanism is used by our tools more...
>
> >
> > Given that walking a FS tree and issuing configuration as writes is NOT
> > performant really (nor handy if you are not a human), currently, even
> > in this FS-based series you can really perform all of the discovery AND
> > the configuration tasks WITHOUT walking the filesystem tree, but instead
> > issuing a bunch of IOCTLs issued on a special 'control' file that I
> > embedded in the FS. Such UAPI IOCTLs described at:
>
> Makes sense.
>
> >
> > https://lore.kernel.org/arm-scmi/20260612223802.1337232-6-cristian.marussi@arm.com/T/#u
> >
> > So my plan of action in order to get rid of the FS in-kenel implementation
> > would be to drop this Filesystem in favour of simple character devices
> > and move the existent IOCTLs interface (revisited where needed) on top of
> > these devices: that way you will be able to use IOCTLs to enumerate the
> > Telemetry sources and then configure them.
> >
> > Read will then happen (probably) leveraging a number of chardev fops like:
> > IOCTLs, .read and .mmap...up to the tool decide what to use.
> >
> > After this porting to chardev is done, I would start optionally exposing
> > again all of this in a human-readable alternative way by adding a layer
> > of FUSE on top of this chardev interface.
>
> Yes. How high-priority is the fs side? Or would a tool using a library to access
> this information also work in the first step?
>
I have to sync with tools on this...because they are stiil probably
using currently the FS, but it was already planned for the future to move to
a more low level access (ioctl/mmap)...
...my aim would be, at this point, to favour this transition without sudden
breaking their current world (and have to expatriate :P)
..from my personal point of view, I would certainly like to still have the
FUSE layer for ease of testing and verification on my side...but it is just
a nice to have...
> >
> > Basically my aim is to drop the FS implementation from the kernel, as
> > advised, while trying to optionally make it still available via a userspace
> > FUSE implementation...IOW the intention would be for the next V5 to expose
> > the same interfaces as V4 but with the help of a tool instead that builds,
> > if wanted, a FUSE mount built on top of the chardev interface.
[snip]
> >>
> >> It's a good question how that could be done, if you need more information about
> >> these events from user space.
> >
> > I have NOT really delved into that, so as of know we do NOT fed any data
> > to existing Kernel subsystems, not there is any available in-kernel
> > interface to consume DE data (nobody asked), but, I can imagine 2 solution:
> >
> > - our beloved architects decide to 'architect' more DataEvents in the
> > next version of the spec.. i.e. they reserve some specific DE IDs to
> > represent some well defined entity (like it is done already in the spec
> > for a dozen IDs)...this avoids the needs of any new interface all
> > together
>
> That would be the cleanest solution :)
>
Definitely agree.
> >
> > OR
> >
> > - we open some sort of user-->kernel ABI channel 'somewhere' where the
> > userspace tool, interpreting the JSON description, can communicate something
> > like " on this platform ID 1,2,3,4 should be fed to the IIO sensors frmwk
> > too, while ID 39,8,76 can be fed to HWMON..." etc
> >
> >>
> >> [...]
> >>
> >>
> >> That sounds reasonable.
> >>
> >> [...]
> >>
[snip]
> > Regarding the user concurrency, I have already explicitly pushed back on
> > this, our own tools team: any concurrent read or configuration write is
> > allowed and properly handled in a consistent way, BUT on the configuration
> > side the last write/ioctl wins: there is NO in-kernel OR userspace
> > co-ordination provided out of the box: IOW if you use multiple tools
> > concurrently to apply conflicting configurations, it is none of our problem
>
> Would concurrent reading work? I assume so, right?
>
Yes concurrent reading is not a problem, and concurrent writes are
properly handled at the write/message level (i.e. no corruption) BUT
no co-ordination is provided from the kernel on those config writes,
last write wins.
> >
> > ...similarly as if you have an actively running network configuration daemon
> > and you try to set your IP manually...nobody will prevent you from doing this,
> > the same netlink will be used freely by you on the shell and the daemon (if you
> > have enough privilege), but you will gonna have unexpected result...
> >
> > I dont either see the case to enforce exclusive access for Telemetry resources:
> > co-ordination is up to the user in my view...I mean if you have 2 tools
> > configuring concurrently SCMI telemetry in a conflicting way something has been
> > misconfigured somewhere
> >
> > .....having said that, I understand that the concurrency co-ordination
> > issue can be particularly tricky to spot and solve in userspace, so I DO
> > expose a generation counter entry that is updated on any configuration
> > change, so that a userspace app using Telemetry can monitor (poll) this
> > counter to spot if someone else on the system is quietly suddenly applying
> > configuration changes...
>
> Okay, so a single writer (admin) changing stuff could get picked up my possibly
> many concurrent readers?
Mmm...not sure what you mean here...
If you configure your Telemetry as you desire and start collecting data via
readers, BUT then some other process changes configs under your belt, that is
allowed as said, and so your analisys could be impacted...(something turned off
as an example, or update interval changed)...
...so while this is NOT regulated/co-ordinated by the Kernel, in order to
ease the detection of such events by your reading process, I provide a pollable
entry that returns an integer and then blocks until such counter is next updated
by an intervening under-the-hood configuration change...so you can configure,
monitor the generatin counter and then starts reading you data, sure that you
will detect any conflicting re-config issued by a rougue process...
(and I have to still extend this event polling mechanism to use a user
provided eventfd...since it was NOT strictly needed...but now with
IOCTLs interface I will add that too...)
>
> >
> >>>
> >>> Should/could such a tool live in the kernel tree (tools/) at least for
> >>> ease of development/deployment ?
> >>
> >> I think OOT.
> >>
> >
> > Ok.
> >
> > Sorry for the long email..I hope I have clarified the situation, anyway
> > I am already moving to get rid of the in-kernel interface as advised in
> > favour of a chardev kernel interface and an optional FUSE based FS...
>
> Yes, thank you a lot, I hope it also helps Christian to help push this into the
> right direction!
>
Thanks a lot, David !
Cristian
^ permalink raw reply
* Re: [PATCH v7 02/30] drm/connector: Add HDMI 2.0 scrambler infrastructure
From: Maxime Ripard @ 2026-06-19 12:44 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Sandy Huang,
Heiko Stübner, Andy Yan, Daniel Stone, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <7b19b243-ad6a-4d1f-b34e-684e8bfe500c@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 7329 bytes --]
On Fri, Jun 12, 2026 at 09:11:54PM +0300, Cristian Ciocaltea wrote:
> Hi Maxime,
>
> Thanks for taking the time to review this!
>
> On 6/12/26 3:06 PM, Maxime Ripard wrote:
> > On Tue, Jun 02, 2026 at 01:44:02AM +0300, Cristian Ciocaltea wrote:
> >> Add the connector-level infrastructure to support HDMI 2.0 scrambling:
> >>
> >> - A scrambler_supported flag to indicate whether the source supports the
> >> scrambling capability, in which case the newly introduced
> >> .scrambler_{enable|disable}() callbacks in drm_connector_hdmi_funcs
> >> are mandatory
> >> - A scrambler_needed flag to be managed by the hdmi state helpers based
> >> on the negotiated TMDS character rate and the source/sink scrambling
> >> capabilities
> >> - A scrambler_enabled flag to track whether scrambling is currently
> >> active
> >> - A delayed work item (scdc_work) with an associated callback (scdc_cb)
> >> to monitor sink-side scrambling status and retry the setup if the sink
> >> resets it
> >>
> >> These are intended to be used by SCDC scrambling helpers to coordinate
> >> scrambling setup and teardown between the source driver and the DRM
> >> core.
> >>
> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> >> ---
> >> drivers/gpu/drm/drm_connector.c | 18 +++++++++
> >> include/drm/drm_connector.h | 81 +++++++++++++++++++++++++++++++++++++++++
> >> 2 files changed, 99 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> index a5d13b92b665..526dc2931b8a 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -220,6 +220,19 @@ void drm_connector_free_work_fn(struct work_struct *work)
> >> }
> >> }
> >>
> >> +static void drm_connector_hdmi_scdc_work(struct work_struct *work)
> >> +{
> >> + struct drm_connector *connector;
> >> + struct drm_connector_hdmi *hdmi;
> >> +
> >> + hdmi = container_of(to_delayed_work(work), struct drm_connector_hdmi,
> >> + scdc_work);
> >> + connector = container_of(hdmi, struct drm_connector, hdmi);
> >> +
> >> + if (hdmi->scdc_cb)
> >> + hdmi->scdc_cb(connector);
> >> +}
> >> +
> >> static int drm_connector_init_only(struct drm_device *dev,
> >> struct drm_connector *connector,
> >> const struct drm_connector_funcs *funcs,
> >> @@ -285,6 +298,7 @@ static int drm_connector_init_only(struct drm_device *dev,
> >> mutex_init(&connector->edid_override_mutex);
> >> mutex_init(&connector->hdmi.infoframes.lock);
> >> mutex_init(&connector->hdmi_audio.lock);
> >> + INIT_DELAYED_WORK(&connector->hdmi.scdc_work, drm_connector_hdmi_scdc_work);
> >> connector->edid_blob_ptr = NULL;
> >> connector->epoch_counter = 0;
> >> connector->tile_blob_ptr = NULL;
> >> @@ -606,6 +620,10 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
> >> !hdmi_funcs->hdmi.write_infoframe)
> >> return -EINVAL;
> >>
> >> + if (connector->hdmi.scrambler_supported &&
> >> + (!hdmi_funcs->scrambler_enable || !hdmi_funcs->scrambler_disable))
> >> + return -EINVAL;
> >> +
> >> ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
> >> if (ret)
> >> return ret;
> >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> >> index 529755c2e862..f1c5c15a6cce 100644
> >> --- a/include/drm/drm_connector.h
> >> +++ b/include/drm/drm_connector.h
> >> @@ -28,6 +28,7 @@
> >> #include <linux/ctype.h>
> >> #include <linux/hdmi.h>
> >> #include <linux/notifier.h>
> >> +#include <linux/workqueue.h>
> >> #include <drm/drm_mode_object.h>
> >> #include <drm/drm_util.h>
> >> #include <drm/drm_property.h>
> >> @@ -1057,6 +1058,19 @@ struct drm_connector_hdmi_state {
> >> * @tmds_char_rate: TMDS Character Rate, in Hz.
> >> */
> >> unsigned long long tmds_char_rate;
> >> +
> >> + /**
> >> + * @scrambler_needed: Whether HDMI 2.0 SCDC scrambling is required
> >> + * for the negotiated mode/bpc/format.
> >> + *
> >> + * Computed by drm_atomic_helper_connector_hdmi_check() from
> >> + * @tmds_char_rate and the source/sink scrambling capabilities.
> >> + *
> >> + * Per HDMI 2.0, scrambling is mandatory above 340 MHz TMDS
> >> + * character rate. Optional scrambling at lower rates is
> >> + * deliberately not requested by the helper.
> >> + */
> >> + bool scrambler_needed;
> >> };
> >>
> >> /**
> >> @@ -1358,6 +1372,36 @@ struct drm_connector_hdmi_funcs {
> >> */
> >> const struct drm_edid *(*read_edid)(struct drm_connector *connector);
> >>
> >> + /**
> >> + * @scrambler_enable:
> >> + *
> >> + * This callback is invoked through @drm_scdc_start_scrambling during
> >> + * a commit to setup SCDC scrambling and high TMDS clock ratio on
> >> + * source side.
> >> + *
> >> + * The @scrambler_enable callback is mandatory if HDMI 2.0 is to be
> >> + * supported.
> >> + *
> >> + * Returns:
> >> + * 0 on success, a negative error code otherwise
> >> + */
> >> + int (*scrambler_enable)(struct drm_connector *connector);
> >> +
> >> + /**
> >> + * @scrambler_disable:
> >> + *
> >> + * This callback is invoked through @drm_scdc_stop_scrambling during
> >> + * a commit to disable SCDC scrambling and high TMDS clock ratio on
> >> + * source side.
> >> + *
> >> + * The @scrambler_disable callback is mandatory if HDMI 2.0 is to be
> >> + * supported.
> >> + *
> >> + * Returns:
> >> + * 0 on success, a negative error code otherwise
> >> + */
> >> + int (*scrambler_disable)(struct drm_connector *connector);
> >> +
> >> /**
> >> * @avi:
> >> *
> >> @@ -1960,6 +2004,43 @@ struct drm_connector_hdmi {
> >> */
> >> unsigned long supported_formats;
> >>
> >> + /**
> >> + * @scrambler_supported: Indicates whether the HDMI controller
> >> + * (source) supports HDMI 2.0 SCDC scrambling.
> >> + *
> >> + * When true, @drm_connector_hdmi_funcs.scrambler_enable and
> >> + * @drm_connector_hdmi_funcs.scrambler_disable are mandatory.
> >> + * This is enforced by drmm_connector_hdmi_init().
> >> + *
> >> + * For HDMI bridge based drivers using drm_bridge_connector_init(),
> >> + * this is propagated automatically from bridges that set the
> >> + * DRM_BRIDGE_OP_HDMI_SCRAMBLER flag in their &drm_bridge->ops.
> >> + * Other drivers must set this field on @connector->hdmi before calling
> >> + * drmm_connector_hdmi_init().
> >> + */
> >> + bool scrambler_supported;
> >> +
> >> + /**
> >> + * @scrambler_enabled: Tracks whether HDMI 2.0 scrambler is currently enabled.
> >> + */
> >> + bool scrambler_enabled;
> >
> > This is already in the state. Why do you need to copy it over here, and
>
> This was supposed to be used exclusively by drm_scdc_{start,stop}_scrambling()
> and drm_scdc_sync_status() helpers to control the work item and conditionally
> trigger CRTC resets. However, it's now also set by vc4_hdmi_connector_init() to
> force disable the scrambler in the vc4_crtc_disable_at_boot() execution path.
Oh, my bad, I misread. I thought it was meant to be a copy of
scrambler_needed, but yeah, you're right it makes sense to keep it as is
and you can ignore this comment.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Handle Apple WFI State Loss
From: Sven Peter @ 2026-06-19 12:40 UTC (permalink / raw)
To: Mark Rutland, Yureka Lilian
Cc: Will Deacon, Catalin Marinas, linux-arm-kernel, linux-kernel,
asahi, Sasha Finkelstein
In-Reply-To: <ajUbcv75FuSPPi9o@J2N7QTR9R3>
On 6/19/26 12:38, Mark Rutland wrote:
> On Wed, Jun 17, 2026 at 09:23:03PM +0200, Yureka Lilian wrote:
>> On 6/15/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.
>
> Are we *certain* that there's no equivalent control elsewhere? i.e. this
> hasn't just moved?
We are as certain as we can be short of Apple confirming this which
isn't going to happen.
XNU has a helper function to "force wfi to use clock gating only" [1]
which is how we learned about this control originally on M1.
This has been disabled starting with M4 using the "NO_CPU_OVRD" define
which they describe as "CPU_OVRD register accesses are banned" [2]. If
there was an equivalent control elsewhere I would expect them to just
use that one instead.
In addition most non-architectural sysregs are read-only starting with
M4 in the non-Apple-entitled boot mode so even if there was such a
control we would likely not be able to access it.
[1]
https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/osfmk/arm64/machine_routines_asm.s#L1129
[2]
https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/pexpert/pexpert/arm64/board_config.h#L197
>
>>>> 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
[...]
>>>> + } while (0)
>>> How can you guarantee that we don't run one of these prior to patching?
>>
>> We can't, but there are a few points to our advantage, namely the boot cpu
>> isn't actually affected by this (when the CYC_OVRD bits are not configured
>> or not supported), and first round of patching happens quite early before
>> the other cpus are started.
>
> I think you're saying that:
>
> * On the boot CPU, WFI *never* loses register state.
>
> * On other CPUs, WFI *might* lose register state (and this cannot be
> inhibited).
>
> Is that understanding correct, or are there other conditions where a WFI
> on the boot CPU can lose register state?
Those are our current observations, yes. We don't know why the boot CPU
behaves differently and there no differences in any Apple sysregs that
would explain it.
But looking at all wfis in the kernel there are bunch in head.S and
similar for infinite loops where we don't care if register state is
lost. The only two that currently matter are a wfit in __delay and the
wfi in the idle loop.
The __delay one gets enabled after arm64_features are found which
happens just before arm64_errata from setup_boot_cpu_features() and
there's no __delay call inbetween that and when alternatives are
applied. If we follow Will's suggestion with an early_param that happens
much earlier as well.
My understanding is that the idle loop won't be reached before
sched_init() and that also happens much later.
>
> IIRC kdump doesn't ensure the new kernel is started on the boot CPU, so
> I think that would be broken. I guess you can't kexec generally due to a
> lack of offlining of secondary CPUs.
Next to that, kexec also runs into issues with all the various
co-processors which we can't easily reset or shut down once they've been
brought up once.
Sven
^ permalink raw reply
* Re: [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions
From: Pragnesh Papaniya @ 2026-06-19 12:31 UTC (permalink / raw)
To: Sudeep Holla
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sibi Sankar, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Dmitry Osipenko, Thierry Reding, Jonathan Hunter, Bjorn Andersson,
Konrad Dybcio, Rajendra Nayak, Pankaj Patil, linux-arm-msm,
linux-kernel, arm-scmi, linux-arm-kernel, devicetree, linux-pm,
linux-tegra, Amir Vajid, Ramakrishna Gottimukkula
In-Reply-To: <20260616-responsible-junglefowl-of-chaos-7eda7d@sudeepholla>
On 16-Jun-26 1:57 PM, Sudeep Holla wrote:
> On Wed, Jun 10, 2026 at 02:21:27PM +0530, Pragnesh Papaniya wrote:
>> The QCOM SCMI vendor protocol provides a generic way of exposing a number of
>> Qualcomm SoC specific features (like memory bus scaling) through a mixture of
>> pre-determined algorithm strings and param_id pairs hosted on the SCMI
>> controller. On Qualcomm Glymur and Hamoa SoCs, the memlat governor and the
>> mechanism to control the various caches and RAM is hosted on the CPU Control
>> Processor (CPUCP) and the method to tweak and start the governor is exposed
>> through the QCOM SCMI Generic Extension Protocol.
>>
>> This series introduces the devfreq SCMI client driver that uses the MEMLAT
>> algorithm string hosted on the QCOM SCMI Generic Extension Protocol to detect
>> memory latency workloads and control frequency/level of the various memory
>> buses (DDR/LLCC/DDR_QOS). DDR/LLCC/DDR_QOS are modelled as devfreq devices
>> using the remote devfreq governor. This provides basic insight into device
>> operation via trans_stat and lets userspace further tweak the parameters of
>> the remote governor.
>>
>> trans_stat data for DDR/LLCC/DDR_QOS is now available with this series:
>>
>> From : To
>> 315000000 479000000 545000000 725000000 840000000 959000000 1090000000 1211000000 time(ms)
>> 315000000: 0 3 6 6 6 7 0 30 143956
>> 479000000: 2 0 7 1 1 1 0 3 356
>> 545000000: 7 6 0 5 5 0 0 10 1200
>> 725000000: 3 0 5 0 6 1 0 6 2172
>> 840000000: 8 2 3 2 0 4 0 12 1188
>> 959000000: 3 0 1 2 2 0 0 13 272
>> 1090000000: 0 0 0 0 0 0 0 0 0
>> 1211000000: 35 4 11 5 11 8 0 0 21684
>> Total transition : 253
>>
>> QCOM SCMI Generic Vendor protocol background:
>> A lot of the vendor protocol numbers used internally were for
>> debug/internal development purposes that were either highly SoC-specific
>> or had to be disabled because some features were fused out during
>> production. This led to a large number of vendor protocol numbers being
>> quickly consumed and never released. Using a single generic vendor
>> protocol with functionality abstracted behind algorithm strings gives us
>> the flexibility of letting such functionality exist during initial
>> development/debugging while still being able to expose mature features
>> (like MEMLAT) once they have stabilised. The param_ids are expected to
>> act as ABI for algorithm strings like MEMLAT.
>>
>
> Not sure if it was discussed in the previous versions or not, it would be
> good if you can capture why some of bus scaling doesn't work with the existing
> SCMI performance protocol and the monitors don't fit the MPAM mode.
>
> Please capture them in 1/9 as a motivation for this vendor protocol. It will
> then help to understand it better as I am still struggling to. Sorry for that.
Thanks for the input!
SCMI perf protocol exports perf domains to kernel where kernel can set
the frequency but here the scaling governor runs on the SCP while kernel
just observes frequency changes made by remote governor. While MPAM is
not enabled/supported on all hardware (Hamoa). Here's the pseudo-code
for remote governor on CPUCP to help you understand more:
Barebone Memlat Pseudocode:
Every sample window, get snapshot of latest AMU counters from each CPU and scale all the memory according to the map_table:
For each CPU
// Calculate IPM ( Instruction retired / cache miss count (L2 cache refills for LLCC voting and CPU RD miss counter for DDR))
If (IPM < IPM_CEIL)
Use CPU cycle counter to determine CPU frequency in the past N milliseconds
LLCC_freq = lookup_llcc_freq(cpu_freq_max)
DDR_freq = lookup_ddr_freq(cpu_freq_max)
DDR_QOS_freq = lookup_ddr_qos_freq(cpu_freq_max)
// Scale all memories
Scale_freq(Memory); // LLCC/DDR/DDR_QOS
>
^ permalink raw reply
* [PATCH v3 73/78] drm/xlnx: zynqmp_dp: Switch to atomic_create_state
From: Maxime Ripard @ 2026-06-19 12:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Maxime Ripard, Laurent Pinchart,
Laurent Pinchart, Tomi Valkeinen, Michal Simek, linux-arm-kernel
In-Reply-To: <20260619-drm-no-more-bridge-reset-v3-0-ff399263111b@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Michal Simek <michal.simek@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 7fb11b0a44f0..b209582bc130 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -2278,11 +2278,11 @@ static const struct drm_bridge_funcs zynqmp_dp_bridge_funcs = {
.mode_valid = zynqmp_dp_bridge_mode_valid,
.atomic_enable = zynqmp_dp_bridge_atomic_enable,
.atomic_disable = zynqmp_dp_bridge_atomic_disable,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
- .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_create_state = drm_atomic_helper_bridge_create_state,
.atomic_check = zynqmp_dp_bridge_atomic_check,
.detect = zynqmp_dp_bridge_detect,
.edid_read = zynqmp_dp_bridge_edid_read,
.atomic_get_input_bus_fmts = zynqmp_dp_bridge_get_input_bus_fmts,
.debugfs_init = zynqmp_dp_bridge_debugfs_init,
--
2.54.0
^ permalink raw reply related
* [PATCH v3 67/78] drm/stm: lvds: Switch to atomic_create_state
From: Maxime Ripard @ 2026-06-19 12:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Maxime Ripard, Yannick Fertre,
Raphael Gallais-Pou, Philippe Cornu, Maxime Coquelin,
Alexandre Torgue, linux-stm32, linux-arm-kernel
In-Reply-To: <20260619-drm-no-more-bridge-reset-v3-0-ff399263111b@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
To: Yannick Fertre <yannick.fertre@foss.st.com>
To: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
To: Philippe Cornu <philippe.cornu@foss.st.com>
To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
To: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/stm/lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/lvds.c b/drivers/gpu/drm/stm/lvds.c
index 50a878688e47..90a44e722057 100644
--- a/drivers/gpu/drm/stm/lvds.c
+++ b/drivers/gpu/drm/stm/lvds.c
@@ -1036,11 +1036,11 @@ static const struct drm_bridge_funcs lvds_bridge_funcs = {
.attach = lvds_attach,
.atomic_enable = lvds_atomic_enable,
.atomic_disable = lvds_atomic_disable,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
- .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_create_state = drm_atomic_helper_bridge_create_state,
};
static int lvds_probe(struct platform_device *pdev)
{
struct device_node *port1, *port2, *remote;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 66/78] drm/rockchip: lvds: Switch to atomic_create_state
From: Maxime Ripard @ 2026-06-19 12:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Maxime Ripard, Heiko Stuebner,
Sandy Huang, Heiko Stübner, Andy Yan, linux-arm-kernel,
linux-rockchip
In-Reply-To: <20260619-drm-no-more-bridge-reset-v3-0-ff399263111b@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
To: Sandy Huang <hjc@rock-chips.com>
To: "Heiko Stübner" <heiko@sntech.de>
To: Andy Yan <andy.yan@rock-chips.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 7a0c4fa29f2f..31dc206bedeb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -117,11 +117,11 @@ rockchip_lvds_bridge_get_modes(struct drm_bridge *bridge, struct drm_connector *
static const
struct drm_bridge_funcs rockchip_lvds_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
- .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_create_state = drm_atomic_helper_bridge_create_state,
.get_modes = rockchip_lvds_bridge_get_modes,
};
static int
rockchip_lvds_encoder_atomic_check(struct drm_encoder *encoder,
--
2.54.0
^ 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