* Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Krzysztof Kozlowski @ 2026-04-11 13:58 UTC (permalink / raw)
To: dennis
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Michael Riesch, Mykola Kvach,
Jimmy Hon, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260411024743.195385-4-dennis@ausil.us>
On Fri, Apr 10, 2026 at 09:47:43PM -0500, dennis@ausil.us wrote:
> From: Dennis Gilmore <dennis@ausil.us>
>
> Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
>
> - eMMC module, you can optionally solder a SPI NOR in place and turn
> off the eMMC
> - PCIe-attached NIC (pcie2x1l1)
> - PCIe NVMe slot (pcie2x1l2)
> - AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
> - BCM4345C5 Bluetooth
> - es8388 audio
> - USB 2.0 and USB 3.0
> - Two HDMI ports, the second is connected to the SoC's DP controller
> driven by a transparent LT8711UXD bridge that has firmware onboard and
> needs no node defined.
>
> Vendors description and links to schematics available:
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
>
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
> .../display/rockchip/rockchip,dw-dp.yaml | 7 +
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Didn't you already got this comment?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: stm32: Enable PHY SSC on DH STM32MP13xx DHCOR DHSBC board
From: Marek Vasut @ 2026-04-11 13:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Alexandre Torgue, Christoph Niedermaier,
Conor Dooley, Krzysztof Kozlowski, Maxime Coquelin, Rob Herring,
devicetree, kernel, linux-kernel, linux-stm32
Add realtek,rxc-ssc-enable and realtek,sysclk-ssc-enable to both PHY
DT nodes to enable PHY Spread Spectrum on RXC and SYSCLK, CLKOUT is
disabled and therefore does not need SSC enabled.
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: kernel@dh-electronics.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
---
arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts b/arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts
index 9902849ed0406..70d85af467353 100644
--- a/arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts
+++ b/arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts
@@ -97,6 +97,8 @@ ethphy1: ethernet-phy@1 {
interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
reg = <1>;
realtek,clkout-disable;
+ realtek,rxc-ssc-enable;
+ realtek,sysclk-ssc-enable;
reset-assert-us = <15000>;
reset-deassert-us = <55000>;
reset-gpios = <&gpioa 11 GPIO_ACTIVE_LOW>;
@@ -146,6 +148,8 @@ ethphy2: ethernet-phy@1 {
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
reg = <1>;
realtek,clkout-disable;
+ realtek,rxc-ssc-enable;
+ realtek,sysclk-ssc-enable;
reset-assert-us = <15000>;
reset-deassert-us = <55000>;
reset-gpios = <&gpiog 8 GPIO_ACTIVE_LOW>;
--
2.53.0
^ permalink raw reply related
* [PATCH] arm64: dts: st: Fix SAI addresses on stm32mp251
From: Marek Vasut @ 2026-04-11 13:02 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Alexandre Torgue, Conor Dooley, Krzysztof Kozlowski,
Maxime Coquelin, Olivier Moysan, Rob Herring, devicetree,
linux-kernel, linux-stm32
The second field of SAI register addresses should be within 0x3f0 bytes
from the start of the SAI register addresses, the second field describes
the ID registers which are at that addrses. Currently, the second field
does not match RM, fix it.
Fixes: bf26d75a95f1 ("arm64: dts: st: add sai support on stm32mp251")
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Olivier Moysan <olivier.moysan@foss.st.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
---
arch/arm64/boot/dts/st/stm32mp251.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 673fbc5632e69..9c63fdb5a885a 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -1202,7 +1202,7 @@ spi5: spi@40280000 {
sai1: sai@40290000 {
compatible = "st,stm32mp25-sai";
- reg = <0x40290000 0x4>, <0x4029a3f0 0x10>;
+ reg = <0x40290000 0x4>, <0x402903f0 0x10>;
ranges = <0 0x40290000 0x400>;
#address-cells = <1>;
#size-cells = <1>;
@@ -1236,7 +1236,7 @@ sai1b: audio-controller@40290024 {
sai2: sai@402a0000 {
compatible = "st,stm32mp25-sai";
- reg = <0x402a0000 0x4>, <0x402aa3f0 0x10>;
+ reg = <0x402a0000 0x4>, <0x402a03f0 0x10>;
ranges = <0 0x402a0000 0x400>;
#address-cells = <1>;
#size-cells = <1>;
@@ -1270,7 +1270,7 @@ sai2b: audio-controller@402a0024 {
sai3: sai@402b0000 {
compatible = "st,stm32mp25-sai";
- reg = <0x402b0000 0x4>, <0x402ba3f0 0x10>;
+ reg = <0x402b0000 0x4>, <0x402b03f0 0x10>;
ranges = <0 0x402b0000 0x400>;
#address-cells = <1>;
#size-cells = <1>;
@@ -1362,7 +1362,7 @@ usart1: serial@40330000 {
sai4: sai@40340000 {
compatible = "st,stm32mp25-sai";
- reg = <0x40340000 0x4>, <0x4034a3f0 0x10>;
+ reg = <0x40340000 0x4>, <0x403403f0 0x10>;
ranges = <0 0x40340000 0x400>;
#address-cells = <1>;
#size-cells = <1>;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/1] KVM: arm64: nv: Avoid full shadow s2 unmap
From: Wei-Lin Chang @ 2026-04-11 12:50 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: <20260411125024.3735989-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,
create a new range that spans all the overlapping ranges including the
input range and replace those existing ranges. In the mean time, mark
this new spanning canonical IPA range 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: --||||-----|||||||---------||||||||||-----------
insert spanning range and replace overlapping ones:
--||||-----||||||||||||||||||||||||||-----------
^^^^^^^^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 | 4 +
arch/arm64/include/asm/kvm_nested.h | 4 +
arch/arm64/kvm/mmu.c | 30 ++++--
arch/arm64/kvm/nested.c | 147 +++++++++++++++++++++++++++-
4 files changed, 177 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 851f6171751c..a97bd461c1e1 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -217,6 +217,10 @@ struct kvm_s2_mmu {
*/
bool nested_stage2_enabled;
+ /* canonical IPA to nested IPA range lookup */
+ struct maple_tree nested_revmap_mt;
+ bool nested_revmap_broken;
+
#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..f039220e87a6 100644
--- a/arch/arm64/include/asm/kvm_nested.h
+++ b/arch/arm64/include/asm/kvm_nested.h
@@ -76,6 +76,8 @@ extern void kvm_s2_mmu_iterate_by_vmid(struct kvm *kvm, u16 vmid,
const union tlbi_info *info,
void (*)(struct kvm_s2_mmu *,
const union tlbi_info *));
+extern void kvm_record_nested_revmap(gpa_t gpa, struct kvm_s2_mmu *mmu,
+ gpa_t fault_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 d089c107d9b7..4c9b9cf6dc43 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -5,6 +5,7 @@
*/
#include <linux/acpi.h>
+#include <linux/maple_tree.h>
#include <linux/mman.h>
#include <linux/kvm_host.h>
#include <linux/io.h>
@@ -1099,6 +1100,7 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
{
struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
struct kvm_pgtable *pgt = NULL;
+ struct maple_tree *mt = &mmu->nested_revmap_mt;
write_lock(&kvm->mmu_lock);
pgt = mmu->pgt;
@@ -1108,8 +1110,11 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
free_percpu(mmu->last_vcpu_ran);
}
- if (kvm_is_nested_s2_mmu(kvm, mmu))
+ if (kvm_is_nested_s2_mmu(kvm, mmu)) {
+ if (!mtree_empty(mt))
+ mtree_destroy(mt);
kvm_init_nested_s2_mmu(mmu);
+ }
write_unlock(&kvm->mmu_lock);
@@ -1631,6 +1636,10 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
goto out_unlock;
}
+ if (s2fd->nested)
+ kvm_record_nested_revmap(gfn << PAGE_SHIFT, pgt->mmu,
+ s2fd->fault_ipa, PAGE_SIZE);
+
ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
__pfn_to_phys(pfn), prot,
memcache, flags);
@@ -2031,6 +2040,13 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, gfn_to_gpa(gfn),
prot, flags);
} else {
+ if (s2fd->nested) {
+ phys_addr_t ipa = gfn_to_gpa(get_canonical_gfn(s2fd, s2vi));
+
+ ipa &= ~(mapping_size - 1);
+ kvm_record_nested_revmap(ipa, pgt->mmu, gfn_to_gpa(gfn),
+ mapping_size);
+ }
ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, gfn_to_gpa(gfn), mapping_size,
__pfn_to_phys(pfn), prot,
memcache, flags);
@@ -2388,14 +2404,16 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
{
+ gpa_t gpa = range->start << PAGE_SHIFT;
+ size_t size = (range->end - range->start) << PAGE_SHIFT;
+ bool may_block = range->may_block;
+
if (!kvm->arch.mmu.pgt || kvm_vm_is_protected(kvm))
return false;
- __unmap_stage2_range(&kvm->arch.mmu, range->start << PAGE_SHIFT,
- (range->end - range->start) << PAGE_SHIFT,
- range->may_block);
+ __unmap_stage2_range(&kvm->arch.mmu, gpa, size, may_block);
+ kvm_unmap_gfn_range_nested(kvm, gpa, size, may_block);
- kvm_nested_s2_unmap(kvm, range->may_block);
return false;
}
@@ -2673,7 +2691,7 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
write_lock(&kvm->mmu_lock);
kvm_stage2_unmap_range(&kvm->arch.mmu, gpa, size, true);
- kvm_nested_s2_unmap(kvm, true);
+ kvm_unmap_gfn_range_nested(kvm, gpa, size, true);
write_unlock(&kvm->mmu_lock);
}
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 883b6c1008fb..c9ebe969b453 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,19 @@ struct vncr_tlb {
*/
#define S2_MMU_PER_VCPU 2
+/*
+ * Per shadow S2 reverse map (IPA -> nested IPA range) maple tree payload
+ * layout:
+ *
+ * bit 63: valid, 1 for non-polluted entries, prevents the case where the
+ * nested IPA is 0 and turns the whole value to 0
+ * bits 55-12: nested IPA bits 55-12
+ * bit 0: polluted, 1 for polluted, 0 for not
+ */
+#define VALID_ENTRY BIT(63)
+#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 +783,57 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
return s2_mmu;
}
+void kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
+ gpa_t fault_ipa, size_t map_size)
+{
+ struct maple_tree *mt = &mmu->nested_revmap_mt;
+ gpa_t start = ipa;
+ gpa_t end = ipa + map_size - 1;
+ u64 entry, new_entry = 0;
+ MA_STATE(mas, mt, start, end);
+
+ if (mmu->nested_revmap_broken)
+ return;
+
+ mtree_lock(mt);
+ 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 unlock;
+ /*
+ * Create a "polluted" range that spans all the overlapping
+ * ranges and store it.
+ */
+ while (entry && mas.index <= end) {
+ start = min(mas.index, start);
+ end = max(mas.last, end);
+ entry = (u64)mas_find_range(&mas, end);
+ }
+ new_entry |= UNKNOWN_IPA;
+ } else {
+ new_entry |= fault_ipa;
+ new_entry |= VALID_ENTRY;
+ }
+
+ mas_set_range(&mas, start, end);
+ if (mas_store_gfp(&mas, (void *)new_entry, GFP_NOWAIT | __GFP_ACCOUNT))
+ mmu->nested_revmap_broken = true;
+unlock:
+ mtree_unlock(mt);
+}
+
void kvm_init_nested_s2_mmu(struct kvm_s2_mmu *mmu)
{
/* CnP being set denotes an invalid entry */
mmu->tlb_vttbr = VTTBR_CNP_BIT;
mmu->nested_stage2_enabled = false;
atomic_set(&mmu->refcnt, 0);
+ mt_init(&mmu->nested_revmap_mt);
+ mmu->nested_revmap_broken = false;
}
void kvm_vcpu_load_hw_mmu(struct kvm_vcpu *vcpu)
@@ -1150,6 +1209,90 @@ void kvm_nested_s2_wp(struct kvm *kvm)
kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
}
+static void reset_revmap_and_unmap(struct kvm_s2_mmu *mmu, bool may_block)
+{
+ mtree_destroy(&mmu->nested_revmap_mt);
+ kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
+ mmu->nested_revmap_broken = false;
+}
+
+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;
+ bool unlock, fallback;
+ MA_STATE(mas, mt, gpa, end);
+
+ if (mmu->nested_revmap_broken) {
+ unlock = false;
+ fallback = true;
+ goto fin;
+ }
+
+ mtree_lock(mt);
+ 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) {
+ unlock = true;
+ fallback = true;
+ goto fin;
+ }
+
+ /*
+ * Ignore result, it is okay if a reverse mapping erase
+ * fails.
+ */
+ mas_store_gfp(&mas, NULL, GFP_NOWAIT | __GFP_ACCOUNT);
+
+ mtree_unlock(mt);
+ kvm_stage2_unmap_range(mmu, entry & NESTED_IPA_MASK, entry_size,
+ may_block);
+ mtree_lock(mt);
+ /*
+ * 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);
+ }
+ unlock = true;
+ fallback = false;
+
+fin:
+ if (unlock)
+ mtree_unlock(mt);
+ if (fallback)
+ reset_revmap_and_unmap(mmu, may_block);
+}
+
+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;
@@ -1163,7 +1306,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))
- kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
+ reset_revmap_and_unmap(mmu, may_block);
}
kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
@@ -1848,7 +1991,7 @@ void check_nested_vcpu_requests(struct kvm_vcpu *vcpu)
write_lock(&vcpu->kvm->mmu_lock);
if (mmu->pending_unmap) {
- kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), true);
+ reset_revmap_and_unmap(mmu, true);
mmu->pending_unmap = false;
}
write_unlock(&vcpu->kvm->mmu_lock);
--
2.43.0
^ permalink raw reply related
* [PATCH 0/1] KVM: arm64: nv: Implement nested stage-2 reverse map
From: Wei-Lin Chang @ 2026-04-11 12:50 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 is v2 of optimizing the shadow s2 mmu unmapping during MMU
notifiers. Thanks to Sashiko, who helped point out the many problems [1]
in v1.
* Changes from v1 [2]:
- Rebased on to a newer kvmarm/next, where user_mem_abort() underwent
a significant refactor.
- Added a flag VALID_ENTRY (bit 63) to each non-polluted reverse map
entry, so that if nested IPA == 0, we still insert a non-zero entry
to the maple tree.
- Added usage of the maple tree lock while using the tree. Previously
I though I could piggyback on kvm->mmu_lock, but this doesn't work
for 2 reasons:
1. The maple tree advanced API (mas_*) expects the maple tree lock
to be held.
2. At stage-2 fault time, kvm->mmu_lock is only taken for read.
Therefore even if 1. does not matter, parallel accesses to the
maple tree could still happen.
- Changed from using GFP_KERNEL_ACCOUNT to (GFP_NOWAIT | __GFP_ACCOUNT)
in maple tree operations. This is done because GFP_KERNEL_ACCOUNT
can sleep, and we are holding kvm->mmu_lock while doing the
operations.
- Made the code able to tolerate reverse map creation failure. In v1
if a maple tree operation fails, the error is reported back to the
caller which in the end fails the vCPU run. It shouldn't be this way
as the reverse map is an optimization and it shouldn't fail the
normal operation as we can fallback to a full unmap.
- Added a boolean nested_revmap_broken in struct kvm_s2_mmu. If
reverse map creation fails, the reverse map becomes unreliable. Keep
this failure information with nested_revmap_broken so that we can
fallback when we need to unmap.
- Removed patch 2,3,4 for now. After we start using the maple tree
lock, and keeping track of the reverse map failure state in
nested_revmap_broken, the s2 mmu look up acceleration in v1 patch 2
becomes very complicated, as the canonical maple tree used to speed
up s2 mmu look up can also encounter allocation failures which we
also need to keep track of and fallback. In the mean time the
consistency between the trees is not easy to reason about when
errors happen. Additionally, the extra lock of the canonical maple
tree also needs to be considered and care must be taken to not
introduce lock order inversion.
Given the above I believe it is best to leave the reverse map
improvements out for now, so as to not use too much time thinking
about optimization before the initial version of the reverse map is
even good.
Thanks!
[1]: https://sashiko.dev/#/patchset/20260330100633.2817076-1-weilin.chang%40arm.com
[2]: https://lore.kernel.org/kvmarm/20260330100633.2817076-1-weilin.chang@arm.com/
Wei-Lin Chang (1):
KVM: arm64: nv: Avoid full shadow s2 unmap
arch/arm64/include/asm/kvm_host.h | 4 +
arch/arm64/include/asm/kvm_nested.h | 4 +
arch/arm64/kvm/mmu.c | 30 ++++--
arch/arm64/kvm/nested.c | 147 +++++++++++++++++++++++++++-
4 files changed, 177 insertions(+), 8 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2] arm: lpae: fix non-atomic page table entry update issue
From: Wang YanQing @ 2026-04-11 12:27 UTC (permalink / raw)
To: Russell King (Oracle), akpm, willy, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260315032950.GA5618@udknight>
On Sun, Mar 15, 2026 at 11:29:50AM +0800, Wang YanQing wrote:
> On Sun, Mar 15, 2026 at 01:12:28AM +0000, Russell King (Oracle) wrote:
> > On Sun, Mar 15, 2026 at 08:47:46AM +0800, Wang YanQing wrote:
> > Thanks. Now, please locate where the need for the updates to the page
> > tables needs to be done atomically, bearing in mind that we program
> > SCTLR.AFE=1 and SCTLR.HA=0, meaning the hardware won't write-back to
> > the page tables to e.g. update the access flag.
>
> When LPAE is enabled and in the 3G/1G userspace & kernel space config, we
> use ttbr0 for address space 0-3G, and use ttbr1 for top 1G kernel space,
> but wait a moment, the module space is in ttbr0 instead of ttbr1, because
> module space is belong to 0-3G.
>
> Then we don't switch ttbr0 to the same value as ttbr1 in task switch, so
> when we switch from normal userspace thread to kernel thread, we use the
> do_translation_fault() to fault in the module space for the kernel thread
> when it accesses the module space. Now please think a situation that
> userspace repeats create new short-lived processes (run shell cmds, etc),
> we will use do_translation_fault() to fault in the PMD entries repeatly
> when switch from new created process to running kernel thread, we need
> to update pmd entry automatically here, hw is allowed to do data/instruction
> preload and trigger page table walker to see the partial update pmd entry,
> page table walker will cache it, and it will cause translation fault,
> because it doesn't see the upper 32-bit.
>
> When the userspace process is a multi-threads process, in smp environment,
> other cpus could use the same pgd for their according kernel thread, all
> the page table walker of the smp cpus have the chance to cache the partial
> update entry.
>
Hi Russell King, what is the status about this patch?
On some SoC, Texas Instruments Keystone etc, it will run arm32 linux kernel on
high address (KEYSTONE_HIGH_PHYS_START = 0x800000000ULL), then all the physical
address of page table will be 64-bit and will meet the issue described in the
patch
Thanks
^ permalink raw reply
* Re: [PATCH v6 2/3] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: Jimmy Hon @ 2026-04-11 11:58 UTC (permalink / raw)
To: dennis
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Michael Riesch, Mykola Kvach,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-3-dennis@ausil.us>
On Fri, Apr 10, 2026 at 9:47 PM <dennis@ausil.us> wrote:
>
> From: Dennis Gilmore <dennis@ausil.us>
>
> The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
> Orange Pi 5B but has had sound, USB, and leds wired up differently. The
> boards also use gmac for ethernet where the Pro has a PCIe attached NIC.
>
> I have not changed the definitions from what was in rk3588s-orangepi-5.dtsi
>
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Still works on Orange Pi 5.
Having the 5 and 5B share a dtsi is similar to how the 5 Max and 5
Ultra share a dtsi while the 5 Plus has more differences.
Tested-By: Jimmy Hon <honyuenkwun@gmail.com>
Reviewed-By: Jimmy Hon <honyuenkwun@gmail.com>
> ---
> .../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 192 +++++++++++++++++
> .../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
> .../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 198 +-----------------
> .../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
> 4 files changed, 209 insertions(+), 189 deletions(-)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
> new file mode 100644
> index 000000000000..b04dd667605d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
> + * but not the Orange Pi 5 Pro.
> + */
> +
> +#include <dt-bindings/usb/pd.h>
> +#include "rk3588s-orangepi-5.dtsi"
> +
> +/ {
> + aliases {
> + ethernet0 = &gmac1;
> + };
> +
> + analog-sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hp_detect>;
> + simple-audio-card,name = "rockchip,es8388";
> + simple-audio-card,bitclock-master = <&masterdai>;
> + simple-audio-card,format = "i2s";
> + simple-audio-card,frame-master = <&masterdai>;
> + simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> + simple-audio-card,mclk-fs = <256>;
> + simple-audio-card,routing =
> + "Headphones", "LOUT1",
> + "Headphones", "ROUT1",
> + "LINPUT1", "Microphone Jack",
> + "RINPUT1", "Microphone Jack",
> + "LINPUT2", "Onboard Microphone",
> + "RINPUT2", "Onboard Microphone";
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Microphone", "Onboard Microphone",
> + "Headphone", "Headphones";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s1_8ch>;
> + };
> +
> + masterdai: simple-audio-card,codec {
> + sound-dai = <&es8388>;
> + system-clock-frequency = <12288000>;
> + };
> + };
> +
> + pwm-leds {
> + compatible = "pwm-leds";
> +
> + led {
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_STATUS;
> + linux,default-trigger = "heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm0 0 25000 0>;
> + };
> + };
> +};
> +
> +&gmac1 {
> + clock_in_out = "output";
> + phy-handle = <&rgmii_phy1>;
> + phy-mode = "rgmii-rxid";
> + pinctrl-0 = <&gmac1_miim
> + &gmac1_tx_bus2
> + &gmac1_rx_bus2
> + &gmac1_rgmii_clk
> + &gmac1_rgmii_bus>;
> + pinctrl-names = "default";
> + tx_delay = <0x42>;
> + status = "okay";
> +};
> +
> +&i2c6 {
> + es8388: audio-codec@10 {
> + compatible = "everest,es8388", "everest,es8328";
> + reg = <0x10>;
> + clocks = <&cru I2S1_8CH_MCLKOUT>;
> + AVDD-supply = <&vcc_3v3_s0>;
> + DVDD-supply = <&vcc_1v8_s0>;
> + HPVDD-supply = <&vcc_3v3_s0>;
> + PVDD-supply = <&vcc_3v3_s0>;
> + assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
> + assigned-clock-rates = <12288000>;
> + #sound-dai-cells = <0>;
> + };
> +
> + usbc0: usb-typec@22 {
> + compatible = "fcs,fusb302";
> + reg = <0x22>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usbc0_int>;
> + vbus-supply = <&vbus_typec>;
> + status = "okay";
> +
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + data-role = "dual";
> + op-sink-microwatt = <1000000>;
> + power-role = "dual";
> + sink-pdos =
> + <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
> + source-pdos =
> + <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> + try-power-role = "source";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usbc0_hs: endpoint {
> + remote-endpoint = <&usb_host0_xhci_drd_sw>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + usbc0_ss: endpoint {
> + remote-endpoint = <&usbdp_phy0_typec_ss>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + usbc0_sbu: endpoint {
> + remote-endpoint = <&usbdp_phy0_typec_sbu>;
> + };
> + };
> + };
> + };
> + };
> +};
> +
> +&i2s1_8ch {
> + rockchip,i2s-tx-route = <3 2 1 0>;
> + rockchip,i2s-rx-route = <1 3 2 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2s1m0_sclk
> + &i2s1m0_mclk
> + &i2s1m0_lrck
> + &i2s1m0_sdi1
> + &i2s1m0_sdo3>;
> + status = "okay";
> +};
> +
> +&pwm0 {
> + pinctrl-0 = <&pwm0m2_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> +
> +&usb_host0_xhci {
> + dr_mode = "otg";
> + usb-role-switch;
> +
> + port {
> + usb_host0_xhci_drd_sw: endpoint {
> + remote-endpoint = <&usbc0_hs>;
> + };
> + };
> +};
> +
> +&usb_host2_xhci {
> + status = "okay";
> +};
> +
> +&usbdp_phy0 {
> + mode-switch;
> + orientation-switch;
> + sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
> + sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usbdp_phy0_typec_ss: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&usbc0_ss>;
> + };
> +
> + usbdp_phy0_typec_sbu: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&usbc0_sbu>;
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
> index 83b9b6645a1e..d76bdf1b5e90 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
> @@ -2,12 +2,16 @@
>
> /dts-v1/;
>
> -#include "rk3588s-orangepi-5.dtsi"
> +#include "rk3588s-orangepi-5-5b.dtsi"
>
> / {
> model = "Xunlong Orange Pi 5";
> compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
>
> + aliases {
> + mmc0 = &sdmmc;
> + };
> +
> vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
> compatible = "regulator-fixed";
> enable-active-high;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> index dafad29f9854..5c154cc6c62a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> @@ -3,19 +3,13 @@
> /dts-v1/;
>
> #include <dt-bindings/gpio/gpio.h>
> -#include <dt-bindings/leds/common.h>
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/soc/rockchip,vop2.h>
> -#include <dt-bindings/usb/pd.h>
> #include "rk3588s.dtsi"
>
> / {
> - aliases {
> - ethernet0 = &gmac1;
> - mmc0 = &sdmmc;
> - };
> -
> chosen {
> stdout-path = "serial2:1500000n8";
> };
> @@ -34,38 +28,6 @@ button-recovery {
> };
> };
>
> - analog-sound {
> - compatible = "simple-audio-card";
> - pinctrl-names = "default";
> - pinctrl-0 = <&hp_detect>;
> - simple-audio-card,name = "rockchip,es8388";
> - simple-audio-card,bitclock-master = <&masterdai>;
> - simple-audio-card,format = "i2s";
> - simple-audio-card,frame-master = <&masterdai>;
> - simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> - simple-audio-card,mclk-fs = <256>;
> - simple-audio-card,routing =
> - "Headphones", "LOUT1",
> - "Headphones", "ROUT1",
> - "LINPUT1", "Microphone Jack",
> - "RINPUT1", "Microphone Jack",
> - "LINPUT2", "Onboard Microphone",
> - "RINPUT2", "Onboard Microphone";
> - simple-audio-card,widgets =
> - "Microphone", "Microphone Jack",
> - "Microphone", "Onboard Microphone",
> - "Headphone", "Headphones";
> -
> - simple-audio-card,cpu {
> - sound-dai = <&i2s1_8ch>;
> - };
> -
> - masterdai: simple-audio-card,codec {
> - sound-dai = <&es8388>;
> - system-clock-frequency = <12288000>;
> - };
> - };
> -
> hdmi0-con {
> compatible = "hdmi-connector";
> type = "a";
> @@ -77,18 +39,6 @@ hdmi0_con_in: endpoint {
> };
> };
>
> - pwm-leds {
> - compatible = "pwm-leds";
> -
> - led {
> - color = <LED_COLOR_ID_GREEN>;
> - function = LED_FUNCTION_STATUS;
> - linux,default-trigger = "heartbeat";
> - max-brightness = <255>;
> - pwms = <&pwm0 0 25000 0>;
> - };
> - };
> -
> vbus_typec: regulator-vbus-typec {
> compatible = "regulator-fixed";
> enable-active-high;
> @@ -101,15 +51,6 @@ vbus_typec: regulator-vbus-typec {
> vin-supply = <&vcc5v0_sys>;
> };
>
> - vcc5v0_sys: regulator-vcc5v0-sys {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc5v0_sys";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - };
> -
> vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
> compatible = "regulator-fixed";
> gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
> @@ -119,6 +60,15 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
> regulator-max-microvolt = <3300000>;
> vin-supply = <&vcc_3v3_s3>;
> };
> +
> + vcc5v0_sys: regulator-vcc5v0-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> };
>
> &combphy0_ps {
> @@ -161,20 +111,6 @@ &cpu_l3 {
> cpu-supply = <&vdd_cpu_lit_s0>;
> };
>
> -&gmac1 {
> - clock_in_out = "output";
> - phy-handle = <&rgmii_phy1>;
> - phy-mode = "rgmii-rxid";
> - pinctrl-0 = <&gmac1_miim
> - &gmac1_tx_bus2
> - &gmac1_rx_bus2
> - &gmac1_rgmii_clk
> - &gmac1_rgmii_bus>;
> - pinctrl-names = "default";
> - tx_delay = <0x42>;
> - status = "okay";
> -};
> -
> &gpu {
> mali-supply = <&vdd_gpu_s0>;
> status = "okay";
> @@ -270,69 +206,6 @@ &i2c6 {
> pinctrl-0 = <&i2c6m3_xfer>;
> status = "okay";
>
> - es8388: audio-codec@10 {
> - compatible = "everest,es8388", "everest,es8328";
> - reg = <0x10>;
> - clocks = <&cru I2S1_8CH_MCLKOUT>;
> - AVDD-supply = <&vcc_3v3_s0>;
> - DVDD-supply = <&vcc_1v8_s0>;
> - HPVDD-supply = <&vcc_3v3_s0>;
> - PVDD-supply = <&vcc_3v3_s0>;
> - assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
> - assigned-clock-rates = <12288000>;
> - #sound-dai-cells = <0>;
> - };
> -
> - usbc0: usb-typec@22 {
> - compatible = "fcs,fusb302";
> - reg = <0x22>;
> - interrupt-parent = <&gpio0>;
> - interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&usbc0_int>;
> - vbus-supply = <&vbus_typec>;
> - status = "okay";
> -
> - usb_con: connector {
> - compatible = "usb-c-connector";
> - label = "USB-C";
> - data-role = "dual";
> - op-sink-microwatt = <1000000>;
> - power-role = "dual";
> - sink-pdos =
> - <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
> - source-pdos =
> - <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> - try-power-role = "source";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - usbc0_hs: endpoint {
> - remote-endpoint = <&usb_host0_xhci_drd_sw>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - usbc0_ss: endpoint {
> - remote-endpoint = <&usbdp_phy0_typec_ss>;
> - };
> - };
> -
> - port@2 {
> - reg = <2>;
> - usbc0_sbu: endpoint {
> - remote-endpoint = <&usbdp_phy0_typec_sbu>;
> - };
> - };
> - };
> - };
> - };
> -
> hym8563: rtc@51 {
> compatible = "haoyu,hym8563";
> reg = <0x51>;
> @@ -346,18 +219,6 @@ hym8563: rtc@51 {
> };
> };
>
> -&i2s1_8ch {
> - rockchip,i2s-tx-route = <3 2 1 0>;
> - rockchip,i2s-rx-route = <1 3 2 0>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&i2s1m0_sclk
> - &i2s1m0_mclk
> - &i2s1m0_lrck
> - &i2s1m0_sdi1
> - &i2s1m0_sdo3>;
> - status = "okay";
> -};
> -
> &i2s5_8ch {
> status = "okay";
> };
> @@ -404,12 +265,6 @@ typec5v_pwren: typec5v-pwren {
> };
> };
>
> -&pwm0 {
> - pinctrl-0 = <&pwm0m2_pins>;
> - pinctrl-names = "default";
> - status = "okay";
> -};
> -
> &rknn_core_0 {
> npu-supply = <&vdd_npu_s0>;
> sram-supply = <&vdd_npu_s0>;
> @@ -841,26 +696,7 @@ &uart2 {
> };
>
> &usbdp_phy0 {
> - mode-switch;
> - orientation-switch;
> - sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
> - sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
> status = "okay";
> -
> - port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - usbdp_phy0_typec_ss: endpoint@0 {
> - reg = <0>;
> - remote-endpoint = <&usbc0_ss>;
> - };
> -
> - usbdp_phy0_typec_sbu: endpoint@1 {
> - reg = <1>;
> - remote-endpoint = <&usbc0_sbu>;
> - };
> - };
> };
>
> &usb_host0_ehci {
> @@ -872,15 +708,7 @@ &usb_host0_ohci {
> };
>
> &usb_host0_xhci {
> - dr_mode = "otg";
> - usb-role-switch;
> status = "okay";
> -
> - port {
> - usb_host0_xhci_drd_sw: endpoint {
> - remote-endpoint = <&usbc0_hs>;
> - };
> - };
> };
>
> &usb_host1_ehci {
> @@ -891,7 +719,7 @@ &usb_host1_ohci {
> status = "okay";
> };
>
> -&usb_host2_xhci {
> +&vop {
> status = "okay";
> };
>
> @@ -899,10 +727,6 @@ &vop_mmu {
> status = "okay";
> };
>
> -&vop {
> - status = "okay";
> -};
> -
> &vp0 {
> vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
> reg = <ROCKCHIP_VOP2_EP_HDMI0>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
> index d21ec320d295..8af174777809 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
> @@ -2,7 +2,7 @@
>
> /dts-v1/;
>
> -#include "rk3588s-orangepi-5.dtsi"
> +#include "rk3588s-orangepi-5-5b.dtsi"
>
> / {
> model = "Xunlong Orange Pi 5B";
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH] ASoC: imx-rpmsg: Fix ignore-suspend-widgets only applied to codec DAPM
From: Mark Brown @ 2026-04-11 10:40 UTC (permalink / raw)
To: Chancel Liu
Cc: shengjiu.wang, Xiubo.Lee, festevam, nicoleotsuka, lgirdwood,
perex, tiwai, Frank.Li, s.hauer, kernel, linux-sound,
linuxppc-dev, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260411072439.1125664-1-chancel.liu@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
On Sat, Apr 11, 2026 at 04:24:39PM +0900, Chancel Liu wrote:
> Currently the property "ignore-suspend-widgets" are applied only to the
> codec's DAPM context. However, some widgets listed in the property
> (e.g. "Headphone Jack") belong to card or CPU DAI DAPM context.
> Extend the handling so that widgets which are marked ignoring suspend
> are looked up across all widgets in the card.
> --- a/sound/soc/fsl/imx-rpmsg.c
> +++ b/sound/soc/fsl/imx-rpmsg.c
> + num_widgets = of_property_count_strings(data->card.dev->of_node,
> + "ignore-suspend-widgets");
Don't we get an error code back if the property doesn't exist at all?
> + for_each_card_widgets(card, w) {
> + for (i = 0; i < num_widgets; i++) {
> + of_property_read_string_index(data->card.dev->of_node,
> + "ignore-suspend-widgets",
> + i, &widgets);
> + if (!strcmp(w->name, widgets)) {
> + ret = snd_soc_dapm_ignore_suspend(w->dapm, widgets);
> + if (ret) {
> + dev_err(dev, "failed to find ignore suspend widgets\n");
> + return ret;
> + }
> + }
> + }
> + }
This seems like the wrong level to implement this search, it should be
in the core. I'm also not seeing any prefix handling, the widget name
might've been prefixed at runtime.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [soc:for-next] BUILD SUCCESS 249ca93803738427749b611f728601c8da41c2d1
From: kernel test robot @ 2026-04-11 10:35 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 249ca93803738427749b611f728601c8da41c2d1 soc: document merges
elapsed time: 726m
configs tested: 180
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260411 gcc-12.5.0
arc randconfig-002-20260411 gcc-12.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm nhk8815_defconfig clang-23
arm randconfig-001-20260411 gcc-12.5.0
arm randconfig-002-20260411 gcc-12.5.0
arm randconfig-003-20260411 gcc-12.5.0
arm randconfig-004-20260411 gcc-12.5.0
arm shmobile_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260411 clang-23
arm64 randconfig-002-20260411 clang-23
arm64 randconfig-003-20260411 clang-23
arm64 randconfig-004-20260411 clang-23
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260411 clang-23
csky randconfig-002-20260411 clang-23
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260411 gcc-14.3.0
hexagon randconfig-002-20260411 gcc-14.3.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260411 gcc-14
i386 buildonly-randconfig-002-20260411 gcc-14
i386 buildonly-randconfig-003-20260411 gcc-14
i386 buildonly-randconfig-004-20260411 gcc-14
i386 buildonly-randconfig-005-20260411 gcc-14
i386 buildonly-randconfig-006-20260411 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260411 clang-20
i386 randconfig-002-20260411 clang-20
i386 randconfig-003-20260411 clang-20
i386 randconfig-004-20260411 clang-20
i386 randconfig-005-20260411 clang-20
i386 randconfig-006-20260411 clang-20
i386 randconfig-007-20260411 clang-20
i386 randconfig-011-20260411 clang-20
i386 randconfig-012-20260411 clang-20
i386 randconfig-013-20260411 clang-20
i386 randconfig-014-20260411 clang-20
i386 randconfig-015-20260411 clang-20
i386 randconfig-016-20260411 clang-20
i386 randconfig-017-20260411 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260411 gcc-14.3.0
loongarch randconfig-002-20260411 gcc-14.3.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260411 gcc-14.3.0
nios2 randconfig-002-20260411 gcc-14.3.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260411 gcc-11.5.0
parisc randconfig-002-20260411 gcc-11.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260411 gcc-11.5.0
powerpc randconfig-002-20260411 gcc-11.5.0
powerpc64 randconfig-001-20260411 gcc-11.5.0
powerpc64 randconfig-002-20260411 gcc-11.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260411 gcc-10.5.0
riscv randconfig-002-20260411 gcc-10.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260411 gcc-10.5.0
s390 randconfig-002-20260411 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260411 gcc-10.5.0
sh randconfig-002-20260411 gcc-10.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260411 gcc-14
sparc randconfig-002-20260411 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260411 gcc-14
sparc64 randconfig-002-20260411 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260411 gcc-14
um randconfig-002-20260411 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260411 gcc-14
x86_64 buildonly-randconfig-002-20260411 gcc-14
x86_64 buildonly-randconfig-003-20260411 gcc-14
x86_64 buildonly-randconfig-004-20260411 gcc-14
x86_64 buildonly-randconfig-005-20260411 gcc-14
x86_64 buildonly-randconfig-006-20260411 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260411 gcc-14
x86_64 randconfig-002-20260411 gcc-14
x86_64 randconfig-003-20260411 gcc-14
x86_64 randconfig-004-20260411 gcc-14
x86_64 randconfig-005-20260411 gcc-14
x86_64 randconfig-006-20260411 gcc-14
x86_64 randconfig-011-20260411 clang-20
x86_64 randconfig-012-20260411 clang-20
x86_64 randconfig-013-20260411 clang-20
x86_64 randconfig-014-20260411 clang-20
x86_64 randconfig-015-20260411 clang-20
x86_64 randconfig-016-20260411 clang-20
x86_64 randconfig-071-20260411 clang-20
x86_64 randconfig-072-20260411 clang-20
x86_64 randconfig-073-20260411 clang-20
x86_64 randconfig-074-20260411 clang-20
x86_64 randconfig-075-20260411 clang-20
x86_64 randconfig-076-20260411 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260411 gcc-14
xtensa randconfig-002-20260411 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v5 0/4] KVM: arm64: PMU: Use multiple host PMUs
From: Akihiko Odaki @ 2026-04-11 10:20 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Kees Cook,
Gustavo A. R. Silva, Paolo Bonzini, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, kvmarm, linux-kernel, linux-hardening, devel,
kvm, linux-doc, linux-kselftest, Akihiko Odaki
On a heterogeneous arm64 system, KVM's PMU emulation is based on the
features of a single host PMU instance. When a vCPU is migrated to a
pCPU with an incompatible PMU, counters such as PMCCNTR_EL0 stop
incrementing.
Although this behavior is permitted by the architecture, Windows does
not handle it gracefully and may crash with a division-by-zero error.
The current workaround requires VMMs to pin vCPUs to a set of pCPUs
that share a compatible PMU. This is difficult to implement correctly in
QEMU/libvirt, where pinning occurs after vCPU initialization, and it
also restricts the guest to a subset of available pCPUs.
This patch introduces the KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
attribute. If set, PMUv3 will be emulated without programmable event
counters. KVM will be able to run VCPUs on any physical CPUs with a
compatible hardware PMU.
This allows Windows guests to run reliably on heterogeneous systems
without crashing, even without vCPU pinning, and enables VMMs to
schedule vCPUs across all available pCPUs, making full use of the host
hardware.
A QEMU patch that demonstrates the usage of the new attribute is
available at:
https://lore.kernel.org/qemu-devel/20260225-kvm-v2-1-b8d743db0f73@rsg.ci.i.u-tokyo.ac.jp/
("[PATCH RFC v2] target/arm/kvm: Choose PMU backend")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
---
Changes in v5:
- Rebased.
- Fixed the order to clear KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY in
kvm_arm_pmu_v3_set_pmu().
- Fixed the setting of KVM_ARM_VCPU_PMU_V3_IRQ in
test_fixed_counters_only().
- Changed to WARN_ON_ONCE() when kvm_pmu_probe_armpmu() returns NULL in
kvm_pmu_create_perf_event(), which is no longer supposed to happen.
- Link to v4: https://lore.kernel.org/r/20260317-hybrid-v4-0-bd62bcd48644@rsg.ci.i.u-tokyo.ac.jp
Changes in v4:
- Extracted kvm_pmu_enabled_counter_mask() into a separate patch.
- Added patch "KVM: arm64: PMU: Protect the list of PMUs with RCU".
- Merged KVM_REQ_CREATE_PMU into KVM_REQ_RELOAD_PMU.
- Added a check to avoid unnecessary KVM_REQ_RELOAD_PMU requests.
- Dropped the change to avoid setting kvm_arm_set_default_pmu() when
KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY is not set.
- Link to v3: https://lore.kernel.org/r/20260225-hybrid-v3-0-46e8fe220880@rsg.ci.i.u-tokyo.ac.jp
Changes in v3:
- Renamed the attribute to KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY.
- Changed to request the creation of perf counters when loading vCPU.
- Link to v2: https://lore.kernel.org/r/20250806-hybrid-v2-0-0661aec3af8c@rsg.ci.i.u-tokyo.ac.jp
Changes in v2:
- Added the KVM_ARM_VCPU_PMU_V3_COMPOSITION attribute to opt in the
feature.
- Added code to handle overflow.
- Link to v1: https://lore.kernel.org/r/20250319-hybrid-v1-1-4d1ada10e705@daynix.com
---
Akihiko Odaki (4):
KVM: arm64: PMU: Add kvm_pmu_enabled_counter_mask()
KVM: arm64: PMU: Protect the list of PMUs with RCU
KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY
KVM: arm64: selftests: Test PMU_V3_FIXED_COUNTERS_ONLY
Documentation/virt/kvm/devices/vcpu.rst | 29 ++++
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/include/uapi/asm/kvm.h | 1 +
arch/arm64/kvm/arm.c | 1 +
arch/arm64/kvm/pmu-emul.c | 188 ++++++++++++++-------
include/kvm/arm_pmu.h | 2 +
.../selftests/kvm/arm64/vpmu_counter_access.c | 148 +++++++++++++---
7 files changed, 288 insertions(+), 83 deletions(-)
---
base-commit: 9a9c8ce300cd3859cc87b408ef552cd697cc2ab7
change-id: 20250224-hybrid-01d5ff47edd2
Best regards,
--
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
^ permalink raw reply
* [PATCH v5 2/4] KVM: arm64: PMU: Protect the list of PMUs with RCU
From: Akihiko Odaki @ 2026-04-11 10:20 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Kees Cook,
Gustavo A. R. Silva, Paolo Bonzini, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, kvmarm, linux-kernel, linux-hardening, devel,
kvm, linux-doc, linux-kselftest, Akihiko Odaki
In-Reply-To: <20260411-hybrid-v5-0-b043b4d9f49e@rsg.ci.i.u-tokyo.ac.jp>
Convert the list of PMUs to a RCU-protected list that has primitives to
avoid read-side contention.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
---
arch/arm64/kvm/pmu-emul.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index 59ec96e09321..ef5140bbfe28 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -7,9 +7,9 @@
#include <linux/cpu.h>
#include <linux/kvm.h>
#include <linux/kvm_host.h>
-#include <linux/list.h>
#include <linux/perf_event.h>
#include <linux/perf/arm_pmu.h>
+#include <linux/rculist.h>
#include <linux/uaccess.h>
#include <asm/kvm_emulate.h>
#include <kvm/arm_pmu.h>
@@ -26,7 +26,6 @@ static bool kvm_pmu_counter_is_enabled(struct kvm_pmc *pmc);
bool kvm_supports_guest_pmuv3(void)
{
- guard(mutex)(&arm_pmus_lock);
return !list_empty(&arm_pmus);
}
@@ -808,7 +807,7 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
return;
entry->arm_pmu = pmu;
- list_add_tail(&entry->entry, &arm_pmus);
+ list_add_tail_rcu(&entry->entry, &arm_pmus);
}
static struct arm_pmu *kvm_pmu_probe_armpmu(void)
@@ -817,7 +816,7 @@ static struct arm_pmu *kvm_pmu_probe_armpmu(void)
struct arm_pmu *pmu;
int cpu;
- guard(mutex)(&arm_pmus_lock);
+ guard(rcu)();
/*
* It is safe to use a stale cpu to iterate the list of PMUs so long as
@@ -837,7 +836,7 @@ static struct arm_pmu *kvm_pmu_probe_armpmu(void)
* carried here.
*/
cpu = raw_smp_processor_id();
- list_for_each_entry(entry, &arm_pmus, entry) {
+ list_for_each_entry_rcu(entry, &arm_pmus, entry) {
pmu = entry->arm_pmu;
if (cpumask_test_cpu(cpu, &pmu->supported_cpus))
@@ -1088,9 +1087,9 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
int ret = -ENXIO;
lockdep_assert_held(&kvm->arch.config_lock);
- mutex_lock(&arm_pmus_lock);
+ guard(rcu)();
- list_for_each_entry(entry, &arm_pmus, entry) {
+ list_for_each_entry_rcu(entry, &arm_pmus, entry) {
arm_pmu = entry->arm_pmu;
if (arm_pmu->pmu.type == pmu_id) {
if (kvm_vm_has_ran_once(kvm) ||
@@ -1106,7 +1105,6 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
}
}
- mutex_unlock(&arm_pmus_lock);
return ret;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/4] KVM: arm64: PMU: Add kvm_pmu_enabled_counter_mask()
From: Akihiko Odaki @ 2026-04-11 10:20 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Kees Cook,
Gustavo A. R. Silva, Paolo Bonzini, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, kvmarm, linux-kernel, linux-hardening, devel,
kvm, linux-doc, linux-kselftest, Akihiko Odaki
In-Reply-To: <20260411-hybrid-v5-0-b043b4d9f49e@rsg.ci.i.u-tokyo.ac.jp>
This function will be useful to enumerate enabled counters.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
---
arch/arm64/kvm/pmu-emul.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index b03dbda7f1ab..59ec96e09321 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -619,18 +619,24 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
}
}
-static bool kvm_pmu_counter_is_enabled(struct kvm_pmc *pmc)
+static u64 kvm_pmu_enabled_counter_mask(struct kvm_vcpu *vcpu)
{
- struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
- unsigned int mdcr = __vcpu_sys_reg(vcpu, MDCR_EL2);
+ u64 mask = 0;
- if (!(__vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(pmc->idx)))
- return false;
+ if (__vcpu_sys_reg(vcpu, MDCR_EL2) & MDCR_EL2_HPME)
+ mask |= kvm_pmu_hyp_counter_mask(vcpu);
- if (kvm_pmu_counter_is_hyp(vcpu, pmc->idx))
- return mdcr & MDCR_EL2_HPME;
+ if (kvm_vcpu_read_pmcr(vcpu) & ARMV8_PMU_PMCR_E)
+ mask |= ~kvm_pmu_hyp_counter_mask(vcpu);
+
+ return __vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask;
+}
+
+static bool kvm_pmu_counter_is_enabled(struct kvm_pmc *pmc)
+{
+ struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
- return kvm_vcpu_read_pmcr(vcpu) & ARMV8_PMU_PMCR_E;
+ return kvm_pmu_enabled_counter_mask(vcpu) & BIT(pmc->idx);
}
static bool kvm_pmc_counts_at_el0(struct kvm_pmc *pmc)
--
2.53.0
^ permalink raw reply related
* [PATCH v5 3/4] KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY
From: Akihiko Odaki @ 2026-04-11 10:20 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Kees Cook,
Gustavo A. R. Silva, Paolo Bonzini, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, kvmarm, linux-kernel, linux-hardening, devel,
kvm, linux-doc, linux-kselftest, Akihiko Odaki
In-Reply-To: <20260411-hybrid-v5-0-b043b4d9f49e@rsg.ci.i.u-tokyo.ac.jp>
On a heterogeneous arm64 system, KVM's PMU emulation is based on the
features of a single host PMU instance. When a vCPU is migrated to a
pCPU with an incompatible PMU, counters such as PMCCNTR_EL0 stop
incrementing.
Although this behavior is permitted by the architecture, Windows does
not handle it gracefully and may crash with a division-by-zero error.
The current workaround requires VMMs to pin vCPUs to a set of pCPUs
that share a compatible PMU. This is difficult to implement correctly in
QEMU/libvirt, where pinning occurs after vCPU initialization, and it
also restricts the guest to a subset of available pCPUs.
Introduce the KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY attribute to
create a "fixed-counters-only" PMU. When set, KVM exposes a PMU that is
compatible with all pCPUs but that does not support programmable
event counters which may have different feature sets on different PMUs.
This allows Windows guests to run reliably on heterogeneous systems
without crashing, even without vCPU pinning, and enables VMMs to
schedule vCPUs across all available pCPUs, making full use of the host
hardware.
Much like KVM_ARM_VCPU_PMU_V3_IRQ and other read-write attributes, this
attribute provides a getter that facilitates kernel and userspace
debugging/testing.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
---
Documentation/virt/kvm/devices/vcpu.rst | 29 ++++++
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/include/uapi/asm/kvm.h | 1 +
arch/arm64/kvm/arm.c | 1 +
arch/arm64/kvm/pmu-emul.c | 156 +++++++++++++++++++++++---------
include/kvm/arm_pmu.h | 2 +
6 files changed, 148 insertions(+), 43 deletions(-)
diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
index 60bf205cb373..e0aeb1897d77 100644
--- a/Documentation/virt/kvm/devices/vcpu.rst
+++ b/Documentation/virt/kvm/devices/vcpu.rst
@@ -161,6 +161,35 @@ explicitly selected, or the number of counters is out of range for the
selected PMU. Selecting a new PMU cancels the effect of setting this
attribute.
+1.6 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
+------------------------------------------------------
+
+:Parameters: no additional parameter in kvm_device_attr.addr
+
+:Returns:
+
+ ======= =====================================================
+ -EBUSY Attempted to set after initializing PMUv3 or running
+ VCPU, or attempted to set for the first time after
+ setting an event filter
+ -ENXIO Attempted to get before setting
+ -ENODEV Attempted to set while PMUv3 not supported
+ ======= =====================================================
+
+If set, PMUv3 will be emulated without programmable event counters. The VCPU
+will use any compatible hardware PMU. This attribute is particularly useful on
+heterogeneous systems where different hardware PMUs cover different physical
+CPUs. The compatibility of hardware PMUs can be checked with
+KVM_ARM_VCPU_PMU_V3_SET_PMU. All VCPUs in a VM share this attribute. It isn't
+possible to set it for the first time if a PMU event filter is already present.
+
+Note that KVM will not make any attempts to run the VCPU on the physical CPUs
+with compatible hardware PMUs. This is entirely left to userspace. However,
+attempting to run the VCPU on an unsupported CPU will fail and KVM_RUN will
+return with exit_reason = KVM_EXIT_FAIL_ENTRY and populate the fail_entry struct
+by setting hardware_entry_failure_reason field to
+KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED and the cpu field to the processor id.
+
2. GROUP: KVM_ARM_VCPU_TIMER_CTRL
=================================
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 59f25b85be2b..b59e0182472c 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -353,6 +353,8 @@ struct kvm_arch {
#define KVM_ARCH_FLAG_WRITABLE_IMP_ID_REGS 10
/* Unhandled SEAs are taken to userspace */
#define KVM_ARCH_FLAG_EXIT_SEA 11
+ /* PMUv3 is emulated without progammable event counters */
+#define KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY 12
unsigned long flags;
/* VM-wide vCPU feature set */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index a792a599b9d6..474c84fa757f 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -436,6 +436,7 @@ enum {
#define KVM_ARM_VCPU_PMU_V3_FILTER 2
#define KVM_ARM_VCPU_PMU_V3_SET_PMU 3
#define KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS 4
+#define KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY 5
#define KVM_ARM_VCPU_TIMER_CTRL 1
#define KVM_ARM_VCPU_TIMER_IRQ_VTIMER 0
#define KVM_ARM_VCPU_TIMER_IRQ_PTIMER 1
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 620a465248d1..dca16ca26d32 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -634,6 +634,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
if (has_vhe())
kvm_vcpu_load_vhe(vcpu);
kvm_arch_vcpu_load_fp(vcpu);
+ kvm_vcpu_load_pmu(vcpu);
kvm_vcpu_pmu_restore_guest(vcpu);
if (kvm_arm_is_pvtime_enabled(&vcpu->arch))
kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index ef5140bbfe28..c827e66af0a2 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -326,7 +326,10 @@ u64 kvm_pmu_implemented_counter_mask(struct kvm_vcpu *vcpu)
static void kvm_pmc_enable_perf_event(struct kvm_pmc *pmc)
{
- if (!pmc->perf_event) {
+ struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
+
+ if (!pmc->perf_event ||
+ !cpumask_test_cpu(vcpu->cpu, &to_arm_pmu(pmc->perf_event->pmu)->supported_cpus)) {
kvm_pmu_create_perf_event(pmc);
return;
}
@@ -667,10 +670,8 @@ static bool kvm_pmc_counts_at_el2(struct kvm_pmc *pmc)
return kvm_pmc_read_evtreg(pmc) & ARMV8_PMU_INCLUDE_EL2;
}
-static int kvm_map_pmu_event(struct kvm *kvm, unsigned int eventsel)
+static int kvm_map_pmu_event(struct arm_pmu *pmu, unsigned int eventsel)
{
- struct arm_pmu *pmu = kvm->arch.arm_pmu;
-
/*
* The CPU PMU likely isn't PMUv3; let the driver provide a mapping
* for the guest's PMUv3 event ID.
@@ -681,6 +682,23 @@ static int kvm_map_pmu_event(struct kvm *kvm, unsigned int eventsel)
return eventsel;
}
+static struct arm_pmu *kvm_pmu_probe_armpmu(int cpu)
+{
+ struct arm_pmu_entry *entry;
+ struct arm_pmu *pmu;
+
+ guard(rcu)();
+
+ list_for_each_entry_rcu(entry, &arm_pmus, entry) {
+ pmu = entry->arm_pmu;
+
+ if (cpumask_test_cpu(cpu, &pmu->supported_cpus))
+ return pmu;
+ }
+
+ return NULL;
+}
+
/**
* kvm_pmu_create_perf_event - create a perf event for a counter
* @pmc: Counter context
@@ -694,6 +712,12 @@ static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
int eventsel;
u64 evtreg;
+ if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags)) {
+ arm_pmu = kvm_pmu_probe_armpmu(vcpu->cpu);
+ if (WARN_ON_ONCE(!arm_pmu))
+ return;
+ }
+
evtreg = kvm_pmc_read_evtreg(pmc);
kvm_pmu_stop_counter(pmc);
@@ -722,7 +746,7 @@ static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
* Don't create an event if we're running on hardware that requires
* PMUv3 event translation and we couldn't find a valid mapping.
*/
- eventsel = kvm_map_pmu_event(vcpu->kvm, eventsel);
+ eventsel = kvm_map_pmu_event(arm_pmu, eventsel);
if (eventsel < 0)
return;
@@ -810,42 +834,6 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
list_add_tail_rcu(&entry->entry, &arm_pmus);
}
-static struct arm_pmu *kvm_pmu_probe_armpmu(void)
-{
- struct arm_pmu_entry *entry;
- struct arm_pmu *pmu;
- int cpu;
-
- guard(rcu)();
-
- /*
- * It is safe to use a stale cpu to iterate the list of PMUs so long as
- * the same value is used for the entirety of the loop. Given this, and
- * the fact that no percpu data is used for the lookup there is no need
- * to disable preemption.
- *
- * It is still necessary to get a valid cpu, though, to probe for the
- * default PMU instance as userspace is not required to specify a PMU
- * type. In order to uphold the preexisting behavior KVM selects the
- * PMU instance for the core during vcpu init. A dependent use
- * case would be a user with disdain of all things big.LITTLE that
- * affines the VMM to a particular cluster of cores.
- *
- * In any case, userspace should just do the sane thing and use the UAPI
- * to select a PMU type directly. But, be wary of the baggage being
- * carried here.
- */
- cpu = raw_smp_processor_id();
- list_for_each_entry_rcu(entry, &arm_pmus, entry) {
- pmu = entry->arm_pmu;
-
- if (cpumask_test_cpu(cpu, &pmu->supported_cpus))
- return pmu;
- }
-
- return NULL;
-}
-
static u64 __compute_pmceid(struct arm_pmu *pmu, bool pmceid1)
{
u32 hi[2], lo[2];
@@ -888,6 +876,9 @@ u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
u64 val, mask = 0;
int base, i, nr_events;
+ if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags))
+ return 0;
+
if (!pmceid1) {
val = compute_pmceid0(cpu_pmu);
base = 0;
@@ -915,6 +906,26 @@ u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
return val & mask;
}
+void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu)
+{
+ unsigned long mask = kvm_pmu_enabled_counter_mask(vcpu);
+ struct kvm_pmc *pmc;
+ struct arm_pmu *cpu_pmu;
+ int i;
+
+ for_each_set_bit(i, &mask, 32) {
+ pmc = kvm_vcpu_idx_to_pmc(vcpu, i);
+ if (!pmc->perf_event)
+ continue;
+
+ cpu_pmu = to_arm_pmu(pmc->perf_event->pmu);
+ if (!cpumask_test_cpu(vcpu->cpu, &cpu_pmu->supported_cpus)) {
+ kvm_make_request(KVM_REQ_RELOAD_PMU, vcpu);
+ break;
+ }
+ }
+}
+
void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu)
{
u64 mask = kvm_pmu_implemented_counter_mask(vcpu);
@@ -1016,6 +1027,9 @@ u8 kvm_arm_pmu_get_max_counters(struct kvm *kvm)
{
struct arm_pmu *arm_pmu = kvm->arch.arm_pmu;
+ if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags))
+ return 0;
+
/*
* PMUv3 requires that all event counters are capable of counting any
* event, though the same may not be true of non-PMUv3 hardware.
@@ -1070,7 +1084,24 @@ static void kvm_arm_set_pmu(struct kvm *kvm, struct arm_pmu *arm_pmu)
*/
int kvm_arm_set_default_pmu(struct kvm *kvm)
{
- struct arm_pmu *arm_pmu = kvm_pmu_probe_armpmu();
+ /*
+ * It is safe to use a stale cpu to iterate the list of PMUs so long as
+ * the same value is used for the entirety of the loop. Given this, and
+ * the fact that no percpu data is used for the lookup there is no need
+ * to disable preemption.
+ *
+ * It is still necessary to get a valid cpu, though, to probe for the
+ * default PMU instance as userspace is not required to specify a PMU
+ * type. In order to uphold the preexisting behavior KVM selects the
+ * PMU instance for the core during vcpu init. A dependent use
+ * case would be a user with disdain of all things big.LITTLE that
+ * affines the VMM to a particular cluster of cores.
+ *
+ * In any case, userspace should just do the sane thing and use the UAPI
+ * to select a PMU type directly. But, be wary of the baggage being
+ * carried here.
+ */
+ struct arm_pmu *arm_pmu = kvm_pmu_probe_armpmu(raw_smp_processor_id());
if (!arm_pmu)
return -ENODEV;
@@ -1098,6 +1129,7 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
break;
}
+ clear_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags);
kvm_arm_set_pmu(kvm, arm_pmu);
cpumask_copy(kvm->arch.supported_cpus, &arm_pmu->supported_cpus);
ret = 0;
@@ -1108,11 +1140,42 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
return ret;
}
+static int kvm_arm_pmu_v3_set_pmu_fixed_counters_only(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = vcpu->kvm;
+ struct arm_pmu_entry *entry;
+ struct arm_pmu *arm_pmu;
+ struct cpumask *supported_cpus = kvm->arch.supported_cpus;
+
+ lockdep_assert_held(&kvm->arch.config_lock);
+
+ if (kvm_vm_has_ran_once(kvm) ||
+ (kvm->arch.pmu_filter &&
+ !test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags)))
+ return -EBUSY;
+
+ set_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags);
+ kvm_arm_set_nr_counters(kvm, 0);
+ cpumask_clear(supported_cpus);
+
+ guard(rcu)();
+
+ list_for_each_entry_rcu(entry, &arm_pmus, entry) {
+ arm_pmu = entry->arm_pmu;
+ cpumask_or(supported_cpus, supported_cpus, &arm_pmu->supported_cpus);
+ }
+
+ return 0;
+}
+
static int kvm_arm_pmu_v3_set_nr_counters(struct kvm_vcpu *vcpu, unsigned int n)
{
struct kvm *kvm = vcpu->kvm;
- if (!kvm->arch.arm_pmu)
+ lockdep_assert_held(&kvm->arch.config_lock);
+
+ if (!kvm->arch.arm_pmu &&
+ !test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags))
return -EINVAL;
if (n > kvm_arm_pmu_get_max_counters(kvm))
@@ -1227,6 +1290,8 @@ int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
return kvm_arm_pmu_v3_set_nr_counters(vcpu, n);
}
+ case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
+ return kvm_arm_pmu_v3_set_pmu_fixed_counters_only(vcpu);
case KVM_ARM_VCPU_PMU_V3_INIT:
return kvm_arm_pmu_v3_init(vcpu);
}
@@ -1253,6 +1318,10 @@ int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
irq = vcpu->arch.pmu.irq_num;
return put_user(irq, uaddr);
}
+ case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
+ lockdep_assert_held(&vcpu->kvm->arch.config_lock);
+ if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags))
+ return 0;
}
return -ENXIO;
@@ -1266,6 +1335,7 @@ int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
case KVM_ARM_VCPU_PMU_V3_FILTER:
case KVM_ARM_VCPU_PMU_V3_SET_PMU:
case KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS:
+ case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
if (kvm_vcpu_has_pmu(vcpu))
return 0;
}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 96754b51b411..1375cbaf97b2 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -56,6 +56,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
u64 select_idx);
+void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu);
void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu);
int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
struct kvm_device_attr *attr);
@@ -161,6 +162,7 @@ static inline u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
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) {}
+static inline void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu) {}
static inline void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu) {}
static inline u8 kvm_arm_pmu_get_pmuver_limit(void)
{
--
2.53.0
^ permalink raw reply related
* [PATCH v5 4/4] KVM: arm64: selftests: Test PMU_V3_FIXED_COUNTERS_ONLY
From: Akihiko Odaki @ 2026-04-11 10:20 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Kees Cook,
Gustavo A. R. Silva, Paolo Bonzini, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, kvmarm, linux-kernel, linux-hardening, devel,
kvm, linux-doc, linux-kselftest, Akihiko Odaki
In-Reply-To: <20260411-hybrid-v5-0-b043b4d9f49e@rsg.ci.i.u-tokyo.ac.jp>
Assert the following:
- KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY is unset at initialization.
- KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY can be set.
- Setting KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY for the first time
after setting an event filter results in EBUSY.
- KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY can be set again even if an
event filter has already been set.
- Setting KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY after running a VCPU
results in EBUSY.
- The existing test cases pass with
KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY set.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
---
.../selftests/kvm/arm64/vpmu_counter_access.c | 148 +++++++++++++++++----
1 file changed, 122 insertions(+), 26 deletions(-)
diff --git a/tools/testing/selftests/kvm/arm64/vpmu_counter_access.c b/tools/testing/selftests/kvm/arm64/vpmu_counter_access.c
index ae36325c022f..50189fb56374 100644
--- a/tools/testing/selftests/kvm/arm64/vpmu_counter_access.c
+++ b/tools/testing/selftests/kvm/arm64/vpmu_counter_access.c
@@ -403,12 +403,7 @@ static void create_vpmu_vm(void *guest_code)
{
struct kvm_vcpu_init init;
uint8_t pmuver, ec;
- uint64_t dfr0, irq = 23;
- struct kvm_device_attr irq_attr = {
- .group = KVM_ARM_VCPU_PMU_V3_CTRL,
- .attr = KVM_ARM_VCPU_PMU_V3_IRQ,
- .addr = (uint64_t)&irq,
- };
+ uint64_t dfr0;
/* The test creates the vpmu_vm multiple times. Ensure a clean state */
memset(&vpmu_vm, 0, sizeof(vpmu_vm));
@@ -434,8 +429,6 @@ static void create_vpmu_vm(void *guest_code)
TEST_ASSERT(pmuver != ID_AA64DFR0_EL1_PMUVer_IMP_DEF &&
pmuver >= ID_AA64DFR0_EL1_PMUVer_IMP,
"Unexpected PMUVER (0x%x) on the vCPU with PMUv3", pmuver);
-
- vcpu_ioctl(vpmu_vm.vcpu, KVM_SET_DEVICE_ATTR, &irq_attr);
}
static void destroy_vpmu_vm(void)
@@ -461,15 +454,25 @@ static void run_vcpu(struct kvm_vcpu *vcpu, uint64_t pmcr_n)
}
}
-static void test_create_vpmu_vm_with_nr_counters(unsigned int nr_counters, bool expect_fail)
+static void test_create_vpmu_vm_with_nr_counters(unsigned int nr_counters,
+ bool fixed_counters_only,
+ bool expect_fail)
{
struct kvm_vcpu *vcpu;
unsigned int prev;
int ret;
+ uint64_t irq = 23;
create_vpmu_vm(guest_code);
vcpu = vpmu_vm.vcpu;
+ if (fixed_counters_only)
+ vcpu_device_attr_set(vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY, NULL);
+
+ vcpu_device_attr_set(vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_IRQ, &irq);
+
prev = get_pmcr_n(vcpu_get_reg(vcpu, KVM_ARM64_SYS_REG(SYS_PMCR_EL0)));
ret = __vcpu_device_attr_set(vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
@@ -489,15 +492,15 @@ static void test_create_vpmu_vm_with_nr_counters(unsigned int nr_counters, bool
* Create a guest with one vCPU, set the PMCR_EL0.N for the vCPU to @pmcr_n,
* and run the test.
*/
-static void run_access_test(uint64_t pmcr_n)
+static void run_access_test(uint64_t pmcr_n, bool fixed_counters_only)
{
uint64_t sp;
struct kvm_vcpu *vcpu;
struct kvm_vcpu_init init;
- pr_debug("Test with pmcr_n %lu\n", pmcr_n);
+ pr_debug("Test with pmcr_n %lu, fixed_counters_only %d\n", pmcr_n, fixed_counters_only);
- test_create_vpmu_vm_with_nr_counters(pmcr_n, false);
+ test_create_vpmu_vm_with_nr_counters(pmcr_n, fixed_counters_only, false);
vcpu = vpmu_vm.vcpu;
/* Save the initial sp to restore them later to run the guest again */
@@ -531,14 +534,14 @@ static struct pmreg_sets validity_check_reg_sets[] = {
* Create a VM, and check if KVM handles the userspace accesses of
* the PMU register sets in @validity_check_reg_sets[] correctly.
*/
-static void run_pmregs_validity_test(uint64_t pmcr_n)
+static void run_pmregs_validity_test(uint64_t pmcr_n, bool fixed_counters_only)
{
int i;
struct kvm_vcpu *vcpu;
uint64_t set_reg_id, clr_reg_id, reg_val;
uint64_t valid_counters_mask, max_counters_mask;
- test_create_vpmu_vm_with_nr_counters(pmcr_n, false);
+ test_create_vpmu_vm_with_nr_counters(pmcr_n, fixed_counters_only, false);
vcpu = vpmu_vm.vcpu;
valid_counters_mask = get_counters_mask(pmcr_n);
@@ -588,11 +591,11 @@ static void run_pmregs_validity_test(uint64_t pmcr_n)
* the vCPU to @pmcr_n, which is larger than the host value.
* The attempt should fail as @pmcr_n is too big to set for the vCPU.
*/
-static void run_error_test(uint64_t pmcr_n)
+static void run_error_test(uint64_t pmcr_n, bool fixed_counters_only)
{
pr_debug("Error test with pmcr_n %lu (larger than the host)\n", pmcr_n);
- test_create_vpmu_vm_with_nr_counters(pmcr_n, true);
+ test_create_vpmu_vm_with_nr_counters(pmcr_n, fixed_counters_only, true);
destroy_vpmu_vm();
}
@@ -622,22 +625,115 @@ static bool kvm_supports_nr_counters_attr(void)
return supported;
}
-int main(void)
+static void test_config(uint64_t pmcr_n, bool fixed_counters_only)
{
- uint64_t i, pmcr_n;
-
- TEST_REQUIRE(kvm_has_cap(KVM_CAP_ARM_PMU_V3));
- TEST_REQUIRE(kvm_supports_vgic_v3());
- TEST_REQUIRE(kvm_supports_nr_counters_attr());
+ uint64_t i;
- pmcr_n = get_pmcr_n_limit();
for (i = 0; i <= pmcr_n; i++) {
- run_access_test(i);
- run_pmregs_validity_test(i);
+ run_access_test(i, fixed_counters_only);
+ run_pmregs_validity_test(i, fixed_counters_only);
}
for (i = pmcr_n + 1; i < ARMV8_PMU_MAX_COUNTERS; i++)
- run_error_test(i);
+ run_error_test(i, fixed_counters_only);
+}
+
+static void test_fixed_counters_only(void)
+{
+ struct kvm_pmu_event_filter filter = { .nevents = 0 };
+ struct kvm_vm *vm;
+ struct kvm_vcpu *running_vcpu;
+ struct kvm_vcpu *stopped_vcpu;
+ struct kvm_vcpu_init init;
+ int ret;
+ uint64_t irq = 23;
+
+ create_vpmu_vm(guest_code);
+ ret = __vcpu_has_device_attr(vpmu_vm.vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY);
+ if (ret) {
+ TEST_ASSERT(ret == -1 && errno == ENXIO,
+ KVM_IOCTL_ERROR(KVM_GET_DEVICE_ATTR, ret));
+ destroy_vpmu_vm();
+ return;
+ }
+
+ /* Assert that FIXED_COUNTERS_ONLY is unset at initialization. */
+ ret = __vcpu_device_attr_get(vpmu_vm.vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY, NULL);
+ TEST_ASSERT(ret == -1 && errno == ENXIO,
+ KVM_IOCTL_ERROR(KVM_GET_DEVICE_ATTR, ret));
+
+ /* Assert that setting FIXED_COUNTERS_ONLY succeeds. */
+ vcpu_device_attr_set(vpmu_vm.vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY, NULL);
+
+ /* Assert that getting FIXED_COUNTERS_ONLY succeeds. */
+ vcpu_device_attr_get(vpmu_vm.vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY, NULL);
+
+ /*
+ * Assert that setting FIXED_COUNTERS_ONLY again succeeds even if an
+ * event filter has already been set.
+ */
+ vcpu_device_attr_set(vpmu_vm.vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FILTER, &filter);
+
+ vcpu_device_attr_set(vpmu_vm.vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY, NULL);
+
+ destroy_vpmu_vm();
+
+ create_vpmu_vm(guest_code);
+
+ /*
+ * Assert that setting FIXED_COUNTERS_ONLY results in EBUSY if an event
+ * filter has already been set while FIXED_COUNTERS_ONLY has not.
+ */
+ vcpu_device_attr_set(vpmu_vm.vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FILTER, &filter);
+
+ ret = __vcpu_device_attr_set(vpmu_vm.vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY, NULL);
+ TEST_ASSERT(ret == -1 && errno == EBUSY,
+ KVM_IOCTL_ERROR(KVM_GET_DEVICE_ATTR, ret));
+
+ destroy_vpmu_vm();
+
+ /*
+ * Assert that setting FIXED_COUNTERS_ONLY after running a VCPU results
+ * in EBUSY.
+ */
+ vm = vm_create(2);
+ vm_ioctl(vm, KVM_ARM_PREFERRED_TARGET, &init);
+ init.features[0] |= (1 << KVM_ARM_VCPU_PMU_V3);
+ running_vcpu = aarch64_vcpu_add(vm, 0, &init, guest_code);
+ stopped_vcpu = aarch64_vcpu_add(vm, 1, &init, guest_code);
+ kvm_arch_vm_finalize_vcpus(vm);
+ vcpu_device_attr_set(running_vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_IRQ, &irq);
+ vcpu_device_attr_set(running_vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_INIT, NULL);
+ vcpu_run(running_vcpu);
+
+ ret = __vcpu_device_attr_set(stopped_vcpu, KVM_ARM_VCPU_PMU_V3_CTRL,
+ KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY, NULL);
+ TEST_ASSERT(ret == -1 && errno == EBUSY,
+ KVM_IOCTL_ERROR(KVM_GET_DEVICE_ATTR, ret));
+
+ kvm_vm_free(vm);
+
+ test_config(0, true);
+}
+
+int main(void)
+{
+ TEST_REQUIRE(kvm_has_cap(KVM_CAP_ARM_PMU_V3));
+ TEST_REQUIRE(kvm_supports_vgic_v3());
+ TEST_REQUIRE(kvm_supports_nr_counters_attr());
+
+ test_config(get_pmcr_n_limit(), false);
+ test_fixed_counters_only();
return 0;
}
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.1 (#1)
From: Krzysztof Kozlowski @ 2026-04-11 9:33 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Arnd Bergmann, arm, soc, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel
In-Reply-To: <87cy072bho.fsf@BLaptop.bootlin.com>
On Fri, Apr 10, 2026 at 03:25:39PM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for dt64 for mvebu for v7.1.
>
> Gregory
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt64-7.1-1
>
> for you to fetch changes up to 00e6d608fe80b0f68c325cb46862f78e9a8ec768:
>
> arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node (2026-04-09 10:14:40 +0200)
>
> ----------------------------------------------------------------
> mvebu dt64 for 7.1 (part 1)
>
> - Armada 37xx/3720 device tree fixes:
> - Reorder USB PHYs, standardize names, drop undocumented
> properties, fix schema alignment
>
> - Add Marvell 7k COMe board bindings and uDPU ethernet aliases
>
> - Cleanup: drop unused .dtsi files
>
Days in linux-next:
----------------------------------------
1 | ++ (2)
...
So a few things were just applied, unless this was rebased?
I will wait with this. It might miss the merge window if v7.0 is
released this weekend.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] amlogic ARM64 DT updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-11 9:32 UTC (permalink / raw)
To: Neil Armstrong; +Cc: soc, arm, linux-amlogic, linux-arm-kernel
In-Reply-To: <2fde1b11-d2a4-4aa2-8c28-d20fbbb54f7f@linaro.org>
On Fri, Apr 10, 2026 at 10:50:58AM +0200, Neil Armstrong wrote:
> Hi,
>
> Here's the Amlogic ARM64 DT changes for v7.1, including a bunch of fixes
> and improvements for the Khadas VIM4 and VIM1s SBCs, plus some additions
> for the Phicomm N1 and a couple of low priority fixes.
>
> Thanks,
> Neil
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git tags/amlogic-arm64-dt-for-v7.1
>
> for you to fetch changes up to 401e5c73eedde8225e87bd11c794b8409248ff41:
>
> arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number (2026-04-08 14:27:20 +0200)
Days in linux-next:
----------------------------------------
1 | ++++++++ (8)
...
So a few things were just applied, unless this was rebased?
I will wait with this. It might miss the merge window if v7.0 is
released this weekend.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt for v7.1 (#1)
From: Krzysztof Kozlowski @ 2026-04-11 9:29 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Arnd Bergmann, arm, soc, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel
In-Reply-To: <87qzoo3412.fsf@BLaptop.bootlin.com>
On Thu, Apr 09, 2026 at 10:56:57AM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for dt for mvebu for v7.1.
>
> Gregory
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt-7.1-1
>
> for you to fetch changes up to 29d8a380643521422a9907f3e982e142fe22d19e:
>
> MAINTAINERS: drop file entry in Marvell Kirkwood and Armada SOC support (2026-03-02 16:24:43 +0100)
>
> ----------------------------------------------------------------
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: fixes for v7.0 (#1)
From: Krzysztof Kozlowski @ 2026-04-11 8:54 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Arnd Bergmann, arm, soc, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel
In-Reply-To: <87tstk35d2.fsf@BLaptop.bootlin.com>
On Thu, Apr 09, 2026 at 10:28:09AM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for fixes for mvebu for v7.0.
>
> Gregory
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-fixes-7.0-1
>
> for you to fetch changes up to edb7efa767da8bb82d724b85178be251ec4e060e:
>
> dt-bindings: arm64: add Marvell 7k COMe boards (2026-03-13 16:41:11 +0100)
>
> ----------------------------------------------------------------
> mvebu fixes for 7.0 (part 1)
>
> A new device tree has been merged without a binding, which triggered
> warnings during dtb_checks. The commit in this pull request fixes this
> issue, enabling easier detection of new problems in device trees by
> reducing the number of false warnings.
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Reset controller fixes for v7.0, part 3
From: Krzysztof Kozlowski @ 2026-04-11 8:52 UTC (permalink / raw)
To: Philipp Zabel; +Cc: soc, linux-arm-kernel, kernel
In-Reply-To: <20260408094152.1698594-1-p.zabel@pengutronix.de>
On Wed, Apr 08, 2026 at 11:41:52AM +0200, Philipp Zabel wrote:
> Dear arm-soc maintainers,
>
> The following changes since commit a0e0c2f8c5f32b675f58e25a9338283cedb5ad2b:
>
> reset: spacemit: k3: Decouple composite reset lines (2026-03-23 12:25:47 +0100)
>
> are available in the Git repository at:
>
> https://git.pengutronix.de/git/pza/linux.git tags/reset-fixes-for-v7.0-3
>
> for you to fetch changes up to 9797524ef2b69c6b187b55bd844eb72a8c1cbd99:
>
> reset: amlogic: t7: Fix null reset ops (2026-03-31 17:19:18 +0200)
>
> ----------------------------------------------------------------
> Reset controller fixes for v7.0, part 3
>
> * Add missing reset ops for amlogic,t7-reset to the reset-meson driver.
> The resets are unused as of now, but as soon as they are, the driver
> would otherwise run into a NULL pointer dereference.
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] firmware: arm_ffa: Fix for v7.1
From: Krzysztof Kozlowski @ 2026-04-11 8:49 UTC (permalink / raw)
To: Sudeep Holla; +Cc: ARM SoC Team, SoC Team, ALKML, Arnd Bergmann
In-Reply-To: <20260407100841.3150090-1-sudeep.holla@kernel.org>
On Tue, Apr 07, 2026 at 11:08:39AM +0100, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull ! This is the only fix/update I have at the moment for v7.1
> So, I am sending it early as fix but late as an update for v7.1.
>
> Regards,
> Sudeep
>
> -->8
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/ffa-fix-7.1
>
> for you to fetch changes up to 83210251fd70d5f96bcdc8911e15f7411a6b2463:
>
> firmware: arm_ffa: Use the correct buffer size during RXTX_MAP (2026-04-07 10:47:42 +0100)
>
> ----------------------------------------------------------------
> Arm FF-A fix for v7.1
>
> Use the page aligned backing allocation size when computing the RXTX_MAP
> page count. This fixes FF-A RX/TX buffer registration on kernels built
> with 16K/64K PAGE_SIZE, where alloc_pages_exact() backs the buffer with a
> larger aligned span than the discovered minimum buffer size.
Can we avoid per-driver trees or pulls? You do maintain also ARM SCMI
firmware driver, so this could be sent together? I think you also use
the same Git tree, right?
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Allwinner Device Tree Changes for 7.1 - Part 2
From: Krzysztof Kozlowski @ 2026-04-11 8:44 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: soc, Jernej Skrabec, Samuel Holland, linux-sunxi,
linux-arm-kernel
In-Reply-To: <adPIgTlQxnVpYgH4@home.wens.tw>
On Mon, Apr 06, 2026 at 10:51:45PM +0800, Chen-Yu Tsai wrote:
> The following changes since commit b912e48bee355b6b1faf86efc4a23191324ffecb:
>
> arm64: dts: allwinner: h6: Add TaiqiCat (TQC) A01 support (2026-03-14 15:27:04 +0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-for-7.1-2
>
> for you to fetch changes up to c755e39836ec492b0bc210fd96c2b720b5b4a690:
>
> arm64: dts: allwinner: enable h616 timer support (2026-03-29 21:20:49 +0800)
>
> ----------------------------------------------------------------
> Allwinner Device Tree Changes for 7.1 - Part 2
>
> UART DMA channels added for A64 and H6. Standard resolution MMIO timer added
> for H616. This timer can be used as a broadcast timer for wakeup from idle
> states.
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] One more Qualcomm driver update for v7.1
From: Krzysztof Kozlowski @ 2026-04-11 8:41 UTC (permalink / raw)
To: Bjorn Andersson
Cc: arm, soc, linux-arm-msm, linux-arm-kernel, Arnd Bergmann,
Bjorn Andersson
In-Reply-To: <20260406132138.2265013-1-andersson@kernel.org>
On Mon, Apr 06, 2026 at 08:21:38AM -0500, Bjorn Andersson wrote:
>
> The following changes since commit d6e766e391ef0b2be62682e007223fc72ba7764f:
>
> Merge branch '20260125-iris-ubwc-v4-1-1ff30644ac81@oss.qualcomm.com' into drivers-for-7.1 (2026-03-30 12:46:14 -0500)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-7.1-2
>
> for you to fetch changes up to a31ad9339eff4ce401dec816b01a94b4e3c47898:
>
> firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X (2026-04-02 16:09:01 -0500)
>
> ----------------------------------------------------------------
> One more Qualcomm driver update for v7.1
>
> Flag Lenovo IdeaCentre Mini X to have functional QSEECOM/uefisecapp.
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] A few more Arm64 DeviceTree updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-11 8:38 UTC (permalink / raw)
To: Bjorn Andersson
Cc: arm, soc, linux-arm-msm, linux-arm-kernel, Arnd Bergmann,
Paul Sajna, Wenmeng Liu, Sudarshan Shetty, Bjorn Andersson,
Casey Connolly, Jie Zhang, Abel Vesa, Alexander Martinz,
Amir Dahan, Christopher Brown, Gaurav Kohli, Mukesh Ojha,
Odelu Kukatla, Qingqing Zhou
In-Reply-To: <20260406132007.2264408-1-andersson@kernel.org>
On Mon, Apr 06, 2026 at 08:20:07AM -0500, Bjorn Andersson wrote:
>
> The following changes since commit b683730e27ba4f91986c4c92f5cb7297f1e01a6d:
>
> arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP (2026-03-30 09:35:01 -0500)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-7.1-2
>
> for you to fetch changes up to af241225893ac4933bb8f0615f2dfda8ea2326ce:
>
> arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X (2026-04-02 16:08:54 -0500)
>
> ----------------------------------------------------------------
A note: your GPG key has expired. Consider dropping expiration time. At
least I am planning to drop it in my next keys update.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] A few more Arm64 DeviceTree updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-11 8:36 UTC (permalink / raw)
To: Bjorn Andersson
Cc: arm, soc, linux-arm-msm, linux-arm-kernel, Arnd Bergmann,
Paul Sajna, Wenmeng Liu, Sudarshan Shetty, Bjorn Andersson,
Casey Connolly, Jie Zhang, Abel Vesa, Alexander Martinz,
Amir Dahan, Christopher Brown, Gaurav Kohli, Mukesh Ojha,
Odelu Kukatla, Qingqing Zhou
In-Reply-To: <20260406132007.2264408-1-andersson@kernel.org>
On Mon, Apr 06, 2026 at 08:20:07AM -0500, Bjorn Andersson wrote:
>
> The following changes since commit b683730e27ba4f91986c4c92f5cb7297f1e01a6d:
>
> arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP (2026-03-30 09:35:01 -0500)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-7.1-2
>
> for you to fetch changes up to af241225893ac4933bb8f0615f2dfda8ea2326ce:
>
> arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X (2026-04-02 16:08:54 -0500)
>
> ----------------------------------------------------------------
> A few more Arm64 DeviceTree updates for v7.1
>
> Introduce the Hamoa-based Lenovo IdeaCentre Mini X, the Dragonwing
> IQ-615 (Talos) EVK, and a Talos EVK camera overlay.
>
> Enable DisplayPort support on the Glymur CRD.
>
> Add WiFi, Bluetooh, LEDs, and venus on LG-based SDM845 devices. Add
> battery, charger, and display on the LG G7 ThinQ.
>
> Enable SD-card, describe the audio amplifier, and increase the speed of
> the i2c clock for touchscreen on the SHIFT SHIFT6mq.
>
> Add camera subsystem, camera control interface, GPU, GMU, and GPU
> cooling on the Talos platform. Enable the GPU on the Ride board.
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] i.MX arm dts changes for v7.1 (V2)
From: Krzysztof Kozlowski @ 2026-04-11 8:25 UTC (permalink / raw)
To: Frank Li
Cc: soc, arm, Shawn Guo, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260406020819.2812877-1-Frank.Li@nxp.com>
On Sun, Apr 05, 2026 at 10:08:08PM -0400, Frank Li wrote:
> From: Frank.Li@nxp.com
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-dt-7.1
>
> for you to fetch changes up to 0037d16644b15686eec420a90f05bcd2804edf6d:
>
> ARM: dts: imx: Add DT overlays for DH i.MX6 DHCOM SoM and boards (2026-04-05 21:35:41 -0400)
>
> Changes in v2:
> drop patch: ARM: dts: imx53: drop fallback compatible "dlg,da9052"
>
> ----------------------------------------------------------------
> i.MX ARM device tree changes for 7.1:
>
> - Device Tree Schema Compliance Fixes
>
> Fixed numerous CHECK_DTBS warnings across multiple i.MX SoC families
> Renamed nodes to match schema requirements (tcq→touchscreen,
> uart8250→serial, iomuxc→pinmux, etc.). Fixed node naming conventions
> (added "led-" prefix, proper addressing formats).
>
> Corrected compatible strings and removed undocumented fallbacks. Added
> required properties (clocks, clock-names, power supplies,
> #sound-dai-cells).
>
> - New Hardware Support
>
> Added DT overlays for various expansion modules (i.MX6 DHCOM PDK2,
> PicoITX display boards). Added support for muRata 1YN WiFi chip
> (replacement for 1DX) on i.MX6ULL DHCOR board.
>
> i.MX7ULP: Added CPU clock and OPP table support for frequency scaling.
>
> - Boot Phase Properties
> Added bootph.yaml properties to multiple TQ-Systems boards and SoCs:
> imx7s, tqma7, mba7 imx6ul/ull, tqma6ul/ull, mba6ulx imx6qdl, tqma6, mba6.
>
> - Bug Fixes & Corrections
>
> Fixed interrupt property usage (interrupts→interrupts-extended where
> needed). Corrected spelling ("TQ-Systems" with hyphen). Removed redundant
> intermediate nodes in pinmux hierarchy. Fixed clock references and
> naming.
>
> ----------------------------------------------------------------
Thanks, applied
Best regards,
Krzysztof
^ 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