* [PATCH 1/2] crypto: atmel-ecc - add support for atecc608b
From: Thorsten Blum @ 2026-03-30 10:08 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Tested on hardware with an ATECC608B at 0x60. The device binds
successfully, passes the driver's sanity check, and registers the
ecdh-nist-p256 KPP algorithm.
The hardware ECDH path was also exercised using a minimal KPP test
module, covering private key generation, public key derivation, and
shared secret computation.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index b6a77c8d439c..5793e0c44113 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -371,6 +371,8 @@ static void atmel_ecc_remove(struct i2c_client *client)
static const struct of_device_id atmel_ecc_dt_ids[] = {
{
.compatible = "atmel,atecc508a",
+ }, {
+ .compatible = "atmel,atecc608b",
}, {
/* sentinel */
}
@@ -380,6 +382,7 @@ MODULE_DEVICE_TABLE(of, atmel_ecc_dt_ids);
static const struct i2c_device_id atmel_ecc_id[] = {
{ "atecc508a" },
+ { "atecc608b" },
{ }
};
MODULE_DEVICE_TABLE(i2c, atmel_ecc_id);
^ permalink raw reply related
* [PATCH 4/4] KVM: arm64: nv: Create nested IPA direct map to speed up reverse map removal
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-1-weilin.chang@arm.com>
Iterating through the whole reverse map to find which entries to remove
when handling guest hypervisor TLBIs is not efficient. Create a direct
map that goes from nested IPA to canonical IPA so that the canonical
IPA range affected by the TLBI can be quickly determined, then remove
the entries in the reverse map accordingly.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 3 +
arch/arm64/kvm/mmu.c | 2 +
arch/arm64/kvm/nested.c | 131 ++++++++++++++++++++----------
3 files changed, 95 insertions(+), 41 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 06f83bb7ff1d..6b0858805530 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -220,6 +220,9 @@ struct kvm_s2_mmu {
/* canonical IPA to nested IPA range lookup, protected by kvm.mmu_lock */
struct maple_tree nested_revmap_mt;
+ /* nested IPA to canonical IPA range lookup, protected by kvm.mmu_lock */
+ struct maple_tree nested_direct_mt;
+
#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
struct dentry *shadow_pt_debugfs_dentry;
#endif
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 2b413d3dc790..9f27a9669ec9 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1010,6 +1010,7 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
kvm_init_nested_s2_mmu(mmu);
mt_init(&mmu->nested_revmap_mt);
+ mt_init(&mmu->nested_direct_mt);
return 0;
@@ -1112,6 +1113,7 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
mtree_destroy(&mmu->nested_revmap_mt);
if (kvm_is_nested_s2_mmu(kvm, mmu)) {
+ mtree_destroy(&mmu->nested_direct_mt);
kvm_init_nested_s2_mmu(mmu);
}
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 125fa21ca2e7..4c96130abf82 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -45,13 +45,12 @@ struct vncr_tlb {
#define S2_MMU_PER_VCPU 2
/*
- * Per shadow S2 reverse map (IPA -> nested IPA range) maple tree payload
- * layout:
+ * Per shadow S2 reverse & direct map maple tree payload layout:
*
- * bits 55-12: nested IPA bits 55-12
- * bit 0: polluted, 1 for polluted, 0 for not
+ * bits 55-12: {nested, canonical} IPA bits 55-12
+ * bit 0: polluted, 1 for polluted, 0 for not, only used in reverse map
*/
-#define NESTED_IPA_MASK GENMASK_ULL(55, 12)
+#define ADDR_MASK GENMASK_ULL(55, 12)
#define UNKNOWN_IPA BIT(0)
void kvm_init_nested(struct kvm *kvm)
@@ -915,74 +914,118 @@ static int record_accel(struct kvm_s2_mmu *mmu, gpa_t gpa,
void kvm_remove_nested_revmap(struct kvm_s2_mmu *mmu, u64 addr, u64 size)
{
/*
- * Iterate through the mt of this mmu, remove all unpolluted canonical
- * ipa ranges that maps to ranges that are strictly within
- * [addr, addr + size).
+ * For all ranges in direct_mt that are completely covered by the range
+ * we are TLBIing [addr, addr + size), we remove the reverse map AND
+ * its corresponding direct map together, when these conditions are
+ * met:
+ *
+ * 1. The TLBI range completely covers the stored nested IPA range.
+ * 2. The reverse map is not polluted. This ensures the reverse map
+ * and the direct map are 1:1.
*/
- struct maple_tree *mt = &mmu->nested_revmap_mt;
- void *entry;
- u64 nested_ipa, nested_ipa_end, addr_end = addr + size;
- size_t revmap_size;
+ struct maple_tree *direct_mt = &mmu->nested_direct_mt;
+ struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
+ gpa_t nested_ipa_start = addr;
+ gpa_t nested_ipa_end = addr + size - 1;
+ u64 entry_ipa, entry_nested_ipa;
+ u64 ipa, ipa_end;
- MA_STATE(mas, mt, 0, ULONG_MAX);
+ MA_STATE(mas_nested_ipa, direct_mt, nested_ipa_start, nested_ipa_end);
+ entry_ipa = (u64)mas_find_range(&mas_nested_ipa, nested_ipa_end);
- mas_for_each(&mas, entry, ULONG_MAX) {
- if ((u64)entry & UNKNOWN_IPA)
- continue;
+ while (entry_ipa && mas_nested_ipa.index <= nested_ipa_end) {
+ ipa = entry_ipa & ADDR_MASK;
+ ipa_end = ipa + mas_nested_ipa.last - mas_nested_ipa.index;
- revmap_size = mas.last - mas.index + 1;
- nested_ipa = (u64)entry & NESTED_IPA_MASK;
- nested_ipa_end = nested_ipa + revmap_size;
+ /* Use ipa range to find the corresponding entry in revmap. */
+ MA_STATE(mas_ipa, revmap_mt, ipa, ipa_end);
+ entry_nested_ipa = (u64)mas_find_range(&mas_ipa, ipa_end);
- if (nested_ipa >= addr && nested_ipa_end <= addr_end) {
- accel_clear_mmu_range(mmu, mas.index, revmap_size);
- mas_erase(&mas);
+ /*
+ * Reverse and direct map are created together at s2 faults,
+ * thus every direct map range should also have a corresponding
+ * reverse map range, however that can be polluted.
+ */
+ BUG_ON(!entry_nested_ipa);
+
+ /* The two conditions outlined above. */
+ if (!(entry_nested_ipa & UNKNOWN_IPA) &&
+ mas_nested_ipa.index >= addr &&
+ mas_nested_ipa.last <= nested_ipa_end) {
+ /*
+ * If the reverse map isn't polluted, the direct and
+ * reverse map are expected to be 1:1, thus they must
+ * have the same size.
+ */
+ BUG_ON(mas_ipa.last - mas_ipa.index !=
+ mas_nested_ipa.last - mas_nested_ipa.index);
+
+ accel_clear_mmu_range(mmu, mas_ipa.index,
+ mas_ipa.last - mas_ipa.index + 1);
+ mas_erase(&mas_ipa);
+ mas_erase(&mas_nested_ipa);
}
+ entry_ipa = (u64)mas_find_range(&mas_nested_ipa, nested_ipa_end);
}
}
int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
gpa_t fault_ipa, size_t map_size)
{
- struct maple_tree *mt = &mmu->nested_revmap_mt;
- gpa_t start = ipa;
- gpa_t end = ipa + map_size - 1;
+ struct maple_tree *direct_mt = &mmu->nested_direct_mt;
+ struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
+ gpa_t ipa_start = ipa;
+ gpa_t ipa_end = ipa + map_size - 1;
+ gpa_t fault_ipa_end = fault_ipa + map_size - 1;
u64 entry, new_entry = 0;
int r = 0;
lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
- MA_STATE(mas, mt, start, end);
+ MA_STATE(mas_ipa, revmap_mt, ipa_start, ipa_end);
+ MA_STATE(mas_nested_ipa, direct_mt, fault_ipa, fault_ipa_end);
r = record_accel(mmu, ipa, map_size);
if (r)
goto out;
- entry = (u64)mas_find_range(&mas, end);
+ r = mas_store_gfp(&mas_nested_ipa, (void *)ipa, GFP_KERNEL_ACCOUNT);
+ /*
+ * In the case of direct map store failure, don't clean up
+ * record_accel()'s successfully installed accel mt entry. Keeping
+ * it is fine as it will just cause us to check a few more s2 mmus
+ * in the mmu notifier.
+ */
+ if (r)
+ goto out;
+
+ entry = (u64)mas_find_range(&mas_ipa, ipa_end);
if (entry) {
/* maybe just a perm update... */
- if (!(entry & UNKNOWN_IPA) && mas.index == start &&
- mas.last == end &&
- fault_ipa == (entry & NESTED_IPA_MASK))
+ if (!(entry & UNKNOWN_IPA) && mas_ipa.index == ipa_start &&
+ mas_ipa.last == ipa_end &&
+ fault_ipa == (entry & ADDR_MASK))
goto out;
/*
* Remove every overlapping range, then create a "polluted"
* range that spans all these ranges and store it.
*/
- while (entry && mas.index <= end) {
- start = min(mas.index, start);
- end = max(mas.last, end);
- mas_erase(&mas);
- entry = (u64)mas_find_range(&mas, end);
+ while (entry && mas_ipa.index <= ipa_end) {
+ ipa_start = min(mas_ipa.index, ipa_start);
+ ipa_end = max(mas_ipa.last, ipa_end);
+ mas_erase(&mas_ipa);
+ entry = (u64)mas_find_range(&mas_ipa, ipa_end);
}
new_entry |= UNKNOWN_IPA;
} else {
new_entry |= fault_ipa;
}
- mas_set_range(&mas, start, end);
- r = mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
+ mas_set_range(&mas_ipa, ipa_start, ipa_end);
+ r = mas_store_gfp(&mas_ipa, (void *)new_entry, GFP_KERNEL_ACCOUNT);
+ if (r)
+ mas_erase(&mas_nested_ipa);
out:
return r;
}
@@ -1371,13 +1414,14 @@ void kvm_nested_s2_wp(struct kvm *kvm)
static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
size_t unmap_size, bool may_block)
{
- struct maple_tree *mt = &mmu->nested_revmap_mt;
+ struct maple_tree *direct_mt = &mmu->nested_direct_mt;
+ struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
gpa_t start = gpa;
gpa_t end = gpa + unmap_size - 1;
u64 entry;
size_t entry_size;
- MA_STATE(mas, mt, gpa, end);
+ MA_STATE(mas, revmap_mt, gpa, end);
entry = (u64)mas_find_range(&mas, end);
while (entry && mas.index <= end) {
@@ -1388,15 +1432,18 @@ static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
* touches any polluted range.
*/
if (entry & UNKNOWN_IPA) {
- mtree_destroy(mt);
+ mtree_destroy(direct_mt);
+ mtree_destroy(revmap_mt);
accel_clear_mmu(mmu);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu),
may_block);
return;
}
+ /* not polluted, direct map and reverse map must be 1:1 */
+ mtree_erase(direct_mt, entry & ADDR_MASK);
mas_erase(&mas);
accel_clear_mmu_range(mmu, mas.index, entry_size);
- kvm_stage2_unmap_range(mmu, entry & NESTED_IPA_MASK, entry_size,
+ kvm_stage2_unmap_range(mmu, entry & ADDR_MASK, entry_size,
may_block);
/*
* Other maple tree operations during preemption could render
@@ -1447,6 +1494,7 @@ void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
if (kvm_s2_mmu_valid(mmu)) {
+ mtree_destroy(&mmu->nested_direct_mt);
mtree_destroy(&mmu->nested_revmap_mt);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
}
@@ -2135,6 +2183,7 @@ void check_nested_vcpu_requests(struct kvm_vcpu *vcpu)
write_lock(&vcpu->kvm->mmu_lock);
if (mmu->pending_unmap) {
+ mtree_destroy(&mmu->nested_direct_mt);
mtree_destroy(&mmu->nested_revmap_mt);
accel_clear_mmu(mmu);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), true);
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] KVM: arm64: nv: Remove reverse map entries during TLBI handling
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-1-weilin.chang@arm.com>
When a guest hypervisor issues a TLBI for a specific IPA range, KVM
unmaps that range from all the effected shadow stage-2s. During this we
get the opportunity to remove the reverse map, and lower the probability
of creating polluted reverse map ranges at subsequent stage-2 faults.
However, the TLBI ranges are specified in nested IPA, so in order to
locate the affected ranges in the reverse map maple tree, which is a
mapping from canonical IPA to nested IPA, we can only iterate through
the entire tree and check each entry.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/include/asm/kvm_nested.h | 1 +
arch/arm64/kvm/nested.c | 29 +++++++++++++++++++++++++++++
arch/arm64/kvm/sys_regs.c | 3 +++
3 files changed, 33 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
index 4d09d567d7f9..376619cdc9d5 100644
--- a/arch/arm64/include/asm/kvm_nested.h
+++ b/arch/arm64/include/asm/kvm_nested.h
@@ -76,6 +76,7 @@ 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_remove_nested_revmap(struct kvm_s2_mmu *mmu, u64 addr, u64 size);
extern int kvm_record_nested_revmap(gpa_t gpa, struct kvm_s2_mmu *mmu,
gpa_t fault_gpa, size_t map_size);
extern void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index c7d00cb40ba5..125fa21ca2e7 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -912,6 +912,35 @@ static int record_accel(struct kvm_s2_mmu *mmu, gpa_t gpa,
return mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
}
+void kvm_remove_nested_revmap(struct kvm_s2_mmu *mmu, u64 addr, u64 size)
+{
+ /*
+ * Iterate through the mt of this mmu, remove all unpolluted canonical
+ * ipa ranges that maps to ranges that are strictly within
+ * [addr, addr + size).
+ */
+ struct maple_tree *mt = &mmu->nested_revmap_mt;
+ void *entry;
+ u64 nested_ipa, nested_ipa_end, addr_end = addr + size;
+ size_t revmap_size;
+
+ MA_STATE(mas, mt, 0, ULONG_MAX);
+
+ mas_for_each(&mas, entry, ULONG_MAX) {
+ if ((u64)entry & UNKNOWN_IPA)
+ continue;
+
+ revmap_size = mas.last - mas.index + 1;
+ nested_ipa = (u64)entry & NESTED_IPA_MASK;
+ nested_ipa_end = nested_ipa + revmap_size;
+
+ if (nested_ipa >= addr && nested_ipa_end <= addr_end) {
+ accel_clear_mmu_range(mmu, mas.index, revmap_size);
+ mas_erase(&mas);
+ }
+ }
+}
+
int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
gpa_t fault_ipa, size_t map_size)
{
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e1001544d4f4..c7af0eac9ee4 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -4006,6 +4006,7 @@ union tlbi_info {
static void s2_mmu_unmap_range(struct kvm_s2_mmu *mmu,
const union tlbi_info *info)
{
+ kvm_remove_nested_revmap(mmu, info->range.start, info->range.size);
/*
* The unmap operation is allowed to drop the MMU lock and block, which
* means that @mmu could be used for a different context than the one
@@ -4104,6 +4105,8 @@ static void s2_mmu_unmap_ipa(struct kvm_s2_mmu *mmu,
max_size = compute_tlb_inval_range(mmu, info->ipa.addr);
base_addr &= ~(max_size - 1);
+ kvm_remove_nested_revmap(mmu, base_addr, max_size);
+
/*
* See comment in s2_mmu_unmap_range() for why this is allowed to
* reschedule.
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] KVM: arm64: nv: Accelerate canonical IPA unmapping with canonical s2 mmu maple tree
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-1-weilin.chang@arm.com>
Checking every nested mmu during canonical IPA unmapping is slow,
especially when there are many valid nested mmus. We can leverage the
unused maple tree in the canonical kvm_s2_mmu to accelerate this
process.
At stage-2 fault time, other than recording the reverse map, also add an
entry in canonical s2 mmu's maple tree, with the canonical IPA range as
the key, and the "nested s2 mmu this fault is happending to" encoded in
the entry.
With the new maple tree for acceleration's information, at canonical
IPA unmap time we can look into the tree to retrieve the nested mmus
affected by this unmap much quicker.
In terms of encoding the nested mmus in the entry, there are 62 bits
available for each entry (bits 1 and 0 are reserved by the maple tree).
Each bit represents a number of nested mmus base on the total number of
nested mmus, this value grows in power of 2, so for example:
total nested mmus: 1-62 -> each bit represents: 1 nested mmu
63-124 -> 2 nested mmus
125-248 -> 4 nested mmus
... ...
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/mmu.c | 5 +-
arch/arm64/kvm/nested.c | 166 ++++++++++++++++++++++++++++--
3 files changed, 163 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 1d0db7f268cc..06f83bb7ff1d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -321,6 +321,7 @@ struct kvm_arch {
struct kvm_s2_mmu *nested_mmus;
size_t nested_mmus_size;
int nested_mmus_next;
+ int mmus_per_bit_power;
/* Interrupt controller */
struct vgic_dist vgic;
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 6beb07d817c8..2b413d3dc790 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1009,6 +1009,8 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
if (kvm_is_nested_s2_mmu(kvm, mmu))
kvm_init_nested_s2_mmu(mmu);
+ mt_init(&mmu->nested_revmap_mt);
+
return 0;
out_destroy_pgtable:
@@ -1107,8 +1109,9 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
free_percpu(mmu->last_vcpu_ran);
}
+ mtree_destroy(&mmu->nested_revmap_mt);
+
if (kvm_is_nested_s2_mmu(kvm, mmu)) {
- mtree_destroy(&mmu->nested_revmap_mt);
kvm_init_nested_s2_mmu(mmu);
}
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 53392cc7dbae..c7d00cb40ba5 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -80,7 +80,7 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
{
struct kvm *kvm = vcpu->kvm;
struct kvm_s2_mmu *tmp;
- int num_mmus, ret = 0;
+ int num_mmus, power = 0, ret = 0;
if (test_bit(KVM_ARM_VCPU_HAS_EL2_E2H0, kvm->arch.vcpu_features) &&
!cpus_have_final_cap(ARM64_HAS_HCR_NV1))
@@ -131,6 +131,25 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
kvm->arch.nested_mmus_size = num_mmus;
+ /*
+ * Calculate how many s2 mmus are represented by each bit in the
+ * acceleration maple tree entries.
+ *
+ * power == 0 -> 1 s2 mmu
+ * power == 1 -> 2 s2 mmus
+ * power == 2 -> 4 s2 mmus
+ * power == 3 -> 8 s2 mmus
+ * etc.
+ *
+ * We use only the top 62 bits in the canonical s2 mmu maple tree
+ * entries, bits 0 and 1 are not used, since maple trees reserve values
+ * with bit patterns ending in 10 that are also smaller that 4096.
+ */
+ while (62 * (1 << power) < kvm->arch.nested_mmus_size)
+ power++;
+
+ kvm->arch.mmus_per_bit_power = power;
+
return 0;
}
@@ -780,6 +799,119 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
return s2_mmu;
}
+static int s2_mmu_to_accel_bit(struct kvm_s2_mmu *mmu)
+{
+ BUG_ON(&mmu->arch->mmu == mmu);
+
+ int index = mmu - mmu->arch->nested_mmus;
+ int power = mmu->arch->mmus_per_bit_power;
+
+ return (index >> power) + 2;
+}
+
+/* this returns the first s2 mmu from the span */
+static struct kvm_s2_mmu *accel_bit_to_s2_mmu(struct kvm *kvm, int bit)
+{
+ int power = kvm->arch.mmus_per_bit_power;
+ int index = (bit - 2) << power;
+
+ BUG_ON(index >= kvm->arch.nested_mmus_size);
+
+ return &kvm->arch.nested_mmus[index];
+}
+
+static void accel_clear_mmu_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
+ size_t size)
+{
+ struct maple_tree *mt = &mmu->arch->mmu.nested_revmap_mt;
+ int bit = s2_mmu_to_accel_bit(mmu);
+ void *entry, *new_entry;
+ gpa_t start = gpa;
+ gpa_t end = gpa + size - 1;
+
+ if (mmu->arch->mmus_per_bit_power > 0) {
+ /* sadly nothing we can do here... */
+ return;
+ }
+
+ MA_STATE(mas, mt, start, end);
+
+ entry = mas_find_range(&mas, end);
+ BUG_ON(!entry);
+
+ /*
+ * 1. Ranges smaller than the queried range should not exist, because
+ * for the same mmu, the same ranges are added in both the accel mt
+ * and the mmu's mt at fault time.
+ *
+ * 2. Ranges larger than the queried range could exist, since
+ * another mmu could have a range mapped on top.
+ * However in this case we don't know whether there are other
+ * smaller ranges in this larger range that belongs to this same
+ * mmu, so we can't just remove the bit.
+ */
+ if (mas.index == start && mas.last == end) {
+ new_entry = (void *)((unsigned long)entry & ~BIT(bit));
+ /*
+ * This naturally clears the range from the mt if
+ * new_entry == 0.
+ */
+ mas_store_gfp(&mas, new_entry, GFP_KERNEL_ACCOUNT);
+ }
+}
+
+static void accel_clear_mmu(struct kvm_s2_mmu *mmu)
+{
+ struct maple_tree *mt = &mmu->arch->mmu.nested_revmap_mt;
+ int bit = s2_mmu_to_accel_bit(mmu);
+ void *entry, *new_entry;
+
+ if (mmu->arch->mmus_per_bit_power > 0) {
+ /* sadly nothing we can do here... */
+ return;
+ }
+
+ MA_STATE(mas, mt, 0, ULONG_MAX);
+
+ mas_for_each(&mas, entry, ULONG_MAX) {
+ new_entry = (void *)((unsigned long)entry & ~BIT(bit));
+ /*
+ * This naturally clears the range from the mt if
+ * new_entry == 0.
+ */
+ mas_store_gfp(&mas, new_entry, GFP_KERNEL_ACCOUNT);
+ }
+}
+
+static int record_accel(struct kvm_s2_mmu *mmu, gpa_t gpa,
+ size_t map_size)
+{
+ struct maple_tree *mt = &mmu->arch->mmu.nested_revmap_mt;
+ gpa_t start = gpa;
+ gpa_t end = gpa + map_size - 1;
+ u64 entry, new_entry = 0;
+
+ MA_STATE(mas, mt, start, end);
+ entry = (u64)mas_find_range(&mas, end);
+
+ /*
+ * OR every overlapping range's entry, then create a
+ * range that spans all these ranges and store it.
+ */
+ while (entry && mas.index <= end) {
+ start = min(mas.index, start);
+ end = max(mas.last, end);
+ new_entry |= entry;
+ mas_erase(&mas);
+ entry = (u64)mas_find_range(&mas, end);
+ }
+
+ new_entry |= BIT(s2_mmu_to_accel_bit(mmu));
+ mas_set_range(&mas, start, end);
+
+ return mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
+}
+
int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
gpa_t fault_ipa, size_t map_size)
{
@@ -792,6 +924,11 @@ int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
MA_STATE(mas, mt, start, end);
+
+ r = record_accel(mmu, ipa, map_size);
+ if (r)
+ goto out;
+
entry = (u64)mas_find_range(&mas, end);
if (entry) {
@@ -827,7 +964,6 @@ void kvm_init_nested_s2_mmu(struct kvm_s2_mmu *mmu)
mmu->tlb_vttbr = VTTBR_CNP_BIT;
mmu->nested_stage2_enabled = false;
atomic_set(&mmu->refcnt, 0);
- mt_init(&mmu->nested_revmap_mt);
}
void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu)
@@ -1224,11 +1360,13 @@ static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
*/
if (entry & UNKNOWN_IPA) {
mtree_destroy(mt);
+ accel_clear_mmu(mmu);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu),
may_block);
return;
}
mas_erase(&mas);
+ accel_clear_mmu_range(mmu, mas.index, entry_size);
kvm_stage2_unmap_range(mmu, entry & NESTED_IPA_MASK, entry_size,
may_block);
/*
@@ -1243,17 +1381,27 @@ static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
void kvm_unmap_gfn_range_nested(struct kvm *kvm, gpa_t gpa, size_t size,
bool may_block)
{
- int i;
+ struct maple_tree *mt = &kvm->arch.mmu.nested_revmap_mt;
+ gpa_t start = gpa;
+ gpa_t end = gpa + size - 1;
+ u64 entry;
+ int bit, i = 0;
+ int power = kvm->arch.mmus_per_bit_power;
+ struct kvm_s2_mmu *mmu;
+ MA_STATE(mas, mt, start, end);
if (!kvm->arch.nested_mmus_size)
return;
- /* TODO: accelerate this using mt of canonical s2 mmu */
- for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
- struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+ entry = (u64)mas_find_range(&mas, end);
- if (kvm_s2_mmu_valid(mmu))
- unmap_mmu_ipa_range(mmu, gpa, size, may_block);
+ while (entry && mas.index <= end) {
+ for_each_set_bit(bit, (unsigned long *)&entry, 64) {
+ mmu = accel_bit_to_s2_mmu(kvm, bit);
+ for (i = 0; i < (1 << power); i++)
+ unmap_mmu_ipa_range(mmu + i, gpa, size, may_block);
+ }
+ entry = (u64)mas_find_range(&mas, end);
}
}
@@ -1274,6 +1422,7 @@ void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
}
}
+ mtree_destroy(&kvm->arch.mmu.nested_revmap_mt);
kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
}
@@ -1958,6 +2107,7 @@ void check_nested_vcpu_requests(struct kvm_vcpu *vcpu)
write_lock(&vcpu->kvm->mmu_lock);
if (mmu->pending_unmap) {
mtree_destroy(&mmu->nested_revmap_mt);
+ accel_clear_mmu(mmu);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), true);
mmu->pending_unmap = false;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 1/4] KVM: arm64: nv: Avoid full shadow s2 unmap
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-1-weilin.chang@arm.com>
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, erase
those existing ranges, and create a new range that spans all the
overlapping ranges including the input range. In the mean time, mark
this new spanning canonical IPA range as "polluted" indicating we lost
track of 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
polluted status (stored as a bit called UNKNOWN_IPA), therefore besides
maple tree's internal operation, memory allocation is avoided.
Example:
|||| means existing range, ---- means empty range
input: $$$$$$$$$$$$$$$$$$$$$$$$$$
tree: --||||-----|||||||---------||||||||||-----------
free overlaps:
--||||------------------------------------------
insert spanning range:
--||||-----||||||||||||||||||||||||||-----------
^^^^^^^^polluted!^^^^^^^^^
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 polluted status:
polluted -> fall back and fully invalidate the current shadow stage-2,
also clear the tree
not polluted -> 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 | 3 +
arch/arm64/include/asm/kvm_nested.h | 4 +
arch/arm64/kvm/mmu.c | 27 +++++--
arch/arm64/kvm/nested.c | 112 +++++++++++++++++++++++++++-
4 files changed, 140 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 8545811e2238..1d0db7f268cc 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -217,6 +217,9 @@ struct kvm_s2_mmu {
*/
bool nested_stage2_enabled;
+ /* canonical IPA to nested IPA range lookup, protected by kvm.mmu_lock */
+ 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..4d09d567d7f9 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 int kvm_record_nested_revmap(gpa_t gpa, struct kvm_s2_mmu *mmu,
+ gpa_t fault_gpa, 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 17d64a1e11e5..6beb07d817c8 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1107,8 +1107,10 @@ 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)) {
+ mtree_destroy(&mmu->nested_revmap_mt);
kvm_init_nested_s2_mmu(mmu);
+ }
write_unlock(&kvm->mmu_lock);
@@ -1625,6 +1627,13 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
goto out_unlock;
}
+ if (nested) {
+ ret = kvm_record_nested_revmap(gfn << PAGE_SHIFT, pgt->mmu,
+ fault_ipa, PAGE_SIZE);
+ if (ret)
+ goto out_unlock;
+ }
+
ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault_ipa, PAGE_SIZE,
__pfn_to_phys(pfn), prot,
memcache, flags);
@@ -1922,6 +1931,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
prot &= ~KVM_NV_GUEST_MAP_SZ;
ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, fault_ipa, prot, flags);
} else {
+ if (nested) {
+ ret = kvm_record_nested_revmap(gfn << PAGE_SHIFT, pgt->mmu,
+ fault_ipa, vma_pagesize);
+ if (ret)
+ goto out_unlock;
+ }
ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault_ipa, vma_pagesize,
__pfn_to_phys(pfn), prot,
memcache, flags);
@@ -2223,14 +2238,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)
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);
+ kvm_unmap_gfn_range_nested(kvm, gpa, size, may_block);
- kvm_nested_s2_unmap(kvm, range->may_block);
return false;
}
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 883b6c1008fb..53392cc7dbae 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,16 @@ struct vncr_tlb {
*/
#define S2_MMU_PER_VCPU 2
+/*
+ * Per shadow S2 reverse map (IPA -> nested IPA range) maple tree payload
+ * layout:
+ *
+ * bits 55-12: nested IPA bits 55-12
+ * bit 0: polluted, 1 for polluted, 0 for not
+ */
+#define NESTED_IPA_MASK GENMASK_ULL(55, 12)
+#define UNKNOWN_IPA BIT(0)
+
void kvm_init_nested(struct kvm *kvm)
{
kvm->arch.nested_mmus = NULL;
@@ -769,12 +780,54 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
return s2_mmu;
}
+int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
+ gpa_t fault_ipa, size_t map_size)
+{
+ struct maple_tree *mt = &mmu->nested_revmap_mt;
+ gpa_t start = ipa;
+ gpa_t end = ipa + map_size - 1;
+ u64 entry, new_entry = 0;
+ int r = 0;
+
+ lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
+
+ MA_STATE(mas, mt, start, end);
+ entry = (u64)mas_find_range(&mas, end);
+
+ if (entry) {
+ /* maybe just a perm update... */
+ if (!(entry & UNKNOWN_IPA) && mas.index == start &&
+ mas.last == end &&
+ fault_ipa == (entry & NESTED_IPA_MASK))
+ goto out;
+ /*
+ * Remove every overlapping range, then create a "polluted"
+ * range that spans all these ranges and store it.
+ */
+ while (entry && mas.index <= end) {
+ start = min(mas.index, start);
+ end = max(mas.last, end);
+ mas_erase(&mas);
+ entry = (u64)mas_find_range(&mas, end);
+ }
+ new_entry |= UNKNOWN_IPA;
+ } else {
+ new_entry |= fault_ipa;
+ }
+
+ mas_set_range(&mas, start, end);
+ r = mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
+out:
+ return r;
+}
+
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);
}
void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu)
@@ -1150,6 +1203,60 @@ void kvm_nested_s2_wp(struct kvm *kvm)
kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
}
+static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
+ size_t unmap_size, bool may_block)
+{
+ struct maple_tree *mt = &mmu->nested_revmap_mt;
+ gpa_t start = gpa;
+ gpa_t end = gpa + unmap_size - 1;
+ u64 entry;
+ size_t entry_size;
+
+ MA_STATE(mas, mt, gpa, end);
+ entry = (u64)mas_find_range(&mas, end);
+
+ while (entry && mas.index <= end) {
+ start = mas.last + 1;
+ entry_size = mas.last - mas.index + 1;
+ /*
+ * Give up and invalidate this s2 mmu if the unmap range
+ * touches any polluted range.
+ */
+ if (entry & UNKNOWN_IPA) {
+ mtree_destroy(mt);
+ kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu),
+ may_block);
+ return;
+ }
+ mas_erase(&mas);
+ kvm_stage2_unmap_range(mmu, entry & NESTED_IPA_MASK, entry_size,
+ may_block);
+ /*
+ * Other maple tree operations during preemption could render
+ * this ma_state invalid, so reset it.
+ */
+ mas_set_range(&mas, start, end);
+ entry = (u64)mas_find_range(&mas, end);
+ }
+}
+
+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;
+
+ /* TODO: accelerate this using mt of canonical s2 mmu */
+ 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);
+ }
+}
+
void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
{
int i;
@@ -1162,8 +1269,10 @@ void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
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))
+ if (kvm_s2_mmu_valid(mmu)) {
+ mtree_destroy(&mmu->nested_revmap_mt);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
+ }
}
kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
@@ -1848,6 +1957,7 @@ void check_nested_vcpu_requests(struct kvm_vcpu *vcpu)
write_lock(&vcpu->kvm->mmu_lock);
if (mmu->pending_unmap) {
+ mtree_destroy(&mmu->nested_revmap_mt);
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), true);
mmu->pending_unmap = false;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 0/4] KVM: arm64: nv: Implement nested stage-2 reverse map
From: Wei-Lin Chang @ 2026-03-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
Hi,
This series optimizes the shadow s2 mmu unmapping during MMU notifiers.
Motivation
==========
KVM registers MMU notifiers to unmap stage-2 mappings for the guest when
the backing memory's userspace VA to PA translation has changed, some
reasons include memory reclaim and and migration. In the non-NV case
this is straight forward, the registered function simply unmaps the VM's
IPA from the stage-2 page tables. However, in the NV case the nested
MMUs store nested IPA to PA mappings, and we have no clue which of these
nested mappings are backed by the same memory that the MMU notifiers are
unmapping. The consequence is that since we don't know which nested
mappings should be removed, we can only unmap every nested MMU in its
entirety within the guest to be safe. This kills performance when MMU
notifiers are called often, and we would like a better alternative than
unmapping all shadow stage-2s everytime.
Design
======
The basic idea is create a reverse map from the canonical IPA to the
nested IPA, so that when the MMU notifier informs us about the canonical
IPA range that must be unmapped, we can look up the reverse map to find
the nested IPA range affected and unmap it from the nested MMU. To
achieve fine grained unmapping, each nested MMU is equipped with its own
reverse map.
The maple tree is chosen to store the reverse map, mainly for its good
support for dealing with ranges. Two methods of storing the reverse map
are considered: either using the canonical IPA as the key for the tree,
or using the PA as the key for the tree, the value stored is the nested
IPA range for both. In this series the method using canonical IPA as the
key is implemented, which I believe is a better scheme. A comparison
between the two is presented in a later section.
It is possible for a nested context to have multiple nested IPA ranges
mapped to the same IPA. In these cases idealy our reverse map should
contain 1-to-many relations, so that we are able to find all nested IPA
ranges to unmap during MMU notifiers. However since this requires more
information than what a 64 bit maple tree value can store, we will be
forced to store the information in allocated data pointed to by the
maple tree value. This creates extra memory we have to manage, and
increases the maintenance effort from tracking 1-to-many mappings, for
example by keeping a linked list of nested IPA ranges.
Instead, we introduce what is called the "polluted" canonical IPA
ranges, which means for these canonical IPA ranges we have lost track of
what nested IPA ranges are mapped to this canonical IPA range. Polluted
canonical IPA ranges are created when at shadow stage-2 fault time, we
find that the canonical IPA range we are trying to insert to the reverse
map overlaps one or more pre-existing ranges, in this case the minimum
polluted spanning range is calculated and inserted to replace all
pre-existing ranges.
Example:
|||| means existing range, ---- means empty range
input: $$$$$$$$$$$$$$$$$$$$$$$$$$
tree: --||||-----|||||||---------||||||||||-----------
free overlaps:
--||||------------------------------------------
insert spanning polluted range:
--||||-----||||||||||||||||||||||||||-----------
^^^^^^^^polluted!^^^^^^^^^
Later when a request to unmap a canonical IPA range arises which affects
a polluted canonical IPA range, simply fall back to unmapping the entire
nested MMU.
MMU notifier optimization
=========================
Every nested MMU keeps its own reverse map, therefore we must check
every nested MMU when we unmap canonical IPA ranges in the MMU notifier,
which is not efficient. We can leverage the canonical stage-2 MMU's
unused maple tree to point to the nested MMUs that hold mappings
of each stored canonical IPA range. This is implemented in patch 2 with
more detail in the commit message.
TLBI handling
=============
When a guest hypervisor issues a TLBI for a specific IPA range, KVM
unmaps that range from all the effected shadow stage-2s. During this we
get the opportunity to remove the reverse map, and lower the probability
of creating polluted reverse map ranges at subsequent stage-2 faults.
However, the TLBI ranges are specified in nested IPA, so in order to
locate the affected ranges in the reverse map maple tree, which is a
mapping from canonical IPA to nested IPA, we can only iterate through
the entire tree and check each entry. This is implemented in patch 3.
In patch 4, we further improve this by introducing a direct map that
goes from nested IPA to canonical IPA, allowing us to quicky locate
which reverse mapping to remove when handed a nested IPA range during
TLBI handling.
Reverse map key, canonical IPA vs PA
====================================
This is a brief comparison of using either canonical IPA or PA as the
key to the reverse map, base on the 4 aspects of the implementation.
Reverse map creation
--------------------
Using both canonical IPA and PA requires almost identical operations.
Canonical IPA unmapping (MMU notifier)
--------------------------------------
For canonical IPA as the key, simply search the reverse map and
invalidate the retrieved nested IPA range.
For PA as the key, we must first translate the given canonical IPA range
into PA either via
a) walking the user space page table or..
b) calling kvm_gmem_get_pfn() if the memslot is a guest_memfd one
Further, kvm_gmem_get_pfn() forcefully allocates the physical page if
the queried canonical IPA is not faulted in. This of course is not
acceptable for our use case, so writing some guest_memfd code will be
required for this to work.
Canonical IPA unmapping optimization
------------------------------------
Using both canonical IPA and PA requires identical operation.
TLBI handling
-------------
For canonical IPA as the key, like said above we can either:
a) iterate the reverse map to find the entry to remove, or
b) create a direct map to find the canonical IPA range
For PA as the key, it is more straightforward, simply find the PA by
walking the shadow stage-2, then remove the PA range from the reverse
map. However this still requires a page table walk.
Summary
-------
I believe it is clear that using canonical IPA as the key saves us a lot
of trouble:
a) no page table walks are required
b) we go from dealing with 3 address spaces (PA, canonical IPA, nested
IPA) to 2 (canonical IPA, nested IPA)
c) the problem with guest_memfd is circumvented
Locking
=======
All maple trees are protected by kvm.mmu_lock, therefore no maple tree
locks are taken.
Testing
=======
The current plan to test is to enhance kselftest with NV capability, so
that we can instruct L1 and L2 to set up and access memory to populate
shadow page tables, userspace can then trigger MMU notifiers by e.g.
munmap, mremap, etc. During these operations userspace can read the
shadow page tables exposed in debugfs [1] to check whether the shadow
page tables are in an expected state or not.
Thanks!
[1]: https://lore.kernel.org/kvmarm/20260317182638.1592507-2-weilin.chang@arm.com
Wei-Lin Chang (4):
KVM: arm64: nv: Avoid full shadow s2 unmap
KVM: arm64: nv: Accelerate canonical IPA unmapping with canonical s2
mmu maple tree
KVM: arm64: nv: Remove reverse map entries during TLBI handling
KVM: arm64: nv: Create nested IPA direct map to speed up reverse map
removal
arch/arm64/include/asm/kvm_host.h | 7 +
arch/arm64/include/asm/kvm_nested.h | 5 +
arch/arm64/kvm/mmu.c | 32 ++-
arch/arm64/kvm/nested.c | 342 +++++++++++++++++++++++++++-
arch/arm64/kvm/sys_regs.c | 3 +
5 files changed, 382 insertions(+), 7 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH] net: lpc_eth: Fix a possible memory leak in lpc_mii_probe()
From: Vladimir Zapolskiy @ 2026-03-30 10:04 UTC (permalink / raw)
To: Ma Ke, piotr.wojtaszczyk, andrew+netdev, davem, edumazet, kuba,
pabeni, alexandre.belloni
Cc: linux-arm-kernel, netdev, linux-kernel, stable
In-Reply-To: <20260330081636.2887980-1-make24@iscas.ac.cn>
Hello Ma Ke,
On 3/30/26 11:16, Ma Ke wrote:
> lpc_mii_probe() calls of_phy_find_device() to obtain a phy_device
> pointer. of_phy_find_device() increments the refcount of the device.
> The current implementation does not decrement the refcount after using
> the pointer, which leads to a memory leak.
this is correct, there is an actual detected bug.
>
> Add phy_device_free() to balance the refcount.
But this does not sound right, you shoud use of_node_put(pldat->phy_node).
>
> Found by code review.
>
> Signed-off-by: Ma Ke <make24@iscas.ac.cn>
> Cc: stable@vger.kernel.org
> Fixes: 3503bf024b3e ("net: lpc_eth: parse phy nodes from device tree")
> ---
> drivers/net/ethernet/nxp/lpc_eth.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
> index 8b9a3e3bba30..8ce7c9bb6dd6 100644
> --- a/drivers/net/ethernet/nxp/lpc_eth.c
> +++ b/drivers/net/ethernet/nxp/lpc_eth.c
> @@ -751,7 +751,7 @@ static void lpc_handle_link_change(struct net_device *ndev)
> static int lpc_mii_probe(struct net_device *ndev)
> {
> struct netdata_local *pldat = netdev_priv(ndev);
> - struct phy_device *phydev;
> + struct phy_device *phydev, *phydev_tmp;
>
> /* Attach to the PHY */
> if (lpc_phy_interface_mode(&pldat->pdev->dev) == PHY_INTERFACE_MODE_MII)
> @@ -760,17 +760,18 @@ static int lpc_mii_probe(struct net_device *ndev)
> netdev_info(ndev, "using RMII interface\n");
>
> if (pldat->phy_node)
> - phydev = of_phy_find_device(pldat->phy_node);
> + phydev_tmp = of_phy_find_device(pldat->phy_node);
> else
> - phydev = phy_find_first(pldat->mii_bus);
> - if (!phydev) {
> + phydev_tmp = phy_find_first(pldat->mii_bus);
> + if (!phydev_tmp) {
I didn't get it, why the new phydev_tmp is needed above, please
restore the original code above.
> netdev_err(ndev, "no PHY found\n");
> return -ENODEV;
> }
>
> - phydev = phy_connect(ndev, phydev_name(phydev),
> + phydev = phy_connect(ndev, phydev_name(phydev_tmp),
> &lpc_handle_link_change,
> lpc_phy_interface_mode(&pldat->pdev->dev));
> + phy_device_free(phydev_tmp);
This is plainly wrong and has to be dropped or changed to
if (pldat->phy_node)
of_node_put(pldat->phy_node);
> if (IS_ERR(phydev)) {
> netdev_err(ndev, "Could not attach to PHY\n");
> return PTR_ERR(phydev);
Is it AI generated fix or what?.. The change looks bad, it introduces
more severe issues than it fixes.
If you think you cannot create a proper change, let me know.
--
Best wishes,
Vladimir
^ permalink raw reply
* [PATCH v3 0/2] Enable audio support for J721S2 EVM
From: Moteen Shah @ 2026-03-30 9:44 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
This patch series, adds support for analog audio on J721S2 EVM using
device tree overlays.
Earlier version of the patchset sent upstream[0] was rejected as
its dependency[1], which resolves the DTBS check errors introduced
by [0] also got rejected on the grounds of ABI breakage.
Another solution to fix the DTBS check errors introduced by [0] is
to modify the ti,j721e-system-controller.yaml binding to allow
audio-refclk as clock-controller child. This is done in the first
patch of this series.
Changes since v2:
Link to v2: https://lore.kernel.org/all/20260205130707.2033197-1-m-shah@ti.com/
- Fix Makefile entries to follow alphabetical ordering
- Update model string from "j721e-cpb" to "j721s2-cpb"
- Fix gpio-line-names typo: "UBS926_PWR_SW_CNTRL" -> "UB926_PWR_SW_CNTRL"
Changes since v1:
Link to v1: https://lore.kernel.org/all/20260112104536.83309-1-m-shah@ti.com/
- Convert the changes to an overlay
- Enumerate the I2C mux used
- Remove CANUART_MUX_SEL1 gpio hog
- Fix typos
- Add gpio-line-names
- Fix commit message to showcase the right idle-state for muxes
- Carry review from Rob and Hari
Test log: https://gist.github.com/Jamm02/4d4c00bf88fa76cddae6319124341c53
[0]: https://lore.kernel.org/linux-arm-kernel/20250604104656.38752-1-j-choudhary@ti.com/
[1]: https://lore.kernel.org/all/20250603095609.33569-4-j-choudhary@ti.com/
Jayesh Choudhary (1):
arm64: dts: ti: Add audio overlay for k3-j721s2-evm
Moteen Shah (1):
ti,j721e-system-controller.yaml: Allow audio-refclk as
clock-controller child
.../soc/ti/ti,j721e-system-controller.yaml | 6 +-
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 161 ++++++++++++++++++
3 files changed, 169 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
--
2.34.1
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 9:54 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFoz-sm0pfvn5iSYFY0mrW38vaGRZsFvrVPqsv7BsYxeWQ@mail.gmail.com>
On 23/03/2026 12:13, Ulf Hansson wrote:
> Hi Krzysztof,
>
> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>>
>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
>>> This series adds support for the power domains on Google GS101.
>>>
>>> There are a few differences compared to SoCs already supported by this
>>> driver:
>>> * register access does not work via plain ioremap() / readl() /
>>> writel().
>>> Instead, the regmap created by the PMU driver must be used (which
>>> uses Arm SMCC calls under the hood).
>>> * DTZPC: a call needs to be made before and after power domain off/on,
>>> to inform the EL3 firmware of the request.
>>> * power domains can and are fed by a regulator rail and therefore
>>> regulator control needed be implemented.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
>>
>> Best regards,
>
> Usually I pick up the power-domain related changes for the DT bindings
> and host them via an immutable branch called "dt". If needed, SOC
> maintainers can pull it to apply/test the corresponding DTS changes.
>
> That said, I am open to whatever you think is best here. Perhaps it's
> easier if you can drop the DT patches and provide your acks instead or
> if you can share them via an immutable branch for me to pull?
I did not pick up any pmdomain binding patches. I picked up only soc and
according to cover letter there are no dependencies between anything here.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm
From: Moteen Shah @ 2026-03-30 9:44 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260330094459.128648-1-m-shah@ti.com>
From: Jayesh Choudhary <j-choudhary@ti.com>
Add device tree overlay to enable analog audio support on J721S2-EVM
using PCM3168A codec connected to McASP4 serializers.
- Add nodes for sound-card, audio codec, I2C3 and McASP4
- Add pinmux for I2C3, McASP4, AUDIO_EXT_REFCLK1 and WKUP_GPIO_0
- Add GPIO expander (TCA6408) for codec control
- Add GPIO hogs to route I2C3 lines and McASP serializers
- Set idle-state to 0 in mux0 and mux1 for McASP signal routing
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Co-developed-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 161 ++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index ba01a929e06f..17048f2f5043 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-audio.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
@@ -264,6 +265,8 @@ k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie1-ep.dtbo
k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-j721s2-evm-audio-dtbs := k3-j721s2-common-proc-board.dtb \
+ k3-j721s2-evm-audio.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
k3-j721s2-evm-pcie1-ep.dtbo
k3-j721s2-evm-usb0-type-a-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -328,6 +331,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
+ k3-j721s2-evm-audio.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
new file mode 100644
index 000000000000..2a3ff1cfc650
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Device Tree Overlay for J721S2 Audio Support
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "k3-pinctrl.h"
+
+&{/} {
+ codec_audio: sound {
+ compatible = "ti,j7200-cpb-audio";
+ model = "j721s2-cpb";
+
+ ti,cpb-mcasp = <&mcasp4>;
+ ti,cpb-codec = <&pcm3168a_1>;
+
+ clocks = <&k3_clks 213 0>, <&k3_clks 213 1>,
+ <&k3_clks 157 299>, <&k3_clks 157 328>;
+ clock-names = "cpb-mcasp-auxclk", "cpb-mcasp-auxclk-48000",
+ "cpb-codec-scki", "cpb-codec-scki-48000";
+ };
+
+ i2c_mux: mux-controller-2 {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ mux-gpios = <&wkup_gpio0 54 GPIO_ACTIVE_HIGH>;
+ idle-state = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_mux_pins_default>;
+ };
+};
+
+&main_pmx0 {
+ mcasp4_pins_default: mcasp4-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x0c8, PIN_OUTPUT_PULLDOWN, 1) /* (AD28) MCASP4_ACLKX */
+ J721S2_IOPAD(0x06c, PIN_OUTPUT_PULLDOWN, 1) /* (V26) MCASP4_AFSX */
+ J721S2_IOPAD(0x068, PIN_INPUT_PULLDOWN, 1) /* (U28) MCASP4_AXR1 */
+ J721S2_IOPAD(0x0c4, PIN_OUTPUT_PULLDOWN, 1) /* (AB26) MCASP4_AXR2 */
+ J721S2_IOPAD(0x070, PIN_OUTPUT_PULLDOWN, 1) /* (R27) MCASP4_AXR3 */
+ >;
+ };
+
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x078, PIN_OUTPUT, 1) /* (Y25) MCAN2_RX.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+};
+
+&wkup_pmx2 {
+ main_i2c3_mux_pins_default: main-i2c3-mux-default-pins {
+ pinctrl-single,pins = <
+ J721S2_WKUP_IOPAD(0x038, PIN_OUTPUT, 7) /* (B27) WKUP_GPIO0_54 */
+ >;
+ };
+};
+
+&exp2 {
+ p09-hog {
+ /* P09 - MCASP/TRACE_MUX_S0 */
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "MCASP/TRACE_MUX_S0";
+ };
+
+ p10-hog {
+ /* P10 - MCASP/TRACE_MUX_S1 */
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MCASP/TRACE_MUX_S1";
+ };
+};
+
+&mux0 {
+ idle-state = <0>;
+};
+
+&mux1 {
+ idle-state = <0>;
+};
+
+&scm_conf {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ audio_refclk1: clock-controller@42e4 {
+ compatible = "ti,am62-audio-refclk";
+ reg = <0x42e4 0x4>;
+ clocks = <&k3_clks 157 299>;
+ assigned-clocks = <&k3_clks 157 299>;
+ assigned-clock-parents = <&k3_clks 157 328>;
+ #clock-cells = <0>;
+ };
+};
+
+&k3_clks {
+ /* Configure AUDIO_EXT_REFCLK1 pin as output */
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+};
+
+&main_i2c3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_pins_default>;
+ clock-frequency = <400000>;
+ mux-states = <&i2c_mux 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ exp3: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "CODEC_RSTZ", "CODEC_SPARE1",
+ "UB926_RESETN", "UB926_LOCK",
+ "UB926_PWR_SW_CNTRL", "UB926_TUNER_RESET",
+ "UB926_GPIO_SPARE";
+ };
+
+ pcm3168a_1: audio-codec@44 {
+ compatible = "ti,pcm3168a";
+ reg = <0x44>;
+ #sound-dai-cells = <1>;
+ reset-gpios = <&exp3 0 GPIO_ACTIVE_LOW>;
+ clocks = <&audio_refclk1>;
+ clock-names = "scki";
+ VDD1-supply = <&vsys_3v3>;
+ VDD2-supply = <&vsys_3v3>;
+ VCCAD1-supply = <&vsys_5v0>;
+ VCCAD2-supply = <&vsys_5v0>;
+ VCCDA1-supply = <&vsys_5v0>;
+ VCCDA2-supply = <&vsys_5v0>;
+ };
+};
+
+&mcasp4 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcasp4_pins_default>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ auxclk-fs-ratio = <256>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 2 1 1
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/2] ti,j721e-system-controller.yaml: Allow audio-refclk as clock-controller child
From: Moteen Shah @ 2026-03-30 9:44 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260330094459.128648-1-m-shah@ti.com>
The ti,j721e-system-controller binding currently only allows
clock-controller@ child nodes to reference the ti,am654-ehrpwm-tbclk
schema. However, the system controller on J721S2 also contains audio
reference clock controllers (ti,am62-audio-refclk) that use the same
clock-controller@XXXX naming pattern.
Hence, extend the clock-controller pattern to accept either ehrpwm-tbclk
or audio-refclk schemas using a oneOf constraint.
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
.../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
index f3bd0be3b279..d5d84a8f1257 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
@@ -53,9 +53,11 @@ patternProperties:
"^clock-controller@[0-9a-f]+$":
type: object
- $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
+ oneOf:
+ - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
+ - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
description:
- Clock provider for TI EHRPWM nodes.
+ Clock provider for TI EHRPWM or Audio Reference Clock nodes.
"phy@[0-9a-f]+$":
type: object
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: pkvm: Rollback refcount on hyp share/unshare error
From: Quentin Perret @ 2026-03-30 9:41 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm, kernel-team
In-Reply-To: <20260324172757.2147153-1-vdonnefort@google.com>
Hey Vincent,
On Tuesday 24 Mar 2026 at 17:27:57 (+0000), Vincent Donnefort wrote:
> If one of the HVC __pkvm_host_share_hyp or __pkvm_host_unshare_hyp fails,
> rollback the refcount to ensure the hyp_shared_pfns tracking reflects
> the actual sharing status.
If any of these hypercalls fail I think we're still in trouble as
kvm_{un}share_hyp() work on multi-page ranges and we could leak pages in
a borked state if we fail halfway through. And failing any of these
hypercalls is also sign of a bigger problem somewhere else so I wasn't
too worried.
But if we're going to fix this properly, I'd suggest also improving the
error handling in kvm_share_hyp(). 'Fixing' kvm_unshare_hyp() is a bit
harder because we must tell the caller to leak the data structure that
was shared I presume, so maybe we just keep the WARN and cross our
fingers :)
Cheers,
Quentin
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 17d64a1e11e5..0fb41d2c8b44 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -493,11 +493,17 @@ static int share_pfn_hyp(u64 pfn)
> goto unlock;
> }
>
> + ret = kvm_call_hyp_nvhe(__pkvm_host_share_hyp, pfn);
> + if (ret) {
> + kfree(this);
> + goto unlock;
> + }
> +
> this->pfn = pfn;
> this->count = 1;
> rb_link_node(&this->node, parent, node);
> rb_insert_color(&this->node, &hyp_shared_pfns);
> - ret = kvm_call_hyp_nvhe(__pkvm_host_share_hyp, pfn);
> +
> unlock:
> mutex_unlock(&hyp_shared_pfns_lock);
>
> @@ -521,9 +527,15 @@ static int unshare_pfn_hyp(u64 pfn)
> if (this->count)
> goto unlock;
>
> + ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_hyp, pfn);
> + if (ret) {
> + this->count++;
> + goto unlock;
> + }
> +
> rb_erase(&this->node, &hyp_shared_pfns);
> kfree(this);
> - ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_hyp, pfn);
> +
> unlock:
> mutex_unlock(&hyp_shared_pfns_lock);
>
>
> base-commit: c369299895a591d96745d6492d4888259b004a9e
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* Re: [PATCH 4/5] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Ard Biesheuvel @ 2026-03-30 9:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ard Biesheuvel, linux-raid, linux-arm-kernel, linux-crypto,
Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260330053233.GB4736@lst.de>
On Mon, 30 Mar 2026, at 07:32, Christoph Hellwig wrote:
> On Fri, Mar 27, 2026 at 03:45:56PM +0100, Ard Biesheuvel wrote:
>> On Fri, 27 Mar 2026, at 14:50, Christoph Hellwig wrote:
>> > On Fri, Mar 27, 2026 at 12:30:52PM +0100, Ard Biesheuvel wrote:
>> >> From: Ard Biesheuvel <ardb@kernel.org>
>> >>
>> >> Tweak the arm64 code so that the pure NEON intrinsics implementation of
>> >> XOR is shared between arm64 and ARM.
>> >
>> > Instead of hiding the implementation in a header, just split xor-neon.c
>> > into two .c files, one of which could be built by arm32 as well.
>>
>> That is what patch 3/5 does. This patch wires up that version into arm64, and drops the copy that has become redundant as a result.
>
> Yeah, sorry - I misread the series a little.
>
>>
>> > probably
>> > in the arm/ instead of the arm64/ subdirectory, but we can also add a
>> > new arm-common one if that's what the arm maintainers prefer.
>>
>> Having the shared pure NEON version in arm/ is perfectly fine.
>
> So here would be my preference:
>
> - keep all the arm/arm64 code in lib/raid/xor/arm
> - have the neon and EOR3 code in a single xor-neon.c file, with an
> ifdef CONFIG_ARM64 around the EOE3 routines
>
> This avoid the including of .c files which is always a bit ugly.
> But if there is a strong argument to prefer including of the .c file I
> can live with that as well.
>
I've respun it without the include. Instead, I've added this to arm/xor-neon.c
+#ifdef CONFIG_ARM64
+extern typeof(__xor_neon_2) __xor_eor3_2 __alias(__xor_neon_2);
+#endif
so that __xor_eor3_2() exists in the arm64 build as an alias. That way, the arm64-only EOR3 implementation can just remain a separate compilation unit.
I could move the eor3 code under arm/ too, but that seems a bit odd given that it is arm64 only, and a arm64/ sub-directory exists.
^ permalink raw reply
* Re: [PATCH] crypto: aspeed/hash: Use memcpy_from_sglist() in aspeed_ahash_dma_prepare()
From: Neal Liu @ 2026-03-30 9:36 UTC (permalink / raw)
To: Paul Louvel, Herbert Xu, David S. Miller, Joel Stanley,
Andrew Jeffery
Cc: Thomas Petazzoni, linux-aspeed@lists.ozlabs.org,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260327092418.10476-1-paul.louvel@bootlin.com>
> Replace scatterwalk_map_and_copy() with memcpy_from_sglist() in
> aspeed_ahash_dma_prepare(). The latter provides a simpler interface
> without requiring a direction parameter, making the code easier to
> read and less error-prone.
>
> No functional change intended.
>
> Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
> ---
> drivers/crypto/aspeed/aspeed-hace-hash.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/aspeed/aspeed-hace-hash.c b/drivers/crypto/aspeed/aspeed-hace-hash.c
> index f8f37c9d5f3c..6f0d03cfbefc 100644
> --- a/drivers/crypto/aspeed/aspeed-hace-hash.c
> +++ b/drivers/crypto/aspeed/aspeed-hace-hash.c
> @@ -182,8 +182,7 @@ static int aspeed_ahash_dma_prepare(struct aspeed_hace_dev *hace_dev)
> final = true;
> } else
> length -= remain;
> - scatterwalk_map_and_copy(hash_engine->ahash_src_addr, rctx->src_sg,
> - rctx->offset, length, 0);
> + memcpy_from_sglist(hash_engine->ahash_src_addr, rctx->src_sg, rctx->offset, length);
> aspeed_ahash_update_counter(rctx, length);
> if (final)
> length += aspeed_ahash_fill_padding(
> --
> 2.53.0
Reviewed-by: Neal Liu <neal_liu@aspeedtech.com>
^ permalink raw reply
* Re: [PATCH v3 7/9] regulator: mt6392: Add support for MT6392 regulator
From: Chen-Yu Tsai @ 2026-03-30 9:35 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Gary Bisson, Louis-Alexis Eyraud, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2J355NZH=7iQ9sTDBhAmtjP7xTpXe21_3Z9J_R5YvdXAQ@mail.gmail.com>
On Mon, Mar 30, 2026 at 3:39 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> Il giorno gio 19 mar 2026 alle ore 06:04 Chen-Yu Tsai
> <wenst@chromium.org> ha scritto:
>
> > If this PMIC is anything like the MT6358, then it has 0.01V fine
> > tuning for most if not all the LDOs. It is sometimes needed as
> > a rail may have a 0.04V boost that would otherwise be invisible
> > to the system. And then if you have something like 3.04V set in
> > the DT constraints, you end up with something the regulator driver
> > doesn't support, but the hardware does.
> >
> > Please see how it's done in the MT6358 driver. I spent a lot of
> > time on that driver to make it actually support the full range
> > of voltages, and describing the supplies.
> >
>
> I had a good look at the datasheet (MT6392 PMIC Datasheet v1.0 08 Dec.
> 2016) and unfortunately I did not see any fine tuning option in there.
> I'm sure this data sheet is not perfect as it's missing some regulator
> registers that are clearly used in the Android sources, but there's no
> mention of fine tuning in that code either. I guess it does not have
> that capability.
Well, thanks for looking. FWIW on the MT6358 / MT6366, the main voltage
control and the fine tuning are mostly in the same register. The fine
tuning is described as "calibrates output voltage" from +00mV to +100mV.
I looked into this because the LDO table shows some of the default voltages
with 0.01V precision, but the main voltage controls only have 0.1V precision.
ChenYu
> I will shortly submit v4 that hopefully addresses the rest of the comments.
>
> Thanks for your help!
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH v2 1/4] staging: vc04_services: vchiq-mmal: validate component index in event_to_host_cb()
From: Dan Carpenter @ 2026-03-30 9:35 UTC (permalink / raw)
To: Sebastian Josue Alba Vives
Cc: Greg Kroah-Hartman, Florian Fainelli, bcm-kernel-feedback-list,
linux-staging, linux-rpi-kernel, linux-arm-kernel, linux-media,
Dave Stevenson, kernel-list, stable
In-Reply-To: <20260329071616.507876-2-sebasjosue84@gmail.com>
On Sun, Mar 29, 2026 at 01:15:39AM -0600, Sebastian Josue Alba Vives wrote:
> From: Sebastián Alba Vives <sebasjosue84@gmail.com>
>
> event_to_host_cb() uses msg->u.event_to_host.client_component as an
> index into the instance->component[] array (size VCHIQ_MMAL_MAX_COMPONENTS
> = 64) without bounds validation. While the kernel generally trusts the
> hardware it is bound to, a bounds check here hardens the driver against
> potential firmware bugs that could otherwise cause an uncontrolled
> out-of-bounds array access and kernel crash.
>
> Add a bounds check on comp_idx before using it as an array index and
> move the component pointer assignment after the validation. Use
> pr_err_ratelimited() to avoid log flooding. Note: this file does not
> currently have access to a struct device, so dev_err() is not available.
>
> Cc: stable@vger.kernel.org
> Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
This fixes tag is wrong. That patch just moves code around.
I can't apply this patch to linux-next. Is this another out of tree
bug?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v3] lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
From: David Laight @ 2026-03-30 9:31 UTC (permalink / raw)
To: Eric Biggers
Cc: Demian Shulhan, linux-crypto, linux-kernel, linux-arm-kernel,
ardb
In-Reply-To: <20260329221821.GC2106@quark>
On Sun, 29 Mar 2026 15:18:21 -0700
Eric Biggers <ebiggers@kernel.org> wrote:
> On Sun, Mar 29, 2026 at 10:57:04PM +0100, David Laight wrote:
> > Final thought:
> > Is that allowing for the cost of kernel_fpu_begin()? - which I think only
> > affects the first call.
> > And the cost of the data-cache misses for the lookup table reads? - again
> > worse for the first call.
>
> I assume you mean kernel_neon_begin(). This is an arm64 patch.
Well, much the same.
> (I encourage you to actually read the code. You seem to send a lot of
> speculation-heavy comments without actually reading the code.)
I have looked at the code, since I (mostly) understand the maths I can
almost work out what it is doing - but all the conversions between three
different ways of holding two 64bit values in one 128bit register really
don't help.
> Currently, the benchmark in crc_kunit just measures the throughput in a
> loop (as has been discussed before). So no, it doesn't currently
> capture the overhead of pulling code and data into cache. For NEON
> register use it captures only the amortized overhead.
>
> Note that using PMULL saves having to pull the table into memory, while
> using the table is a bit less code and saves having to use kernel-mode
> NEON. So both have their advantages and disadvantages.
Indeed - so the 128 is really a 'finger in the air' value :-)
> This patch does fall back to the table for the last 'len & ~15' bytes,
> which means the table may be needed anyway.
Nibble lookups on two separate tables (256 bytes instead of 2k) might
be almost as fast even with the tables in the cache.
The critical part of the table lookup loop should be the:
crc = crc ^ table[crc & 0xff]
part (the rotate should get hidden in the memory read latency).
With nibble tables is becomes:
crc = crc ^ table_lo[crc & 0xf] ^ table_hi[(crc & 0xf0) >> 4]
on any modern cpu the table lookups will happen in parallel; so it
should just add one 'xor' to the loop.
(And yes, I probably could measure it, at least in userspace on x86-64.)
> That is not the optimal way
> to do it, and it's something to address later when this is replaced with
> something similar to x86's crc-pclmul-template.S.
That is one bit I do need to grok...
David
>
> - Eric
^ permalink raw reply
* [PATCH] usb: phy: mxs: manually reset phy regs after a warm reset
From: Xu Yang @ 2026-03-30 9:31 UTC (permalink / raw)
To: gregkh, Frank.Li, s.hauer, kernel, festevam
Cc: linux-usb, imx, linux-arm-kernel, linux-kernel
The usb phy registers are not fully reset on warm reset under stress
conditions. We need to manually reset those (CTRL, PWD, DEBUG, PLL_SIC)
regs after a warm reset. This will reset DEBUG and PLL_SIC registers.
CTRL and PWD register are handled by "SFT" bit in stmp_reset_block().
ERR051269: USB PHY registers not fully resetting on warm reset under
stress conditions
The following USB PHY registers must be written by SW to restore the reset
value after a warm reset:
Reg: ctrl Addr: 0x29910030 Data: 0xc000_0000
Reg: pwd Addr: 0x29910000 Data: 0x001e_1c00
Reg: debug0 Addr: 0x29910050 Data: 0x7f18_0000
Reg: pll_sic Addr: 0x299100a0 Data: 0x00d1_2000
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
drivers/usb/phy/phy-mxs-usb.c | 32 +++++++++++++++++++++++++++++---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 7069dd3f4d0d..dd42db8a0829 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -209,6 +209,9 @@ static const struct mxs_phy_data imx6ul_phy_data = {
static const struct mxs_phy_data imx7ulp_phy_data = {
};
+static const struct mxs_phy_data imx8ulp_phy_data = {
+};
+
static const struct of_device_id mxs_phy_dt_ids[] = {
{ .compatible = "fsl,imx6sx-usbphy", .data = &imx6sx_phy_data, },
{ .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
@@ -217,6 +220,7 @@ static const struct of_device_id mxs_phy_dt_ids[] = {
{ .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
{ .compatible = "fsl,imx6ul-usbphy", .data = &imx6ul_phy_data, },
{ .compatible = "fsl,imx7ulp-usbphy", .data = &imx7ulp_phy_data, },
+ { .compatible = "fsl,imx8ulp-usbphy", .data = &imx8ulp_phy_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
@@ -248,6 +252,11 @@ static inline bool is_imx7ulp_phy(struct mxs_phy *mxs_phy)
return mxs_phy->data == &imx7ulp_phy_data;
}
+static inline bool is_imx8ulp_phy(struct mxs_phy *mxs_phy)
+{
+ return mxs_phy->data == &imx8ulp_phy_data;
+}
+
static inline bool is_imx6ul_phy(struct mxs_phy *mxs_phy)
{
return mxs_phy->data == &imx6ul_phy_data;
@@ -305,12 +314,29 @@ static int mxs_phy_pll_enable(void __iomem *base, bool enable)
return ret;
}
+/*
+ * The imx8ulp phy registers are not properly reset after a warm
+ * reset (ERR051269). Using the following steps to reset DEBUG and
+ * PLL_SIC regs. CTRL and PWD regs are reset by "SFT" bit in
+ * stmp_reset_block().
+ */
+static void mxs_phy_regs_reset(void __iomem *base)
+{
+ writel(0x7f180000, base + HW_USBPHY_DEBUG_SET);
+ writel(~0x7f180000, base + HW_USBPHY_DEBUG_CLR);
+ writel(0x00d12000, base + HW_USBPHY_PLL_SIC_SET);
+ writel(~0x00d12000, base + HW_USBPHY_PLL_SIC_CLR);
+}
+
static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
{
int ret;
void __iomem *base = mxs_phy->phy.io_priv;
- if (is_imx7ulp_phy(mxs_phy)) {
+ if (is_imx8ulp_phy(mxs_phy))
+ mxs_phy_regs_reset(base);
+
+ if (is_imx7ulp_phy(mxs_phy) || is_imx8ulp_phy(mxs_phy)) {
ret = mxs_phy_pll_enable(base, true);
if (ret)
return ret;
@@ -368,7 +394,7 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
return 0;
disable_pll:
- if (is_imx7ulp_phy(mxs_phy))
+ if (is_imx7ulp_phy(mxs_phy) || is_imx8ulp_phy(mxs_phy))
mxs_phy_pll_enable(base, false);
return ret;
}
@@ -487,7 +513,7 @@ static void mxs_phy_shutdown(struct usb_phy *phy)
writel(BM_USBPHY_CTRL_CLKGATE,
phy->io_priv + HW_USBPHY_CTRL_SET);
- if (is_imx7ulp_phy(mxs_phy))
+ if (is_imx7ulp_phy(mxs_phy) || is_imx8ulp_phy(mxs_phy))
mxs_phy_pll_enable(phy->io_priv, false);
if (mxs_phy->phy_3p0)
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v2] PCI: imx6: Don't remove MSI capability For i.MX7D/i.MX8M
From: Hongxing Zhu @ 2026-03-30 9:02 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Qiang Yu
In-Reply-To: <kqv3x4qocp7rkas5oedlpzd43h3ez7dg26hqnfgubbjdhhxlwe@rfnsicbv7qba>
> -----Original Message-----
> From: Manivannan Sadhasivam <mani@kernel.org>
> Sent: 2026年3月30日 15:23
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de; lpieralisi@kernel.org;
> kwilczynski@kernel.org; robh@kernel.org; bhelgaas@google.com;
> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com;
> linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> imx@lists.linux.dev; linux-kernel@vger.kernel.org; stable@vger.kernel.org;
> Qiang Yu <qiang.yu@oss.qualcomm.com>
> Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> i.MX7D/i.MX8M
>
> + Qiang
>
> On Thu, Mar 19, 2026 at 05:18:23PM +0800, Richard Zhu wrote:
> > The MSI trigger mechanism for endpoint devices connected to i.MX7D,
> > i.MX8MM, and i.MX8MQ PCIe root complex ports depends on the MSI
> > capability register settings in the root complex. Removing the MSI
> > capability breaks MSI functionality for these endpoints.
> >
>
> What is the relation between Root Port MSI and endpoint MSI? Endpoint MSIs
> should be routed to the platform MSI controller (DWC i.MSI-RX or External like
> GIC-ITS) independent of the Root Port MSI state.
Hi Mani:
Thank for your kindly concern.
The MSI controller (DWC i.MSI-RX) on i.MX7D, i.MX8MM, and i.MX8MQ platforms
requires the RC's MSI capability to remain enabled. Removing it breaks MSI
routing from endpoints to the platform MSI controller.
Best Regards
Richard Zhu
>
> I'm just trying to understand the issue here.
>
> - Mani
>
> > Preserve the MSI capability for i.MX7D/i.MX8M PCIe root complex to
> > maintain MSI functionality.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: f5cd8a929c825 ("PCI: dwc: Remove MSI/MSIX capability for Root
> > Port if iMSI-RX is used as MSI controller")
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> > v2 changes:
> > CC stable tree.
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 20dafd2710a3..0b0d6a210406 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -41,6 +41,7 @@
> > #define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> > #define IMX8MQ_GPR_PCIE_VREG_BYPASS BIT(12)
> > #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE GENMASK(11, 8)
> > +#define IMX8MM_PCIE_MSI_CAP_OFFSET 0x50
> >
> > #define IMX95_PCIE_PHY_GEN_CTRL 0x0
> > #define IMX95_PCIE_REF_USE_PAD BIT(17)
> > @@ -117,6 +118,7 @@ enum imx_pcie_variants {
> > #define IMX_PCIE_FLAG_HAS_LUT BIT(10)
> > #define IMX_PCIE_FLAG_8GT_ECN_ERR051586 BIT(11)
> > #define IMX_PCIE_FLAG_SKIP_L23_READY BIT(12)
> > +#define IMX_PCIE_FLAG_KEEP_MSI_CAP BIT(13)
> >
> > #define imx_check_flag(pci, val) (pci->drvdata->flags & val)
> >
> > @@ -976,10 +978,17 @@ static int imx_pcie_start_link(struct dw_pcie
> > *pci) {
> > struct imx_pcie *imx_pcie = to_imx_pcie(pci);
> > struct device *dev = pci->dev;
> > - u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> > + u8 offset;
> > u32 tmp;
> > int ret;
> >
> > + if (imx_pcie->drvdata->flags & IMX_PCIE_FLAG_KEEP_MSI_CAP) {
> > + offset = dw_pcie_find_capability(pci, PCI_CAP_ID_PM);
> > + dw_pcie_dbi_ro_wr_en(pci);
> > + dw_pcie_writeb_dbi(pci, offset + 1,
> IMX8MM_PCIE_MSI_CAP_OFFSET);
> > + dw_pcie_dbi_ro_wr_dis(pci);
> > + }
> > +
> > if (!(imx_pcie->drvdata->flags &
> > IMX_PCIE_FLAG_SPEED_CHANGE_WORKAROUND)) {
> > imx_pcie_ltssm_enable(dev);
> > @@ -991,6 +1000,7 @@ static int imx_pcie_start_link(struct dw_pcie *pci)
> > * started in Gen2 mode, there is a possibility the devices on the
> > * bus will not be detected at all. This happens with PCIe switches.
> > */
> > + offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> > dw_pcie_dbi_ro_wr_en(pci);
> > tmp = dw_pcie_readl_dbi(pci, offset + PCI_EXP_LNKCAP);
> > tmp &= ~PCI_EXP_LNKCAP_SLS;
> > @@ -1897,6 +1907,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> > [IMX7D] = {
> > .variant = IMX7D,
> > .flags = IMX_PCIE_FLAG_SUPPORTS_SUSPEND |
> > + IMX_PCIE_FLAG_KEEP_MSI_CAP |
> > IMX_PCIE_FLAG_HAS_APP_RESET |
> > IMX_PCIE_FLAG_SKIP_L23_READY |
> > IMX_PCIE_FLAG_HAS_PHY_RESET,
> > @@ -1909,6 +1920,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> > [IMX8MQ] = {
> > .variant = IMX8MQ,
> > .flags = IMX_PCIE_FLAG_HAS_APP_RESET |
> > + IMX_PCIE_FLAG_KEEP_MSI_CAP |
> > IMX_PCIE_FLAG_HAS_PHY_RESET |
> > IMX_PCIE_FLAG_SUPPORTS_SUSPEND,
> > .gpr = "fsl,imx8mq-iomuxc-gpr",
> > @@ -1923,6 +1935,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> > [IMX8MM] = {
> > .variant = IMX8MM,
> > .flags = IMX_PCIE_FLAG_SUPPORTS_SUSPEND |
> > + IMX_PCIE_FLAG_KEEP_MSI_CAP |
> > IMX_PCIE_FLAG_HAS_PHYDRV |
> > IMX_PCIE_FLAG_HAS_APP_RESET,
> > .gpr = "fsl,imx8mm-iomuxc-gpr",
> > --
> > 2.37.1
> >
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4] crypto: testmgr - Add test vectors for authenc(hmac(md5),cbc(aes))
From: Herbert Xu @ 2026-03-30 8:46 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: davem, mcoquelin.stm32, alexandre.torgue, linux-crypto,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <c2a3dc2e-8d4a-4a59-ac5a-ca22be705488@wp.pl>
On Fri, Mar 27, 2026 at 06:03:48PM +0100, Aleksander Jan Bajkowski wrote:
>
> Checked the crypto tree, and this patch still isn't applied. I've sent
> multiple test vectors, and you're probably referring to a another patch.
> Should I send it again, or will you accept it as is?
>
> By the way, that's the last one. As of now, all my routers have the missing
> vectors added :)
Thanks I'll put the patch back into the queue.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 4/9] mm: move free_reserved_area() to mm/memblock.c
From: Vlastimil Babka (SUSE) @ 2026-03-30 9:00 UTC (permalink / raw)
To: Mike Rapoport, Andrew Morton
Cc: Alexander Potapenko, Alexander Viro, Andreas Larsson,
Ard Biesheuvel, Borislav Petkov, Brendan Jackman,
Christophe Leroy (CS GROUP), Catalin Marinas, Christian Brauner,
David S. Miller, Dave Hansen, David Hildenbrand, Dmitry Vyukov,
Ilias Apalodimas, Ingo Molnar, Jan Kara, Johannes Weiner,
Liam R. Howlett, Lorenzo Stoakes, Madhavan Srinivasan,
Marco Elver, Marek Szyprowski, Masami Hiramatsu, Michael Ellerman,
Michal Hocko, Nicholas Piggin, H. Peter Anvin, Rob Herring,
Robin Murphy, Saravana Kannan, Suren Baghdasaryan,
Thomas Gleixner, Will Deacon, Zi Yan, devicetree, iommu,
kasan-dev, linux-arm-kernel, linux-efi, linux-fsdevel,
linux-kernel, linux-mm, linux-trace-kernel, linuxppc-dev,
sparclinux, x86
In-Reply-To: <20260323074836.3653702-5-rppt@kernel.org>
On 3/23/26 08:48, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
>
> free_reserved_area() is related to memblock as it frees reserved memory
> back to the buddy allocator, similar to what memblock_free_late() does.
>
> Move free_reserved_area() to mm/memblock.c to prepare for further
> consolidation of the functions that free reserved memory.
>
> No functional changes.
>
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] phy: hdmi: Add FRL TxFFE level control
From: Vladimir Oltean @ 2026-03-30 8:57 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, kernel, linux-phy,
linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260328-hdptx-ffe-v1-0-53ebd5dea20a@collabora.com>
On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:
> During HDMI 2.1 Fixed Rate Link training, the source and sink may
> negotiate a Transmitter Feed Forward Equalizer (TxFFE) level to
> compensate for signal quality degradation on the physical channel. The
> source starts at level 0 and may increment it up to a maximum agreed
> upon during LTS3 in response to persistent link failures reported by the
> sink. TxFFE adjustment is optional and entirely independent of the FRL
> rate and lane count selection.
>
> Patch 1 extends the HDMI PHY configuration API with two new fields in
> the frl sub-struct: ffe_level to carry the requested level, and a
> set_ffe_level flag that switches the semantics of a phy_configure() call
> to a pure equalizer update, leaving all other fields ignored.
>
> Patch 2 implements the new interface in the Rockchip Samsung HDPTX PHY
> driver.
>
> The series depends on the "[PATCH 0/6] phy: rockchip: samsung-hdptx:
> Clock fixes and API transition cleanups" patchset:
>
> https://lore.kernel.org/all/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com/
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Cristian Ciocaltea (2):
> phy: hdmi: Add optional FRL TxFFE config options
> phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control
>
> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 74 +++++++++++++++++++++--
> include/linux/phy/phy-hdmi.h | 6 ++
> 2 files changed, 75 insertions(+), 5 deletions(-)
> ---
> base-commit: f7b64ed948718290209074a50bb0df17e5944873
> change-id: 20260328-hdptx-ffe-a89c51e66904
> prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
> prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
> prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
> prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
> prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
> prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
> prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb
Sorry for my ignorance; who is supposed to act upon this git-format-patch
base tree information and in what way?
As things stand today, the build infrastructure we have in place will
not be able to apply and test your series unless it applies directly
onto the linux-phy/next branch.
^ permalink raw reply
* Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-30 8:50 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Andy Shevchenko, Aaro Koskinen, Janusz Krzysztofik, Arnd Bergmann,
Bartosz Golaszewski, Tony Lindgren, Russell King, Dmitry Torokhov,
Hans de Goede, Linux-OMAP, linux-arm-kernel, linux-kernel,
Kevin Hilman
In-Reply-To: <aco3YBCQsT2BN2_N@kuha>
On Mon, Mar 30, 2026 at 10:43 AM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> > > Thanks. This makes sense. Both omap16xx_gpio_init() and
> > > software_node_init() run as postcore_initcall() so if the order is not
> > > right, it will fail.
> > >
> > > Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
> > > reason to run software_node_init() as a postcore initcall? It only
> > > allocates the kset, can we move it to core_initcall() by any chance?
> >
> > Good question. I don't know why it's chosen like this.
> > Let ask Heikki, who is the author of the code.
>
> I don't remember why it was it made a postcore initcall (I only
> remember that there was some reason at the time). It's probable
> fine to just make it a core initcall.
>
Thanks, I think I'll do as Dmitry suggested and make the exact moment
software nodes are initialized deterministic by moving it into the
driver core initialization.
Bart
^ permalink raw reply
* Re: [PATCH v2 0/3] media: imx-csi: cleanup media pipeline start
From: Michael Tretter @ 2026-03-30 8:49 UTC (permalink / raw)
To: Hans Verkuil, Steve Longerbeam, Philipp Zabel, Frank Li,
Mauro Carvalho Chehab, Fabio Estevam, Greg Kroah-Hartman,
Shawn Guo, Sascha Hauer, linux-media, imx, linux-arm-kernel,
Pengutronix Kernel Team, linux-staging
In-Reply-To: <aXOoc0lvAtPt0fAL@pengutronix.de>
Hi Hans,
On Fri, 23 Jan 2026 17:57:23 +0100, Michael Tretter wrote:
> On Thu, 18 Dec 2025 10:23:48 +0100, Michael Tretter wrote:
> > The imx media device currently assumes that there is only a single media
> > pipeline. However, the media graph has multiple imx capture devices.
> > These may be started separately on media pipelines if they don't cause
> > conflicts in the media graph.
> >
> > Move the media pipeline from the media device to the capture devices to
> > properly track and handle multiple media pipelines for the imx-csi.
> > Refactor the code to start the media pipeline from the driver to help
> > the reader.
>
Could you take a look and apply this series for the imx-media driver,
too? The patches are already reviewed by Frank Li and Philipp Zabel.
Michael
>
> >
> > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
> > ---
> > Changes in v2:
> > - Improve code readability in Patch 2
> > - Update commit message of Patch 3 as suggested by Frank Li
> > - Link to v1: https://patch.msgid.link/20251107-media-imx-cleanup-v1-0-f82a693c28f4@pengutronix.de
> >
> > ---
> > Michael Tretter (3):
> > media: imx-csi: move media_pipeline to video device
> > media: imx-csi: explicitly start media pipeline on pad 0
> > media: imx-csi: use media_pad_is_streaming helper
> >
> > drivers/staging/media/imx/imx-media-capture.c | 8 ++++----
> > drivers/staging/media/imx/imx-media-utils.c | 12 ++++++++----
> > drivers/staging/media/imx/imx-media.h | 7 ++++---
> > 3 files changed, 16 insertions(+), 11 deletions(-)
> > ---
> > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> > change-id: 20251107-media-imx-cleanup-9022d941ae44
^ permalink raw reply
* [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown
From: Ren Wei @ 2026-03-30 8:46 UTC (permalink / raw)
To: security
Cc: davem, dsahern, edumazet, kuba, pabeni, horms, afaerber, mani,
yoshfuji, yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
zcliangcn, n05ec, netdev, linux-arm-kernel, linux-actions,
linux-kernel
In-Reply-To: <cover.1774855883.git.zcliangcn@gmail.com>
From: Zhengchuan Liang <zcliangcn@gmail.com>
`ip6fl_seq_show()` walks the global flowlabel hash under the seq-file
RCU read-side lock and prints `fl->opt->opt_nflen` when an option block
is present.
Exclusive flowlabels currently free `fl->opt` as soon as `fl->users`
drops to zero in `fl_release()`. However, the surrounding
`struct ip6_flowlabel` remains visible in the global hash table until
later garbage collection removes it and `fl_free_rcu()` finally tears it
down.
A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that
early `kfree()` and dereference freed option state, triggering a crash
in `ip6fl_seq_show()`.
Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches
the lifetime already required for the enclosing flowlabel while readers
can still reach it under RCU.
Fixes: d3aedd5ebd4b ("ipv6 flowlabel: Convert hash list to RCU.")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/ipv6/ip6_flowlabel.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 7c12bf75beedf..c92f98c6f6ecc 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -133,11 +133,6 @@ static void fl_release(struct ip6_flowlabel *fl)
if (time_after(ttd, fl->expires))
fl->expires = ttd;
ttd = fl->expires;
- if (fl->opt && fl->share == IPV6_FL_S_EXCL) {
- struct ipv6_txoptions *opt = fl->opt;
- fl->opt = NULL;
- kfree(opt);
- }
if (!timer_pending(&ip6_fl_gc_timer) ||
time_after(ip6_fl_gc_timer.expires, ttd))
mod_timer(&ip6_fl_gc_timer, ttd);
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox