* [PATCH v3 1/4] KVM: arm64: Expose PMMIR_EL1.SLOTS under strict PMUv3 UAPI
From: Congkai Tan @ 2026-07-22 20:26 UTC (permalink / raw)
To: Oliver Upton, kvmarm, linux-arm-kernel
Cc: Congkai Tan, Marc Zyngier, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Jonathan Corbet, Shuah Khan, Haris Okanovic, Geoff Blake,
Stanislav Spassov, kvm, linux-doc, linux-kselftest, linux-kernel
In-Reply-To: <20260722202702.4165917-1-congkai@amazon.com>
Introduce a new field pmmir_slots in struct kvm_arch to store
PMMIR_EL1.SLOTS. It only saves the actual hardware PMU value when
the VMM explicitly selects a PMU under KVM_ARM_VCPU_PMU_V3_STRICT.
Otherwise, it stays 0 after allocation.
Use this field to implement guest access, userspace get, and userspace
set for PMMIR_EL1:
- access_pmmir(): uses the value in kvm->arch.pmmir_slots directly. If
the VMM selected a PMU and KVM_ARM_VCPU_PMU_V3_STRICT is set, the guest
can correctly read the underlying core's SLOTS. Otherwise, it continues
to read 0 since the true SLOTS value can be nondeterministic.
- get_pmmir(): same as access_pmmir().
- set_pmmir(): only the SLOTS field is writable; a value setting any
other bit is rejected with -EINVAL, since get_pmmir() returns SLOTS
zero-extended. A value of 0 resets kvm->arch.pmmir_slots to 0 for
backward compatibility, as the register is RAZ in older KVM, a value
matching the current SLOTS is accepted as a no-op, and anything else is
rejected with -EINVAL. Once the VM has run PMMIR_EL1 is immutable, so a
mismatching write then returns -EBUSY.
The register is now exposed via KVM_GET_REG_LIST for PMUv3 vCPUs, so add
it to the get-reg-list selftest's PMU register list.
Signed-off-by: Congkai Tan <congkai@amazon.com>
Reviewed-by: Geoff Blake <blakgeof@amazon.com>
Reviewed-by: Haris Okanovic <harisokn@amazon.com>
Reviewed-by: Stanislav Spassov <stanspas@amazon.de>
Co-developed-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Oliver Upton <oupton@kernel.org>
---
arch/arm64/include/asm/kvm_host.h | 3 +
arch/arm64/include/uapi/asm/kvm.h | 1 +
arch/arm64/kvm/pmu-emul.c | 11 ++++
arch/arm64/kvm/sys_regs.c | 63 ++++++++++++++++++-
include/kvm/arm_pmu.h | 4 ++
.../selftests/kvm/arm64/get-reg-list.c | 1 +
6 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index bae2c4f92ef5..9e035d587970 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -387,6 +387,9 @@ struct kvm_arch {
/* Maximum number of counters for the guest */
u8 nr_pmu_counters;
+ /* PMMIR_EL1.SLOTS value exposed to the guest. */
+ u8 pmmir_slots;
+
/* Hypercall features firmware registers' descriptor */
struct kvm_smccc_features smccc_feat;
struct maple_tree smccc_filter;
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 1c13bfa2d38a..019e5e3d892e 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -106,6 +106,7 @@ struct kvm_regs {
#define KVM_ARM_VCPU_PTRAUTH_GENERIC 6 /* VCPU uses generic authentication */
#define KVM_ARM_VCPU_HAS_EL2 7 /* Support nested virtualization */
#define KVM_ARM_VCPU_HAS_EL2_E2H0 8 /* Limit NV support to E2H RES0 */
+#define KVM_ARM_VCPU_PMU_V3_STRICT 9 /* No default PMU creation */
struct kvm_vcpu_init {
__u32 target;
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index 98305bbfc095..7ac00423fa8d 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -1092,6 +1092,17 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
kvm_arm_set_pmu(kvm, arm_pmu);
cpumask_copy(kvm->arch.supported_cpus, &arm_pmu->supported_cpus);
+
+ /*
+ * Since a specific PMU is explicitly selected,
+ * PMMIR_EL1.SLOTS is deterministic to the guest.
+ * If KVM_ARM_VCPU_PMU_V3_STRICT is set, snapshot
+ * the value to allow the guest to read it.
+ */
+ if (kvm_vcpu_has_pmuv3_strict(vcpu))
+ kvm->arch.pmmir_slots =
+ FIELD_GET(ARMV8_PMU_SLOTS,
+ arm_pmu->reg_pmmir);
ret = 0;
break;
}
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 5d5c579d4579..4c6f608c4fe5 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1367,6 +1367,64 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool access_pmmir(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ if (p->is_write)
+ return write_to_read_only(vcpu, p, r);
+
+ /*
+ * If KVM_ARM_VCPU_PMU_V3_STRICT is set and PMU was explicitly
+ * selected, the underlying hardware SLOTS value was read into this
+ * field. Otherwise, it stays 0. All other PMMIR_EL1 fields are RAZ.
+ */
+ p->regval = FIELD_PREP(ARMV8_PMU_SLOTS, vcpu->kvm->arch.pmmir_slots);
+ return true;
+}
+
+static int get_pmmir(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
+ u64 *val)
+{
+ *val = FIELD_PREP(ARMV8_PMU_SLOTS, vcpu->kvm->arch.pmmir_slots);
+ return 0;
+}
+
+static int set_pmmir(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
+ u64 val)
+{
+ struct kvm *kvm = vcpu->kvm;
+ u8 slots = FIELD_GET(ARMV8_PMU_SLOTS, val);
+
+ /*
+ * Only the SLOTS field is exposed (get_pmmir returns just that field),
+ * so reject a write that sets any other bit rather than silently
+ * masking it.
+ */
+ if (val & ~(u64)ARMV8_PMU_SLOTS)
+ return -EINVAL;
+
+ guard(mutex)(&kvm->arch.config_lock);
+
+ /*
+ * Once the VM has started PMMIR_EL1 is immutable. Reject any write
+ * that does not match the current value.
+ */
+ if (kvm_vm_has_ran_once(kvm))
+ return slots == kvm->arch.pmmir_slots ? 0 : -EBUSY;
+
+ /*
+ * Only SLOTS = 0 is honored for backwards compatibility with the
+ * old RAZ behavior. Reject any non-zero write that does not match
+ * the current value.
+ */
+ if (!slots)
+ kvm->arch.pmmir_slots = 0;
+ else if (slots != kvm->arch.pmmir_slots)
+ return -EINVAL;
+
+ return 0;
+}
+
static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
@@ -3448,7 +3506,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ PMU_SYS_REG(PMINTENCLR_EL1),
.access = access_pminten, .reg = PMINTENSET_EL1,
.get_user = get_pmreg, .set_user = set_pmreg },
- { SYS_DESC(SYS_PMMIR_EL1), trap_raz_wi },
+ { PMU_SYS_REG(PMMIR_EL1), .access = access_pmmir, .reset = NULL,
+ .get_user = get_pmmir, .set_user = set_pmmir },
{ SYS_DESC(SYS_MAIR_EL1), access_vm_reg, reset_unknown, MAIR_EL1 },
{ SYS_DESC(SYS_PIRE0_EL1), NULL, reset_unknown, PIRE0_EL1,
@@ -4593,7 +4652,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ CP15_PMU_SYS_REG(HI, 0, 9, 14, 4), .access = access_pmceid },
{ CP15_PMU_SYS_REG(HI, 0, 9, 14, 5), .access = access_pmceid },
/* PMMIR */
- { CP15_PMU_SYS_REG(DIRECT, 0, 9, 14, 6), .access = trap_raz_wi },
+ { CP15_PMU_SYS_REG(DIRECT, 0, 9, 14, 6), .access = access_pmmir },
/* PRRR/MAIR0 */
{ AA32(LO), Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, MAIR_EL1 },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index b5e5942204fc..6b4a118d17ca 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -75,6 +75,9 @@ void kvm_vcpu_pmu_resync_el0(void);
#define kvm_vcpu_has_pmu(vcpu) \
(vcpu_has_feature(vcpu, KVM_ARM_VCPU_PMU_V3))
+#define kvm_vcpu_has_pmuv3_strict(vcpu) \
+ (vcpu_has_feature(vcpu, KVM_ARM_VCPU_PMU_V3_STRICT))
+
/*
* Updates the vcpu's view of the pmu events for this cpu.
* Must be called before every vcpu run after disabling interrupts, to ensure
@@ -160,6 +163,7 @@ static inline u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
}
#define kvm_vcpu_has_pmu(vcpu) ({ false; })
+#define kvm_vcpu_has_pmuv3_strict(vcpu) ({ false; })
static inline void kvm_pmu_update_vcpu_events(struct kvm_vcpu *vcpu) {}
static inline void kvm_vcpu_pmu_restore_guest(struct kvm_vcpu *vcpu) {}
static inline void kvm_vcpu_pmu_restore_host(struct kvm_vcpu *vcpu) {}
diff --git a/tools/testing/selftests/kvm/arm64/get-reg-list.c b/tools/testing/selftests/kvm/arm64/get-reg-list.c
index 0a3a94c4cca1..cfa99979d57c 100644
--- a/tools/testing/selftests/kvm/arm64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/arm64/get-reg-list.c
@@ -532,6 +532,7 @@ static __u64 base_regs[] = {
static __u64 pmu_regs[] = {
ARM64_SYS_REG(3, 0, 9, 14, 1), /* PMINTENSET_EL1 */
ARM64_SYS_REG(3, 0, 9, 14, 2), /* PMINTENCLR_EL1 */
+ ARM64_SYS_REG(3, 0, 9, 14, 6), /* PMMIR_EL1 */
ARM64_SYS_REG(3, 3, 9, 12, 0), /* PMCR_EL0 */
ARM64_SYS_REG(3, 3, 9, 12, 1), /* PMCNTENSET_EL0 */
ARM64_SYS_REG(3, 3, 9, 12, 2), /* PMCNTENCLR_EL0 */
--
2.50.1
^ permalink raw reply related
* [PATCH v3 2/4] KVM: arm64: Advertise STALL_SLOT* in PMCEID1 under strict PMUv3 UAPI
From: Congkai Tan @ 2026-07-22 20:27 UTC (permalink / raw)
To: Oliver Upton, kvmarm, linux-arm-kernel
Cc: Congkai Tan, Marc Zyngier, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Jonathan Corbet, Shuah Khan, Haris Okanovic, Geoff Blake,
Stanislav Spassov, kvm, linux-doc, linux-kselftest, linux-kernel
In-Reply-To: <20260722202702.4165917-1-congkai@amazon.com>
Skip masking STALL_SLOT, STALL_SLOT_FRONTEND and STALL_SLOT_BACKEND out
of PMCEID1 when KVM_ARM_VCPU_PMU_V3_STRICT is set, because this is when
PMMIR_EL1.SLOTS is exposed to guests, making these events meaningful for
collection.
Change the parameter of compute_pmceid1() from arm_pmu to kvm_vcpu, to
check if KVM_ARM_VCPU_PMU_V3_STRICT is set. Also updated the signature of
compute_pmceid0() for consistency.
Signed-off-by: Congkai Tan <congkai@amazon.com>
Reviewed-by: Geoff Blake <blakgeof@amazon.com>
Reviewed-by: Haris Okanovic <harisokn@amazon.com>
Reviewed-by: Stanislav Spassov <stanspas@amazon.de>
---
arch/arm64/kvm/pmu-emul.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index 7ac00423fa8d..bcfd0a91e114 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -838,9 +838,9 @@ static u64 __compute_pmceid(struct arm_pmu *pmu, bool pmceid1)
return ((u64)hi[pmceid1] << 32) | lo[pmceid1];
}
-static u64 compute_pmceid0(struct arm_pmu *pmu)
+static u64 compute_pmceid0(struct kvm_vcpu *vcpu)
{
- u64 val = __compute_pmceid(pmu, 0);
+ u64 val = __compute_pmceid(vcpu->kvm->arch.arm_pmu, 0);
/* always support SW_INCR */
val |= BIT(ARMV8_PMUV3_PERFCTR_SW_INCR);
@@ -849,32 +849,33 @@ static u64 compute_pmceid0(struct arm_pmu *pmu)
return val;
}
-static u64 compute_pmceid1(struct arm_pmu *pmu)
+static u64 compute_pmceid1(struct kvm_vcpu *vcpu)
{
- u64 val = __compute_pmceid(pmu, 1);
+ u64 val = __compute_pmceid(vcpu->kvm->arch.arm_pmu, 1);
/*
- * Don't advertise STALL_SLOT*, as PMMIR_EL0 is handled
- * as RAZ
+ * If KVM_ARM_VCPU_PMU_V3_STRICT is not set, PMMIR_EL1 is
+ * unconditionally RAZ, so don't advertise STALL_SLOT* events.
*/
- val &= ~(BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT - 32) |
- BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT_FRONTEND - 32) |
- BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT_BACKEND - 32));
+ if (!kvm_vcpu_has_pmuv3_strict(vcpu))
+ val &= ~(BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT - 32) |
+ BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT_FRONTEND - 32) |
+ BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT_BACKEND - 32));
+
return val;
}
u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
{
- struct arm_pmu *cpu_pmu = vcpu->kvm->arch.arm_pmu;
unsigned long *bmap = vcpu->kvm->arch.pmu_filter;
u64 val, mask = 0;
int base, i, nr_events;
if (!pmceid1) {
- val = compute_pmceid0(cpu_pmu);
+ val = compute_pmceid0(vcpu);
base = 0;
} else {
- val = compute_pmceid1(cpu_pmu);
+ val = compute_pmceid1(vcpu);
base = 32;
}
--
2.50.1
^ permalink raw reply related
* [PATCH v3 0/4] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests
From: Congkai Tan @ 2026-07-22 20:26 UTC (permalink / raw)
To: Oliver Upton, kvmarm, linux-arm-kernel
Cc: Congkai Tan, Marc Zyngier, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Jonathan Corbet, Shuah Khan, Haris Okanovic, Geoff Blake,
Stanislav Spassov, kvm, linux-doc, linux-kselftest, linux-kernel
Today when the perf tool runs in a guest on cores with PMUv3p4, it fails
to parse the default metrics with "Failure to read '#slots'", since perf
can only read 0 from sysfs caps/slots, which is backed by PMMIR_EL1.SLOTS
that KVM traps as RAZ/WI.
Taking into account backward compatibility and heterogeneous systems, the
exposure of PMMIR_EL1.SLOTS is gated behind a new vCPU feature flag:
- Patch 1 exposes PMMIR_EL1.SLOTS of the selected PMU under the (as yet
unsettable) KVM_ARM_VCPU_PMU_V3_STRICT flag, and adds userspace get/set
for PMMIR_EL1 so that SLOTS can be reset to 0 for backward
compatibility.
- Patch 2 stops masking STALL_SLOT* in PMCEID1 under the flag.
- Patch 3 makes strict-mode userspace configure the number of event
counters via the KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS attribute rather
than PMCR_EL0.N, whose meaning is context-dependent under NV.
- Patch 4 adds the KVM_ARM_VCPU_PMU_V3_STRICT flag itself: when set, KVM
does not create a default PMU during vCPU init, and the VMM must select
one explicitly via KVM_ARM_VCPU_PMU_V3_SET_PMU before the first
KVM_RUN. This flips the gate on and can serve as an umbrella flag for
future PMUv3 UAPI changes.
When the flag is not set, behaviors are unchanged.
v2: https://lore.kernel.org/r/20260702190421.420992-1-congkai@amazon.com
v1: https://lore.kernel.org/r/20260601193954.2103455-1-congkai@amazon.com
v2 -> v3 changes:
- Reordered so the KVM_ARM_VCPU_PMU_V3_STRICT flag / KVM_CAP exposure
comes last (now patch 4), after the flag-guarded behavior patches.
- Reworked on top of Oliver Upton's refinements (thanks!):
* Move the NULL-arm_pmu check into kvm_arm_pmu_v3_init() (returns
-ENXIO) instead of failing at the first KVM_RUN, and report zero
counters from kvm_arm_pmu_get_max_counters() before a PMU is set.
* Documentation and -ENXIO ordering notes for the PMU device
attributes (SET_PMU must precede INIT/FILTER).
- New patch (Oliver): ignore userspace writes to PMCR_EL0.N under the
strict flag and require the KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS
attribute, since PMCR_EL0.N is context-dependent under NV.
- Advertise the KVM_CAP_ARM_PMU_V3_STRICT capability.
- Documentation fixes in api.rst (the flag Requires KVM_ARM_VCPU_PMU_V3).
Congkai Tan (3):
KVM: arm64: Expose PMMIR_EL1.SLOTS under strict PMUv3 UAPI
KVM: arm64: Advertise STALL_SLOT* in PMCEID1 under strict PMUv3 UAPI
KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_STRICT vCPU feature
Oliver Upton (1):
KVM: arm64: Ignore writes to PMCR_EL0.N when using strict UAPI
Documentation/virt/kvm/api.rst | 11 ++++
Documentation/virt/kvm/devices/vcpu.rst | 11 +++-
arch/arm64/include/asm/kvm_host.h | 5 +-
arch/arm64/include/uapi/asm/kvm.h | 1 +
arch/arm64/kvm/arm.c | 19 ++++--
arch/arm64/kvm/pmu-emul.c | 54 ++++++++++++----
arch/arm64/kvm/sys_regs.c | 64 ++++++++++++++++++-
include/kvm/arm_pmu.h | 4 ++
include/uapi/linux/kvm.h | 1 +
.../selftests/kvm/arm64/get-reg-list.c | 1 +
10 files changed, 149 insertions(+), 22 deletions(-)
base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
--
2.50.1
^ permalink raw reply
* Re: [PATCH v7 08/11] KVM: TDX: Get/put PAMT pages when (un)mapping private memory
From: Edgecombe, Rick P @ 2026-07-22 19:51 UTC (permalink / raw)
To: seanjc@google.com
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Huang, Kai,
Hansen, Dave, Zhao, Yan Y, linux-kernel@vger.kernel.org,
Wu, Binbin, kas@kernel.org, mingo@redhat.com,
binbin.wu@linux.intel.com, pbonzini@redhat.com,
nik.borisov@suse.com, linux-doc@vger.kernel.org, hpa@zytor.com,
tglx@kernel.org, Annapurve, Vishal, bp@alien8.de,
tony.lindgren@linux.intel.com, Gao, Chao, x86@kernel.org
In-Reply-To: <amEbS6WDEyrvW72Q@google.com>
On Wed, 2026-07-22 at 12:34 -0700, Sean Christopherson wrote:
> Maybe put it in code? E.g.
>
> /*
> * Minus one page to exclude the root SPT, but plus one page for a
> * possible 4KiB private mapping.
> */
> min_nr_spts += -1 + 1;
>
> return tdx_topup_pamt_cache(&to_tdx(vcpu)->pamt_cache, min_nr_spts);
Haha, yea. I felt too silly writing that code. But I'm ok. This has definitely
had enough confusion over the versions to warrant something.
^ permalink raw reply
* Re: [PATCH v7 08/11] KVM: TDX: Get/put PAMT pages when (un)mapping private memory
From: Sean Christopherson @ 2026-07-22 19:41 UTC (permalink / raw)
To: Rick Edgecombe
Cc: bp, dave.hansen, hpa, kas, kvm, linux-coco, linux-doc,
linux-kernel, mingo, nik.borisov, pbonzini, tglx, vannapurve, x86,
chao.gao, yan.y.zhao, kai.huang, tony.lindgren, binbin.wu,
Binbin Wu
In-Reply-To: <20260718014500.2231262-9-rick.p.edgecombe@intel.com>
On Fri, Jul 17, 2026, Rick Edgecombe wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>
> Add Dynamic PAMT support to KVM's S-EPT MMU by "getting" a PAMT page when
> adding guest memory (PAGE.ADD or PAGE.AUG), and "putting" the page when
> removing guest memory (PAGE.REMOVE).
>
> To access the per-vCPU PAMT caches without plumbing @vcpu throughout the
> TDP MMU, begrudgingly use kvm_get_running_vcpu() to get the vCPU, and bug
> the VM if KVM attempts to set an S-EPT leaf without an active vCPU. KVM
> only supports creating _new_ mappings in page (pre)fault paths, all of
> which require an active vCPU.
>
> The PAMT memory holds metadata for TDX protected memory. With Dynamic
> PAMT, PAMT_4K is allocated on demand. The kernel supplies the TDX module
> with a few pages that cover 2MB of host physical memory.
>
> Releases are balanced via tdx_pamt_put(): every control-page free goes
> through tdx_free_control_page(), and guest data pages are put directly on
> the successful tdh_mem_page_remove() path and in the
> tdx_mem_page_add/aug() error path.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> [rick: enhance log, reviewing, rebase, with help from AI tooling]
> Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
> ---
With the nits fixed,
Acked-by: Sean Christopherson <seanjc@google.com>
^ permalink raw reply
* Re: [PATCH v4 1/1] Documentation: real-time: Add kernel configuration guide
From: Ahmed S. Darwish @ 2026-07-22 19:40 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Jonathan Corbet, Clark Williams, Steven Rostedt, linux-rt-devel,
Matthew Wilcox, John Ogness, Derek Barbosa, linux-doc,
linux-kernel
In-Reply-To: <20260721130248.ndwsFtHE@linutronix.de>
On Tue, 21 Jul 2026, Sebastian Andrzej Siewior wrote:
>
> On 2026-07-16 21:57:14 [+0200], Ahmed S. Darwish wrote:
> > +``CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE``
> > +-------------------------------------------
> > +
> > +:Expectation: enabled
> > +:Severity: *high*
> > +
> > +Real-Time workloads expect a fixed CPU frequency during execution. Using
> > +the performance governor is an easy way to achieve that purely from kernel
> > +configuration.
> > +
> > +This is not a blanket rule. Some setups might prefer to clock the CPU to
> > +lower speeds due to thermal packaging or other requirements. The key is
> > +that the CPU frequency remains constant once set.
>
> A dynamic governor such as CONFIG_CPU_FREQ_GOV_POWERSAVE must be
> avoided.
>
ACK.
>
> > …
> > +
> > +- :doc:`Regarding hardware (System memory and cache) </core-api/real-time/hardware>`
> > +- :doc:`/filesystems/resctrl`>
>
> I've been told by Jonathan to avoid this and just use plain file
> references such as
> - Documentation/admin-guide/pm/cpuidle.rst
> - Documentation/admin-guide/pm/index.rst
>
ACK.
> > +- `Real-Time and Graphics: A Contradiction?`_
>
> And this might be included inline, too.
>
> > +``CONFIG_TRACING`` (and tracing options)
> > +----------------------------------------
> > +
> > +:Expectation: enabled
> > +:Severity: *info*
> > +
> > +Shipping kernels with tracing support enabled (but not actively running) is
> > +highly recommended. This will allow the users to extract more information
> > +if latency problems arise. Nonetheless, some tracers do incur latency
> > +overhead by just being enabled; see :ref:`tracers`.
>
> Instead of this jumping forth and back while reading, couldn't the
> CONFIG_IRQSOFF_TRACER and CONFIG_PREEMPT_TRACER be added here?
>
I'll think of something.
> >
> > +Non-performance CPU frequency governors
> > +---------------------------------------
>
> so here it is.
> > …
> > …
>
> Could we please merge this in the previous section so that we don't have
> two times the CPU frequency governors.
>
OK.
>
> Could we merge the caution box from before here somehow? The statement
> is that lockdep is very helpful in validating lockchains and so on
> especially on paths which are only seen if the real-time workload is
> active. However, since it can easily introduce scheduling latencies of
> 10ms it is hardly an option that ca be enabled in production.
>
I'll think of something.
> > +
> > +``CONFIG_DEBUG_FS``
> > +^^^^^^^^^^^^^^^^^^^
> > +
> > +This is safe to include in real-time kernels, *provided that debugfs is
> > +not accessed during production runtime*.
>
> It is safe to have as long as you don't use it.
which is what I said above.
>
> I would drop it.
>
Well, earlier I stated that debug options need to be disabled for a
real-time kernel, except the explicitly list debug options which are deemed
OK. So I need to mention that CONFIG_DEBUG_FS is deemed OK. The list
above is not saying, "enable it for RT". It rather says, "if you need it,
it's not problematic for RT."
>
> > +
> > +``CONFIG_DEBUG_KERNEL``
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Meta-option which allows debug features to be enabled. This configuration
> > +option has no runtime impact, but be aware of any debug features that it
> > +may have allowed to be enabled.
>
> This one should come first (if at all) because it enables to access of
> few of the options mentioned in this section.
>
All the options are alphabetically listed, so that the 3-level table of
contents on top (which lists all options) is clear and users cannot miss anything.
I'll think about this.
Thanks,
Ahmed
^ permalink raw reply
* Re: [PATCH v7 06/11] KVM: TDX: Allocate PAMT memory for TD and vCPU control structures
From: Sean Christopherson @ 2026-07-22 19:40 UTC (permalink / raw)
To: Rick Edgecombe
Cc: bp, dave.hansen, hpa, kas, kvm, linux-coco, linux-doc,
linux-kernel, mingo, nik.borisov, pbonzini, tglx, vannapurve, x86,
chao.gao, yan.y.zhao, kai.huang, tony.lindgren, binbin.wu,
Binbin Wu
In-Reply-To: <20260718014500.2231262-7-rick.p.edgecombe@intel.com>
On Fri, Jul 17, 2026, Rick Edgecombe wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>
> Use control page helpers for allocating and freeing TD control structures,
> such that these operations can work for Dynamic PAMT.
>
> The TDX module tracks some state for each page of physical memory that it
> might use. It calls this state the PAMT. It includes separate state for
> each page size a physical page could be utilized at within the TDX module
> (1GB, 2MB, 4KB). In Dynamic PAMT, only the 4KB page size state is
> allocated dynamically. So the kernel must ensure PAMT backing is installed
> for any 4KB page being gifted to the TDX module, and must tear down the
> backing when all associated gifted pages are reclaimed.
>
> TD scoped control pages (TDR, TDCS) and vCPU scoped control pages (TDVPR,
> TDCX) are all handed to the TDX module at 4KB page size and are therefore
> subject to this requirement. Replace the raw alloc_page()/__free_page()
> calls for these pages with tdx_alloc/free_control_page().
>
> Switching between special Dynamic PAMT operations or normal page
> alloc/free operations is handled internally in
> tdx_alloc/free_control_page(). So don't check for Dynamic PAMT around these
> calls. Just call them unconditionally. Similarly, drop the NULL checks
> before freeing, as tdx_free_control_page() handles NULL internally.
>
> No functional change intended when Dynamic PAMT is not in use.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> [sean: handle alloc+free+reclaim in one patch]
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> [rick: enhance log, reviewing, rebase, with help from AI tooling]
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
> Reviewed-by: Yan Zhao <yan.y.zhao@intel.com>
> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
> ---
Acked-by: Sean Christopherson <seanjc@google.com>
^ permalink raw reply
* Re: [PATCH v7 08/11] KVM: TDX: Get/put PAMT pages when (un)mapping private memory
From: Sean Christopherson @ 2026-07-22 19:34 UTC (permalink / raw)
To: Rick P Edgecombe
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Kai Huang,
Dave Hansen, Yan Y Zhao, tony.lindgren@linux.intel.com, Binbin Wu,
kas@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, nik.borisov@suse.com,
linux-doc@vger.kernel.org, hpa@zytor.com, tglx@kernel.org,
Vishal Annapurve, bp@alien8.de, Chao Gao, x86@kernel.org,
binbin.wu@linux.intel.com
In-Reply-To: <4ad035a82ee10dc4645e26a4bd1daf40786a743a.camel@intel.com>
On Wed, Jul 22, 2026, Rick P Edgecombe wrote:
> On Wed, 2026-07-22 at 16:46 +0300, Nikolay Borisov wrote:
> > > +static int tdx_topup_external_pamt_cache(struct kvm_vcpu *vcpu, int
> > > min_nr_spts)
> > > +{
> > > + /*
> > > + * Don't cover the root SPT, but cover a possible 4KB private
> > > + * page in addition to the SPTs. So -1 to exclude the root
> > > + * SPT, and +1 for the guest page cancel out.
> > > + */
> >
> > That comment here doesn't seem to correspond to the code in anyway.
> > There are no +-1 adjustments.
>
> The +1 and -1 cancel each other out. Hmm, how about:
> /*
> * Don't cover the root SPT, but cover a possible 4KB private
> * page in addition to the SPTs. The -1 to exclude the root
> * SPT and +1 for the guest page cancel each other out. So
> * make no adjustments.
> */
Maybe put it in code? E.g.
/*
* Minus one page to exclude the root SPT, but plus one page for a
* possible 4KiB private mapping.
*/
min_nr_spts += -1 + 1;
return tdx_topup_pamt_cache(&to_tdx(vcpu)->pamt_cache, min_nr_spts);
^ permalink raw reply
* Re: [PATCH v7 08/11] KVM: TDX: Get/put PAMT pages when (un)mapping private memory
From: Edgecombe, Rick P @ 2026-07-22 19:20 UTC (permalink / raw)
To: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Huang, Kai,
Hansen, Dave, Zhao, Yan Y, tony.lindgren@linux.intel.com,
Wu, Binbin, kas@kernel.org, seanjc@google.com, mingo@redhat.com,
linux-kernel@vger.kernel.org, pbonzini@redhat.com,
nik.borisov@suse.com, linux-doc@vger.kernel.org, hpa@zytor.com,
tglx@kernel.org, Annapurve, Vishal, bp@alien8.de, Gao, Chao,
x86@kernel.org
Cc: binbin.wu@linux.intel.com
In-Reply-To: <20900cd6-6d05-4a20-a21d-2a1d4a6ef5e5@suse.com>
On Wed, 2026-07-22 at 16:46 +0300, Nikolay Borisov wrote:
> > +static int tdx_topup_external_pamt_cache(struct kvm_vcpu *vcpu, int
> > min_nr_spts)
> > +{
> > + /*
> > + * Don't cover the root SPT, but cover a possible 4KB private
> > + * page in addition to the SPTs. So -1 to exclude the root
> > + * SPT, and +1 for the guest page cancel out.
> > + */
>
> That comment here doesn't seem to correspond to the code in anyway.
> There are no +-1 adjustments.
The +1 and -1 cancel each other out. Hmm, how about:
/*
* Don't cover the root SPT, but cover a possible 4KB private
* page in addition to the SPTs. The -1 to exclude the root
* SPT and +1 for the guest page cancel each other out. So
* make no adjustments.
*/
And thanks for the RB tags!
> > + return tdx_topup_pamt_cache(&to_tdx(vcpu)->pamt_cache,
> > min_nr_spts);
^ permalink raw reply
* [RFT PATCH v2] hwmon: Add support for currX_emergency and inX_emergency attributes
From: Guenter Roeck @ 2026-07-22 19:20 UTC (permalink / raw)
To: Hardware Monitoring
Cc: linux-doc, Guenter Roeck, Manaf Meethalavalappu Pallikunhi
Some hardware monitoring chips support three alarm levels for current and
voltage measurements. Add support for currX_emergency and inX_emergency
attributes to support such chips.
Cc: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v2: Also add emergency alarm attributes, and drop stray What: entry from
documentation.
Documentation/ABI/testing/sysfs-class-hwmon | 24 +++++++++++++++++++++
Documentation/hwmon/sysfs-interface.rst | 8 +++++++
drivers/hwmon/hwmon.c | 4 ++++
include/linux/hwmon.h | 8 +++++++
4 files changed, 44 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon
index b185bdfc7186..24937054f0c0 100644
--- a/Documentation/ABI/testing/sysfs-class-hwmon
+++ b/Documentation/ABI/testing/sysfs-class-hwmon
@@ -81,6 +81,18 @@ Description:
take drastic action such as power down or reset. At the very
least, it should report a fault.
+What: /sys/class/hwmon/hwmonX/inY_emergency
+Description:
+ Voltage emergency max value.
+
+ Unit: millivolt
+
+ RW
+
+ If voltage reaches or exceeds this limit, the system is expected
+ to take drastic action such as immediate power down or reset.
+ At the very least, it should report a fault.
+
What: /sys/class/hwmon/hwmonX/inY_input
Description:
Voltage input value.
@@ -647,6 +659,18 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/currY_emergency
+Description:
+ Current emergency high value.
+
+ Unit: milliampere
+
+ RW
+
+ If a current reaches or exceeds this limit, the system is
+ expected to take drastic action such as immediate power down
+ or reset. At the very least, it should report a fault.
+
What: /sys/class/hwmon/hwmonX/currY_input
Description:
Current input value
diff --git a/Documentation/hwmon/sysfs-interface.rst b/Documentation/hwmon/sysfs-interface.rst
index 94e1bbce172a..47faca56a979 100644
--- a/Documentation/hwmon/sysfs-interface.rst
+++ b/Documentation/hwmon/sysfs-interface.rst
@@ -127,6 +127,9 @@ Voltages
`in[0-*]_crit`
Voltage critical max value.
+`in[0-*]_emergency`
+ Voltage emergency max value.
+
`in[0-*]_input`
Voltage input value.
@@ -332,6 +335,9 @@ Currents
`curr[1-*]_crit`
Current critical high value.
+`curr[1-*]_emergency`
+ Current emergency high value.
+
`curr[1-*]_input`
Current input value.
@@ -529,10 +535,12 @@ implementation.
| `in[0-*]_max_alarm`, | |
| `in[0-*]_lcrit_alarm`, | - 0: no alarm |
| `in[0-*]_crit_alarm`, | - 1: alarm |
+| `in[0-*]_emergency_alarm`, | |
| `curr[1-*]_min_alarm`, | |
| `curr[1-*]_max_alarm`, | RO |
| `curr[1-*]_lcrit_alarm`, | |
| `curr[1-*]_crit_alarm`, | |
+| `curr[1-*]_emergency_alarm`, | |
| `power[1-*]_cap_alarm`, | |
| `power[1-*]_max_alarm`, | |
| `power[1-*]_crit_alarm`, | |
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index 55a9a3ddd4aa..91a43fc35532 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -621,6 +621,7 @@ static const char * const hwmon_in_attr_templates[] = {
[hwmon_in_max] = "in%d_max",
[hwmon_in_lcrit] = "in%d_lcrit",
[hwmon_in_crit] = "in%d_crit",
+ [hwmon_in_emergency] = "in%d_emergency",
[hwmon_in_average] = "in%d_average",
[hwmon_in_lowest] = "in%d_lowest",
[hwmon_in_highest] = "in%d_highest",
@@ -631,6 +632,7 @@ static const char * const hwmon_in_attr_templates[] = {
[hwmon_in_max_alarm] = "in%d_max_alarm",
[hwmon_in_lcrit_alarm] = "in%d_lcrit_alarm",
[hwmon_in_crit_alarm] = "in%d_crit_alarm",
+ [hwmon_in_emergency_alarm] = "in%d_emergency_alarm",
[hwmon_in_rated_min] = "in%d_rated_min",
[hwmon_in_rated_max] = "in%d_rated_max",
[hwmon_in_beep] = "in%d_beep",
@@ -644,6 +646,7 @@ static const char * const hwmon_curr_attr_templates[] = {
[hwmon_curr_max] = "curr%d_max",
[hwmon_curr_lcrit] = "curr%d_lcrit",
[hwmon_curr_crit] = "curr%d_crit",
+ [hwmon_curr_emergency] = "curr%d_emergency",
[hwmon_curr_average] = "curr%d_average",
[hwmon_curr_lowest] = "curr%d_lowest",
[hwmon_curr_highest] = "curr%d_highest",
@@ -654,6 +657,7 @@ static const char * const hwmon_curr_attr_templates[] = {
[hwmon_curr_max_alarm] = "curr%d_max_alarm",
[hwmon_curr_lcrit_alarm] = "curr%d_lcrit_alarm",
[hwmon_curr_crit_alarm] = "curr%d_crit_alarm",
+ [hwmon_curr_emergency_alarm] = "curr%d_emergency_alarm",
[hwmon_curr_rated_min] = "curr%d_rated_min",
[hwmon_curr_rated_max] = "curr%d_rated_max",
[hwmon_curr_beep] = "curr%d_beep",
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index 77a6f2bffcba..9ebd482a42db 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -134,6 +134,7 @@ enum hwmon_in_attributes {
hwmon_in_max,
hwmon_in_lcrit,
hwmon_in_crit,
+ hwmon_in_emergency,
hwmon_in_average,
hwmon_in_lowest,
hwmon_in_highest,
@@ -144,6 +145,7 @@ enum hwmon_in_attributes {
hwmon_in_max_alarm,
hwmon_in_lcrit_alarm,
hwmon_in_crit_alarm,
+ hwmon_in_emergency_alarm,
hwmon_in_rated_min,
hwmon_in_rated_max,
hwmon_in_beep,
@@ -156,6 +158,7 @@ enum hwmon_in_attributes {
#define HWMON_I_MAX BIT(hwmon_in_max)
#define HWMON_I_LCRIT BIT(hwmon_in_lcrit)
#define HWMON_I_CRIT BIT(hwmon_in_crit)
+#define HWMON_I_EMERGENCY BIT(hwmon_in_emergency)
#define HWMON_I_AVERAGE BIT(hwmon_in_average)
#define HWMON_I_LOWEST BIT(hwmon_in_lowest)
#define HWMON_I_HIGHEST BIT(hwmon_in_highest)
@@ -166,6 +169,7 @@ enum hwmon_in_attributes {
#define HWMON_I_MAX_ALARM BIT(hwmon_in_max_alarm)
#define HWMON_I_LCRIT_ALARM BIT(hwmon_in_lcrit_alarm)
#define HWMON_I_CRIT_ALARM BIT(hwmon_in_crit_alarm)
+#define HWMON_I_EMERGENCY_ALARM BIT(hwmon_in_emergency_alarm)
#define HWMON_I_RATED_MIN BIT(hwmon_in_rated_min)
#define HWMON_I_RATED_MAX BIT(hwmon_in_rated_max)
#define HWMON_I_BEEP BIT(hwmon_in_beep)
@@ -178,6 +182,7 @@ enum hwmon_curr_attributes {
hwmon_curr_max,
hwmon_curr_lcrit,
hwmon_curr_crit,
+ hwmon_curr_emergency,
hwmon_curr_average,
hwmon_curr_lowest,
hwmon_curr_highest,
@@ -188,6 +193,7 @@ enum hwmon_curr_attributes {
hwmon_curr_max_alarm,
hwmon_curr_lcrit_alarm,
hwmon_curr_crit_alarm,
+ hwmon_curr_emergency_alarm,
hwmon_curr_rated_min,
hwmon_curr_rated_max,
hwmon_curr_beep,
@@ -199,6 +205,7 @@ enum hwmon_curr_attributes {
#define HWMON_C_MAX BIT(hwmon_curr_max)
#define HWMON_C_LCRIT BIT(hwmon_curr_lcrit)
#define HWMON_C_CRIT BIT(hwmon_curr_crit)
+#define HWMON_C_EMERGENCY BIT(hwmon_curr_emergency)
#define HWMON_C_AVERAGE BIT(hwmon_curr_average)
#define HWMON_C_LOWEST BIT(hwmon_curr_lowest)
#define HWMON_C_HIGHEST BIT(hwmon_curr_highest)
@@ -209,6 +216,7 @@ enum hwmon_curr_attributes {
#define HWMON_C_MAX_ALARM BIT(hwmon_curr_max_alarm)
#define HWMON_C_LCRIT_ALARM BIT(hwmon_curr_lcrit_alarm)
#define HWMON_C_CRIT_ALARM BIT(hwmon_curr_crit_alarm)
+#define HWMON_C_EMERGENCY_ALARM BIT(hwmon_curr_emergency_alarm)
#define HWMON_C_RATED_MIN BIT(hwmon_curr_rated_min)
#define HWMON_C_RATED_MAX BIT(hwmon_curr_rated_max)
#define HWMON_C_BEEP BIT(hwmon_curr_beep)
--
2.45.2
^ permalink raw reply related
* Re: [PATCH v7 08/11] KVM: TDX: Get/put PAMT pages when (un)mapping private memory
From: Edgecombe, Rick P @ 2026-07-22 19:18 UTC (permalink / raw)
To: seanjc@google.com
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Huang, Kai,
Hansen, Dave, Zhao, Yan Y, Wu, Binbin, kas@kernel.org,
mingo@redhat.com, pbonzini@redhat.com,
sashiko-reviews@lists.linux.dev, tony.lindgren@linux.intel.com,
linux-doc@vger.kernel.org, nik.borisov@suse.com, hpa@zytor.com,
tglx@kernel.org, Annapurve, Vishal, bp@alien8.de,
linux-kernel@vger.kernel.org, Gao, Chao, x86@kernel.org
In-Reply-To: <amDd1Ip3XTvKSTcb@google.com>
On Wed, 2026-07-22 at 08:12 -0700, Sean Christopherson wrote:
> > > > + ret = tdx_pamt_get(page_to_pfn(sept_pt), &to_tdx(vcpu)-
> > > > >pamt_cache);
> > > > + if (ret)
>
> Shouldn't this be a KVM_BUG_ON()? To Sashiko's point about this creating an
> infinite fault loop, that simply shouldn't happen. The whole point of using
> caches for the paging assets is to guarantee success.
Missed this one the first time. Yes it does seem like a good KVM_BUG_ON() case.
I'll update it.
^ permalink raw reply
* Re: [PATCH v7 08/11] KVM: TDX: Get/put PAMT pages when (un)mapping private memory
From: Edgecombe, Rick P @ 2026-07-22 19:17 UTC (permalink / raw)
To: seanjc@google.com
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Huang, Kai,
Hansen, Dave, Zhao, Yan Y, Wu, Binbin, kas@kernel.org,
mingo@redhat.com, tony.lindgren@linux.intel.com,
sashiko-reviews@lists.linux.dev, nik.borisov@suse.com,
linux-doc@vger.kernel.org, pbonzini@redhat.com, hpa@zytor.com,
Annapurve, Vishal, tglx@kernel.org, bp@alien8.de,
linux-kernel@vger.kernel.org, Gao, Chao, x86@kernel.org
In-Reply-To: <amD-WjxP05qKdK-t@google.com>
On Wed, 2026-07-22 at 10:31 -0700, Sean Christopherson wrote:
> On Wed, Jul 22, 2026, Rick P Edgecombe wrote:
> > On Wed, 2026-07-22 at 08:12 -0700, Sean Christopherson wrote:
> >
> It's already there:
Doh, yep.
> > Ok. Is there something we can add to connect the slots lock to the root freeing?
> > Like maybe a helper to encode that rule? Or better to not wrap the delicate
> > details? A comment instead...
>
> Ya, a comment.
>
> LOL, hilarious. I just discovered a (not fully functional) patch sitting in one
> of my many branches that adds the is_page_fault_stale() check, with this as the
> changelog:
>
> KVM: x86/mmu: Ensure page fault isn't stale/obsolete when mapping private PFN
>
> Add a sanity check in the helper used to map private pages into a TDX guest
> to ensure KVM isn't attempting to map memory into an invalid/obsolete root.
> It _should_ be impossible for the root to be invalid, as the only flow that
> marks TDP MMU roots as invalid is "fast all zap", and doing a "fast zap" is
> mutually exclusive with populating TDX memory thanks to slots_lock (this is
> also why KVM doesn't retry kvm_mmu_reload()).
>
> Note, KVM will already WARN on an invalid root if CONFIG_KVM_PROVE_MMU=y,
> but the check is inexpensive compared to the cost of populating memory into
> a TDX guest, and not having a is_page_fault_stale() check _looks_ wrong.
>
> I'll munge that into a mini-series to add the sanity checks. No need to hold
> the D-PAMT series, I see this as orthogonal hardening. I'm leaning towards the
> "have our cake and eat it too" option as the final resting state:
Sounds good to me, thanks. I think Yan was working on a patch, but hadn't
finished it.
>
> do {
> if (signal_pending(current))
> return -EINTR;
>
> if (kvm_test_request(KVM_REQ_VM_DEAD, vcpu))
> return -EIO;
>
> r = kvm_mmu_reload(vcpu);
> if (r)
> return r;
I'm ok either way, but I'd think to make the bugs easier to surface rather than
handle them. It seems at odds with how we discussed KVM_BUG_ON() in the past. A
reader may get the impression that kvm_mmu_reload() inside the retry is
required.
Hmm, does the new paradigm of AI finding ancient lurking bugs tilt the
safety/minimalism balance?
>
> r = mmu_topup_memory_caches(vcpu, false);
> if (r)
> return r;
>
> cond_resched();
>
> guard(read_lock)(&kvm->mmu_lock);
>
> /* Comment goes here. */
> WARN_ON_ONCE(kvm_test_request(KVM_REQ_MMU_FREE_OBSOLETE_ROOTS, vcpu));
>
> /*
> * Snapshot the invalidation sequence counter after acquiring
> * mmu_lock, as guest_memfd guarantees the validity of the pfn,
> * i.e. any concurrent invalidations are guaranteed to be
> * irrelevant.
> */
> fault.mmu_seq = vcpu->kvm->mmu_invalidate_seq;
> if (is_page_fault_stale(vcpu, &fault))
> continue;
>
> r = kvm_tdp_mmu_map(vcpu, &fault);
> } while (r == RET_PF_RETRY);
^ permalink raw reply
* Re: [PATCH v8 3/3] iommu/arm-smmu-v3: Enable CFGI/TLBI-repeat workaround on Tegra264
From: Nicolin Chen @ 2026-07-22 19:16 UTC (permalink / raw)
To: Ashish Mhetre
Cc: catalin.marinas, will, corbet, skhan, robin.murphy, joro, jgg,
linux-arm-kernel, linux-doc, linux-kernel, iommu, linux-tegra
In-Reply-To: <20260722102033.1122277-4-amhetre@nvidia.com>
On Wed, Jul 22, 2026 at 10:20:33AM +0000, Ashish Mhetre wrote:
> The host repeats only the invalidations it issues itself. On a nesting
> setup the guest submits its own invalidations, either directly through
> VCMDQ or via the iommufd user-invalidation path, so the guest is the one
> that has to apply the workaround there. Report the erratum to user space
> through the new IOMMU_HW_INFO_ARM_SMMUV3_ERRATA_REPEAT_TLBI_CFGI hw_info
> flag so a VMM can confirm the guest runs a matching "nvidia,tegra264-smmu"
> (or otherwise double the commands itself). The host therefore does not
> repeat the guest's user-issued invalidations, which would otherwise be
> doubled a second time.
I think this "enable" patch is doing a bit too much.
All the iommufd-related changes can be added separately
I would do a cleanup:
- arm-smmu-v3: Factor force_sync
- arm-smmu-v3: Add arm_smmu_erratum_repeat_tlbi_cfgi_key and WAR
- arm-smmu-v3-iommufd: Add IOMMU_HW_INFO_ARM_SMMUV3_ERRATA_REPEAT_TLBI_CFGI
- arm-smmu-v3: Set arm_smmu_erratum_repeat_tlbi_cfgi_key
> +/**
> + * enum iommu_hw_info_arm_smmuv3_flags - Flags for ARM SMMUv3 hw_info
> + * @IOMMU_HW_INFO_ARM_SMMUV3_ERRATA_REPEAT_TLBI_CFGI: If set, user space must
> + * issue TLBI/CFGI+SYNC commands twice due to a hardware erratum T264-SMMU-3.
> + * See the description at arm_smmu_erratum_repeat_tlbi_cfgi_key.
You can follow the kdoc style as enum iommufd_option.
Nicolin
^ permalink raw reply
* Re: [PATCH v8 2/3] iommu/arm-smmu-v3: Introduce CFGI/TLBI-repeat workaround infrastructure
From: Nicolin Chen @ 2026-07-22 19:02 UTC (permalink / raw)
To: Ashish Mhetre
Cc: catalin.marinas, will, corbet, skhan, robin.murphy, joro, jgg,
linux-arm-kernel, linux-doc, linux-kernel, iommu, linux-tegra,
Jason Gunthorpe
In-Reply-To: <20260722102033.1122277-3-amhetre@nvidia.com>
On Wed, Jul 22, 2026 at 10:20:32AM +0000, Ashish Mhetre wrote:
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index c909c9a88538..9508bf50d14c 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -1207,10 +1207,15 @@ void arm_smmu_attach_commit(struct arm_smmu_attach_state *state);
> int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
> struct arm_smmu_cmdq *cmdq,
> struct arm_smmu_cmd *cmds, int n,
> bool sync);
> +bool arm_smmu_erratum_cmd_needs_repeating(struct arm_smmu_cmd *cmd);
Is this needed?
Nicolin
^ permalink raw reply
* [RFT PATCH] hwmon: Add support for currX_emergency and inX_emergency attributes
From: Guenter Roeck @ 2026-07-22 18:57 UTC (permalink / raw)
To: Hardware Monitoring
Cc: linux-doc, Guenter Roeck, Manaf Meethalavalappu Pallikunhi
Some hardware monitoring chips support three alarm levels for current and
voltage measurements. Add support for currX_emergency and inX_emergency
attributes to support such chips.
Cc: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
RFT: Waiting for an actual chip driver using the new attributes.
Documentation/ABI/testing/sysfs-class-hwmon | 26 +++++++++++++++++++++
Documentation/hwmon/sysfs-interface.rst | 6 +++++
drivers/hwmon/hwmon.c | 2 ++
include/linux/hwmon.h | 4 ++++
4 files changed, 38 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon
index b185bdfc7186..42fd89305101 100644
--- a/Documentation/ABI/testing/sysfs-class-hwmon
+++ b/Documentation/ABI/testing/sysfs-class-hwmon
@@ -81,6 +81,18 @@ Description:
take drastic action such as power down or reset. At the very
least, it should report a fault.
+What: /sys/class/hwmon/hwmonX/inY_emergency
+Description:
+ Voltage emergency max value.
+
+ Unit: millivolt
+
+ RW
+
+ If voltage reaches or exceeds this limit, the system is expected
+ to take drastic action such as immediate power down or reset.
+ At the very least, it should report a fault.
+
What: /sys/class/hwmon/hwmonX/inY_input
Description:
Voltage input value.
@@ -647,6 +659,20 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/currY_emergency
+Description:
+ Current emergency high value.
+
+ Unit: milliampere
+
+ RW
+
+ If a current reaches or exceeds this limit, the system is
+ expected to take drastic action such as immediate power down
+ or reset. At the very least, it should report a fault.
+
+What: /sys/class/hwmon/hwmonX/inY_input
+
What: /sys/class/hwmon/hwmonX/currY_input
Description:
Current input value
diff --git a/Documentation/hwmon/sysfs-interface.rst b/Documentation/hwmon/sysfs-interface.rst
index 94e1bbce172a..e8f2a12793af 100644
--- a/Documentation/hwmon/sysfs-interface.rst
+++ b/Documentation/hwmon/sysfs-interface.rst
@@ -127,6 +127,9 @@ Voltages
`in[0-*]_crit`
Voltage critical max value.
+`in[0-*]_emergency`
+ Voltage emergency max value.
+
`in[0-*]_input`
Voltage input value.
@@ -332,6 +335,9 @@ Currents
`curr[1-*]_crit`
Current critical high value.
+`curr[1-*]_emergency`
+ Current emergency high value.
+
`curr[1-*]_input`
Current input value.
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index 55a9a3ddd4aa..a07bfe7ac7db 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -621,6 +621,7 @@ static const char * const hwmon_in_attr_templates[] = {
[hwmon_in_max] = "in%d_max",
[hwmon_in_lcrit] = "in%d_lcrit",
[hwmon_in_crit] = "in%d_crit",
+ [hwmon_in_emergency] = "in%d_emergency",
[hwmon_in_average] = "in%d_average",
[hwmon_in_lowest] = "in%d_lowest",
[hwmon_in_highest] = "in%d_highest",
@@ -644,6 +645,7 @@ static const char * const hwmon_curr_attr_templates[] = {
[hwmon_curr_max] = "curr%d_max",
[hwmon_curr_lcrit] = "curr%d_lcrit",
[hwmon_curr_crit] = "curr%d_crit",
+ [hwmon_curr_emergency] = "curr%d_emergency",
[hwmon_curr_average] = "curr%d_average",
[hwmon_curr_lowest] = "curr%d_lowest",
[hwmon_curr_highest] = "curr%d_highest",
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index 77a6f2bffcba..2cd433966723 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -134,6 +134,7 @@ enum hwmon_in_attributes {
hwmon_in_max,
hwmon_in_lcrit,
hwmon_in_crit,
+ hwmon_in_emergency,
hwmon_in_average,
hwmon_in_lowest,
hwmon_in_highest,
@@ -156,6 +157,7 @@ enum hwmon_in_attributes {
#define HWMON_I_MAX BIT(hwmon_in_max)
#define HWMON_I_LCRIT BIT(hwmon_in_lcrit)
#define HWMON_I_CRIT BIT(hwmon_in_crit)
+#define HWMON_I_EMERGENCY BIT(hwmon_in_emergency)
#define HWMON_I_AVERAGE BIT(hwmon_in_average)
#define HWMON_I_LOWEST BIT(hwmon_in_lowest)
#define HWMON_I_HIGHEST BIT(hwmon_in_highest)
@@ -178,6 +180,7 @@ enum hwmon_curr_attributes {
hwmon_curr_max,
hwmon_curr_lcrit,
hwmon_curr_crit,
+ hwmon_curr_emergency,
hwmon_curr_average,
hwmon_curr_lowest,
hwmon_curr_highest,
@@ -199,6 +202,7 @@ enum hwmon_curr_attributes {
#define HWMON_C_MAX BIT(hwmon_curr_max)
#define HWMON_C_LCRIT BIT(hwmon_curr_lcrit)
#define HWMON_C_CRIT BIT(hwmon_curr_crit)
+#define HWMON_C_EMERGENCY BIT(hwmon_curr_emergency)
#define HWMON_C_AVERAGE BIT(hwmon_curr_average)
#define HWMON_C_LOWEST BIT(hwmon_curr_lowest)
#define HWMON_C_HIGHEST BIT(hwmon_curr_highest)
--
2.45.2
^ permalink raw reply related
* Re: [PATCH v5 1/5] selftests/mm: make file helpers return errors
From: John Hubbard @ 2026-07-22 18:57 UTC (permalink / raw)
To: Sarthak Sharma, David Hildenbrand (Arm), Mark Brown
Cc: Andrew Morton, Lorenzo Stoakes, Liam R . Howlett, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Shuah Khan,
Shuah Khan, Jason Gunthorpe, Peter Xu, Leon Romanovsky, Zi Yan,
Baolin Wang, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jonathan Corbet, Anshuman Khandual, linux-mm,
linux-kselftest, linux-doc, linux-kernel
In-Reply-To: <cd539861-5f98-4906-8e36-f2a5a70687a5@arm.com>
On 7/21/26 10:24 PM, Sarthak Sharma wrote:
> Hi David and Mark!
>
> On 7/21/26 8:24 PM, David Hildenbrand (Arm) wrote:
>> On 7/21/26 15:48, Mark Brown wrote:
>>> On Tue, Jul 21, 2026 at 03:39:09PM +0200, David Hildenbrand (Arm) wrote:
>>>> On 7/16/26 14:32, Sarthak Sharma wrote:
>>>
>>>>> fd = open(path, O_RDONLY);
>>>>> - if (fd == -1)
>>>>> - return 0;
>>>>> + if (fd == -1) {
>>>>> + int err = errno;
>>>>> +
>>>>> + printf("# %s: %s (%d)\n", path, strerror(err), err);
>>>
>>>> Shouldn't we be using
>>>
>>>> ksft_print_msg()
>>>
>>>> That does the magic "# " for us.
>>>
>>> Or ksft_perror().
>>
>>
>> Right, and if we want to move this to tools/lib/mm later, maybe we can just not
>> print anything and instead only return expressive errnos.
>>
>
> Yes, we are not using ksft_* prints here because these functions move to
> tools/lib/mm later in the series.
>
> Printing errors from the helpers was suggested by Mike [1]. I also think
> this is useful since the diagnostic handling stays at one place, instead
> of duplicating it in every caller.
This is a common pitfall. In fact, the lower ("leaf") routines, *especially*
library-like functions that are called by disparate callers, should be
usually be silent.
That's because printing is a policy choice, and libraries must refrain
from imposing that policy onto their callers.
Higher up the call stack, the code has more context, and is able to
make more informed choices about whether or not to print something.
And when or if they do print, they may include some of that extra
context, and so you can now see that the printing code is potentially
different at each call site, and now you haven't actually saved any
duplication after all by trying to centralize it.>
> If we want helpers to be silent, I can change them to return errors and
> let the callers handle the diagnostics. Please let me know how I should
> proceed here.
>
> [1]
> https://lore.kernel.org/all/178048086818.472368.16811711474077698399.b4-review@b4/
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH v9 8/8] drm/gpusvm: Use hmm_range_fault_unlocked_timeout() for range faults
From: Stanislav Kinsburskii @ 2026-07-22 18:52 UTC (permalink / raw)
To: Matthew Brost
Cc: airlied, akhilesh, akpm, corbet, dakr, david, decui, haiyangz,
jgg, kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, intel-xe, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <al7CGPdJGM+asOFK@gsse-cloud1.jf.intel.com>
On Mon, Jul 20, 2026 at 05:49:28PM -0700, Matthew Brost wrote:
> On Wed, Jul 15, 2026 at 11:16:52AM -0700, Stanislav Kinsburskii wrote:
> > Several GPU SVM paths take mmap_read_lock() only to call hmm_range_fault()
> > and open-code mmu interval sequence setup before each HMM walk. They also
> > retry -EBUSY until HMM_RANGE_DEFAULT_TIMEOUT expires.
> >
> > Use hmm_range_fault_unlocked_timeout() for those faults. The HMM helper now
> > owns mmap_lock acquisition and refreshes range->notifier_seq for its
> > internal retries, while GPU SVM keeps its existing driver-lock validation
> > with mmu_interval_read_retry() after a successful fault.
> >
> > Pass HMM_RANGE_DEFAULT_TIMEOUT as the helper retry budget for each HMM
> > fault attempt. This scopes the timeout to repeated HMM notifier retries
> > while preserving the outer retry loops that restart when the interval is
> > invalidated before GPU SVM updates or consumes the mapping state.
> >
>
> This part doesn't seem right for get_pages(), see below.
>
> > Leave drm_gpusvm_check_pages() on hmm_range_fault() because that path is
> > called with the mmap lock already held by its caller.
> >
> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> > Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com>
> > ---
> > drivers/gpu/drm/drm_gpusvm.c | 61 +++++-------------------------------------
> > 1 file changed, 7 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
> > index 958cb605aedd..de5bbfe58ee9 100644
> > --- a/drivers/gpu/drm/drm_gpusvm.c
> > +++ b/drivers/gpu/drm/drm_gpusvm.c
> > @@ -773,8 +773,7 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
> > .end = end,
> > .dev_private_owner = dev_private_owner,
> > };
> > - unsigned long timeout =
> > - jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
> > + unsigned long timeout = msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
> > enum drm_gpusvm_scan_result state = DRM_GPUSVM_SCAN_UNPOPULATED, new_state;
> > unsigned long *pfns;
> > unsigned long npages = npages_in_range(start, end);
> > @@ -788,22 +787,7 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
> > hmm_range.hmm_pfns = pfns;
> >
> > retry:
> > - hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> > - mmap_read_lock(range->gpusvm->mm);
> > -
> > - while (true) {
> > - err = hmm_range_fault(&hmm_range);
> > - if (err == -EBUSY) {
> > - if (time_after(jiffies, timeout))
> > - break;
> > -
> > - hmm_range.notifier_seq =
> > - mmu_interval_read_begin(notifier);
> > - continue;
> > - }
> > - break;
> > - }
> > - mmap_read_unlock(range->gpusvm->mm);
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range, timeout);
> > if (err)
> > goto err_free;
> >
> > @@ -1406,8 +1390,7 @@ int drm_gpusvm_get_pages(struct drm_gpusvm *gpusvm,
> > .dev_private_owner = ctx->device_private_page_owner,
> > };
> > void *zdd;
> > - unsigned long timeout =
> > - jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
> > + unsigned long timeout = msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
> > unsigned long i, j;
> > unsigned long npages = npages_in_range(pages_start, pages_end);
> > unsigned long num_dma_mapped;
> > @@ -1422,9 +1405,6 @@ int drm_gpusvm_get_pages(struct drm_gpusvm *gpusvm,
> > struct dma_iova_state *state = &svm_pages->state;
> >
> > retry:
> > - if (time_after(jiffies, timeout))
> > - return -EBUSY;
> > -
>
> I think that by deleting the code above, you have changed this function's
> semantics by removing the hard cap of HMM_RANGE_DEFAULT_TIMEOUT. This
> code was added because, on some non-production platforms, the timing in
> this function could cause it to livelock.
>
> Is there any reason this was remove aside from timeout variable not
> being a deadline now? You likely should add the deadline back in.
>
Indeed, this one can be called from a kernel thread context as well.
I'll revert the change in the next revision.
Thanks,
Stanislav
> Matt
>
> > hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> > if (drm_gpusvm_pages_valid_unlocked(gpusvm, svm_pages))
> > goto set_seqno;
> > @@ -1439,21 +1419,7 @@ int drm_gpusvm_get_pages(struct drm_gpusvm *gpusvm,
> > }
> >
> > hmm_range.hmm_pfns = pfns;
> > - while (true) {
> > - mmap_read_lock(mm);
> > - err = hmm_range_fault(&hmm_range);
> > - mmap_read_unlock(mm);
> > -
> > - if (err == -EBUSY) {
> > - if (time_after(jiffies, timeout))
> > - break;
> > -
> > - hmm_range.notifier_seq =
> > - mmu_interval_read_begin(notifier);
> > - continue;
> > - }
> > - break;
> > - }
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range, timeout);
> > mmput(mm);
> > if (err)
> > goto err_free;
> > @@ -1720,8 +1686,7 @@ int drm_gpusvm_range_evict(struct drm_gpusvm *gpusvm,
> > .end = drm_gpusvm_range_end(range),
> > .dev_private_owner = NULL,
> > };
> > - unsigned long timeout =
> > - jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
> > + unsigned long timeout = msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
> > unsigned long *pfns;
> > unsigned long npages = npages_in_range(drm_gpusvm_range_start(range),
> > drm_gpusvm_range_end(range));
> > @@ -1736,24 +1701,12 @@ int drm_gpusvm_range_evict(struct drm_gpusvm *gpusvm,
> > return -ENOMEM;
> >
> > hmm_range.hmm_pfns = pfns;
> > - while (!time_after(jiffies, timeout)) {
> > - hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> > - if (time_after(jiffies, timeout)) {
> > - err = -ETIME;
> > - break;
> > - }
> > -
> > - mmap_read_lock(mm);
> > - err = hmm_range_fault(&hmm_range);
> > - mmap_read_unlock(mm);
> > - if (err != -EBUSY)
> > - break;
> > - }
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range, timeout);
> >
> > kvfree(pfns);
> > mmput(mm);
> >
> > - return err;
> > + return err == -EBUSY ? -ETIME : err;
> > }
> > EXPORT_SYMBOL_GPL(drm_gpusvm_range_evict);
> >
> >
> >
^ permalink raw reply
* Re: [PATCH bpf-next v5 8/8] selftests: net: add test for XDP_PASS skb checksum invalidation
From: Jakub Kicinski @ 2026-07-22 18:35 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Lorenzo Bianconi, Donald Hunter, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Andrew Lunn, Tony Nguyen, Przemek Kitszel, Alexander Lobakin,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Shuah Khan,
Maciej Fijalkowski, Jonathan Corbet, Shuah Khan,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Vladimir Vdovin,
Jakub Sitnicki, netdev, bpf, intel-wired-lan, linux-kselftest,
linux-doc
In-Reply-To: <amEEEohxmC8hkBvY@devvm7509.cco0.facebook.com>
On Wed, 22 Jul 2026 11:00:07 -0700 Stanislav Fomichev wrote:
> > > This is about current drivers that only report UNNECESSARY with xdp: the xdp
> > > prog has to maintain in-packet checksum if it changes the payload. I think
> > > it's a fair assumption?
> >
> > What about decap? If we decap the header that device validated
> > as UNNECESSARY there's no possibility of maintaining the checksum
> > (by which IIUC you mean correcting it in along the payload changes).
> >
> > I think we'd need some API to "decrement the csum level" ?
> > Or some heuristic in the drivers to decrement if the head moved
> > by at least len(IP+UDP) into the packet ?
>
> True :-/ I guess one more case to document?
What would we be documenting? That it's a known bug and we have no idea
how to address it? Or am I missing something?
Again:
.. the ask was to sketch out the plan of explicitly
updating/invalidating the checksum even if we don't
implement it today
^ permalink raw reply
* Re: [PATCH bpf-next v5 8/8] selftests: net: add test for XDP_PASS skb checksum invalidation
From: Stanislav Fomichev @ 2026-07-22 18:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Lorenzo Bianconi, Donald Hunter, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Andrew Lunn, Tony Nguyen, Przemek Kitszel, Alexander Lobakin,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Shuah Khan,
Maciej Fijalkowski, Jonathan Corbet, Shuah Khan,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Vladimir Vdovin,
Jakub Sitnicki, netdev, bpf, intel-wired-lan, linux-kselftest,
linux-doc
In-Reply-To: <20260721183256.6f49d6e1@kernel.org>
On 07/21, Jakub Kicinski wrote:
> On Tue, 21 Jul 2026 16:03:37 -0700 Stanislav Fomichev wrote:
> > > > For unnecessary, I think the safe expectation is that the bpf program
> > > > will update the value of the checksum in the packet if it touches the data?
> > >
> > > Documenting as expected behavior which no driver currently follows
> > > is a bit silly. I thought the ask was to sketch out the plan of
> > > explicitly updating/invalidating the checksum even if we don't
> > > implement it today?
> >
> > This is about current drivers that only report UNNECESSARY with xdp: the xdp
> > prog has to maintain in-packet checksum if it changes the payload. I think
> > it's a fair assumption?
>
> What about decap? If we decap the header that device validated
> as UNNECESSARY there's no possibility of maintaining the checksum
> (by which IIUC you mean correcting it in along the payload changes).
>
> I think we'd need some API to "decrement the csum level" ?
> Or some heuristic in the drivers to decrement if the head moved
> by at least len(IP+UDP) into the packet ?
True :-/ I guess one more case to document?
> > In terms of documentation, here is what I have on my side, lmk if that makes
> > sense, roughly:
> >
> > - TODAY
> > - some drivers (correctly) disable reporting COMPLETE when XDP is attached
> > - the xdp program has to modify the packet checksum value if it
> > changes the payload
> > - some drivers (incorrectly?) report COMPLETE for xdp-to-skb path -> unsafe,
> > needs to be fixed
> > - updating the payload doesn't update skb->csum, so the safest
> > option right now is to only do UNNECESSARY with xdp for all drivers
>
> Yes, that sounds fair.
>
> > - the hw test needs to make sure that the csum is either
> > NONE or UNNECESSARY, and will error out on COMPLETE
>
> Driver can report COMPLETE to XDP, just not to the stack.
> I think we can use a tracepoint (bpftrace) or attach in TCP
> to check the skb state?
No strong opinion on this, it seems easier to report the same to both
xdp and bpf (at least initially)
^ permalink raw reply
* Re: [PATCH v7 08/11] KVM: TDX: Get/put PAMT pages when (un)mapping private memory
From: Sean Christopherson @ 2026-07-22 17:31 UTC (permalink / raw)
To: Rick P Edgecombe
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Kai Huang,
Dave Hansen, Yan Y Zhao, Binbin Wu, kas@kernel.org,
mingo@redhat.com, pbonzini@redhat.com,
sashiko-reviews@lists.linux.dev, tony.lindgren@linux.intel.com,
linux-doc@vger.kernel.org, nik.borisov@suse.com, hpa@zytor.com,
tglx@kernel.org, Vishal Annapurve, bp@alien8.de,
linux-kernel@vger.kernel.org, Chao Gao, x86@kernel.org
In-Reply-To: <5ef176573157b595d674cfca28923d919e54ad73.camel@intel.com>
On Wed, Jul 22, 2026, Rick P Edgecombe wrote:
> On Wed, 2026-07-22 at 08:12 -0700, Sean Christopherson wrote:
> > Hmm, yeah, I think I agree. Super duper technically, that's a fix for an
> > existing flaw. Because very, very, VERY theoretically, the cache of page
> > table pages could be exhausted. E.g. if some other task managed to free non-
> > leaf page tables while mmu_lock was dropped, thus forcing
> > kvm_tdp_mmu_map_private_pfn() to allocate from its cache over and over. In
> > practice, that's likely impossible thanks to holding slots_lock, but given
> > that (a) retry should be rare and (b) kvm_mmu_topup_memory_cache()
> > is basically free if no work needs to be done, I don't see any reason to do
> > topup outside of the retry loop.
> >
> > The other thing we should address is the call to kvm_mmu_reload(). Like cache
> > exhaustion, it *should* be impossible for the root to be
> > invalidated/obsoleted, thanks to holding slots lock. But as evidenced by the
> > rash of recent shadow MMU bugs, we don't always get things perfect, and lack
> > of defense-in-depth can be *extremely* painful.
>
> Should we assert that we are holding slots lock then? Otherwise the reason for
> the warnings would be confusing. To me at least.
It's already there:
int kvm_tdp_mmu_map_private_pfn(struct kvm_vcpu *vcpu, gfn_t gfn, kvm_pfn_t pfn)
{
struct kvm_page_fault fault = {
.addr = gfn_to_gpa(gfn),
.error_code = PFERR_GUEST_FINAL_MASK | PFERR_PRIVATE_ACCESS,
.prefetch = true,
.is_tdp = true,
.nx_huge_page_workaround_enabled = is_nx_huge_page_enabled(vcpu->kvm),
.max_level = PG_LEVEL_4K,
.req_level = PG_LEVEL_4K,
.goal_level = PG_LEVEL_4K,
.is_private = true,
.gfn = gfn,
.slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn),
.pfn = pfn,
.map_writable = true,
};
struct kvm *kvm = vcpu->kvm;
int r;
lockdep_assert_held(&kvm->slots_lock); <=====
> > I don't think I want to just move kvm_mmu_reload() into the loop, because KVM
> > should provide stronger guarantees with respect to the validity of the loop,
> > versus the population of the caches. I.e. I want to WARN if the root becomes
> > obsolete after the initial reload. And more importantly, KVM really should
> > check the validity of the root after acquiring mmu_lock.
> >
> > We can't simply call is_page_fault_stale(), because mmu_invalidate_retry_gfn()
> > is inherently fuzzy, i.e. could get false positives, even though the pfn
> > provided by guest_memfd is guaranteed to be valid. E.g. if shared gfns
> > surrounding the to-be-mapped gfn are concurrently invalidated.
> >
> > So, this?
> >
> > r = kvm_mmu_reload(vcpu);
> > if (r)
> > return r;
> >
> > do {
> > if (signal_pending(current))
> > return -EINTR;
> >
> > if (kvm_test_request(KVM_REQ_VM_DEAD, vcpu))
> > return -EIO;
> >
> > r = mmu_topup_memory_caches(vcpu, false);
> > if (r)
> > return r;
> >
> > cond_resched();
> >
> > guard(read_lock)(&kvm->mmu_lock);
> >
> > if
> > (WARN_ON_ONCE(kvm_test_request(KVM_REQ_MMU_FREE_OBSOLETE_ROOTS, vcpu)))
> > return -EIO;
> >
> > r = kvm_tdp_mmu_map(vcpu, &fault);
> > } while (r == RET_PF_RETRY);
> >
>
> Ok. Is there something we can add to connect the slots lock to the root freeing?
> Like maybe a helper to encode that rule? Or better to not wrap the delicate
> details? A comment instead...
Ya, a comment.
LOL, hilarious. I just discovered a (not fully functional) patch sitting in one
of my many branches that adds the is_page_fault_stale() check, with this as the
changelog:
KVM: x86/mmu: Ensure page fault isn't stale/obsolete when mapping private PFN
Add a sanity check in the helper used to map private pages into a TDX guest
to ensure KVM isn't attempting to map memory into an invalid/obsolete root.
It _should_ be impossible for the root to be invalid, as the only flow that
marks TDP MMU roots as invalid is "fast all zap", and doing a "fast zap" is
mutually exclusive with populating TDX memory thanks to slots_lock (this is
also why KVM doesn't retry kvm_mmu_reload()).
Note, KVM will already WARN on an invalid root if CONFIG_KVM_PROVE_MMU=y,
but the check is inexpensive compared to the cost of populating memory into
a TDX guest, and not having a is_page_fault_stale() check _looks_ wrong.
I'll munge that into a mini-series to add the sanity checks. No need to hold
the D-PAMT series, I see this as orthogonal hardening. I'm leaning towards the
"have our cake and eat it too" option as the final resting state:
do {
if (signal_pending(current))
return -EINTR;
if (kvm_test_request(KVM_REQ_VM_DEAD, vcpu))
return -EIO;
r = kvm_mmu_reload(vcpu);
if (r)
return r;
r = mmu_topup_memory_caches(vcpu, false);
if (r)
return r;
cond_resched();
guard(read_lock)(&kvm->mmu_lock);
/* Comment goes here. */
WARN_ON_ONCE(kvm_test_request(KVM_REQ_MMU_FREE_OBSOLETE_ROOTS, vcpu));
/*
* Snapshot the invalidation sequence counter after acquiring
* mmu_lock, as guest_memfd guarantees the validity of the pfn,
* i.e. any concurrent invalidations are guaranteed to be
* irrelevant.
*/
fault.mmu_seq = vcpu->kvm->mmu_invalidate_seq;
if (is_page_fault_stale(vcpu, &fault))
continue;
r = kvm_tdp_mmu_map(vcpu, &fault);
} while (r == RET_PF_RETRY);
^ permalink raw reply
* Re: [PATCH v7 5/7] iio: adc: mcp3911: Add support for spi-device-addr
From: Marius.Cristea @ 2026-07-22 17:19 UTC (permalink / raw)
To: corbet, robh, andy, kent, Michael.Hennerich, lars, conor+dt,
skhan, dlechner, nuno.sa, janani.sunil, krzk+dt, p.zabel, jic23,
marcus.folkesson, broonie
Cc: linux-spi, nedo80, devicetree, linux-kernel, linux-iio, linux-doc,
jan.sun97
In-Reply-To: <20260722-ad5529r-driver-v7-5-7781cd74ad75@analog.com>
On Wed, 2026-07-22 at 09:54 +0200, Janani Sunil wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> Read the generic spi-device-addr property when determining the
> hardware
> device address. Fall back to the deprecated microchip,device-addr
> property and then to the historical device-addr property to preserve
> compatibility with existing devicetrees.
>
> The device address remains 0 when none of the properties are present.
>
> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> ---
> drivers/iio/adc/mcp3911.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
> index ddc3721f3f68..3919a326b4db 100644
> --- a/drivers/iio/adc/mcp3911.c
> +++ b/drivers/iio/adc/mcp3911.c
> @@ -740,10 +740,13 @@ static int mcp3911_probe(struct spi_device
> *spi)
> }
>
> /*
> - * Fallback to "device-addr" due to historical mismatch
> between
> - * dt-bindings and implementation.
> + * Fall back to the vendor-specific property, then to
> "device-addr"
> + * due to a historical mismatch between the binding and
> implementation.
> */
> - ret = device_property_read_u32(dev, "microchip,device-addr",
> &adc->dev_addr);
> + ret = device_property_read_u32(dev, "spi-device-addr", &adc-
> >dev_addr);
> + if (ret)
> + ret = device_property_read_u32(dev,
> "microchip,device-addr",
> + &adc->dev_addr);
> if (ret)
> device_property_read_u32(dev, "device-addr", &adc-
> >dev_addr);
> if (adc->dev_addr > 3) {
>
> --
> 2.43.0
Reviewed-by: Marius Cristea <marius.cristea@microchip.com>
^ permalink raw reply
* Re: [PATCH v7 5/7] iio: adc: mcp3911: Add support for spi-device-addr
From: Marius.Cristea @ 2026-07-22 17:18 UTC (permalink / raw)
To: conor, janani.sunil
Cc: corbet, linux-doc, robh, andy, nedo80, kent, Michael.Hennerich,
jan.sun97, lars, conor+dt, linux-spi, linux-kernel, devicetree,
skhan, dlechner, nuno.sa, p.zabel, jic23, marcus.folkesson,
krzk+dt, linux-iio, broonie
In-Reply-To: <20260722-vintage-handwork-eaaa304ed0b4@spud>
On Wed, 2026-07-22 at 17:43 +0100, Conor Dooley wrote:
> On Wed, Jul 22, 2026 at 05:41:54PM +0100, Conor Dooley wrote:
> > On Wed, Jul 22, 2026 at 09:54:17AM +0200, Janani Sunil wrote:
> > > Read the generic spi-device-addr property when determining the
> > > hardware
> > > device address. Fall back to the deprecated microchip,device-addr
> > > property and then to the historical device-addr property to
> > > preserve
> > > compatibility with existing devicetrees.
> > >
> > > The device address remains 0 when none of the properties are
> > > present.
> > >
> > > Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> > > ---
> > > drivers/iio/adc/mcp3911.c | 9 ++++++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/iio/adc/mcp3911.c
> > > b/drivers/iio/adc/mcp3911.c
> > > index ddc3721f3f68..3919a326b4db 100644
> > > --- a/drivers/iio/adc/mcp3911.c
> > > +++ b/drivers/iio/adc/mcp3911.c
> > > @@ -740,10 +740,13 @@ static int mcp3911_probe(struct spi_device
> > > *spi)
> > > }
> > >
> > > /*
> > > - * Fallback to "device-addr" due to historical mismatch
> > > between
> > > - * dt-bindings and implementation.
> > > + * Fall back to the vendor-specific property, then to
> > > "device-addr"
> > > + * due to a historical mismatch between the binding and
> > > implementation.
> >
> > Jaysus, bit of a mess here.
> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> >
> > > */
> > > - ret = device_property_read_u32(dev, "microchip,device-
> > > addr", &adc->dev_addr);
> > > + ret = device_property_read_u32(dev, "spi-device-addr",
> > > &adc->dev_addr);
> > > + if (ret)
> > > + ret = device_property_read_u32(dev,
> > > "microchip,device-addr",
> > > + &adc->dev_addr);
> > > if (ret)
> > > device_property_read_u32(dev, "device-addr",
> > > &adc->dev_addr);
>
> Actually, this should check the return value, right?
Default hardware address is 0x00, unless a special order with custom
hardware address is made. I think is safe to try to communicate with
the default HW address, regardless of the return value.
>
> > > if (adc->dev_addr > 3) {
> > >
> > > --
> > > 2.43.0
> > >
>
^ permalink raw reply
* Re: [PATCH v7 3/7] iio: adc: mcp3564: Add support for spi-device-addr
From: Conor Dooley @ 2026-07-22 17:12 UTC (permalink / raw)
To: Marius.Cristea
Cc: janani.sunil, corbet, linux-doc, robh, andy, nedo80, kent,
Michael.Hennerich, jan.sun97, lars, conor+dt, linux-spi,
linux-kernel, devicetree, skhan, dlechner, nuno.sa, p.zabel,
jic23, marcus.folkesson, krzk+dt, linux-iio, broonie
In-Reply-To: <3b5253f88b8363727dedee9481212e5be222bc9f.camel@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]
On Wed, Jul 22, 2026 at 05:02:28PM +0000, Marius.Cristea@microchip.com wrote:
> On Wed, 2026-07-22 at 17:45 +0100, Conor Dooley wrote:
> > On Wed, Jul 22, 2026 at 09:54:15AM +0200, Janani Sunil wrote:
> > > Read the generic spi-device-addr property when determining the
> > > hardware
> > > device address. Fall back to the deprecated microchip,hw-device-
> > > address
> > > property to preserve compatibility with existing device trees.
> > >
> > > The device address remains 1 when neither property is present.
> > >
> > > Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> > > ---
> > > drivers/iio/adc/mcp3564.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iio/adc/mcp3564.c b/drivers/iio/adc/mcp3564.c
> > > index 36675563829e..71deb05e878e 100644
> > > --- a/drivers/iio/adc/mcp3564.c
> > > +++ b/drivers/iio/adc/mcp3564.c
> > > @@ -1122,7 +1122,9 @@ static int mcp3564_config(struct iio_dev
> > > *indio_dev, bool *use_internal_vref_att
> > > * addresses are available when multiple devices are
> > > present on the same
> > > * SPI bus with only one Chip Select line for all devices.
> > > */
> > > - device_property_read_u32(dev, "microchip,hw-device-
> > > address", &tmp);
> > > + ret = device_property_read_u32(dev, "spi-device-addr",
> > > &tmp);
> > > + if (ret)
> > > + device_property_read_u32(dev, "microchip,hw-
> > > device-address", &tmp);
> >
> > Same on this one, shouldn't it check the return value so that the
> > below
> > check of temp > 3 doesn't just pass with the default value of tmp?
> >
>
> Default hardware address is 0x01, unless a special order with custom
> hardware address is made. I think is safe to try to communicate with
> the default HW address.
Ah, sounds good so.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: vendor-prefixes: Add Sensylink
From: Guenter Roeck @ 2026-07-22 17:09 UTC (permalink / raw)
To: Conor Dooley
Cc: Troy Mitchell, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Yixun Lan, Jonathan Corbet, Shuah Khan, devicetree, linux-kernel,
linux-hwmon, linux-riscv, spacemit, linux-doc
In-Reply-To: <20260722-devious-seventh-9859bb3741b3@spud>
On 7/22/26 09:15, Conor Dooley wrote:
> On Tue, Jul 21, 2026 at 10:56:36AM -0700, Guenter Roeck wrote:
>> On 7/21/26 08:49, Conor Dooley wrote:
>>> On Tue, Jul 21, 2026 at 02:48:27AM -0700, Troy Mitchell wrote:
>>>> Add the vendor prefix for Sensylink Microelectronics.
>>>>
>>>> Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
>>>> ---
>>>> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>>>> index 396044f368e7..22d0d26f1bbd 100644
>>>> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
>>>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>>>> @@ -1467,6 +1467,8 @@ patternProperties:
>>>> description: Sensirion AG
>>>> "^sensortek,.*":
>>>> description: Sensortek Technology Corporation
>>>> + "^sensylink,.*":
>>>> + description: Sensylink Microelectronics Technology Co., Ltd.
>>>
>>> Googling the company to see what their website is, I seem to see a
>>> different name for the company: Shanghai Sensylink Microelectronics Inc.
>>> Their website has that with the Shanghai dropped.
>>>
>>> Also, probably the commit message should contain
>>> Link: https://en.sensylink.com/
>>>
>>
>> Asking Google search: "Why the two names ? Did they rename themselves at some point ?"
>
> The google search "AI" response was what showed me the different name,
> sounds like I should have questioned it some more!
>
>>
>> Response:
>>
>> Understanding the Name Structure
>>
>> 1. English Legal Name vs. Marketing Abbreviation
>>
>> Sensylink Microelectronics Technology Co., Ltd.:
>> This is the literal translation of their full, formal registered corporate name
>> used for international trade, customs, and legal documentation.
>>
>> Sensylink Microelectronics Inc.:
>> This is a simplified, Westernized abbreviation used on their official
>> English website and marketing materials for cleaner global branding.
>>
>> 2. The Native Chinese Name
>>
>> 上海申矽凌微电子科技股份有限公司 (Shanghai Shenxiling Microelectronics Technology
>> Co., Ltd.): This is the company's sole, official legal name registered with
>> the Chinese government.
>>
>> "Sensylink" is a portmanteau created specifically for international markets,
>> blending "Sensing" (their core technology) and "Link" (their interface and
>> connectivity products).
>>
>> Prodding further, asking if the previous response was complete, it tells
>> me that there was a name change:
>>
>> According to Chinese corporate registry data (via Tianyancha and Qcc),
>> they did change their official Chinese legal name:
>>
>> Old Name: 上海申矽凌微电子科技有限公司 (Shanghai Sensylink Microelectronics Technology
>> Co., Ltd.)
>>
>> New Name: 上海申矽凌微电子科技股份有限公司 (Shanghai Sensylink Microelectronics Technology
>> Co., Ltd. by Shares / Joint-Stock Company)
>>
>> I don't know if Linux has a policy about Legal vs. Marketing names. Personally
>> I don't have an opinion. Your call, really.
>
> I don't know what the policy is, or if there is one, but personally I
> wouldn't use the westernised abbreviation since they may decide to rebrand
> that etc and the vendor prefix information should remain static.
>
> So this is probably fine as-is, just I'd like to see that link added to
> their website.
>
> Thanks (and thanks for doing the extra digging),
Part of that extra digging nowadays is to ask it if its initial response
is real or if it was hallucinated. Sadly enough, most of the time it will
admit that at least part of the initial response does not match reality.
That was the case here as well, because it initially did claim that the
company never changed their name (of course, the next question to ask
would be if it really changed its name or if that was another
hallucination ;-).
Guenter
^ permalink raw reply
* Re: [PATCH v7 3/7] iio: adc: mcp3564: Add support for spi-device-addr
From: Marius.Cristea @ 2026-07-22 17:06 UTC (permalink / raw)
To: corbet, robh, andy, kent, Michael.Hennerich, lars, conor+dt,
skhan, dlechner, nuno.sa, janani.sunil, krzk+dt, p.zabel, jic23,
marcus.folkesson, broonie
Cc: linux-spi, nedo80, devicetree, linux-kernel, linux-iio, linux-doc,
jan.sun97
In-Reply-To: <20260722-ad5529r-driver-v7-3-7781cd74ad75@analog.com>
On Wed, 2026-07-22 at 09:54 +0200, Janani Sunil wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> Read the generic spi-device-addr property when determining the
> hardware
> device address. Fall back to the deprecated microchip,hw-device-
> address
> property to preserve compatibility with existing device trees.
>
> The device address remains 1 when neither property is present.
>
> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> ---
> drivers/iio/adc/mcp3564.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/mcp3564.c b/drivers/iio/adc/mcp3564.c
> index 36675563829e..71deb05e878e 100644
> --- a/drivers/iio/adc/mcp3564.c
> +++ b/drivers/iio/adc/mcp3564.c
> @@ -1122,7 +1122,9 @@ static int mcp3564_config(struct iio_dev
> *indio_dev, bool *use_internal_vref_att
> * addresses are available when multiple devices are present
> on the same
> * SPI bus with only one Chip Select line for all devices.
> */
> - device_property_read_u32(dev, "microchip,hw-device-address",
> &tmp);
> + ret = device_property_read_u32(dev, "spi-device-addr", &tmp);
> + if (ret)
> + device_property_read_u32(dev, "microchip,hw-device-
> address", &tmp);
>
> if (tmp > 3) {
> dev_err_probe(dev, tmp,
>
> --
> 2.43.0
Reviewed-by: Marius Cristea <marius.cristea@microchip.com>
^ 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