* [PATCH v2 04/13] arm64/sysreg: Add HACDBS consumer and base registers
From: Leonardo Bras @ 2026-06-29 11:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Rafael J. Wysocki, Len Brown, Saket Dumbre, Paolo Bonzini,
Jonathan Cameron, Chengwen Feng, Leonardo Bras, Kees Cook,
Mikołaj Lenczewski, James Morse, Zeng Heng, mrigendrachaubey,
Thomas Huth, Ryan Roberts, Yeoreum Yun, Mark Brown, Kevin Brodsky,
James Clark, Fuad Tabba, Raghavendra Rao Ananta,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng
Cc: linux-arm-kernel, linux-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <20260629111820.1873540-1-leo.bras@arm.com>
They will be used on a later commit to make use of the FEAT_HACDBS
mechanism if available.
Signed-off-by: Leonardo Bras <leo.bras@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/tools/sysreg | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index bc1788b1662b..7b7c3d6a0f03 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -4627,20 +4627,50 @@ EndEnum
Enum 9:8 IRGN0
0b00 NC
0b01 WBWA
0b10 WT
0b11 WBnWA
EndEnum
Field 7:6 SL0
Field 5:0 T0SZ
EndSysreg
+Sysreg HACDBSBR_EL2 3 4 2 3 4
+Res0 63:56
+Field 55:12 BADDR
+Field 11 EN
+Res0 10:4
+UnsignedEnum 3:0 SZ
+ 0b0000 4K
+ 0b0001 8K
+ 0b0010 16K
+ 0b0011 32K
+ 0b0100 64K
+ 0b0101 128K
+ 0b0110 256K
+ 0b0111 512K
+ 0b1000 1M
+ 0b1001 2M
+EndEnum
+EndSysreg
+
+Sysreg HACDBSCONS_EL2 3 4 2 3 5
+UnsignedEnum 63:62 ERR_REASON
+ 0b00 NOF
+ 0b01 STRUCTF
+ 0b10 IPAF
+ 0b11 IPAHACF
+EndEnum
+Res0 61:19
+Field 18:0 INDEX
+EndSysreg
+
Sysreg GCSCR_EL2 3 4 2 5 0
Fields GCSCR_ELx
EndSysreg
Sysreg GCSPR_EL2 3 4 2 5 1
Fields GCSPR_ELx
EndSysreg
Sysreg HDBSSBR_EL2 3 4 2 3 2
Res0 63:56
--
2.54.0
^ permalink raw reply related
* [PATCH v2 05/13] KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ
From: Leonardo Bras @ 2026-06-29 11:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Rafael J. Wysocki, Len Brown, Saket Dumbre, Paolo Bonzini,
Jonathan Cameron, Chengwen Feng, Leonardo Bras, Kees Cook,
Mikołaj Lenczewski, James Morse, Zeng Heng, mrigendrachaubey,
Thomas Huth, Ryan Roberts, Yeoreum Yun, Mark Brown, Kevin Brodsky,
James Clark, Fuad Tabba, Raghavendra Rao Ananta,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng
Cc: linux-arm-kernel, linux-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <20260629111820.1873540-1-leo.bras@arm.com>
Find via ACPI [1] the Id for HACDBSIRQ, initialize it as a per-cpu IRQ
and make sure any cpu able to run virtualization has it active.
Introduce a per-cpu structure used by the HACDBSIRQ handler to keep track
of entries size and the status of HACDBS. Size is used to detect end of
processing in case the number of entries being processed is different of
the supported entries size.
Status may look easily replaceable by checking HACDBS registers now, but
will make the OFF/IDLE detection easier in next patches.
Signed-off-by: Leonardo Bras <leo.bras@arm.com>
[1] https://github.com/tianocore/edk2/issues/12409
---
arch/arm64/include/asm/acpi.h | 3 +
arch/arm64/include/asm/kvm_dirty_bit.h | 18 +++++
include/acpi/actbl2.h | 1 +
arch/arm64/kvm/arm.c | 5 ++
arch/arm64/kvm/dirty_bit.c | 97 ++++++++++++++++++++++++++
5 files changed, 124 insertions(+)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 8a54ca6ba602..883315e9d79d 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -38,20 +38,23 @@
#define BAD_MADT_GICC_ENTRY(entry, end) \
(!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \
(unsigned long)(entry) + (entry)->header.length > (end))
#define ACPI_MADT_GICC_SPE (offsetof(struct acpi_madt_generic_interrupt, \
spe_interrupt) + sizeof(u16))
#define ACPI_MADT_GICC_TRBE (offsetof(struct acpi_madt_generic_interrupt, \
trbe_interrupt) + sizeof(u16))
+
+#define ACPI_MADT_GICC_HACDBSIRQ (offsetof(struct acpi_madt_generic_interrupt, \
+ hacdbsirq_gsi) + sizeof(u32))
/*
* Arm® Functional Fixed Hardware Specification Version 1.2.
* Table 2: Arm Architecture context loss flags
*/
#define CPUIDLE_CORE_CTXT BIT(0) /* Core context Lost */
static inline unsigned int arch_get_idle_state_flags(u32 arch_flags)
{
if (arch_flags & CPUIDLE_CORE_CTXT)
return CPUIDLE_FLAG_TIMER_STOP;
diff --git a/arch/arm64/include/asm/kvm_dirty_bit.h b/arch/arm64/include/asm/kvm_dirty_bit.h
index dd16438f0651..904e59f95b7e 100644
--- a/arch/arm64/include/asm/kvm_dirty_bit.h
+++ b/arch/arm64/include/asm/kvm_dirty_bit.h
@@ -2,11 +2,29 @@
/*
* Copyright (C) 2026 ARM Ltd.
* Author: Leonardo Bras <leo.bras@arm.com>
*/
#ifndef __ARM64_KVM_DIRTY_BIT_H__
#define __ARM64_KVM_DIRTY_BIT_H__
#include <asm/kvm_pgtable.h>
+enum hacdbs_status {
+ HACDBS_OFF,
+ HACDBS_IDLE,
+ HACDBS_RUNNING,
+ HACDBS_ERROR
+};
+
+struct hacdbs {
+ enum hacdbs_status status;
+ int size;
+};
+
+DECLARE_PER_CPU(struct hacdbs, hacdbs_pcp);
+
+void __init kvm_hacdbs_init(void);
+void kvm_hacdbs_cpu_up(void);
+void kvm_hacdbs_cpu_down(void);
+
#endif /* __ARM64_KVM_DIRTY_BIT_H__ */
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index baef525367b5..eaefb494ef59 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -1442,20 +1442,21 @@ struct acpi_madt_generic_interrupt {
u64 gich_base_address;
u32 vgic_interrupt;
u64 gicr_base_address;
u64 arm_mpidr;
u8 efficiency_class;
u8 reserved2[1];
u16 spe_interrupt; /* ACPI 6.3 */
u16 trbe_interrupt; /* ACPI 6.5 */
u16 iaffid; /* ACPI 6.7 */
u32 irs_id;
+ u32 hacdbsirq_gsi; /* ACPI 6.X */
};
/* Masks for Flags field above */
/* ACPI_MADT_ENABLED (1) Processor is usable if set */
#define ACPI_MADT_PERFORMANCE_IRQ_MODE (1<<1) /* 01: Performance Interrupt Mode */
#define ACPI_MADT_VGIC_IRQ_MODE (1<<2) /* 02: VGIC Maintenance Interrupt mode */
#define ACPI_MADT_GICC_ONLINE_CAPABLE (1<<3) /* 03: Processor is online capable */
#define ACPI_MADT_GICC_NON_COHERENT (1<<4) /* 04: GIC redistributor is not coherent */
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 50adfff75be8..dc1a4629aaeb 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -35,20 +35,21 @@
#include <asm/cpufeature.h>
#include <asm/virt.h>
#include <asm/kvm_arm.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
#include <asm/kvm_nested.h>
#include <asm/kvm_pkvm.h>
#include <asm/kvm_ptrauth.h>
+#include <asm/kvm_dirty_bit.h>
#include <asm/sections.h>
#include <asm/stacktrace/nvhe.h>
#include <kvm/arm_hypercalls.h>
#include <kvm/arm_pmu.h>
#include <kvm/arm_psci.h>
#include <kvm/arm_vgic.h>
#include <linux/irqchip/arm-gic-v5.h>
@@ -2300,28 +2301,30 @@ int kvm_arch_enable_virtualization_cpu(void)
* disabled, but not with preemption disabled. The former is
* enough to ensure correctness, but most of the helpers
* expect the later and will throw a tantrum otherwise.
*/
preempt_disable();
cpu_hyp_init(NULL);
kvm_vgic_cpu_up();
kvm_timer_cpu_up();
+ kvm_hacdbs_cpu_up();
preempt_enable();
return 0;
}
void kvm_arch_disable_virtualization_cpu(void)
{
+ kvm_hacdbs_cpu_down();
kvm_timer_cpu_down();
kvm_vgic_cpu_down();
if (!is_protected_kvm_enabled())
cpu_hyp_uninit(NULL);
}
#ifdef CONFIG_CPU_PM
static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
unsigned long cmd,
@@ -2474,20 +2477,22 @@ static int __init init_subsystems(void)
goto out;
}
/*
* Init HYP architected timer support
*/
err = kvm_timer_hyp_init(vgic_present);
if (err)
goto out;
+ kvm_hacdbs_init();
+
kvm_register_perf_callbacks();
err = kvm_hyp_trace_init();
if (err)
kvm_err("Failed to initialize Hyp tracing\n");
out:
if (err)
hyp_cpu_pm_exit();
diff --git a/arch/arm64/kvm/dirty_bit.c b/arch/arm64/kvm/dirty_bit.c
index 32fe938d6bf7..789da8712b1b 100644
--- a/arch/arm64/kvm/dirty_bit.c
+++ b/arch/arm64/kvm/dirty_bit.c
@@ -1,16 +1,113 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
* Copyright (C) 2026 ARM Ltd.
* Author: Leonardo Bras <leo.bras@arm.com>
*/
#include <asm/kvm_dirty_bit.h>
+#include <linux/kconfig.h>
+#include <linux/acpi.h>
+
+DEFINE_PER_CPU(struct hacdbs, hacdbs_pcp) = {
+ .status = HACDBS_OFF,
+ .size = 0,
+};
/* HDBSS entry field definitions */
#define HDBSS_ENTRY_VALID BIT(0)
#define HDBSS_ENTRY_TTWL_SHIFT (1)
#define HDBSS_ENTRY_TTWL_MASK (GENMASK(3, 1))
#define HDBSS_ENTRY_TTWL(x) \
(((x) << HDBSS_ENTRY_TTWL_SHIFT) & HDBSS_ENTRY_TTWL_MASK)
#define HDBSS_ENTRY_TTWL_RESV HDBSS_ENTRY_TTWL(-4)
#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
+
+static __ro_after_init int hacdbsirq = -1;
+
+static irqreturn_t hacdbsirq_handler(int irq, void *pcpu)
+{
+ u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
+ unsigned long err = FIELD_GET(HACDBSCONS_EL2_ERR_REASON, cons);
+
+ switch (err) {
+ case HACDBSCONS_EL2_ERR_REASON_NOF:
+ this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
+ break;
+ case HACDBSCONS_EL2_ERR_REASON_IPAHACF:
+ /* When size not a power of two >= 4k, exit with reserved TTLW */
+ int index = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
+
+ if (index >= this_cpu_read(hacdbs_pcp.size)) {
+ this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
+ break;
+ }
+ fallthrough;
+ case HACDBSCONS_EL2_ERR_REASON_STRUCTF:
+ case HACDBSCONS_EL2_ERR_REASON_IPAF:
+ this_cpu_write(hacdbs_pcp.status, HACDBS_ERROR);
+ break;
+ }
+
+ return IRQ_HANDLED;
+}
+
+void kvm_hacdbs_cpu_up(void)
+{
+ if (hacdbsirq < 0)
+ return;
+
+ enable_percpu_irq(hacdbsirq, IRQ_TYPE_LEVEL_HIGH);
+ this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
+}
+
+void kvm_hacdbs_cpu_down(void)
+{
+ if (hacdbsirq < 0)
+ return;
+
+ disable_percpu_irq(hacdbsirq);
+ this_cpu_write(hacdbs_pcp.status, HACDBS_OFF);
+}
+
+#ifdef CONFIG_ACPI
+static int __init hacdbs_acpi_get_irq(void)
+{
+ struct acpi_madt_generic_interrupt *gicc;
+ u32 gsi;
+ int irq;
+
+ gicc = acpi_cpu_get_madt_gicc(smp_processor_id());
+ if (gicc->header.length < ACPI_MADT_GICC_HACDBSIRQ)
+ return -ENXIO;
+
+ gsi = gicc->hacdbsirq_gsi;
+
+ irq = acpi_register_gsi(NULL, gsi, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_HIGH);
+ if (irq < 0) {
+ pr_warn("ACPI: Unable to register HACDBS interrupt: %d\n", gsi);
+ return -ENXIO;
+ }
+
+ return irq;
+}
+#else
+#define hacdbs_acpi_get_irq() (-ENXIO)
+#endif
+
+void __init kvm_hacdbs_init(void)
+{
+ int irq;
+
+ /* FEAT_HACDBS is only supported if Linux runs in EL2 (VHE) */
+ if (!system_supports_hacdbs() || !is_kernel_in_hyp_mode())
+ return;
+
+ irq = hacdbs_acpi_get_irq();
+ if (irq < 0)
+ return;
+
+ if (request_percpu_irq(irq, hacdbsirq_handler, "HACDBSIRQ", &hacdbs_pcp) < 0)
+ return;
+
+ hacdbsirq = irq;
+}
--
2.54.0
^ permalink raw reply related
* [PATCH v2 03/13] arm64/cpufeature: Add system-wide FEAT_HACDBS detection
From: Leonardo Bras @ 2026-06-29 11:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Rafael J. Wysocki, Len Brown, Saket Dumbre, Paolo Bonzini,
Jonathan Cameron, Chengwen Feng, Leonardo Bras, Kees Cook,
Mikołaj Lenczewski, James Morse, Zeng Heng, mrigendrachaubey,
Thomas Huth, Ryan Roberts, Yeoreum Yun, Mark Brown, Kevin Brodsky,
James Clark, Fuad Tabba, Raghavendra Rao Ananta,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng
Cc: linux-arm-kernel, linux-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <20260629111820.1873540-1-leo.bras@arm.com>
FEAT_HACDBS will only be used for dirty-bit cleaning if it is detected in
all running cpus.
Signed-off-by: Leonardo Bras <leo.bras@arm.com>
---
arch/arm64/include/asm/cpufeature.h | 5 +++++
arch/arm64/kernel/cpufeature.c | 8 ++++++++
arch/arm64/tools/cpucaps | 1 +
3 files changed, 14 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index bdfab086fd94..620ae4cddb76 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -861,20 +861,25 @@ static inline bool system_supports_gcs(void)
static inline bool system_supports_haft(void)
{
return cpus_have_final_cap(ARM64_HAFT);
}
static inline bool system_supports_hdbss(void)
{
return cpus_have_final_cap(ARM64_HAS_HDBSS);
}
+static inline bool system_supports_hacdbs(void)
+{
+ return cpus_have_final_cap(ARM64_HACDBS);
+}
+
static __always_inline bool system_supports_mpam(void)
{
return alternative_has_cap_unlikely(ARM64_MPAM);
}
static __always_inline bool system_supports_mpam_hcr(void)
{
return alternative_has_cap_unlikely(ARM64_MPAM_HCR);
}
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index aa327eebaf1c..62f56bbd0a65 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -516,20 +516,21 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr3[] = {
FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR3_EL1_S1POE_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR3_EL1_S1PIE_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR3_EL1_SCTLRX_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR3_EL1_TCRX_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_aa64mmfr4[] = {
S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_E2H0_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_NV_frac_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_HACDBS_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_ctr[] = {
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_EL0_DIC_SHIFT, 1, 1),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_EL0_IDC_SHIFT, 1, 1),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, CTR_EL0_CWG_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, CTR_EL0_ERG_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_EL0_DminLine_SHIFT, 4, 1),
@@ -2764,20 +2765,27 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
{
.desc = "Hardware dirty bit management",
.type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
.capability = ARM64_HW_DBM,
.matches = has_hw_dbm,
.cpu_enable = cpu_enable_hw_dbm,
.cpus = &dbm_cpus,
ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, DBM)
},
#endif
+ {
+ .desc = "Hardware dirty bit Cleaning",
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .capability = ARM64_HACDBS,
+ .matches = has_cpuid_feature,
+ ARM64_CPUID_FIELDS(ID_AA64MMFR4_EL1, HACDBS, IMP)
+ },
#ifdef CONFIG_ARM64_HAFT
{
.desc = "Hardware managed Access Flag for Table Descriptors",
/*
* Contrary to the page/block access flag, the table access flag
* cannot be emulated in software (no access fault will occur).
* Therefore this should be used only if it's supported system
* wide.
*/
.type = ARM64_CPUCAP_SYSTEM_FEATURE,
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index a87706c9d160..bd2c0bb98da6 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -65,20 +65,21 @@ HAS_STAGE2_FWB
HAS_TCR2
HAS_TIDCP1
HAS_TLB_RANGE
HAS_VA52
HAS_VIRT_HOST_EXTN
HAS_WFXT
HAS_XNX
HAS_HDBSS
HAFT
HW_DBM
+HACDBS
KVM_HVHE
KVM_PROTECTED_MODE
MISMATCHED_CACHE_TYPE
MPAM
MPAM_HCR
MTE
MTE_ASYMM
MTE_FAR
MTE_STORE_ONLY
SME
--
2.54.0
^ permalink raw reply related
* [PATCH v2 02/13] KVM: arm64: Enable eager hugepage splitting if HDBSS is available
From: Leonardo Bras @ 2026-06-29 11:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Rafael J. Wysocki, Len Brown, Saket Dumbre, Paolo Bonzini,
Jonathan Cameron, Chengwen Feng, Leonardo Bras, Kees Cook,
Mikołaj Lenczewski, James Morse, Zeng Heng, mrigendrachaubey,
Thomas Huth, Ryan Roberts, Yeoreum Yun, Mark Brown, Kevin Brodsky,
James Clark, Fuad Tabba, Raghavendra Rao Ananta,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng
Cc: linux-arm-kernel, linux-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <20260629111820.1873540-1-leo.bras@arm.com>
FEAT_HDBSS speeds up guest memory dirty tracking by avoiding a page fault
and saving the entry in a tracking structure.
That may be a problem when we have guest memory backed by hugepages or
transparent huge pages, as it's not possible to do on-demand hugepage
splitting, relying only on eager hugepage splitting.
So, at stage2 initialization, enable eager hugepage splitting with
chunk = 256K * PAGE_SIZE if the system supports HDBSS.
Signed-off-by: Leonardo Bras <leo.bras@arm.com>
---
arch/arm64/kvm/mmu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 6c941aaa10c6..e086c01a9325 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1020,22 +1020,26 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
mmu->last_vcpu_ran = alloc_percpu(typeof(*mmu->last_vcpu_ran));
if (!mmu->last_vcpu_ran) {
err = -ENOMEM;
goto out_destroy_pgtable;
}
for_each_possible_cpu(cpu)
*per_cpu_ptr(mmu->last_vcpu_ran, cpu) = -1;
- /* The eager page splitting is disabled by default */
- mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
+ /* The eager page splitting is disabled by default if system has no HDBSS */
+ if (system_supports_hdbss())
+ mmu->split_page_chunk_size = 256 * 1024 * PAGE_SIZE;
+ else
+ mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
+
mmu->split_page_cache.gfp_zero = __GFP_ZERO;
mmu->pgd_phys = __pa(pgt->pgd);
if (kvm_is_nested_s2_mmu(kvm, mmu))
kvm_init_nested_s2_mmu(mmu);
return 0;
out_destroy_pgtable:
--
2.54.0
^ permalink raw reply related
* [PATCH v2 01/13] KVM: arm64: HDBSS bits
From: Leonardo Bras @ 2026-06-29 11:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Rafael J. Wysocki, Len Brown, Saket Dumbre, Paolo Bonzini,
Jonathan Cameron, Chengwen Feng, Leonardo Bras, Kees Cook,
Mikołaj Lenczewski, James Morse, Zeng Heng, mrigendrachaubey,
Thomas Huth, Ryan Roberts, Yeoreum Yun, Mark Brown, Kevin Brodsky,
James Clark, Fuad Tabba, Raghavendra Rao Ananta,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng
Cc: linux-arm-kernel, linux-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <20260629111820.1873540-1-leo.bras@arm.com>
All those bits should come from a future version of HDBSS patchset:
https://lore.kernel.org/lkml/20260225040421.2683931-1-zhengtian10@huawei.com
I added them here in order to fulfill the dependencies and be able to
easily build this patchset, but this particular patch should not be merged
upstream.
Signed-off-by: Leonardo Bras <leo.bras@arm.com>
---
arch/arm64/include/asm/cpufeature.h | 5 +++++
arch/arm64/include/asm/kvm_dirty_bit.h | 12 ++++++++++++
arch/arm64/include/asm/kvm_pgtable.h | 3 +++
arch/arm64/kernel/cpufeature.c | 12 ++++++++++++
arch/arm64/kvm/dirty_bit.c | 16 ++++++++++++++++
arch/arm64/kvm/hyp/pgtable.c | 15 +++++++++++++--
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/tools/cpucaps | 1 +
8 files changed, 63 insertions(+), 3 deletions(-)
create mode 100644 arch/arm64/include/asm/kvm_dirty_bit.h
create mode 100644 arch/arm64/kvm/dirty_bit.c
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index a57870fa96db..bdfab086fd94 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -856,20 +856,25 @@ static inline bool system_supports_poe(void)
static inline bool system_supports_gcs(void)
{
return alternative_has_cap_unlikely(ARM64_HAS_GCS);
}
static inline bool system_supports_haft(void)
{
return cpus_have_final_cap(ARM64_HAFT);
}
+static inline bool system_supports_hdbss(void)
+{
+ return cpus_have_final_cap(ARM64_HAS_HDBSS);
+}
+
static __always_inline bool system_supports_mpam(void)
{
return alternative_has_cap_unlikely(ARM64_MPAM);
}
static __always_inline bool system_supports_mpam_hcr(void)
{
return alternative_has_cap_unlikely(ARM64_MPAM_HCR);
}
diff --git a/arch/arm64/include/asm/kvm_dirty_bit.h b/arch/arm64/include/asm/kvm_dirty_bit.h
new file mode 100644
index 000000000000..dd16438f0651
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_dirty_bit.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2026 ARM Ltd.
+ * Author: Leonardo Bras <leo.bras@arm.com>
+ */
+
+#ifndef __ARM64_KVM_DIRTY_BIT_H__
+#define __ARM64_KVM_DIRTY_BIT_H__
+
+#include <asm/kvm_pgtable.h>
+
+#endif /* __ARM64_KVM_DIRTY_BIT_H__ */
diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index 41a8687938eb..646ff88e0258 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -86,20 +86,22 @@ typedef u64 kvm_pte_t;
#define KVM_PTE_LEAF_ATTR_HI GENMASK(63, 50)
#define KVM_PTE_LEAF_ATTR_HI_SW GENMASK(58, 55)
#define KVM_PTE_LEAF_ATTR_HI_S1_XN BIT(54)
#define KVM_PTE_LEAF_ATTR_HI_S1_UXN BIT(54)
#define KVM_PTE_LEAF_ATTR_HI_S1_PXN BIT(53)
#define KVM_PTE_LEAF_ATTR_HI_S2_XN GENMASK(54, 53)
+#define KVM_PTE_LEAF_ATTR_HI_S2_DBM BIT(51)
+
#define KVM_PTE_LEAF_ATTR_HI_S1_GP BIT(50)
#define KVM_PTE_LEAF_ATTR_S2_PERMS (KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | \
KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \
KVM_PTE_LEAF_ATTR_HI_S2_XN)
/* pKVM invalid pte encodings */
#define KVM_INVALID_PTE_TYPE_MASK GENMASK(63, 60)
#define KVM_INVALID_PTE_ANNOT_MASK ~(KVM_PTE_VALID | \
KVM_INVALID_PTE_TYPE_MASK)
@@ -246,20 +248,21 @@ struct kvm_pgtable_mm_ops {
};
/**
* enum kvm_pgtable_stage2_flags - Stage-2 page-table flags.
* @KVM_PGTABLE_S2_IDMAP: Only use identity mappings.
* @KVM_PGTABLE_S2_AS_S1: Final memory attributes are that of Stage-1.
*/
enum kvm_pgtable_stage2_flags {
KVM_PGTABLE_S2_IDMAP = BIT(0),
KVM_PGTABLE_S2_AS_S1 = BIT(1),
+ KVM_PGTABLE_S2_DBM = BIT(2),
};
/**
* enum kvm_pgtable_prot - Page-table permissions and attributes.
* @KVM_PGTABLE_PROT_UX: Unprivileged execute permission.
* @KVM_PGTABLE_PROT_PX: Privileged execute permission.
* @KVM_PGTABLE_PROT_X: Privileged and unprivileged execute permission.
* @KVM_PGTABLE_PROT_W: Write permission.
* @KVM_PGTABLE_PROT_R: Read permission.
* @KVM_PGTABLE_PROT_DEVICE: Device attributes.
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9a22df0c5120..aa327eebaf1c 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2124,20 +2124,25 @@ static bool has_nested_virt_support(const struct arm64_cpu_capabilities *cap,
return true;
}
static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
int __unused)
{
return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
}
+static bool has_vhe_hdbss(const struct arm64_cpu_capabilities *entry, int cope)
+{
+ return is_kernel_in_hyp_mode() && has_cpuid_feature(entry, cope);
+}
+
bool cpu_supports_bbml2_noabort(void)
{
/*
* We want to allow usage of BBML2 in as wide a range of kernel contexts
* as possible. This list is therefore an allow-list of known-good
* implementations that both support BBML2 and additionally, fulfill the
* extra constraint of never generating TLB conflict aborts when using
* the relaxed BBML2 semantics (such aborts make use of BBML2 in certain
* kernel contexts difficult to prove safe against recursive aborts).
*
@@ -2774,20 +2779,27 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
* cannot be emulated in software (no access fault will occur).
* Therefore this should be used only if it's supported system
* wide.
*/
.type = ARM64_CPUCAP_SYSTEM_FEATURE,
.capability = ARM64_HAFT,
.matches = has_cpuid_feature,
ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, HAFT)
},
#endif
+ {
+ .desc = "Hardware Dirty state tracking structure (HDBSS)",
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .capability = ARM64_HAS_HDBSS,
+ .matches = has_vhe_hdbss,
+ ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, HDBSS)
+ },
{
.desc = "CRC32 instructions",
.capability = ARM64_HAS_CRC32,
.type = ARM64_CPUCAP_SYSTEM_FEATURE,
.matches = has_cpuid_feature,
ARM64_CPUID_FIELDS(ID_AA64ISAR0_EL1, CRC32, IMP)
},
{
.desc = "Speculative Store Bypassing Safe (SSBS)",
.capability = ARM64_SSBS,
diff --git a/arch/arm64/kvm/dirty_bit.c b/arch/arm64/kvm/dirty_bit.c
new file mode 100644
index 000000000000..32fe938d6bf7
--- /dev/null
+++ b/arch/arm64/kvm/dirty_bit.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 ARM Ltd.
+ * Author: Leonardo Bras <leo.bras@arm.com>
+ */
+
+#include <asm/kvm_dirty_bit.h>
+
+/* HDBSS entry field definitions */
+#define HDBSS_ENTRY_VALID BIT(0)
+#define HDBSS_ENTRY_TTWL_SHIFT (1)
+#define HDBSS_ENTRY_TTWL_MASK (GENMASK(3, 1))
+#define HDBSS_ENTRY_TTWL(x) \
+ (((x) << HDBSS_ENTRY_TTWL_SHIFT) & HDBSS_ENTRY_TTWL_MASK)
+#define HDBSS_ENTRY_TTWL_RESV HDBSS_ENTRY_TTWL(-4)
+#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 91a7dfad6686..e16729f0b7bd 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -724,23 +724,27 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
attr = KVM_S2_MEMATTR(pgt, NORMAL);
}
r = stage2_set_xn_attr(prot, &attr);
if (r)
return r;
if (prot & KVM_PGTABLE_PROT_R)
attr |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R;
- if (prot & KVM_PGTABLE_PROT_W)
+ if (prot & KVM_PGTABLE_PROT_W) {
attr |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W;
+ if (pgt->flags & KVM_PGTABLE_S2_DBM)
+ attr |= KVM_PTE_LEAF_ATTR_HI_S2_DBM;
+ }
+
if (!kvm_lpa2_is_enabled())
attr |= FIELD_PREP(KVM_PTE_LEAF_ATTR_LO_S2_SH, sh);
attr |= KVM_PTE_LEAF_ATTR_LO_S2_AF;
attr |= prot & KVM_PTE_LEAF_ATTR_HI_SW;
*ptep = attr;
return 0;
}
@@ -1360,23 +1364,27 @@ int kvm_pgtable_stage2_relax_perms(struct kvm_pgtable *pgt, u64 addr,
kvm_pte_t xn = 0, set = 0, clr = 0;
s8 level;
int ret;
if (prot & KVM_PTE_LEAF_ATTR_HI_SW)
return -EINVAL;
if (prot & KVM_PGTABLE_PROT_R)
set |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R;
- if (prot & KVM_PGTABLE_PROT_W)
+ if (prot & KVM_PGTABLE_PROT_W) {
set |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W;
+ if (pgt->flags & KVM_PGTABLE_S2_DBM)
+ set |= KVM_PTE_LEAF_ATTR_HI_S2_DBM;
+ }
+
ret = stage2_set_xn_attr(prot, &xn);
if (ret)
return ret;
set |= xn & KVM_PTE_LEAF_ATTR_HI_S2_XN;
clr |= ~xn & KVM_PTE_LEAF_ATTR_HI_S2_XN;
ret = stage2_update_leaf_attrs(pgt, addr, 1, set, clr, NULL, &level, flags);
if (!ret || ret == -EAGAIN)
kvm_call_hyp(__kvm_tlb_flush_vmid_ipa_nsh, pgt->mmu, addr, level);
@@ -1578,20 +1586,23 @@ int __kvm_pgtable_stage2_init(struct kvm_pgtable *pgt, struct kvm_s2_mmu *mmu,
u64 vtcr = mmu->vtcr;
u32 ia_bits = VTCR_EL2_IPA(vtcr);
u32 sl0 = FIELD_GET(VTCR_EL2_SL0_MASK, vtcr);
s8 start_level = VTCR_EL2_TGRAN_SL0_BASE - sl0;
pgd_sz = kvm_pgd_pages(ia_bits, start_level) * PAGE_SIZE;
pgt->pgd = (kvm_pteref_t)mm_ops->zalloc_pages_exact(pgd_sz);
if (!pgt->pgd)
return -ENOMEM;
+ if (system_supports_hdbss())
+ flags |= KVM_PGTABLE_S2_DBM;
+
pgt->ia_bits = ia_bits;
pgt->start_level = start_level;
pgt->mm_ops = mm_ops;
pgt->mmu = mmu;
pgt->flags = flags;
pgt->force_pte_cb = force_pte_cb;
/* Ensure zeroed PGD pages are visible to the hardware walker */
dsb(ishst);
return 0;
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 59612d2f277c..6faacd857346 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -17,21 +17,21 @@ kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
inject_fault.o va_layout.o handle_exit.o config.o \
guest.o debug.o reset.o sys_regs.o stacktrace.o \
vgic-sys-reg-v3.o fpsimd.o pkvm.o \
arch_timer.o trng.o vmid.o emulate-nested.o nested.o at.o \
vgic/vgic.o vgic/vgic-init.o \
vgic/vgic-irqfd.o vgic/vgic-v2.o \
vgic/vgic-v3.o vgic/vgic-v4.o \
vgic/vgic-mmio.o vgic/vgic-mmio-v2.o \
vgic/vgic-mmio-v3.o vgic/vgic-kvm-device.o \
vgic/vgic-its.o vgic/vgic-debug.o vgic/vgic-v3-nested.o \
- vgic/vgic-v5.o
+ vgic/vgic-v5.o dirty_bit.o
kvm-$(CONFIG_HW_PERF_EVENTS) += pmu-emul.o pmu.o
kvm-$(CONFIG_ARM64_PTR_AUTH) += pauth.o
kvm-$(CONFIG_PTDUMP_STAGE2_DEBUGFS) += ptdump.o
kvm-$(CONFIG_NVHE_EL2_TRACING) += hyp_trace.o
always-y := hyp_constants.h hyp-constants.s
define rule_gen_hyp_constants
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 9b85a84f6fd4..a87706c9d160 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -62,20 +62,21 @@ HAS_RASV1P1_EXTN
HAS_RNG
HAS_SB
HAS_STAGE2_FWB
HAS_TCR2
HAS_TIDCP1
HAS_TLB_RANGE
HAS_VA52
HAS_VIRT_HOST_EXTN
HAS_WFXT
HAS_XNX
+HAS_HDBSS
HAFT
HW_DBM
KVM_HVHE
KVM_PROTECTED_MODE
MISMATCHED_CACHE_TYPE
MPAM
MPAM_HCR
MTE
MTE_ASYMM
MTE_FAR
--
2.54.0
^ permalink raw reply related
* [PATCH v2 00/13] KVM Dirty-bit cleaning hw accelerator (HACDBS)
From: Leonardo Bras @ 2026-06-29 11:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Rafael J. Wysocki, Len Brown, Saket Dumbre, Paolo Bonzini,
Jonathan Cameron, Chengwen Feng, Leonardo Bras, Kees Cook,
Mikołaj Lenczewski, James Morse, Zeng Heng, mrigendrachaubey,
Thomas Huth, Ryan Roberts, Yeoreum Yun, Mark Brown, Kevin Brodsky,
James Clark, Fuad Tabba, Raghavendra Rao Ananta,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng
Cc: linux-arm-kernel, linux-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
Disclaimer: While this patchset is buildable and testable on it's own,
it is not ready to be merged, as it depends on bits from another
patchset that will superseed the one in [0], and will enable HDBSS.
See note below on patches 1,2.
My expectation on sharing this earlier is to gather feedback on
implementation and testing methods, to make sure it's sure it's ready
when [0] becomes ready.
===
Create an arch-generic dirty-bit cleaning acceleration interface, which
compiles-out if the arch does not implement it, and creates no new API.
Using that, implement an arm64 accelerator based on HACDBS.
This implementation is able to accelerate the cleaning on both
dirty-bitmap and dirty-ring tracking mechanisms on KVM.
Patch 1 & 2 are here just to make this testable, as this patchset
depends on bits from HDBSS that are not upstream yet.
Patch 2 should be included in the HDBSS patchset, and patch 1
is a bunch of bits that I collected across other patches so this can
work. So few free to ignore them on review, as they should be reviewed
in the HDBSS patchset.
To be able to properly use HACDBS, it requires a PPI IRQ that triggers
either on error, or when processing is complete. It's called
HACDBSIRQ, and there is currently no upstream way of announcing it on
ACPI tables, so this patchset uses the suggested table/index in [1],
which at the moment is not merged.
Kernel v7.2-rc1 + this patchset builds properly, passing both kvm selftests
for dirty-bit tracking[2] and a qemu live migration test, with both
HW HACDBS enabled or disabled.
On terms of performance improvement, tests were done using
dirty_log_perf_test[3] to measure the time spent on the following ioctl:
a - KVM_GET_DIRTY_LOG, using dirty-bitmap without manual protect
command: ./dirty_log_perf_test -m 3 -m 6 -m 12 -g
b - KVM_CLEAR_DIRTY_LOG, using dirty-bitmap with manual protect
command: ./dirty_log_perf_test -m 3 -m 6 -m 12
c - KVM_RESET_DIRTY_RINGS, using dirty-ring, using 4096 entries/vcpu.
command: ./dirty_log_perf_test -m 3 -m 6 -m 12 -d 4096
Tests ran in the model show that runtime was reduced by:
-(a) 82.19% (0.16% stdev) for 1GB memory, and
82.45% (0.02% stdev) for 3GB memory
-(b) 81.74% (0.19% stdev) for 1GB memory, and
82.40% (0.38% stdev) for 3GB memory
-(b) 70.90% (0.18% stdev) for 1GB memory, and
70.92% (0.01% stdev) for 3GB memory
Above numbers already take into account the improvements in S2
hugepage-splitting that is implemented by [4].
Please let me know of any question :)
Thanks for reviewing!
Leo
Changes since v1:
- Improvements on splitting with manual protect, skipping when cleaning
pages from the same level-2 entry. (new patch)
- Got the correct concept of chunk_size and thus:
- Corrected it to a reasonable chunk to do page splitting before
rescheduling, considering new improvements from [4].
- TTWL is not based in chunk size, so fix it in LAST_LEVEL
- Minor fixes, removing debugging traces
v1 Link: https://lore.kernel.org/all/20260430111424.3479613-2-leo.bras@arm.com/
[0]: https://lore.kernel.org/all/20260225040421.2683931-1-zhengtian10@huawei.com/
[1]: https://github.com/tianocore/edk2/issues/12409
[2]: dirty_log_test && dirty_log_perf_test
[3]: using this patchset to enable dirty-ring on dirty_log_perf_test:
https://lore.kernel.org/all/20260629105950.1790259-1-leo.bras@arm.com/
[4]: https://lore.kernel.org/all/20260618131447.764085-1-leo.bras@arm.com/
Leonardo Bras (13):
KVM: arm64: HDBSS bits
KVM: arm64: Enable eager hugepage splitting if HDBSS is available
arm64/cpufeature: Add system-wide FEAT_HACDBS detection
arm64/sysreg: Add HACDBS consumer and base registers
KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ
KVM: arm64: dirty_bit: Add base FEAT_HACDBS cleaning routine
kvm: Add arch-generic interface for hw-accelerated dirty-bitmap
cleaning
KVM: arm64: Add hardware-accelerated dirty-bitmap cleaning routine
KVM: arm64: Dirty-bitmap: avoid splitting previously split blocks
kvm/dirty_ring: Introduce get_memslot and move helpers to header
kvm/dirty_ring: Add arch-generic interface for hw-accelerated
dirty-ring cleaning
KVM: arm64: Add hardware-accelerated dirty-ring cleaning routine
KVM: arm64: Enable KVM_HW_DIRTY_BIT
arch/arm64/include/asm/acpi.h | 3 +
arch/arm64/include/asm/cpufeature.h | 10 +
arch/arm64/include/asm/kvm_dirty_bit.h | 67 ++++
arch/arm64/include/asm/kvm_pgtable.h | 3 +
include/acpi/actbl2.h | 1 +
include/linux/kvm_dirty_bit.h | 34 ++
include/linux/kvm_dirty_ring.h | 12 +
include/linux/kvm_host.h | 3 +
arch/arm64/kernel/cpufeature.c | 20 ++
arch/arm64/kvm/arm.c | 5 +
arch/arm64/kvm/dirty_bit.c | 411 +++++++++++++++++++++++++
arch/arm64/kvm/hyp/pgtable.c | 15 +-
arch/arm64/kvm/mmu.c | 12 +-
virt/kvm/dirty_ring.c | 34 +-
virt/kvm/kvm_main.c | 13 +-
arch/arm64/kvm/Kconfig | 1 +
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/tools/cpucaps | 2 +
arch/arm64/tools/sysreg | 30 ++
virt/kvm/Kconfig | 3 +
20 files changed, 659 insertions(+), 22 deletions(-)
create mode 100644 arch/arm64/include/asm/kvm_dirty_bit.h
create mode 100644 include/linux/kvm_dirty_bit.h
create mode 100644 arch/arm64/kvm/dirty_bit.c
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 03/17] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Mark Brown @ 2026-06-29 11:17 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Linus Torvalds, Greg Kroah-Hartman, Nicolas Frattaroli,
Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Heiko Stuebner,
linux-rockchip, linux-sound, linux-arm-kernel, linux-kernel
In-Reply-To: <d2fe7dc85277b01526f9320ed5baab2acd29660b.1782490566.git.u.kleine-koenig@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
On Fri, Jun 26, 2026 at 08:00:22PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Currently that header is only included via:
>
> <sound/dmaengine_pcm.h> ->
> <sound/soc.h> ->
> <linux/platform_device.h>
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 07/16] usb: hub: Power on connected M.2 E-key connectors
From: Andy Shevchenko @ 2026-06-29 11:14 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Bartosz Golaszewski, Alan Stern, linux-acpi, driver-core,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam, Greg Kroah-Hartman,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
In-Reply-To: <CAGXv+5Gbf8+=hMZcK0pYraC1t4qmDx_WVPkr2RhWdm3bq_LZEQ@mail.gmail.com>
On Mon, Jun 29, 2026 at 02:46:42PM +0800, Chen-Yu Tsai wrote:
> On Fri, Jun 12, 2026 at 4:55 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
> > On Thu, Jun 11, 2026 at 6:11 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > > On Wed, 10 Jun 2026 10:40:41 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
...
> > Yeah, instead we need
> >
> > config USB
> > depends on POWER_SEQUENCING && !POWER_SEQUENCING
>
> FTR:
>
> Somehow I remembered this incorrectly. It should be the following instead:
>
> depends on POWER_SEQUENCING || !POWER_SEQUENCING
We have depends on ... if ... expression nowadays for that kind of case.
> and the dependency issue mentioned below then goes away.
>
> > But I ran into a dozen or so drivers that have "select USB", mostly
> > input devices:
> >
> > config TOUCHSCREEN_USB_COMPOSITE
> > tristate "USB Touchscreen Driver"
> > depends on USB_ARCH_HAS_HCD
> > select USB
> >
> > Kconfig complains about unmet dependencies.
> >
> > > I see Andy has some suggestions but in general I like this approach much better
> > > than adding the pwrseq_get_index() function. Thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()
From: Will Deacon @ 2026-06-29 11:12 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Anshuman Khandual, linux-arm-kernel, Catalin Marinas,
Ryan Roberts, linux-kernel, Ben Hutchings
In-Reply-To: <ced1c28d-b9e1-4307-8900-7139c610d176@kernel.org>
On Fri, Jun 26, 2026 at 06:09:27PM +0200, David Hildenbrand (Arm) wrote:
> On 6/26/26 03:28, Anshuman Khandual wrote:
> > flush_tlb_kernel_range() could flush down an entire block mapping just with
> > a single PAGE_SIZE stride. This capability was being used umapping PMD and
> > PUD based block mappings in unmap_hotplug_[pmd|pud]_range().
> >
> > But later on the commit 48478b9f7913
> > ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()") replaced
> > this PAGE_SIZE stride with [PMD|PUD]_SIZE strides, hence forcing multiple
> > PAGE_SIZE stride based TLB flushes on platforms where TLB range operation
> > is not supported. Revert back to the earlier TLB behaviour along with the
> > required comments that were dropped earlier.
> >
>
> Right, it looked like the right thing to do in that commit. I wonder if we can
> make the comments even clearer to prevent his happening another time,
> incorporating the HW consideration.
>
> In any case
>
> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Ryan Roberts <ryan.roberts@arm.com>
> > Cc: David Hildenbrand <david@kernel.org>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > Reported-by: Ben Hutchings <ben@decadent.org.uk>
> > Closes: https://lore.kernel.org/all/b0d5836032ce3135bfc473f6bff791306d086925.camel@decadent.org.uk/
> > Fixes: 48478b9f7913 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
> > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > ---
> > arch/arm64/mm/mmu.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 8242f93f05e4..5ff0041f4a5f 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1509,7 +1509,11 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
> > if (free_mapped) {
> > /* CONT blocks are not supported in the vmemmap */
> > WARN_ON(pmd_cont(pmd));
> > - flush_tlb_kernel_range(addr, addr + PMD_SIZE);
> > + /*
> > + * One TLBI should be sufficient here as the PMD_SIZE
> > + * range is mapped with a single block entry.
> > + */
>
> "Flush only a single page, resulting in a single TLBi for this large block
> mapping, avoiding multiple TLBIs on HW without TLB range flushes."
I'll add something like this when applying and I'll rewrite the commit
message as well.
Cheers,
Will
^ permalink raw reply
* Re: [PATCH v3 3/7] dt-bindings: media: i2c: Utilise video-interface-devices enums
From: Benjamin Mugnier @ 2026-06-29 11:09 UTC (permalink / raw)
To: Kieran Bingham, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jacopo Mondi, Sakari Ailus,
Jimmy Su, Matthias Fend, Mikhail Rudenko, Daniel Scally,
Jacopo Mondi, Michael Riesch, Sylvain Petinot, Laurent Pinchart,
Paul Elder, Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Vladimir Zapolskiy
In-Reply-To: <20260628-kbingham-orientation-v3-3-4ed92968aff8@ideasonboard.com>
Hi Kieran,
Thank you for this patch.
Le 28/06/2026 à 12:22, Kieran Bingham a écrit :
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the existing examples throughout the bindings documentation for
> camera sensors.
>
> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
> ---
> Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml | 3 ++-
> 12 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> index 1a57f2aa1982..b7bc6ba26e6e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> @@ -86,6 +86,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -102,7 +103,7 @@ examples:
> vddio-supply = <®_camera_vddio>;
> reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
> shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> index 6f2017c75125..b9c61395b24f 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> @@ -69,6 +69,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -84,7 +85,7 @@ examples:
> avdd-supply = <&ov08d10_vdda_2v8>;
> dvdd-supply = <&ov08d10_vddd_1v2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> index d96199031b66..fcd617848ce3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> @@ -96,6 +96,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -114,7 +115,7 @@ examples:
> powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> index ad07204057f9..6df62fd0c0c0 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> @@ -85,6 +85,7 @@ examples:
> - |
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> i2c {
> @@ -108,7 +109,7 @@ examples:
> dovdd-supply = <&vcc_2v8>;
>
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> ucam_out: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> index 3368b3bd8ef2..5732657e1484 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> @@ -103,6 +103,7 @@ examples:
> - |
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> i2c {
> @@ -126,7 +127,7 @@ examples:
> dovdd-supply = <&vcc_2v8>;
>
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> ucam_out: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> index 2b6143aff391..24787c9aa155 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> @@ -72,6 +72,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -87,7 +88,7 @@ examples:
> powerdown-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> rotation = <180>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
>
> port {
> endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> index 20f48d5e9b2d..56fb5f18f07b 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> @@ -69,6 +69,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -84,7 +85,7 @@ examples:
> dvdd-supply = <&camera_vddd_1v2>;
> avdd-supply = <&camera_vdda_2v7>;
>
> - orientation = <1>;
> + orientation = <MEDIA_ORIENTATION_BACK>;
> rotation = <90>;
>
> nvmem = <&eeprom>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> index 6050d7e7dcfe..b4a88eaa7ef2 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> @@ -74,6 +74,7 @@ examples:
> - |
> #include <dt-bindings/clock/qcom,camcc-sdm845.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -98,7 +99,7 @@ examples:
> pinctrl-0 = <&cam_front_default>;
>
> rotation = <270>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> cam_front_endpoint: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> index 7c11e871dca6..69a37ff68db3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> @@ -86,6 +86,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -98,7 +99,7 @@ examples:
> clocks = <&clock_cam>;
> dvdd-supply = <&vcc1v1_cam>;
> lens-focus = <&vcm>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&vcc1v8_cam>;
> reset-gpios = <&gpio_expander 14 GPIO_ACTIVE_LOW>;
> rotation = <180>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> index 060ac6829b66..db9f0c15576c 100644
> --- a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> @@ -105,6 +105,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -123,7 +124,7 @@ examples:
> reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> st,leds = <2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> index c6673b8539db..48db22ca4a7e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> @@ -107,6 +107,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -125,7 +126,7 @@ examples:
> reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> st,leds = <6>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> index bc339a7374b2..4a66cb711372 100644
> --- a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> @@ -173,6 +173,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -196,7 +197,7 @@ examples:
> vddgpio-0-supply = <&vsys_v4p2>;
> vddgpio-1-supply = <&vsys_v4p2>;
>
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <0>;
>
> sensors {
>
--
Regards,
Benjamin
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: io: apply the device store-release workaround once per block write
From: Vladimir Murzin @ 2026-06-29 10:48 UTC (permalink / raw)
To: Shanker Donthineni, Catalin Marinas, Will Deacon
Cc: Jason Gunthorpe, linux-arm-kernel, Mark Rutland, linux-kernel,
linux-doc, Vikram Sethi, Jason Sequeira
In-Reply-To: <20260625182425.3194066-3-sdonthineni@nvidia.com>
Hi,
On 6/25/26 19:24, Shanker Donthineni wrote:
> The generic memset_io()/memcpy_toio() are built on __raw_write*(), so on
> parts with the NVIDIA Olympus device store/load ordering erratum the
> ARM64_WORKAROUND_DEVICE_STORE_RELEASE workaround promotes every store in
> the block to a store-release. Each stlr* carries a barrier cost, so block
> MMIO becomes O(n) store-releases, making a block copy many times slower
> than a single ordered burst and growing with the transfer size.
>
> Provide arm64 memset_io()/memcpy_toio() that emit plain str* in the loop
> and order the whole block against subsequent loads with a single
> trailing dmb osh on affected CPUs (a no-op elsewhere, preserving the
> relaxed contract of these helpers). This keeps block MMIO writes at
> one-barrier cost rather than scaling with the transfer size.
>
> Performance (NVIDIA Olympus, write-combining MMIO to a device BAR, single
> PE pinned; per-call cost in ns; consecutive writes ping-pong between two
> buffers so repeated stores are not coalesced; iowrite64/iowrite32 =
> __iowrite{64,32}_copy()):
>
> Table 1 - arm64 memset_io/memcpy_toio (this patch)
> +-------+-----------+-----------+-----------+-------------+
> | size | iowrite64 | iowrite32 | memset_io | memcpy_toio |
> +-------+-----------+-----------+-----------+-------------+
> | 8B | 231.6 ns | 231.6 ns | 232.4 ns | 232.4 ns |
> | 16B | 231.7 ns | 231.9 ns | 232.7 ns | 232.6 ns |
> | 32B | 231.9 ns | 232.7 ns | 232.9 ns | 232.9 ns |
> | 64B | 232.7 ns | 235.0 ns | 233.7 ns | 233.6 ns |
> | 128B | 233.6 ns | 235.8 ns | 234.4 ns | 234.3 ns |
> | 256B | 237.7 ns | 276.8 ns | 264.0 ns | 276.7 ns |
> | 512B | 237.7 ns | 277.1 ns | 238.1 ns | 277.6 ns |
> | 1KB | 253.7 ns | 279.3 ns | 276.1 ns | 294.1 ns |
> | 2KB | 295.0 ns | 318.7 ns | 288.5 ns | 308.3 ns |
> | 4KB | 365.9 ns | 381.4 ns | 365.7 ns | 381.3 ns |
> +-------+-----------+-----------+-----------+-------------+
> all four helpers end with a single trailing barrier (dmb osh).
>
> Table 2 - generic per-store memset_io/memcpy_toio
> +-------+-----------+-----------+-------------+--------------+
> | size | iowrite64 | iowrite32 | memset_io | memcpy_toio |
> +-------+-----------+-----------+-------------+--------------+
> | 8B | 231.6 ns | 231.6 ns | 229.0 ns | 229.0 ns |
> | 16B | 231.7 ns | 231.9 ns | 458.4 ns | 458.5 ns |
> | 32B | 231.9 ns | 232.7 ns | 917.4 ns | 917.5 ns |
> | 64B | 232.7 ns | 234.8 ns | 1835.4 ns | 1835.5 ns |
> | 128B | 233.6 ns | 235.8 ns | 3670.9 ns | 3670.8 ns |
> | 256B | 237.7 ns | 276.7 ns | 7341.6 ns | 7341.6 ns |
> | 512B | 237.7 ns | 279.4 ns | 14001.4 ns | 14001.3 ns |
> | 1KB | 253.7 ns | 279.1 ns | 28631.5 ns | 28631.8 ns |
> | 2KB | 279.4 ns | 317.9 ns | 57276.3 ns | 57275.2 ns |
> | 4KB | 365.7 ns | 381.5 ns | 114564.4 ns | 114563.6 ns |
> +-------+-----------+-----------+-------------+--------------+
> the generic memset_io()/memcpy_toio() build on __raw_write*(), which the
> workaround promotes to store-release, so every store is individually
> ordered - hence O(n) in the store count.
>
> The arm64 versions stay flat at one-barrier cost while the generic
> per-store writers collapse to O(n): at 4KB ~314x slower (~115 us vs
> ~366 ns).
>
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> ---
> arch/arm64/include/asm/io.h | 5 +++
> arch/arm64/kernel/io.c | 82 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 87 insertions(+)
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 69e0fa004d31..649503f347bc 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -266,6 +266,11 @@ __iowrite64_copy(void __iomem *to, const void *from, size_t count)
> }
> #define __iowrite64_copy __iowrite64_copy
>
> +void memset_io(volatile void __iomem *dst, int c, size_t count);
> +#define memset_io memset_io
> +void memcpy_toio(volatile void __iomem *dst, const void *src, size_t count);
> +#define memcpy_toio memcpy_toio
> +
> /*
> * I/O memory mapping functions.
> */
> diff --git a/arch/arm64/kernel/io.c b/arch/arm64/kernel/io.c
> index fe86ada23c7d..b5fd9ee6d9eb 100644
> --- a/arch/arm64/kernel/io.c
> +++ b/arch/arm64/kernel/io.c
> @@ -5,9 +5,91 @@
> * Copyright (C) 2012 ARM Ltd.
> */
>
> +#include <linux/align.h>
> #include <linux/export.h>
> #include <linux/types.h>
> #include <linux/io.h>
> +#include <linux/unaligned.h>
> +
> +#include <asm/alternative.h>
> +
> +/*
> + * ARM64_WORKAROUND_DEVICE_STORE_RELEASE promotes every raw MMIO store
> + * (__raw_write*()) to a store-release on affected CPUs. The generic
> + * memset_io()/memcpy_toio() are built on those helpers, so the workaround would
> + * emit one store-release per element and turn a block write into O(n) ordered
> + * stores - far more costly than the single barrier a block actually needs.
> + *
> + * Provide arm64 versions that emit plain STR in the loop and order the whole
> + * block against subsequent loads with one trailing DMB OSH, patched in only on
> + * affected CPUs (a no-op elsewhere, so the relaxed contract of these helpers is
> + * preserved).
> + *
> + * This capability is currently enabled only for the NVIDIA Olympus device
> + * store/load ordering erratum, where a Device-nGnR* load may be observed before
> + * an older, non-overlapping Device-nGnR* store to the same peripheral.
> + */
> +static __always_inline void iomem_block_store_barrier(void)
> +{
> + asm volatile(ALTERNATIVE("nop", "dmb osh",
> + ARM64_WORKAROUND_DEVICE_STORE_RELEASE)
> + : : : "memory");
> +}
> +
> +void memset_io(volatile void __iomem *dst, int c, size_t count)
> +{
> + u64 qc = (u8)c;
> +
> + qc *= ~0ULL / 0xff;
> +
> + while (count && !IS_ALIGNED((__force unsigned long)dst, sizeof(u64))) {
> + asm volatile("strb %w0, [%1]" : : "rZ"((u8)c), "r"(dst) : "memory");
> + dst++;
> + count--;
> + }
> + while (count >= sizeof(u64)) {
> + asm volatile("str %x0, [%1]" : : "rZ"(qc), "r"(dst) : "memory");
> + dst += sizeof(u64);
> + count -= sizeof(u64);
> + }
> + while (count) {
> + asm volatile("strb %w0, [%1]" : : "rZ"((u8)c), "r"(dst) : "memory");
> + dst++;
> + count--;
> + }
> +
> + iomem_block_store_barrier();
> +}
> +EXPORT_SYMBOL(memset_io);
> +
> +void memcpy_toio(volatile void __iomem *dst, const void *src, size_t count)
> +{
> + while (count && !IS_ALIGNED((__force unsigned long)dst, sizeof(u64))) {
> + asm volatile("strb %w0, [%1]"
> + : : "rZ"(*(const u8 *)src), "r"(dst) : "memory");
> + src++;
> + dst++;
> + count--;
> + }
> + while (count >= sizeof(u64)) {
> + asm volatile("str %x0, [%1]"
> + : : "rZ"(get_unaligned((const u64 *)src)), "r"(dst)
Why do we need get_unaligned() here? I understand this came from
the generic implementation, where it needs to handle architectures
that do not support unaligned accesses. But IIUC this is not an
issue for arm64, and there was no special handling in memcpy_toio()
before 0110feaaf6d0 ("arm64: Use new fallback IO memcpy/memset").
Am I missing something?
> + : "memory");
> + src += sizeof(u64);
> + dst += sizeof(u64);
> + count -= sizeof(u64);
> + }
> + while (count) {
> + asm volatile("strb %w0, [%1]"
> + : : "rZ"(*(const u8 *)src), "r"(dst) : "memory");
> + src++;
> + dst++;
> + count--;
> + }
> +
> + iomem_block_store_barrier();
It is perhaps a matter of taste, but having the inline assembly
here (and in memset_io()) might make the code clearer. To a
casual reader, it would be obvious that the barrier is not
guaranteed and is only applicable to ARM64_WORKAROUND_DEVICE_STORE_RELEASE,
without having to jump back and forth through the code.
Obliviously maintainers might have different preference ;)
Cheers
Vladimir
> +}
> +EXPORT_SYMBOL(memcpy_toio);
>
> /*
> * This generates a memcpy that works on a from/to address which is aligned to
> -- 2.54.0.windows.1
>
^ permalink raw reply
* Re: [PATCH v4 0/2] arm64: errata: NVIDIA Olympus device store/load ordering
From: Vladimir Murzin @ 2026-06-29 10:45 UTC (permalink / raw)
To: Shanker Donthineni, Catalin Marinas, Will Deacon
Cc: Jason Gunthorpe, linux-arm-kernel, Mark Rutland, linux-kernel,
linux-doc, Vikram Sethi, Jason Sequeira
In-Reply-To: <20260625182425.3194066-1-sdonthineni@nvidia.com>
Hi,
On 6/25/26 19:24, Shanker Donthineni wrote:
> This series works around the NVIDIA Olympus device store/load ordering
> erratum (T410-OLY-1027): a Device-nGnR* load can be observed by a
> peripheral before an older, non-overlapping Device-nGnR* store to the
> same peripheral, breaking the program order that drivers rely on for
> MMIO and potentially leaving a device in an incorrect state.
>
> Patch 1 adds the workaround. It promotes the raw MMIO store helpers
> (__raw_writeb/w/l/q, and therefore writel()/writel_relaxed()) to
> store-release on affected CPUs, and promotes the trailing DGH of the
> write-combining __iowrite{32,64}_copy() helpers to dmb osh. Everything is
> gated on a new ARM64_WORKAROUND_DEVICE_STORE_RELEASE cpucap and patched
> in only on affected parts, so it is a no-op elsewhere.
>
> Patch 2 provides arm64 memset_io()/memcpy_toio(). The generic versions
> are built on __raw_write*(), so patch 1 would promote every store in a
> block to a store-release; as each STLR drains the write-combining buffer,
> block MMIO becomes O(n) store-releases. The arm64 versions emit plain
> STR in the loop and order the whole block with a single trailing dmb osh,
> keeping block MMIO at one-barrier cost.
>
> Performance: NVIDIA Olympus, write-combining MMIO to a device BAR, single
> PE pinned; per-call cost in ns. Consecutive writes ping-pong between two
> buffers so repeated stores are not coalesced. iowrite64/iowrite32 =
> __iowrite{64,32}_copy().
>
> Table 1 - workaround off (CONFIG_NVIDIA_OLYMPUS_1027_ERRATUM=n)
> +-------+-----------+-----------+-----------+-------------+
> | size | iowrite64 | iowrite32 | memset_io | memcpy_toio |
> +-------+-----------+-----------+-----------+-------------+
> | 8B | 67.9 ns | 67.8 ns | 3.6 ns | 3.6 ns |
> | 16B | 67.9 ns | 67.8 ns | 4.0 ns | 4.0 ns |
> | 32B | 67.9 ns | 67.9 ns | 4.6 ns | 4.6 ns |
> | 64B | 69.1 ns | 69.1 ns | 69.1 ns | 69.0 ns |
> | 128B | 138.3 ns | 138.3 ns | 138.4 ns | 138.3 ns |
> | 256B | 276.6 ns | 276.6 ns | 276.6 ns | 276.7 ns |
> | 512B | 276.6 ns | 276.5 ns | 276.6 ns | 276.6 ns |
> | 1KB | 276.6 ns | 278.4 ns | 276.6 ns | 276.6 ns |
> | 2KB | 278.4 ns | 278.4 ns | 275.9 ns | 276.6 ns |
> | 4KB | 365.7 ns | 365.7 ns | 365.7 ns | 365.7 ns |
> +-------+-----------+-----------+-----------+-------------+
> relaxed/no-flush: memset_io()/memcpy_toio() issue plain stores with no
> trailing dgh() or barrier, unlike __iowrite*_copy() which ends with dgh().
>
> Table 2 - workaround on, arm64 memset_io/memcpy_toio (this series)
> +-------+-----------+-----------+-----------+-------------+
> | size | iowrite64 | iowrite32 | memset_io | memcpy_toio |
> +-------+-----------+-----------+-----------+-------------+
> | 8B | 231.6 ns | 231.6 ns | 232.4 ns | 232.4 ns |
> | 16B | 231.7 ns | 231.9 ns | 232.7 ns | 232.6 ns |
> | 32B | 231.9 ns | 232.7 ns | 232.9 ns | 232.9 ns |
> | 64B | 232.7 ns | 235.0 ns | 233.7 ns | 233.6 ns |
> | 128B | 233.6 ns | 235.8 ns | 234.4 ns | 234.3 ns |
> | 256B | 237.7 ns | 276.8 ns | 264.0 ns | 276.7 ns |
> | 512B | 237.7 ns | 277.1 ns | 238.1 ns | 277.6 ns |
> | 1KB | 253.7 ns | 279.3 ns | 276.1 ns | 294.1 ns |
> | 2KB | 295.0 ns | 318.7 ns | 288.5 ns | 308.3 ns |
> | 4KB | 365.9 ns | 381.4 ns | 365.7 ns | 381.3 ns |
> +-------+-----------+-----------+-----------+-------------+
> all four helpers end with a single trailing barrier (dmb osh).
>
> Table 3 - workaround on, generic per-store memset_io/memcpy_toio
> +-------+-----------+-----------+-------------+--------------+
> | size | iowrite64 | iowrite32 | memset_io | memcpy_toio |
> +-------+-----------+-----------+-------------+--------------+
> | 8B | 231.6 ns | 231.6 ns | 229.0 ns | 229.0 ns |
> | 16B | 231.7 ns | 231.9 ns | 458.4 ns | 458.5 ns |
> | 32B | 231.9 ns | 232.7 ns | 917.4 ns | 917.5 ns |
> | 64B | 232.7 ns | 234.8 ns | 1835.4 ns | 1835.5 ns |
> | 128B | 233.6 ns | 235.8 ns | 3670.9 ns | 3670.8 ns |
> | 256B | 237.7 ns | 276.7 ns | 7341.6 ns | 7341.6 ns |
> | 512B | 237.7 ns | 279.4 ns | 14001.4 ns | 14001.3 ns |
> | 1KB | 253.7 ns | 279.1 ns | 28631.5 ns | 28631.8 ns |
> | 2KB | 279.4 ns | 317.9 ns | 57276.3 ns | 57275.2 ns |
> | 4KB | 365.7 ns | 381.5 ns | 114564.4 ns | 114563.6 ns |
> +-------+-----------+-----------+-------------+--------------+
> the generic memset_io()/memcpy_toio() build on __raw_write*(), which the
> workaround promotes to store-release, so every store is individually
> ordered - hence O(n) in the store count.
>
> Tables 2 and 3 show why patch 2 is needed: the generic per-store block
> writers collapse to O(n) under the workaround (4KB ~314x slower, ~115 us
> vs ~366 ns), while the arm64 versions stay flat at one-barrier cost.
That's interesting. With the way the patch set is structured, it
now looks like:
1. Fix the erratum, but cause a performance regression.
2. Restore the performance regression and (re)apply the erratum
workaround.
Would it make sense to avoid introducing the performance
regression in the first place by structuring the patch set
slightly differently?
1. (Re)introduce arm64 memset_io()/memcpy_toio().
2. Fix the erratum once for all
What do you reckon?
Cheers
Vladimir
^ permalink raw reply
* Re: [PATCH v14 0/7] Provide support for Trigger Generation Unit
From: Suzuki K Poulose @ 2026-06-29 10:44 UTC (permalink / raw)
To: Songwei.Chai, Greg KH
Cc: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
james.clark, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel,
linux-arm-msm, coresight, devicetree
In-Reply-To: <c09d70e1-edd6-41a8-8ab3-db353bb6f8eb@oss.qualcomm.com>
Hello,
On 29/06/2026 11:17, Songwei.Chai wrote:
>
> On 6/29/2026 12:22 PM, Greg KH wrote:
>> On Mon, Jun 29, 2026 at 11:03:33AM +0800, Songwei.Chai wrote:
>>> Hi Greg & Alexander,
>>>
>>> Apologies for interrupting again.
>>>
>>> As the TGU hardware plays an important role in Qualcomm tracing
>>> design, I
>>> would greatly appreciate it if you could kindly take some time to review
>>> this at your earliest convenience.
>> The merge window _just_ closed, please give us a chance to catch up.
>>
>> Also, why us? Surely you have other reviewers for this code, right?
>
> Hi Greg,
>
> Understood, thanks for letting us know.
>
> Regarding your question: since this introduces a new drivers/hwtracing/
> qcom directory, there is no existing maintainer for it.
> Given your scope (and Alexander's), we believe you are the most relevant
> reviewers.
>
> The reason for creating the qcom directory is as follows:
>
> /We previously tried to upstream this driver under drivers/hwtracing/
> coresight,/
> /but it was not accepted as it is considered Qualcomm-specific and not
> tightly/
> /coupled with the CoreSight subsystem. Based on this feedback, we are
Some clarification here: This device is not CoreSight so we denied
keeping this under drivers/hwtracing/coresight/ - Not because it is
Qualcomm specific. We have TPDM, TPDA, TnoC devices under the coresight
subsystem, which are all Qualcomm specific for e.g.
That said, there are other drivers in drivers/hwtracing/ which I usually
merge and push to Greg, after some reviews/acks from the respective
people (e.g., PTT HiSilicon PCIe Tune and Trace).
But, your proposal was that there were other maintainers for your new
subtree and you were going to push this via ,linux-arm-msm ? to which I
didn't have any objections.
That said, I am fine with pushing this to Greg via the CoreSight pull
requests (similar to Hisilicon PTT driver), but would need someone to
Maintain/Review the driver (with entries in MAINTAINERS, similar to
PTT).
Thoughts ?
Kind regards
Suzuki
> exploring/
> /a dedicated drivers/hwtracing/qcom directory, similar to intel_th, to
> better/
> /support this and future Qualcomm hwtracing drivers./
>
> More details can be found in “[PATCH v14 0/7] -- Why we are proposing
> this”.
>
> Thanks,
> Songwei
>
>>
>> thanks,
>>
>> greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/3] clk: samsung: exynos990: Add PERIS TMU_SUB_PCLK gate
From: Peter Griffin @ 2026-06-29 10:44 UTC (permalink / raw)
To: Denzeel Oliva
Cc: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Conor Dooley, linux-samsung-soc, linux-clk,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260613-exynos990-peris-fix-v3-v3-2-2b230db78ae4@gmail.com>
On Sat, 13 Jun 2026 at 13:36, Denzeel Oliva <wachiturroxd150@gmail.com> wrote:
>
> Add the missing CLK_GOUT_PERIS_TMU_SUB_PCLK gate clock for the Thermal
> Management Unit sub-block and update CLKS_NR_PERIS accordingly.
>
> Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> drivers/clk/samsung/clk-exynos990.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos990.c b/drivers/clk/samsung/clk-exynos990.c
> index 4385c3b76dd6..ee3566b8e57c 100644
> --- a/drivers/clk/samsung/clk-exynos990.c
> +++ b/drivers/clk/samsung/clk-exynos990.c
> @@ -21,7 +21,7 @@
> #define CLKS_NR_HSI0 (CLK_GOUT_HSI0_LHS_ACEL_D_HSI0_CLK + 1)
> #define CLKS_NR_PERIC0 (CLK_GOUT_PERIC0_SYSREG_PCLK + 1)
> #define CLKS_NR_PERIC1 (CLK_GOUT_PERIC1_XIU_P_ACLK + 1)
> -#define CLKS_NR_PERIS (CLK_GOUT_PERIS_OTP_CON_TOP_OSCCLK + 1)
> +#define CLKS_NR_PERIS (CLK_GOUT_PERIS_TMU_SUB_PCLK + 1)
>
> /* ---- CMU_TOP ------------------------------------------------------------- */
>
> @@ -2619,6 +2619,10 @@ static const struct samsung_gate_clock peris_gate_clks[] __initconst = {
> "gout_peris_d_tzpc_peris_pclk", "mout_peris_bus_user",
> CLK_CON_GAT_GOUT_BLK_PERIS_UID_D_TZPC_PERIS_IPCLKPORT_PCLK,
> 21, 0, 0),
> + GATE(CLK_GOUT_PERIS_TMU_SUB_PCLK,
> + "gout_peris_tmu_sub_pclk", "mout_peris_bus_user",
> + CLK_CON_GAT_GOUT_BLK_PERIS_UID_TMU_SUB_IPCLKPORT_PCLK,
> + 21, 0, 0),
> GATE(CLK_GOUT_PERIS_TMU_TOP_PCLK,
> "gout_peris_tmu_top_pclk", "mout_peris_clk_peris_gic",
> CLK_CON_GAT_GOUT_BLK_PERIS_UID_TMU_TOP_IPCLKPORT_PCLK,
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Joey Lu @ 2026-06-29 10:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Arnd Bergmann, Catalin Marinas, Jacky Huang,
Shan-Chun Hung, Hui-Ping Chen, Joey Lu, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260625-sexy-black-tarantula-4031a6@quoll>
On 6/25/2026 3:58 PM, Krzysztof Kozlowski wrote:
> On Thu, Jun 25, 2026 at 10:39:56AM +0800, Joey Lu wrote:
>> properties:
>> compatible:
>> enum:
>> - nuvoton,ma35d1-usb2-phy
>>
>> + reg:
>> + maxItems: 1
>> +
>> "#phy-cells":
>> - const: 0
>> + const: 1
>> + description:
>> + The single cell selects the PHY port. 0 selects the OTG port (USB0,
>> + shared with DWC2 gadget controller) and 1 selects the host-only port
>> + (USB1).
>>
>> - clocks:
>> - maxItems: 1
> This is odd, considering that parent does not have clocks. So explain me
> this:
> 1. USB PHY needed clocks.
> 2. You extend USB PHY to cover second part.
> 3. That extension for second part means that clocks are not needed.
> Really, how? How is it possible in hardware?
The hardware has two independent clock domains:
- The PHY analog block takes the 24 MHz HXT as its reference, wired
directly to the PHY's internal PLL, which derives the required
operating
frequencies internally. This reference path is entirely outside the SoC
software clock tree; no software-gatable clock gate needs to be enabled
for the PHY to power up and lock its PLL. The only software control the
PHY driver exercises is toggling each PHY's Power-On Reset (POR) bit,
which resides in the SYS register block. The driver accesses this via
the parent regmap
- `HUSBH0_GATE` / `HUSBH1_GATE` / `USBD_GATE` are AHB/APB bus interface
clocks for the host and gadget (EHCI, OHCI, DWC2). They gate
the register-access path between the CPU and each controller, not
the PHY
analog circuitry itself.
The original single-port driver enabled `HUSBH0_GATE` as if it belonged
to the
PHY, but that gate is actually owned by EHCI0/OHCI0 and is already
managed by
those controller drivers through their own `clocks` DTS bindings. The PHY
driver was redundantly enabling the same gate.
When extending the driver to cover PHY1, the same pattern held: EHCI1/OHCI1
manage `HUSBH1_GATE` themselves. There is no clock that belongs
exclusively to
the PHY, so `clocks` will be dropped from the PHY binding entirely.
>> + nuvoton,rcalcode:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 1
>> + maxItems: 2
> You should require two values. I understand that any PHY is optional,
> thus you skip the entry, so how would you provide value for PHY1 only?
`nuvoton,rcalcode` will be changed to require exactly two values
(`minItems: 2, maxItems: 2`), one for PHY0 and one for PHY1 respectively.
The property will remain optional overall; when absent, each port
retains its
power-on default value loaded at hardware initialisation. When present, both
entries must be supplied.
>> + items:
>> + minimum: 0
>> + maximum: 15
>> + description:
>> + Resistor calibration trim codes for PHY0 and PHY1 respectively.
>> + Each 4-bit value is written to the RCALCODE field in USBPMISCR and
>> + adjusts the PHY's internal termination resistance. Both entries are
>> + optional; when absent the hardware reset default is used.
>>
>> - nuvoton,sys:
>> - $ref: /schemas/types.yaml#/definitions/phandle
>> + nuvoton,oc-active-high:
>> + type: boolean
>> description:
>> - phandle to syscon for checking the PHY clock status.
>> + When present, the over-current detect input from the VBUS power switch
>> + is treated as active-high. The default (property absent) is active-low.
>> + This setting is shared by both USB host ports.
>>
>> required:
>> - compatible
>> + - reg
> That's ABI break which was not explained in the commit msg - neither
> specifying impact nor actually providing reasons why you break ABI.
>
> And honestly, you have no resources here except the address, so now it
> is clear that this should be folded into parent. See DTS101 talk slides.
The commit message will be updated to explicitly acknowledge the ABI break:
existing DTS files that contain a standalone `usb-phy` node without a `reg`
property will fail dt-schema validation after this change. The impact is
limited to the MA35D1 SoC; no upstream DTS for this SoC existed before this
patch series, so no in-tree board files are broken. The break is intentional
and justified: the PHY register block is physically contained within the
syscon
MMIO range, and modelling it as a child of the syscon with a standard `reg`
property correctly reflects the hardware topology and follows the convention
established by similar sub-blocks in other SoCs.
>> - "#phy-cells"
>> - - clocks
>> - - nuvoton,sys
>>
>> additionalProperties: false
>>
>> examples:
>> - |
>> - #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>> + system-management@40460000 {
>> + compatible = "nuvoton,ma35d1-reset", "syscon", "simple-mfd";
>> + reg = <0x40460000 0x200>;
>> + #reset-cells = <1>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
> Drop. Keep only child node and make parent binding example complete.
The example in `nuvoton,ma35d1-usb2-phy.yaml` will be changed to show only
the `usb-phy@60` child node, without wrapping it in the parent node.
The full parent + child example will be moved to
`nuvoton,ma35d1-reset.yaml`.
Thanks for review.
>>
>> - usb_phy: usb-phy {
>> - compatible = "nuvoton,ma35d1-usb2-phy";
>> - clocks = <&clk USBD_GATE>;
>> - nuvoton,sys = <&sys>;
>> - #phy-cells = <0>;
>> + usb-phy@60 {
>> + compatible = "nuvoton,ma35d1-usb2-phy";
>> + reg = <0x60 0x14>;
>> + #phy-cells = <1>;
>> + };
>> };
>> --
>> 2.43.0
>>
^ permalink raw reply
* RE: [PATCH v6 3/4] reset: cix: add sky1 audss auxiliary reset driver
From: Joakim Zhang @ 2026-06-29 9:11 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Gary Yang
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <0193c47ff4ca98b1a6cb56ed8f4d8876b54756d8.camel@pengutronix.de>
Hello, Philipp
> -----Original Message-----
> From: Philipp Zabel <p.zabel@pengutronix.de>
> Sent: Wednesday, June 24, 2026 4:30 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; Gary Yang
> <gary.yang@cixtech.com>
> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v6 3/4] reset: cix: add sky1 audss auxiliary reset driver
>
> EXTERNAL EMAIL
>
> CAUTION: Suspicious Email from unusual domain.
>
> On Di, 2026-06-23 at 15:08 +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > Add an auxiliary reset controller driver for the AUDSS CRU. Sixteen
> > software reset lines for audio subsystem peripherals are controlled
> > through one register in the CRU register map.
> >
> > The driver is created by the AUDSS clock platform driver and registers
> > the reset controller on the CRU device node.
> >
> > Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> > ---
> > drivers/reset/Kconfig | 14 +++
> > drivers/reset/Makefile | 1 +
> > drivers/reset/reset-sky1-audss.c | 192
> > +++++++++++++++++++++++++++++++
> > 3 files changed, 207 insertions(+)
> > create mode 100644 drivers/reset/reset-sky1-audss.c
> >
> > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> > d009eb0849a3..f74859b292ae 100644
> > --- a/drivers/reset/Kconfig
> > +++ b/drivers/reset/Kconfig
> > @@ -300,6 +300,20 @@ config RESET_SKY1
> > help
> > This enables the reset controller for Cix Sky1.
> >
> > +config RESET_SKY1_AUDSS
> > + tristate "Cix Sky1 Audio Subsystem reset controller"
> > + depends on ARCH_CIX || COMPILE_TEST
> > + select AUXILIARY_BUS
> > + select REGMAP_MMIO
> > + default CLK_SKY1_AUDSS
> > + help
> > + Support for block-level software reset lines in the Cix Sky1
> > + Audio Subsystem (AUDSS) Clock and Reset Unit. Sixteen reset
> > + outputs for audio peripherals are controlled through the CRU
> > + register map. The driver binds as an auxiliary device from
> > + the AUDSS clock driver. Say M or Y here if you want to build
> > + this driver.
> > +
> > config RESET_SOCFPGA
> > bool "SoCFPGA Reset Driver" if COMPILE_TEST && (!ARM
> || !ARCH_INTEL_SOCFPGA)
> > default ARM && ARCH_INTEL_SOCFPGA diff --git
> > a/drivers/reset/Makefile b/drivers/reset/Makefile index
> > 3e52569bd276..e81407ea3e29 100644
> > --- a/drivers/reset/Makefile
> > +++ b/drivers/reset/Makefile
> > @@ -39,6 +39,7 @@ obj-$(CONFIG_RESET_RZV2H_USB2PHY) +=
> > reset-rzv2h-usb2phy.o
> > obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
> > obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
> > obj-$(CONFIG_RESET_SKY1) += reset-sky1.o
> > +obj-$(CONFIG_RESET_SKY1_AUDSS) += reset-sky1-audss.o
> > obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
> > obj-$(CONFIG_RESET_SUNPLUS) += reset-sunplus.o
> > obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o diff --git
> > a/drivers/reset/reset-sky1-audss.c b/drivers/reset/reset-sky1-audss.c
> > new file mode 100644
> > index 000000000000..20870f37d7d7
> > --- /dev/null
> > +++ b/drivers/reset/reset-sky1-audss.c
> > @@ -0,0 +1,192 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Cix Sky1 Audio Subsystem reset controller driver
> > + *
> > + * Copyright 2026 Cix Technology Group Co., Ltd.
> > + */
> > +
> > +#include <dt-bindings/reset/cix,sky1-audss-cru.h>
> > +
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/regmap.h>
> > +#include <linux/reset-controller.h>
> > +
> > +#define SKY1_RESET_SLEEP_MIN_US 50
> > +#define SKY1_RESET_SLEEP_MAX_US 100
> > +
> > +#define AUDSS_SW_RST 0x78
> > +
> > +struct sky1_audss_reset_map {
> > + unsigned int offset;
> > + unsigned int mask;
> > +};
> > +
> > +struct sky1_audss_reset {
> > + struct reset_controller_dev rcdev;
> > + struct regmap *regmap;
> > + const struct sky1_audss_reset_map *map; };
> > +
> > +static const struct sky1_audss_reset_map sky1_audss_reset_map[] = {
> > + [AUDSS_I2S0_SW_RST] = { AUDSS_SW_RST, BIT(0) },
> > + [AUDSS_I2S1_SW_RST] = { AUDSS_SW_RST, BIT(1) },
> > + [AUDSS_I2S2_SW_RST] = { AUDSS_SW_RST, BIT(2) },
> > + [AUDSS_I2S3_SW_RST] = { AUDSS_SW_RST, BIT(3) },
> > + [AUDSS_I2S4_SW_RST] = { AUDSS_SW_RST, BIT(4) },
> > + [AUDSS_I2S5_SW_RST] = { AUDSS_SW_RST, BIT(5) },
> > + [AUDSS_I2S6_SW_RST] = { AUDSS_SW_RST, BIT(6) },
> > + [AUDSS_I2S7_SW_RST] = { AUDSS_SW_RST, BIT(7) },
> > + [AUDSS_I2S8_SW_RST] = { AUDSS_SW_RST, BIT(8) },
> > + [AUDSS_I2S9_SW_RST] = { AUDSS_SW_RST, BIT(9) },
> > + [AUDSS_WDT_SW_RST] = { AUDSS_SW_RST, BIT(10) },
> > + [AUDSS_TIMER_SW_RST] = { AUDSS_SW_RST, BIT(11) },
> > + [AUDSS_MB0_SW_RST] = { AUDSS_SW_RST, BIT(12) },
> > + [AUDSS_MB1_SW_RST] = { AUDSS_SW_RST, BIT(13) },
> > + [AUDSS_HDA_SW_RST] = { AUDSS_SW_RST, BIT(14) },
> > + [AUDSS_DMAC_SW_RST] = { AUDSS_SW_RST, BIT(15) },
> > +};
> > +
> > +static struct sky1_audss_reset *to_sky1_audss_reset(struct
> > +reset_controller_dev *rcdev) {
> > + return container_of(rcdev, struct sky1_audss_reset, rcdev); }
> > +
> > +static int sky1_audss_reset_set(struct reset_controller_dev *rcdev,
> > + unsigned long id, bool assert) {
> > + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> > + const struct sky1_audss_reset_map *signal = &priv->map[id];
> > + unsigned int value = assert ? 0 : signal->mask;
> > +
> > + return regmap_update_bits(priv->regmap, signal->offset,
> > + signal->mask, value);
>
> Why does this propagate the return value ...
I'll propagate the return value in the ops callbacks.
> > +}
> > +
> > +static int sky1_audss_reset_assert(struct reset_controller_dev *rcdev,
> > + unsigned long id) {
> > + sky1_audss_reset_set(rcdev, id, true);
>
> ... only to be ignored? It'd be better to pass it on.
Yes, will add.
> > + usleep_range(SKY1_RESET_SLEEP_MIN_US,
> SKY1_RESET_SLEEP_MAX_US);
> > + return 0;
> > +}
> > +
> > +static int sky1_audss_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long id) {
> > + sky1_audss_reset_set(rcdev, id, false);
> > + usleep_range(SKY1_RESET_SLEEP_MIN_US,
> SKY1_RESET_SLEEP_MAX_US);
> > + return 0;
> > +}
> > +
> > +static int sky1_audss_reset(struct reset_controller_dev *rcdev,
> > + unsigned long id) {
> > + sky1_audss_reset_assert(rcdev, id);
> > + sky1_audss_reset_deassert(rcdev, id);
> > + return 0;
> > +}
>
> Will any AUDSS reset consumer use the reset_control_reset() API?
> If not, no need to implement this.
Will remove both .reset and .status.
> > +
> > +static int sky1_audss_reset_status(struct reset_controller_dev *rcdev,
> > + unsigned long id) {
> > + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> > + const struct sky1_audss_reset_map *signal = &priv->map[id];
> > + unsigned int value;
> > +
> > + regmap_read(priv->regmap, signal->offset, &value);
> > + return !!(value & signal->mask); }
> > +
> > +static const struct reset_control_ops sky1_audss_reset_ops = {
> > + .reset = sky1_audss_reset,
> > + .assert = sky1_audss_reset_assert,
> > + .deassert = sky1_audss_reset_deassert,
> > + .status = sky1_audss_reset_status,
> > +};
> > +
> > +static const struct regmap_config sky1_audss_regmap_config = {
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > +};
> > +
> > +static void sky1_audss_reset_iounmap(void *data) {
> > + iounmap(data);
> > +}
> > +
> > +static int sky1_audss_reset_get_regmap(struct sky1_audss_reset *priv)
> > +{
> > + struct device *dev = priv->rcdev.dev;
> > + void __iomem *base;
> > + int ret;
> > +
> > + priv->regmap = dev_get_regmap(dev->parent, NULL);
> > + if (priv->regmap)
> > + return 0;
> > +
> > + base = of_iomap(dev->parent->of_node, 0);
> > + if (!base)
> > + return dev_err_probe(dev, -ENOMEM, "failed to iomap
> > + address space\n");
> > +
> > + ret = devm_add_action_or_reset(dev, sky1_audss_reset_iounmap, base);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "failed to register
> > + iounmap action\n");
> > +
> > + priv->regmap = devm_regmap_init_mmio(dev, base,
> &sky1_audss_regmap_config);
> > + if (IS_ERR(priv->regmap))
> > + return dev_err_probe(dev, PTR_ERR(priv->regmap),
> > + "failed to initialize regmap\n");
>
> Why is there a fallback path? The clock driver creates the regmap before
> creating the reset aux device, so dev_get_regmap() can never fail.
Agreed.
> > +
> > + return 0;
> > +}
> > +
> > +static int sky1_audss_reset_probe(struct auxiliary_device *adev,
> > + const struct auxiliary_device_id *id)
> > +{
> > + struct sky1_audss_reset *priv;
> > + struct device *dev = &adev->dev;
> > + int ret;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->map = sky1_audss_reset_map;
> > + priv->rcdev.owner = THIS_MODULE;
> > + priv->rcdev.nr_resets = ARRAY_SIZE(sky1_audss_reset_map);
> > + priv->rcdev.ops = &sky1_audss_reset_ops;
> > + priv->rcdev.of_node = dev->parent->of_node;
>
> auxiliary_device_create() uses device_set_of_node_from_dev() to inherit the
> parent of_node, so you can use dev->of_node here.
Done. rcdev.of_node now uses dev->of_node.
> > + priv->rcdev.dev = dev;
> > + priv->rcdev.of_reset_n_cells = 1;
>
> No need to set of_reset_n_cells.
>
> > +
> > + dev_set_drvdata(dev, priv);
>
> This seems unnecessary as well.
>
> > +
> > + ret = sky1_audss_reset_get_regmap(priv);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "failed to get
> > + regmap\n");
> > +
> > + return devm_reset_controller_register(dev, &priv->rcdev); }
> > +
> > +static const struct auxiliary_device_id sky1_audss_reset_ids[] = {
> > + { .name = "clk_sky1_audss.reset" },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(auxiliary, sky1_audss_reset_ids);
> > +
> > +static struct auxiliary_driver sky1_audss_reset_driver = {
> > + .probe = sky1_audss_reset_probe,
> > + .id_table = sky1_audss_reset_ids, };
> > +
>
> Drop this empty line.
Removed dev_set_drvdata() and the extra blank line.
Thanks,
Joakim
^ permalink raw reply
* Re: [PATCH v3 3/5] KVM: arm64: nv: Avoid full shadow s2 unmap
From: Wei-Lin Chang @ 2026-06-29 10:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, kvmarm, linux-kernel, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <86cxyfvgf4.wl-maz@kernel.org>
Hi Marc,
Sorry for the late reply.
On Thu, May 28, 2026 at 01:59:11PM +0100, Marc Zyngier wrote:
> On Sun, 10 May 2026 15:53:36 +0100,
> Wei-Lin Chang <weilin.chang@arm.com> wrote:
> >
> > Currently we are forced to fully unmap all shadow stage-2 for a VM when
> > unmapping a page from the canonical stage-2, for example during an MMU
> > notifier call. This is because we are not tracking what canonical IPA
> > are mapped in the shadow stage-2 page tables hence there is no way to
> > know what to unmap.
> >
> > Create a per kvm_s2_mmu maple tree to track canonical IPA range ->
> > nested IPA range, so that it is possible to partially unmap shadow
> > stage-2 when a canonical IPA range is unmapped. The algorithm is simple
> > and conservative:
> >
> > At each shadow stage-2 map, insert the nested IPA range into the maple
> > tree, with the canonical IPA range as the key. If the canonical IPA
> > range doesn't overlap with existing ranges in the tree, insert as is,
> > and a reverse mapping for this range is established. But if the
> > canonical IPA range overlaps with any existing ranges in the tree,
> > create a new range that spans all the overlapping ranges including the
> > input range and replace those existing ranges. In the mean time, mark
> > this new spanning canonical IPA range with an "UNKNOWN_IPA" bit,
> > indicating we give up tracking the nested IPA ranges that map to this
> > canonical IPA range.
> >
> > The maple tree's 64 bit entry is enough to store the nested IPA and
> > the UNKNOWN_IPA status, therefore besides maple tree's internal
> > operation, memory allocation is avoided.
> >
> > Example:
> > |||| means existing range, ---- means empty range
> >
> > input: $$$$$$$$$$$$$$$$$$$$$$$$$$
> > tree: --||||-----|||||||---------||||||||||-----------
> >
> > insert spanning range and replace overlapping ones:
> > --||||-----||||||||||||||||||||||||||-----------
> > ^^^^marked UNKNOWN_IPA^^^^
> >
> > With the reverse map created, when a canonical IPA range gets unmapped,
> > look into each s2 mmu's maple tree and look for canonical IPA ranges
> > affected, and base on their UNKNOWN_IPA status:
> >
> > UNKNOWN_IPA -> fall back and fully unmap the current shadow
> > stage-2, also clear the tree
> >
> > not UNKNOWN_IPA -> unmap the nested IPA range, and remove the reverse
> > map entry
> >
> > Suggested-by: Marc Zyngier <maz@kernel.org>
> > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 4 +
> > arch/arm64/include/asm/kvm_nested.h | 4 +
> > arch/arm64/kvm/mmu.c | 27 ++++--
> > arch/arm64/kvm/nested.c | 140 +++++++++++++++++++++++++++-
> > 4 files changed, 167 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 1a56d137df10..dc4c0bce1bbb 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -223,6 +223,10 @@ struct kvm_s2_mmu {
> > */
> > bool pending_unmap;
> >
> > + bool nested_revmap_broken;
> > + /* canonical IPA to nested IPA range lookup */
> > + struct maple_tree nested_revmap_mt;
> > +
> > #ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
> > struct dentry *shadow_pt_debugfs_dentry;
> > #endif
> > diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
> > index 091544e6af44..5cbf78dfc685 100644
> > --- a/arch/arm64/include/asm/kvm_nested.h
> > +++ b/arch/arm64/include/asm/kvm_nested.h
> > @@ -76,6 +76,8 @@ extern void kvm_s2_mmu_iterate_by_vmid(struct kvm *kvm, u16 vmid,
> > const union tlbi_info *info,
> > void (*)(struct kvm_s2_mmu *,
> > const union tlbi_info *));
> > +extern void kvm_record_nested_revmap(gpa_t gpa, struct kvm_s2_mmu *mmu,
> > + gpa_t fault_ipa, size_t map_size);
> > extern void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu);
> > extern void kvm_vcpu_put_hw_mmu(struct kvm_vcpu *vcpu);
> >
> > @@ -164,6 +166,8 @@ extern int kvm_s2_handle_perm_fault(struct kvm_vcpu *vcpu,
> > struct kvm_s2_trans *trans);
> > extern int kvm_inject_s2_fault(struct kvm_vcpu *vcpu, u64 esr_el2);
> > extern void kvm_nested_s2_wp(struct kvm *kvm);
> > +extern void kvm_unmap_gfn_range_nested(struct kvm *kvm, gpa_t gpa, size_t size,
> > + bool may_block);
> > extern void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block);
> > extern void kvm_nested_s2_flush(struct kvm *kvm);
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index e4becd5cdf36..ce0bd88cd3c1 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -5,6 +5,7 @@
> > */
> >
> > #include <linux/acpi.h>
> > +#include <linux/maple_tree.h>
> > #include <linux/mman.h>
> > #include <linux/kvm_host.h>
> > #include <linux/io.h>
> > @@ -1099,6 +1100,7 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
> > {
> > struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> > struct kvm_pgtable *pgt = NULL;
> > + struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
> >
> > write_lock(&kvm->mmu_lock);
> > pgt = mmu->pgt;
> > @@ -1108,8 +1110,11 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
> > free_percpu(mmu->last_vcpu_ran);
> > }
> >
> > - if (kvm_is_nested_s2_mmu(kvm, mmu))
> > + if (kvm_is_nested_s2_mmu(kvm, mmu)) {
> > + if (!mtree_empty(revmap_mt))
> > + mtree_destroy(revmap_mt);
> > kvm_init_nested_s2_mmu(mmu);
> > + }
> >
> > write_unlock(&kvm->mmu_lock);
> >
> > @@ -1631,6 +1636,10 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> > goto out_unlock;
> > }
> >
> > + if (s2fd->nested)
> > + kvm_record_nested_revmap(gfn << PAGE_SHIFT, pgt->mmu,
> > + s2fd->fault_ipa, PAGE_SIZE);
> > +
> > ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
> > __pfn_to_phys(pfn), prot,
> > memcache, flags);
> > @@ -2034,6 +2043,10 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
> > ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, gfn_to_gpa(gfn),
> > prot, flags);
> > } else {
> > + if (s2fd->nested)
> > + kvm_record_nested_revmap(canonical_gpa, pgt->mmu,
> > + gfn_to_gpa(gfn), mapping_size);
> > +
> > ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, gfn_to_gpa(gfn), mapping_size,
> > __pfn_to_phys(pfn), prot,
> > memcache, flags);
> > @@ -2389,14 +2402,16 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
> >
> > bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
> > {
> > + gpa_t gpa = range->start << PAGE_SHIFT;
> > + size_t size = (range->end - range->start) << PAGE_SHIFT;
> > + bool may_block = range->may_block;
> > +
> > if (!kvm->arch.mmu.pgt || kvm_vm_is_protected(kvm))
> > return false;
> >
> > - __unmap_stage2_range(&kvm->arch.mmu, range->start << PAGE_SHIFT,
> > - (range->end - range->start) << PAGE_SHIFT,
> > - range->may_block);
> > + __unmap_stage2_range(&kvm->arch.mmu, gpa, size, may_block);
>
> This sort of cleanups could be in a separate patch.
Ack.
>
> > + kvm_unmap_gfn_range_nested(kvm, gpa, size, may_block);
> >
> > - kvm_nested_s2_unmap(kvm, range->may_block);
> > return false;
> > }
> >
> > @@ -2674,7 +2689,7 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
> >
> > write_lock(&kvm->mmu_lock);
> > kvm_stage2_unmap_range(&kvm->arch.mmu, gpa, size, true);
> > - kvm_nested_s2_unmap(kvm, true);
> > + kvm_unmap_gfn_range_nested(kvm, gpa, size, true);
> > write_unlock(&kvm->mmu_lock);
> > }
> >
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 883b6c1008fb..35b5d5f21a23 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> > @@ -7,6 +7,7 @@
> > #include <linux/bitfield.h>
> > #include <linux/kvm.h>
> > #include <linux/kvm_host.h>
> > +#include <linux/maple_tree.h>
> >
> > #include <asm/fixmap.h>
> > #include <asm/kvm_arm.h>
> > @@ -43,6 +44,20 @@ struct vncr_tlb {
> > */
> > #define S2_MMU_PER_VCPU 2
> >
> > +/*
> > + * Per shadow S2 reverse map (IPA -> nested IPA range) maple tree payload
> > + * layout:
> > + *
> > + * bit 62: valid, prevents the case where the nested IPA is 0 and turning
> > + * the whole value to 0
> > + * bits 55-12: nested IPA bits 55-12
> > + * bit 0: UNKNOWN_IPA bit, 1 indicates we give up on tracking what nested
> > + * IPA maps to this canonical IPA in the shadow stage-2
> > + */
> > +#define VALID_ENTRY BIT(62)
> > +#define ADDR_MASK GENMASK_ULL(55, 12)
> > +#define UNKNOWN_IPA BIT(0)
> > +
> > void kvm_init_nested(struct kvm *kvm)
> > {
> > kvm->arch.nested_mmus = NULL;
> > @@ -769,12 +784,57 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
> > return s2_mmu;
> > }
> >
> > +void kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
> > + gpa_t fault_ipa, size_t map_size)
>
> The name fault_ipa doesn't really make sense here. This is the IPA as
> seen from L1 (the input to the L1 S2 tables). We indeed obtain it from
> a fault, but that should not influence the naming here.
>
> Similarly, 'ipa' should be qualified a bit better to reflect that this
> is the L0 IPA.
Yeah these names aren't very clear. I'll change to use 'canonical IPA',
and 'nested IPA'.
>
> > +{
> > + struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
> > + gpa_t ipa_end = ipa + map_size - 1;
>
> Are you always guaranteed that ipa is aligned on map_size?
From what I see in kvm_s2_fault_map() and gmem_abort(), yes, the ipa is
aligned to map_size.
What about adding
if (WARN_ON(!IS_ALIGNED(canonical_ipa, map_size))) {
ALIGN_DOWN(canonical_ipa, map_size);
canonical_ipa_end = canonical_ipa + map_size;
}
to be safe?
>
> > + u64 entry, new_entry = 0;
> > + MA_STATE(mas_rev, revmap_mt, ipa, ipa_end);
> > +
> > + if (mmu->nested_revmap_broken)
> > + return;
> > +
> > + mtree_lock(revmap_mt);
> > + entry = xa_to_value(mas_find_range(&mas_rev, ipa_end));
> > +
> > + if (entry) {
> > + /* maybe just a perm update... */
> > + if (!(entry & UNKNOWN_IPA) && mas_rev.index == ipa &&
>
> Shouldn't you check that VALID_ENTRY is set? Is the index guaranteed
> to match the L0 IPA?
Right now either VALID_ENTRY or UNKNOWN_IPA is set for an exising entry
in the tree, having both set is not expected. I think we can turn
VALID_ENTRY and UNKNOWN_IPA tests into helpers and warn if they are both
set in the helpers?
>
> > + mas_rev.last == ipa_end &&
> > + fault_ipa == (entry & ADDR_MASK))
>
> Again, I think there is a potential alignment issue here.
>
> > + goto unlock;
> > + /*
> > + * Create a "UNKNOWN_IPA" range that spans all the overlapping
> > + * ranges and store it.
> > + */
> > + while (entry && mas_rev.index <= ipa_end) {
> > + ipa = min(mas_rev.index, ipa);
> > + ipa_end = max(mas_rev.last, ipa_end);
> > + entry = xa_to_value(mas_find_range(&mas_rev, ipa_end));
> > + }
> > + new_entry |= UNKNOWN_IPA;
> > + } else {
> > + new_entry |= fault_ipa;
> > + new_entry |= VALID_ENTRY;
> > + }
> > +
> > + mas_set_range(&mas_rev, ipa, ipa_end);
> > + if (mas_store_gfp(&mas_rev, xa_mk_value(new_entry),
> > + GFP_NOWAIT | __GFP_ACCOUNT))
> > + mmu->nested_revmap_broken = true;
>
> I really think we ought to track this event happening. Maybe a trace
> point.
Will do.
>
> > +unlock:
> > + mtree_unlock(revmap_mt);
> > +}
> > +
> > void kvm_init_nested_s2_mmu(struct kvm_s2_mmu *mmu)
> > {
> > /* CnP being set denotes an invalid entry */
> > mmu->tlb_vttbr = VTTBR_CNP_BIT;
> > mmu->nested_stage2_enabled = false;
> > atomic_set(&mmu->refcnt, 0);
> > + mt_init(&mmu->nested_revmap_mt);
> > + mmu->nested_revmap_broken = false;
> > }
> >
> > void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu)
> > @@ -1150,6 +1210,82 @@ void kvm_nested_s2_wp(struct kvm *kvm)
> > kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
> > }
> >
> > +static void reset_revmap_and_unmap(struct kvm_s2_mmu *mmu, bool may_block)
> > +{
> > + mtree_destroy(&mmu->nested_revmap_mt);
> > + mmu->nested_revmap_broken = false;
> > + kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
> > +}
> > +
> > +static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
> > + size_t unmap_size, bool may_block)
>
> Same comment as above about the nature of 'gpa'. I *think* this is the
> L0 IPA, but please clarify.
Will use clearer names from now.
>
> > +{
> > + struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
> > + gpa_t ipa = gpa;
> > + gpa_t ipa_end = gpa + unmap_size - 1;
>
> Similar concerns about alignments.
For this function, I don't think there are any guarantees on alignment
for sizes > PAGE_SIZE, but I think if we make sure the range we unmap
completely covers the input range then things should be fine.
>
> > + u64 entry;
> > + size_t entry_size;
> > + MA_STATE(mas_rev, revmap_mt, gpa, ipa_end);
> > +
> > + if (mmu->nested_revmap_broken) {
> > + reset_revmap_and_unmap(mmu, may_block);
> > + return;
> > + }
> > +
> > + mtree_lock(revmap_mt);
> > + entry = xa_to_value(mas_find_range(&mas_rev, ipa_end));
> > +
> > + while (entry && mas_rev.index <= ipa_end) {
>
> I'm again concerned that the VALID bit is never checked.
>
> > + ipa = mas_rev.last + 1;
> > + entry_size = mas_rev.last - mas_rev.index + 1;
> > + /*
> > + * Give up and invalidate this s2 mmu if the unmap range
> > + * touches any UNKNOWN_IPA range.
> > + */
> > + if (entry & UNKNOWN_IPA) {
> > + mtree_unlock(revmap_mt);
> > + reset_revmap_and_unmap(mmu, may_block);
> > + return;
> > + }
> > +
> > + /*
> > + * Ignore result, it is okay if a reverse mapping erase
> > + * fails.
> > + */
> > + mas_store_gfp(&mas_rev, NULL, GFP_NOWAIT | __GFP_ACCOUNT);
> > +
> > + mtree_unlock(revmap_mt);
> > + kvm_stage2_unmap_range(mmu, entry & ADDR_MASK, entry_size,
> > + may_block);
> > + mtree_lock(revmap_mt);
> > + /*
> > + * Other maple tree operations during preemption could render
> > + * this ma_state invalid, so reset it.
> > + */
> > + mas_set_range(&mas_rev, ipa, ipa_end);
> > + entry = xa_to_value(mas_find_range(&mas_rev, ipa_end));
> > + }
> > + mtree_unlock(revmap_mt);
> > +}
> > +
> > +void kvm_unmap_gfn_range_nested(struct kvm *kvm, gpa_t gpa, size_t size,
> > + bool may_block)
> > +{
> > + int i;
> > +
> > + if (!kvm->arch.nested_mmus_size)
> > + return;
> > +
> > + for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
> > + struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
> > +
> > + if (kvm_s2_mmu_valid(mmu))
> > + unmap_mmu_ipa_range(mmu, gpa, size, may_block);
> > + }
> > +
> > + kvm_invalidate_vncr_ipa(kvm, gpa, gpa + size);
>
> I'm not overly fond of propagating the VNCR invalidation in all the S2
> manipulations. I understand why you are doing it here, but I think we
> need to have a better solution.
I agree. I think moving kvm_invalidate_vncr_ipa() up one level, to the
places where canonical IPA are being invalidated, is slightly more
sensible.
>
> Fundamentally, VNCR invalidation has nothing to do with S2. This
> really is a EL2 S1 thing. And given that you have a reverse map per
> s2_mmu, it would be easy enough to track VNCR TLBs through that.
>
> It doesn't have to be part of this patch, but that would be a good
> thing to disentangle as a subsequent patch.
I'll have a think, thanks!
Thanks,
Wei-Lin Chang
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: exynos990: Add CLK_GOUT_PERIS_TMU_SUB_PCLK
From: Peter Griffin @ 2026-06-29 10:37 UTC (permalink / raw)
To: Denzeel Oliva
Cc: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Conor Dooley, linux-samsung-soc, linux-clk,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260613-exynos990-peris-fix-v3-v3-1-2b230db78ae4@gmail.com>
On Sat, 13 Jun 2026 at 13:36, Denzeel Oliva <wachiturroxd150@gmail.com> wrote:
>
> Add the missing TMU_SUB_PCLK clock ID for the Exynos990 PERIS CMU.
>
> Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> include/dt-bindings/clock/samsung,exynos990.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/dt-bindings/clock/samsung,exynos990.h b/include/dt-bindings/clock/samsung,exynos990.h
> index 47540307cb52..c06f591d9d90 100644
> --- a/include/dt-bindings/clock/samsung,exynos990.h
> +++ b/include/dt-bindings/clock/samsung,exynos990.h
> @@ -434,5 +434,6 @@
> #define CLK_GOUT_PERIS_TMU_TOP_PCLK 17
> #define CLK_GOUT_PERIS_OTP_CON_BIRA_OSCCLK 18
> #define CLK_GOUT_PERIS_OTP_CON_TOP_OSCCLK 19
> +#define CLK_GOUT_PERIS_TMU_SUB_PCLK 20
>
> #endif
>
> --
> 2.54.0
>
^ permalink raw reply
* [PATCH 0/2] arm64: dts: rockchip: fix Li-Po overcharge on Powkiddy RGB10 Max 3 / X55
From: Juan Manuel @ 2026-06-29 10:32 UTC (permalink / raw)
To: macromorgan, heiko
Cc: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]
Hi Chris, Heiko,
While bringing up a couple of Powkiddy RK3566 handhelds I ran into a
battery problem that turns out to be in the device trees, and it has
already cost me two packs, so I'd like to get it fixed for everyone.
Both battery nodes charge the cell above its own declared full voltage:
rk3566-powkiddy-rk2023.dtsi (inherited by the RGB10 Max 3):
constant-charge-voltage-max-microvolt = 4250000 (4.25 V), but
voltage-max-design-microvolt and the ocv-capacity-table-0 100% point
are both 4172000 (4.172 V).
rk3566-powkiddy-x55.dts: constant-charge-voltage-max-microvolt =
4300000 (4.30 V), but voltage-max-design-microvolt and the
ocv-capacity-table-0 100% point are both 4138000 (4.138 V).
So the charger drives each cell ~80–160 mV past its own OCV-100% point
on every cycle. On a standard 4.2 V Li-Po that is an overcharge: it
raises the cell's internal resistance and kills the pack early. The
symptom is textbook — the pack reads a normal voltage/SoC while on the
charger but collapses under load and shuts the device off the moment
it's unplugged. I lost two packs to this before tracing it to the DT;
capping the charge voltage at 4.2 V (verified at the rk817 CHRG_OUT
register) stopped the damage, and a third, already-degraded pack
stabilised.
Patch 1 also corrects the RGB10 Max 3 design capacity: it ships a 4000
mAh cell but inherits the 3151 mAh value from rk2023.dtsi. I did this
as a per-board override so I don't touch the shared profile, which may
well be correct for the RGB30 and other rk2023 users.
One thing worth a look on your side: the shared
rk3566-powkiddy-rk2023.dtsi default itself (4.25 V against a 4.172 V
OCV-100% point) looks like it would overcharge any device using it,
not just the RGB10 Max 3 — but I only have the two units above to test
on, so I've kept the fix scoped to what I can verify.
Thanks a lot for all the handheld DT work; none of these devices would
run mainline without it.
Juan Manuel Lopez Carrillo
[-- Attachment #2: 0001-arm64-dts-rockchip-powkiddy-rgb10max3-fix-battery-pr.patch --]
[-- Type: text/x-patch, Size: 2109 bytes --]
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Juan Manuel Lopez Carrillo <juanmanuellopezcarrillo@gmail.com>
Date: Sun, 29 Jun 2026 12:00:00 +0200
Subject: [PATCH 1/2] arm64: dts: rockchip: powkiddy-rgb10max3: fix battery
profile
The Powkiddy RGB10 Max 3 ships with a 4000 mAh pack, but it inherits its
battery node from rk3566-powkiddy-rk2023.dtsi, which describes a 3151 mAh
cell and, more importantly, sets constant-charge-voltage-max-microvolt to
4250000 (4.25 V).
That charge voltage is above this pack's declared full voltage: the
inherited voltage-max-design-microvolt and the ocv-capacity-table-0 100%
point are both 4172000 (4.172 V). The charger therefore drives the cell
~78 mV past its own declared "full" on every cycle.
For a standard 4.2 V Li-Po this is an overcharge. It raises the cell's
internal resistance and kills the pack prematurely. The failure mode seen
in the field is characteristic: the pack reads a plausible voltage/SoC
while on the charger but collapses under load (and shuts the device off)
as soon as it is unplugged. Two packs were lost this way before the cause
was traced to the DT.
Override the node for this board with the correct 4000 mAh design capacity
and a safe 4.2 V charge ceiling, at/below the cell design max and the
OCV-100% point. The charge current limit (2 A = 0.5C) and the OCV curve
are left unchanged.
Signed-off-by: Juan Manuel Lopez Carrillo <juanmanuellopezcarrillo@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts
--- a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts
@@ -12,6 +12,11 @@
compatible = "powkiddy,rgb10max3", "rockchip,rk3566";
};
+&battery {
+ charge-full-design-microamp-hours = <4000000>;
+ constant-charge-voltage-max-microvolt = <4200000>;
+};
+
&bluetooth {
compatible = "realtek,rtl8723ds-bt";
};
--
2.43.0
[-- Attachment #3: 0002-arm64-dts-rockchip-powkiddy-x55-cap-battery-charge-4.patch --]
[-- Type: text/x-patch, Size: 1723 bytes --]
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Juan Manuel Lopez Carrillo <juanmanuellopezcarrillo@gmail.com>
Date: Sun, 29 Jun 2026 12:05:00 +0200
Subject: [PATCH 2/2] arm64: dts: rockchip: powkiddy-x55: cap battery charge
voltage at 4.2V
The x55 battery node sets constant-charge-voltage-max-microvolt to
4300000 (4.30 V), but the same node declares voltage-max-design-microvolt
and an ocv-capacity-table-0 100% point of 4138000 (4.138 V). The charger
therefore drives the pack ~162 mV above its own declared full voltage on
every cycle.
This overcharges the standard 4.2 V Li-Po, raising its internal resistance
and killing it early - it reads fine on the charger but collapses under
load once unplugged. Cap the charge voltage at the standard, safe 4.2 V.
Design capacity (4000 mAh) and charge current (2 A) are already correct.
Signed-off-by: Juan Manuel Lopez Carrillo <juanmanuellopezcarrillo@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3566-powkiddy-x55.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-x55.dts b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-x55.dts
--- a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-x55.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-x55.dts
@@ -77,7 +77,7 @@
charge-full-design-microamp-hours = <4000000>;
charge-term-current-microamp = <300000>;
constant-charge-current-max-microamp = <2000000>;
- constant-charge-voltage-max-microvolt = <4300000>;
+ constant-charge-voltage-max-microvolt = <4200000>;
factory-internal-resistance-micro-ohms = <91000>;
voltage-max-design-microvolt = <4138000>;
voltage-min-design-microvolt = <3400000>;
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Add bluetooth support to manta
From: Krzysztof Kozlowski @ 2026-06-29 10:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alim Akhtar,
Lukas Timmermann
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Alexandre Marquet
In-Reply-To: <178272778358.113362.3049339184584034398.b4-ty@b4>
On 29/06/2026 12:09, Krzysztof Kozlowski wrote:
>
> On Sun, 14 Jun 2026 22:16:35 +0200, Lukas Timmermann wrote:
>> Enable the bcm4330-bt device for manta boards on serial0.
>> Also adds the necessary pin definitions and interrupt handling for
>> wakeup.
>
> Applied, thanks!
>
> [1/1] ARM: dts: exynos: Add bluetooth support to manta
> https://git.kernel.org/krzk/linux/c/718b15471c2b13a4830e80efbb489c2a849060d1
>
And still incorrect DCO. Checkpatch tells you that, so please run it.
I fixed it up, although already after pushing so all builds will now
complain. That's super annoying. I will reject future patches which
ignore checkpatch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v14 0/7] Provide support for Trigger Generation Unit
From: Songwei.Chai @ 2026-06-29 10:17 UTC (permalink / raw)
To: Greg KH
Cc: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
suzuki.poulose, james.clark, krzk+dt, conor+dt, linux-kernel,
linux-arm-kernel, linux-arm-msm, coresight, devicetree
In-Reply-To: <2026062959-distaste-launder-e253@gregkh>
On 6/29/2026 12:22 PM, Greg KH wrote:
> On Mon, Jun 29, 2026 at 11:03:33AM +0800, Songwei.Chai wrote:
>> Hi Greg & Alexander,
>>
>> Apologies for interrupting again.
>>
>> As the TGU hardware plays an important role in Qualcomm tracing design, I
>> would greatly appreciate it if you could kindly take some time to review
>> this at your earliest convenience.
> The merge window _just_ closed, please give us a chance to catch up.
>
> Also, why us? Surely you have other reviewers for this code, right?
Hi Greg,
Understood, thanks for letting us know.
Regarding your question: since this introduces a new
drivers/hwtracing/qcom directory, there is no existing maintainer for it.
Given your scope (and Alexander's), we believe you are the most relevant
reviewers.
The reason for creating the qcom directory is as follows:
/We previously tried to upstream this driver under
drivers/hwtracing/coresight,/
/but it was not accepted as it is considered Qualcomm-specific and not
tightly/
/coupled with the CoreSight subsystem. Based on this feedback, we are
exploring/
/a dedicated drivers/hwtracing/qcom directory, similar to intel_th, to
better/
/support this and future Qualcomm hwtracing drivers./
More details can be found in “[PATCH v14 0/7] -- Why we are proposing this”.
Thanks,
Songwei
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH] arm64: Clarify ARM64_WORKAROUND_REPEAT_TLBI semantics
From: Mark Rutland @ 2026-06-29 10:09 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: catalin.marinas, mark.rutland, will
Will notes that the ARM64_WORKAROUND_REPEAT_TLBI name is potentially
misleading, and that it would be nice to rename that and add some
documentation. See:
https://lore.kernel.org/linux-arm-kernel/ajKn_Pt50CmOUrsP@willie-the-truck/
To that end, I've renamed the Kconfig symbol and hwcap from:
[CONFIG_]ARM64_WORKAROUND_REPEAT_TLBI
... to:
[CONFIG_]ARM64_WORKAROUND_REPEAT_TLBI_SYNC
... and I've added some rationale alongside the Kconfig. As the Kconfig
symbol isn't user selectable, the usual 'help' section won't appear in
menuconfig, so I've added this as a comment.
The rename was scripted with:
git grep -l REPEAT_TLBI | while read F; do
sed -i '{ s/WORKAROUND_REPEAT_TLBI\>/WORKAROUND_REPEAT_TLBI_SYNC/g }' $F;
done
Bikeshedding-wise, I considered a few names, including:
* ARM64_WORKAROUND_REPEAT_TLBI_SYNC
* ARM64_WORKAROUND_TLBI_REPEAT_SYNC
* ARM64_WORKAROUND_BROADCAST_TLBI_REPEAT_SYNC
... and I settled on ARM64_WORKAROUND_REPEAT_TLBI_SYNC to try keep
things simple, and to avoid unnecessary churn caused by moving
definitions to retain alphabetical order. I'm happy to defer to Will and
Catalin's preference.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/Kconfig | 34 +++++++++++++++++++++++++------
arch/arm64/include/asm/cpucaps.h | 4 ++--
arch/arm64/include/asm/tlbflush.h | 2 +-
arch/arm64/kernel/cpu_errata.c | 6 +++---
arch/arm64/tools/cpucaps | 2 +-
5 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b3afe0688919b..7571104215435 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -701,12 +701,34 @@ config ARM64_ERRATUM_1530923
If unsure, say Y.
-config ARM64_WORKAROUND_REPEAT_TLBI
+config ARM64_WORKAROUND_REPEAT_TLBI_SYNC
bool
+ # This workaround is (only) suitable for TLB invalidation errata where
+ # all of the following conditions are true:
+ #
+ # - The effects of the errata are only a loss of ordering/completion
+ # for explicit memory accesses when the TLBI is completed with a DSB.
+ # The removal of TLB entries is not affected.
+ #
+ # Note that architecturally, S2-only invalidation does not remove
+ # combined S1+S2 entries, and does not complete accesses translated
+ # via those S1+S2 entries. Consequently, where this condition holds,
+ # the errata do not affect S2-only invalidation.
+ #
+ # - The errata only affect broadcast TLB invalidation operations (e.g.
+ # TLBI VMALLE1IS), and do not affect local TLB invalidation
+ # operations (e.g. TLBI VMALLE1).
+ #
+ # - After any number of affected TLBI operations are completed with a
+ # DSB, the errata can be mitigated by executing a single arbitrary
+ # broadcast TLBI (which targets an arbitrary translation regime),
+ # followed by a DSB.
+ #
+ # For more rationale, see commit a8f78680ee6bf795.
config ARM64_ERRATUM_2441007
bool "Cortex-A55: Completion of affected memory accesses might not be guaranteed by completion of a TLBI (rare)"
- select ARM64_WORKAROUND_REPEAT_TLBI
+ select ARM64_WORKAROUND_REPEAT_TLBI_SYNC
help
This option adds a workaround for ARM Cortex-A55 erratum #2441007.
@@ -722,7 +744,7 @@ config ARM64_ERRATUM_2441007
config ARM64_ERRATUM_1286807
bool "Cortex-A76: Modification of the translation table for a virtual address might lead to read-after-read ordering violation (rare)"
- select ARM64_WORKAROUND_REPEAT_TLBI
+ select ARM64_WORKAROUND_REPEAT_TLBI_SYNC
help
This option adds a workaround for ARM Cortex-A76 erratum 1286807.
@@ -944,7 +966,7 @@ config ARM64_ERRATUM_2224489
config ARM64_ERRATUM_2441009
bool "Cortex-A510: Completion of affected memory accesses might not be guaranteed by completion of a TLBI (rare)"
- select ARM64_WORKAROUND_REPEAT_TLBI
+ select ARM64_WORKAROUND_REPEAT_TLBI_SYNC
help
This option adds a workaround for ARM Cortex-A510 erratum #2441009.
@@ -1156,7 +1178,7 @@ config ARM64_ERRATUM_4193714
config ARM64_ERRATUM_4118414
bool "Various: Completion of affected memory accesses might not be guaranteed by completion of a TLBI"
default y
- select ARM64_WORKAROUND_REPEAT_TLBI
+ select ARM64_WORKAROUND_REPEAT_TLBI_SYNC
help
This option adds a workaround for the following errata:
@@ -1340,7 +1362,7 @@ config QCOM_FALKOR_ERRATUM_1003
config QCOM_FALKOR_ERRATUM_1009
bool "Falkor E1009: Prematurely complete a DSB after a TLBI"
default y
- select ARM64_WORKAROUND_REPEAT_TLBI
+ select ARM64_WORKAROUND_REPEAT_TLBI_SYNC
help
On Falkor v1, the CPU may prematurely complete a DSB following a
TLBI xxIS invalidate maintenance operation. Repeat the TLBI operation
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 25c61cda901c5..76350b38f0d7a 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -60,8 +60,8 @@ cpucap_is_possible(const unsigned int cap)
return IS_ENABLED(CONFIG_CAVIUM_ERRATUM_23154);
case ARM64_WORKAROUND_DISABLE_CNP:
return IS_ENABLED(CONFIG_ARM64_WORKAROUND_DISABLE_CNP);
- case ARM64_WORKAROUND_REPEAT_TLBI:
- return IS_ENABLED(CONFIG_ARM64_WORKAROUND_REPEAT_TLBI);
+ case ARM64_WORKAROUND_REPEAT_TLBI_SYNC:
+ return IS_ENABLED(CONFIG_ARM64_WORKAROUND_REPEAT_TLBI_SYNC);
case ARM64_WORKAROUND_SPECULATIVE_SSBS:
return IS_ENABLED(CONFIG_ARM64_ERRATUM_3194386);
case ARM64_WORKAROUND_4193714:
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index d52ac8c17190d..bd68ca6df62ba 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -268,7 +268,7 @@ static inline void __tlbi_level(tlbi_op op, u64 addr, u32 level)
#define __repeat_tlbi_sync(op, arg...) \
do { \
- if (!alternative_has_cap_unlikely(ARM64_WORKAROUND_REPEAT_TLBI)) \
+ if (!alternative_has_cap_unlikely(ARM64_WORKAROUND_REPEAT_TLBI_SYNC)) \
break; \
__tlbi(op, ##arg); \
dsb(ish); \
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 1995e1198648e..685077d44ad17 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -309,7 +309,7 @@ static void cpu_enable_impdef_pmuv3_traps(const struct arm64_cpu_capabilities *_
sysreg_clear_set_s(SYS_HACR_EL2, 0, BIT(56));
}
-#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
+#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI_SYNC
static const struct arm64_cpu_capabilities arm64_repeat_tlbi_list[] = {
#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1009
{
@@ -733,10 +733,10 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
.match_list = qcom_erratum_1003_list,
},
#endif
-#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
+#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI_SYNC
{
.desc = "Broken broadcast TLBI completion",
- .capability = ARM64_WORKAROUND_REPEAT_TLBI,
+ .capability = ARM64_WORKAROUND_REPEAT_TLBI_SYNC,
.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
.matches = cpucap_multi_entry_cap_matches,
.match_list = arm64_repeat_tlbi_list,
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 9b85a84f6fd49..f8368e5d81a8e 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -124,7 +124,7 @@ WORKAROUND_DISABLE_CNP
WORKAROUND_PMUV3_IMPDEF_TRAPS
WORKAROUND_QCOM_FALKOR_E1003
WORKAROUND_QCOM_ORYON_CNTVOFF
-WORKAROUND_REPEAT_TLBI
+WORKAROUND_REPEAT_TLBI_SYNC
WORKAROUND_SPECULATIVE_AT
WORKAROUND_SPECULATIVE_SSBS
WORKAROUND_SPECULATIVE_UNPRIV_LOAD
--
2.30.2
^ permalink raw reply related
* Re: [PATCH] ARM: s3c: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files
From: Krzysztof Kozlowski @ 2026-06-29 10:09 UTC (permalink / raw)
To: Peter Griffin, linux-kernel, Thomas Huth
Cc: linux-samsung-soc, linux-arm-kernel, Alim Akhtar, Russell King
In-Reply-To: <20260619125827.215977-1-thuth@redhat.com>
On Fri, 19 Jun 2026 14:58:27 +0200, Thomas Huth wrote:
> 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.
>
> [...]
Applied, thanks!
[1/1] ARM: s3c: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files
https://git.kernel.org/krzk/linux/c/7b06ff772080919fdb194c95af6b1e3acb079b71
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Add bluetooth support to manta
From: Krzysztof Kozlowski @ 2026-06-29 10:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alim Akhtar,
Lukas Timmermann
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Alexandre Marquet
In-Reply-To: <20260614-manta-bluetooth-v2-1-52de06cabf9d@timmermann.space>
On Sun, 14 Jun 2026 22:16:35 +0200, Lukas Timmermann wrote:
> Enable the bcm4330-bt device for manta boards on serial0.
> Also adds the necessary pin definitions and interrupt handling for
> wakeup.
Applied, thanks!
[1/1] ARM: dts: exynos: Add bluetooth support to manta
https://git.kernel.org/krzk/linux/c/718b15471c2b13a4830e80efbb489c2a849060d1
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* Re: [PATCH v3] soc: samsung: exynos-pmu: fix of_node refcount leak in exynos_get_pmu_regmap()
From: Krzysztof Kozlowski @ 2026-06-29 10:09 UTC (permalink / raw)
To: Weigang He
Cc: Alim Akhtar, Marek Szyprowski, Tomasz Figa, linux-arm-kernel,
linux-samsung-soc, linux-kernel
In-Reply-To: <20260609143852.1783558-1-geoffreyhe2@gmail.com>
On Wed, 10 Jun 2026 00:38:52 +1000, Weigang He wrote:
> exynos_get_pmu_regmap() obtains a device_node via of_find_matching_node()
> and passes it to exynos_get_pmu_regmap_by_phandle(np, NULL). With
> propname == NULL the callee uses np directly and does not drop a
> reference, so the reference taken by of_find_matching_node() is leaked on
> every call -- including on each -EPROBE_DEFER retry of the only in-tree
> caller, exynos_retention_init() in the Exynos pinctrl driver.
>
> [...]
Applied, thanks!
[1/1] soc: samsung: exynos-pmu: fix of_node refcount leak in exynos_get_pmu_regmap()
https://git.kernel.org/krzk/linux/c/fa476d53edd24e8105faace04e881b9c4179738f
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox