* [PATCH v2 08/18] KVM: arm64: vgic: Rationalise per-CPU irq accessor
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
Despite adding the necessary infrastructure to identify irq types,
vgic_get_vcpu_irq() treats GICv5 PPIs in a special way, which
impairs the readability of the code.
Use the existing irq classifiers to handle per-CPU irqs for all
vgic types, and let the normal control flow reach global interrupt
handling without any v5-specific path.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 3ac6d49bc4876..b697678d68b01 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -106,24 +106,23 @@ struct vgic_irq *vgic_get_irq(struct kvm *kvm, u32 intid)
struct vgic_irq *vgic_get_vcpu_irq(struct kvm_vcpu *vcpu, u32 intid)
{
+ enum kvm_device_type type;
+
if (WARN_ON(!vcpu))
return NULL;
- if (vgic_is_v5(vcpu->kvm)) {
- u32 int_num, hwirq_id;
-
- if (!__irq_is_ppi(KVM_DEV_TYPE_ARM_VGIC_V5, intid))
- return NULL;
-
- hwirq_id = FIELD_GET(GICV5_HWIRQ_ID, intid);
- int_num = array_index_nospec(hwirq_id, VGIC_V5_NR_PRIVATE_IRQS);
+ type = vcpu->kvm->arch.vgic.vgic_model;
- return &vcpu->arch.vgic_cpu.private_irqs[int_num];
- }
+ if (__irq_is_sgi(type, intid) || __irq_is_ppi(type, intid)) {
+ switch (type) {
+ case KVM_DEV_TYPE_ARM_VGIC_V5:
+ intid = vgic_v5_get_hwirq_id(intid);
+ intid = array_index_nospec(intid, VGIC_V5_NR_PRIVATE_IRQS);
+ break;
+ default:
+ intid = array_index_nospec(intid, VGIC_NR_PRIVATE_IRQS);
+ }
- /* SGIs and PPIs */
- if (intid < VGIC_NR_PRIVATE_IRQS) {
- intid = array_index_nospec(intid, VGIC_NR_PRIVATE_IRQS);
return &vcpu->arch.vgic_cpu.private_irqs[intid];
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 09/18] KVM: arm64: vgic-v5: Limit support to 64 PPIs
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
Although we have some code supporting 128 PPIs, the only supported
configuration is 64 PPIs. There is no way to test the 128 PPI code,
so it is bound to bitrot very quickly.
Given that KVM/arm64's goal has always been to stick to non-IMPDEF
behaviours, drop the 128 PPI support. Someone motivated enough and
with very strong arguments can always bring it back -- it's all in
the git history.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/hyp/vgic-v5-sr.c | 82 ++++++---------------------
arch/arm64/kvm/sys_regs.c | 17 +++---
arch/arm64/kvm/vgic/vgic-kvm-device.c | 9 +--
3 files changed, 26 insertions(+), 82 deletions(-)
diff --git a/arch/arm64/kvm/hyp/vgic-v5-sr.c b/arch/arm64/kvm/hyp/vgic-v5-sr.c
index 47e6bcd437029..6d69dfe89a96c 100644
--- a/arch/arm64/kvm/hyp/vgic-v5-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v5-sr.c
@@ -30,10 +30,9 @@ void __vgic_v5_save_ppi_state(struct vgic_v5_cpu_if *cpu_if)
{
/*
* The following code assumes that the bitmap storage that we have for
- * PPIs is either 64 (architected PPIs, only) or 128 bits (architected &
- * impdef PPIs).
+ * PPIs is either 64 (architected PPIs, only).
*/
- BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS % 64);
+ BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS != 64);
bitmap_write(host_data_ptr(vgic_v5_ppi_state)->activer_exit,
read_sysreg_s(SYS_ICH_PPI_ACTIVER0_EL2), 0, 64);
@@ -49,22 +48,6 @@ void __vgic_v5_save_ppi_state(struct vgic_v5_cpu_if *cpu_if)
cpu_if->vgic_ppi_priorityr[6] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR6_EL2);
cpu_if->vgic_ppi_priorityr[7] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR7_EL2);
- if (VGIC_V5_NR_PRIVATE_IRQS == 128) {
- bitmap_write(host_data_ptr(vgic_v5_ppi_state)->activer_exit,
- read_sysreg_s(SYS_ICH_PPI_ACTIVER1_EL2), 64, 64);
- bitmap_write(host_data_ptr(vgic_v5_ppi_state)->pendr,
- read_sysreg_s(SYS_ICH_PPI_PENDR1_EL2), 64, 64);
-
- cpu_if->vgic_ppi_priorityr[8] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR8_EL2);
- cpu_if->vgic_ppi_priorityr[9] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR9_EL2);
- cpu_if->vgic_ppi_priorityr[10] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR10_EL2);
- cpu_if->vgic_ppi_priorityr[11] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR11_EL2);
- cpu_if->vgic_ppi_priorityr[12] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR12_EL2);
- cpu_if->vgic_ppi_priorityr[13] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR13_EL2);
- cpu_if->vgic_ppi_priorityr[14] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR14_EL2);
- cpu_if->vgic_ppi_priorityr[15] = read_sysreg_s(SYS_ICH_PPI_PRIORITYR15_EL2);
- }
-
/* Now that we are done, disable DVI */
write_sysreg_s(0, SYS_ICH_PPI_DVIR0_EL2);
write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
@@ -74,9 +57,6 @@ void __vgic_v5_restore_ppi_state(struct vgic_v5_cpu_if *cpu_if)
{
DECLARE_BITMAP(pendr, VGIC_V5_NR_PRIVATE_IRQS);
- /* We assume 64 or 128 PPIs - see above comment */
- BUILD_BUG_ON(VGIC_V5_NR_PRIVATE_IRQS % 64);
-
/* Enable DVI so that the guest's interrupt config takes over */
write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_dvir, 0, 64),
SYS_ICH_PPI_DVIR0_EL2);
@@ -108,50 +88,20 @@ void __vgic_v5_restore_ppi_state(struct vgic_v5_cpu_if *cpu_if)
write_sysreg_s(cpu_if->vgic_ppi_priorityr[7],
SYS_ICH_PPI_PRIORITYR7_EL2);
- if (VGIC_V5_NR_PRIVATE_IRQS == 128) {
- /* Enable DVI so that the guest's interrupt config takes over */
- write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_dvir, 64, 64),
- SYS_ICH_PPI_DVIR1_EL2);
-
- write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_activer, 64, 64),
- SYS_ICH_PPI_ACTIVER1_EL2);
- write_sysreg_s(bitmap_read(cpu_if->vgic_ppi_enabler, 64, 64),
- SYS_ICH_PPI_ENABLER1_EL2);
- write_sysreg_s(bitmap_read(pendr, 64, 64),
- SYS_ICH_PPI_PENDR1_EL2);
-
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[8],
- SYS_ICH_PPI_PRIORITYR8_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[9],
- SYS_ICH_PPI_PRIORITYR9_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[10],
- SYS_ICH_PPI_PRIORITYR10_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[11],
- SYS_ICH_PPI_PRIORITYR11_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[12],
- SYS_ICH_PPI_PRIORITYR12_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[13],
- SYS_ICH_PPI_PRIORITYR13_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[14],
- SYS_ICH_PPI_PRIORITYR14_EL2);
- write_sysreg_s(cpu_if->vgic_ppi_priorityr[15],
- SYS_ICH_PPI_PRIORITYR15_EL2);
- } else {
- write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
-
- write_sysreg_s(0, SYS_ICH_PPI_ACTIVER1_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_ENABLER1_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PENDR1_EL2);
-
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR8_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR9_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR10_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR11_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR12_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR13_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR14_EL2);
- write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR15_EL2);
- }
+ write_sysreg_s(0, SYS_ICH_PPI_DVIR1_EL2);
+
+ write_sysreg_s(0, SYS_ICH_PPI_ACTIVER1_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_ENABLER1_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PENDR1_EL2);
+
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR8_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR9_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR10_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR11_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR12_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR13_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR14_EL2);
+ write_sysreg_s(0, SYS_ICH_PPI_PRIORITYR15_EL2);
}
void __vgic_v5_save_state(struct vgic_v5_cpu_if *cpu_if)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 513f5f1429b5f..6083a1b23dbf9 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -724,6 +724,7 @@ static bool access_gicv5_ppi_enabler(struct kvm_vcpu *vcpu,
{
unsigned long *mask = vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask;
struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
+ unsigned long reg = p->regval;
int i;
/* We never expect to get here with a read! */
@@ -731,21 +732,17 @@ static bool access_gicv5_ppi_enabler(struct kvm_vcpu *vcpu,
return undef_access(vcpu, p, r);
/*
- * If we're only handling architected PPIs and the guest writes to the
- * enable for the non-architected PPIs, we just return as there's
- * nothing to do at all. We don't even allocate the storage for them in
- * this case.
+ * As we're only handling architected PPIs, the guest writes to the
+ * enable for the non-architected PPIs just return as there's
+ * nothing to do at all. We don't even allocate the storage for them.
*/
- if (VGIC_V5_NR_PRIVATE_IRQS == 64 && p->Op2 % 2)
+ if (p->Op2 % 2)
return true;
/*
- * Merge the raw guest write into out bitmap at an offset of either 0 or
- * 64, then and it with our PPI mask.
+ * Merge the raw guest write into out bitmap, anded with our PPI mask.
*/
- bitmap_write(cpu_if->vgic_ppi_enabler, p->regval, 64 * (p->Op2 % 2), 64);
- bitmap_and(cpu_if->vgic_ppi_enabler, cpu_if->vgic_ppi_enabler, mask,
- VGIC_V5_NR_PRIVATE_IRQS);
+ bitmap_and(cpu_if->vgic_ppi_enabler, ®, mask, VGIC_V5_NR_PRIVATE_IRQS);
/*
* Sync the change in enable states to the vgic_irqs. We consider all
diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
index a96c77dccf353..90be99443df3b 100644
--- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
+++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
@@ -730,18 +730,15 @@ static int vgic_v5_get_userspace_ppis(struct kvm_device *dev,
guard(mutex)(&dev->kvm->arch.config_lock);
/*
- * We either support 64 or 128 PPIs. In the former case, we need to
- * return 0s for the second 64 bits as we have no storage backing those.
+ * We only support 64 PPIs, so, we need to return 0s for the
+ * second 64 bits as we have no storage backing those.
*/
ret = put_user(bitmap_read(gicv5_vm->userspace_ppis, 0, 64), uaddr);
if (ret)
return ret;
uaddr++;
- if (VGIC_V5_NR_PRIVATE_IRQS == 128)
- ret = put_user(bitmap_read(gicv5_vm->userspace_ppis, 64, 128), uaddr);
- else
- ret = put_user(0, uaddr);
+ ret = put_user(0, uaddr);
return ret;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 00/18] KVM: arm64: vgic-v5 fixes for 7.2
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
Having completely missed the 7.1 window, this is a repost of this
series cleaning-up the vgic-v5 PPI support now targeting 7.2.
Not a lot has changed since v1 [1], only the documentation typo
spotted by our eagle-eyed Joey.
[1] https://lore.kernel.org/r/20260415115559.2227718-1-maz@kernel.org
Marc Zyngier (9):
KVM: arm64: vgic-v5: Add for_each_visible_v5_ppi() iterator
KVM: arm64: vgic-v5: Move PPI caps into kvm_vgic_global_state
KVM: arm64: vgic-v5: Remove use of __assign_bit() with a constant
KVM: arm64: vgic-v5: Drop pointless ARM64_HAS_GICV5_CPUIF check
KVM: arm64: vgic: Constify struct irq_ops usage
KVM: arm64: vgic: Consolidate vgic_allocate_private_irqs_locked()
KVM: arm64: vgic-v5: Drop defensive checks from
vgic_v5_ppi_queue_irq_unlock()
KVM: arm64: vgic: Rationalise per-CPU irq accessor
KVM: arm64: vgic-v5: Limit support to 64 PPIs
Sascha Bischoff (9):
KVM: arm64: vgic-v5: Add missing trap handing for NV triage
KVM: arm64: vgic-v5: Atomically assign bits to PPI DVI bitmap
KVM: arm64: selftests: Add missing GIC CDEN to no-vgic-v5 selftest
KVM: arm64: selftests: Cleanup unused vars in GICv5 PPI selftest
KVM: arm64: selftests: Improve error handling for GICv5 PPI selftest
Documentation: KVM: Fix typos in VGICv5 documentation
Documentation: KVM: Clarify that PMU_V3_IRQ IntID requirements for
GICv5
irqchip/gic-v5: Immediately exec priority drop following activate
KVM: arm64: Fix arch timer interrupts for GICv3-on-GICv5 guests
.../virt/kvm/devices/arm-vgic-v5.rst | 6 +-
Documentation/virt/kvm/devices/vcpu.rst | 7 +-
arch/arm64/kvm/arch_timer.c | 31 +++----
arch/arm64/kvm/emulate-nested.c | 8 ++
arch/arm64/kvm/hyp/vgic-v5-sr.c | 82 ++++---------------
arch/arm64/kvm/sys_regs.c | 19 ++---
arch/arm64/kvm/vgic/vgic-init.c | 45 ++++------
arch/arm64/kvm/vgic/vgic-kvm-device.c | 9 +-
arch/arm64/kvm/vgic/vgic-v5.c | 51 ++++--------
arch/arm64/kvm/vgic/vgic.c | 27 +++---
arch/arm64/kvm/vgic/vgic.h | 3 +
drivers/irqchip/irq-gic-v5.c | 13 +--
include/kvm/arm_vgic.h | 19 +++--
tools/testing/selftests/kvm/arm64/no-vgic.c | 1 +
tools/testing/selftests/kvm/arm64/vgic_v5.c | 10 +--
15 files changed, 132 insertions(+), 199 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH v2 01/18] KVM: arm64: vgic-v5: Add for_each_visible_v5_ppi() iterator
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
We have multiple instances of iterators walking the vgic_ppi_mask
mask, and the way it is written has a tendency to make one's eyes
bleed.
Factor it as a helper and use that across the code base.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/sys_regs.c | 2 +-
arch/arm64/kvm/vgic/vgic-v5.c | 10 ++++------
arch/arm64/kvm/vgic/vgic.h | 3 +++
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 148fc3400ea81..513f5f1429b5f 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -751,7 +751,7 @@ static bool access_gicv5_ppi_enabler(struct kvm_vcpu *vcpu,
* Sync the change in enable states to the vgic_irqs. We consider all
* PPIs as we don't expose many to the guest.
*/
- for_each_set_bit(i, mask, VGIC_V5_NR_PRIVATE_IRQS) {
+ for_each_visible_v5_ppi(i, vcpu->kvm) {
u32 intid = vgic_v5_make_ppi(i);
struct vgic_irq *irq;
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index fdd39ea7f83ec..c0d36658ffe74 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -316,7 +316,7 @@ static void vgic_v5_sync_ppi_priorities(struct kvm_vcpu *vcpu)
* those actually exposed to the guest by first iterating over the mask
* of exposed PPIs.
*/
- for_each_set_bit(i, vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask, VGIC_V5_NR_PRIVATE_IRQS) {
+ for_each_visible_v5_ppi(i, vcpu->kvm) {
u32 intid = vgic_v5_make_ppi(i);
struct vgic_irq *irq;
int pri_idx, pri_reg, pri_bit;
@@ -358,7 +358,7 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu *vcpu)
if (!priority_mask)
return false;
- for_each_set_bit(i, vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask, VGIC_V5_NR_PRIVATE_IRQS) {
+ for_each_visible_v5_ppi(i, vcpu->kvm) {
u32 intid = vgic_v5_make_ppi(i);
bool has_pending = false;
struct vgic_irq *irq;
@@ -391,8 +391,7 @@ void vgic_v5_fold_ppi_state(struct kvm_vcpu *vcpu)
activer = host_data_ptr(vgic_v5_ppi_state)->activer_exit;
pendr = host_data_ptr(vgic_v5_ppi_state)->pendr;
- for_each_set_bit(i, vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask,
- VGIC_V5_NR_PRIVATE_IRQS) {
+ for_each_visible_v5_ppi(i, vcpu->kvm) {
u32 intid = vgic_v5_make_ppi(i);
struct vgic_irq *irq;
@@ -429,8 +428,7 @@ void vgic_v5_flush_ppi_state(struct kvm_vcpu *vcpu)
* ICC_PPI_PENDRx_EL1, however.
*/
bitmap_zero(pendr, VGIC_V5_NR_PRIVATE_IRQS);
- for_each_set_bit(i, vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask,
- VGIC_V5_NR_PRIVATE_IRQS) {
+ for_each_visible_v5_ppi(i, vcpu->kvm) {
u32 intid = vgic_v5_make_ppi(i);
struct vgic_irq *irq;
diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
index 9d941241c8a2b..f45f7e3ec4d6e 100644
--- a/arch/arm64/kvm/vgic/vgic.h
+++ b/arch/arm64/kvm/vgic/vgic.h
@@ -378,6 +378,9 @@ void vgic_v5_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr);
void vgic_v5_restore_state(struct kvm_vcpu *vcpu);
void vgic_v5_save_state(struct kvm_vcpu *vcpu);
+#define for_each_visible_v5_ppi(__i, __k) \
+ for_each_set_bit(__i, (__k)->arch.vgic.gicv5_vm.vgic_ppi_mask, VGIC_V5_NR_PRIVATE_IRQS)
+
static inline int vgic_v3_max_apr_idx(struct kvm_vcpu *vcpu)
{
struct vgic_cpu *cpu_if = &vcpu->arch.vgic_cpu;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 13/18] KVM: arm64: selftests: Cleanup unused vars in GICv5 PPI selftest
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
Clean up a set of unused variables around the size of the guest's PA
space as they are completely irrelevant for GICv5 when only
considering PPIs.
Fixes: 0a9f38bf612b ("KVM: arm64: selftests: Introduce a minimal GICv5 PPI selftest")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
tools/testing/selftests/kvm/arm64/vgic_v5.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/tools/testing/selftests/kvm/arm64/vgic_v5.c b/tools/testing/selftests/kvm/arm64/vgic_v5.c
index d785b660d8476..a8707120de0d8 100644
--- a/tools/testing/selftests/kvm/arm64/vgic_v5.c
+++ b/tools/testing/selftests/kvm/arm64/vgic_v5.c
@@ -20,8 +20,6 @@ struct vm_gic {
u32 gic_dev_type;
};
-static u64 max_phys_size;
-
#define GUEST_CMD_IRQ_CDIA 10
#define GUEST_CMD_IRQ_DIEOI 11
#define GUEST_CMD_IS_AWAKE 12
@@ -208,13 +206,9 @@ void run_tests(u32 gic_dev_type)
int main(int ac, char **av)
{
int ret;
- int pa_bits;
test_disable_default_vgic();
- pa_bits = vm_guest_mode_params[VM_MODE_DEFAULT].pa_bits;
- max_phys_size = 1ULL << pa_bits;
-
ret = test_kvm_device(KVM_DEV_TYPE_ARM_VGIC_V5);
if (ret) {
pr_info("No GICv5 support; Not running GIC_v5 tests.\n");
--
2.47.3
^ permalink raw reply related
* [PATCH v2 8/8] loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Wandun Chen @ 2026-05-20 9:18 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing
Cc: catalin.marinas, will, chenhuacai, kernel, pjw, palmer, aou, alex,
robh, saravanak, akpm, bhe, rppt, pasha.tatashin, pratyush,
ruirui.yang, m.szyprowski, robin.murphy, leitao, kees, coxu,
tangyouling, songshuaishuai
In-Reply-To: <20260520091844.592753-1-chenwandun@lixiang.com>
From: Wandun Chen <chenwandun1@gmail.com>
From: Wandun Chen <chenwandun@lixiang.com>
Apply the same non-dumpable reserved memory filtering to LoongArch
kdump as was done for arm64. Use of_reserved_mem_kdump_exclude() to
drop flagged regions from the elfcorehdr PT_LOAD segments, and
of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.
Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
---
arch/loongarch/kernel/machine_kexec_file.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
index 5584b798ba46..c5cead362d2d 100644
--- a/arch/loongarch/kernel/machine_kexec_file.c
+++ b/arch/loongarch/kernel/machine_kexec_file.c
@@ -14,6 +14,7 @@
#include <linux/kernel.h>
#include <linux/kexec.h>
#include <linux/memblock.h>
+#include <linux/of_reserved_mem.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/types.h>
@@ -67,6 +68,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
nr_ranges = 2; /* for exclusion of crashkernel region */
for_each_mem_range(i, &start, &end)
nr_ranges++;
+ nr_ranges += of_reserved_mem_kdump_nr_ranges();
cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
if (!cmem)
@@ -91,6 +93,10 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
goto out;
}
+ ret = of_reserved_mem_kdump_exclude(cmem);
+ if (ret < 0)
+ goto out;
+
ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
out:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 10/18] KVM: arm64: vgic-v5: Add missing trap handing for NV triage
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
As things stand, there is no support for Nested Virt with GICv5 guests
yet. However, this is coming and therefore we need to be able to
correctly triage the traps when running with NV.
Add the missing fgtreg lookups required for that to
triage_sysreg_trap(). These are specific to the FGT regs added as part
of GICv5:
* ICH_HFGRTR_EL2
* ICH_HFGWTR_EL2
* ICH_HFGITR_EL2
Fixes: 9d6d9514c08f "(KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/emulate-nested.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index dba7ced74ca5e..a4eb36b4c4421 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -2631,6 +2631,14 @@ bool triage_sysreg_trap(struct kvm_vcpu *vcpu, int *sr_index)
fgtreg = HFGITR2_EL2;
break;
+ case ICH_HFGRTR_GROUP:
+ fgtreg = is_read ? ICH_HFGRTR_EL2 : ICH_HFGWTR_EL2;
+ break;
+
+ case ICH_HFGITR_GROUP:
+ fgtreg = ICH_HFGITR_EL2;
+ break;
+
default:
/* Something is really wrong, bail out */
WARN_ONCE(1, "Bad FGT group (encoding %08x, config %016llx)\n",
--
2.47.3
^ permalink raw reply related
* [PATCH v2 05/18] KVM: arm64: vgic: Constify struct irq_ops usage
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
vgic-v5 has introduced much more prevalent usage of the struct
irq_ops mechanism.
In the process, it becomes evident that suffers from two related
problems:
- it contains flags, rather than only callbacks
- it is mutable, because we need to update the above flags
Swap the flags for a helper retrieving the flags, and make all
irq_ops const, something that is slightly satisfying.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 14 +++++++++-----
arch/arm64/kvm/vgic/vgic-v5.c | 2 +-
arch/arm64/kvm/vgic/vgic.c | 2 +-
include/kvm/arm_vgic.h | 9 +++++----
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index cbea4d9ee9552..f003df76fdda7 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -52,11 +52,17 @@ static u64 kvm_arm_timer_read(struct kvm_vcpu *vcpu,
enum kvm_arch_timer_regs treg);
static bool kvm_arch_timer_get_input_level(int vintid);
-static struct irq_ops arch_timer_irq_ops = {
+static unsigned long kvm_arch_timer_get_irq_flags(void)
+{
+ return kvm_vgic_global_state.no_hw_deactivation ? VGIC_IRQ_SW_RESAMPLE : 0;
+}
+
+static const struct irq_ops arch_timer_irq_ops = {
+ .get_flags = kvm_arch_timer_get_irq_flags,
.get_input_level = kvm_arch_timer_get_input_level,
};
-static struct irq_ops arch_timer_irq_ops_vgic_v5 = {
+static const struct irq_ops arch_timer_irq_ops_vgic_v5 = {
.get_input_level = kvm_arch_timer_get_input_level,
.queue_irq_unlock = vgic_v5_ppi_queue_irq_unlock,
.set_direct_injection = vgic_v5_set_ppi_dvi,
@@ -1392,8 +1398,6 @@ static int kvm_irq_init(struct arch_timer_kvm_info *info)
return -ENOMEM;
}
- if (kvm_vgic_global_state.no_hw_deactivation)
- arch_timer_irq_ops.flags |= VGIC_IRQ_SW_RESAMPLE;
WARN_ON(irq_domain_push_irq(domain, host_vtimer_irq,
(void *)TIMER_VTIMER));
}
@@ -1591,8 +1595,8 @@ static bool kvm_arch_timer_get_input_level(int vintid)
int kvm_timer_enable(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = vcpu_timer(vcpu);
+ const struct irq_ops *ops;
struct timer_map map;
- struct irq_ops *ops;
int ret;
if (timer->enabled)
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 0101ec3f55283..757484d2493b2 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -285,7 +285,7 @@ void vgic_v5_set_ppi_dvi(struct kvm_vcpu *vcpu, struct vgic_irq *irq, bool dvi)
__assign_bit(ppi, cpu_if->vgic_ppi_dvir, dvi);
}
-static struct irq_ops vgic_v5_ppi_irq_ops = {
+static const struct irq_ops vgic_v5_ppi_irq_ops = {
.queue_irq_unlock = vgic_v5_ppi_queue_irq_unlock,
.set_direct_injection = vgic_v5_set_ppi_dvi,
};
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 1e9fe8764584d..3ac6d49bc4876 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -573,7 +573,7 @@ int kvm_vgic_inject_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
}
void kvm_vgic_set_irq_ops(struct kvm_vcpu *vcpu, u32 vintid,
- struct irq_ops *ops)
+ const struct irq_ops *ops)
{
struct vgic_irq *irq = vgic_get_vcpu_irq(vcpu, vintid);
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index ea793479ab254..fe49fb56dc3c9 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -205,7 +205,7 @@ struct vgic_irq;
*/
struct irq_ops {
/* Per interrupt flags for special-cased interrupts */
- unsigned long flags;
+ unsigned long (*get_flags)(void);
#define VGIC_IRQ_SW_RESAMPLE BIT(0) /* Clear the active state for resampling */
@@ -271,7 +271,7 @@ struct vgic_irq {
u8 priority;
u8 group; /* 0 == group 0, 1 == group 1 */
- struct irq_ops *ops;
+ const struct irq_ops *ops;
void *owner; /* Opaque pointer to reserve an interrupt
for in-kernel devices. */
@@ -279,7 +279,8 @@ struct vgic_irq {
static inline bool vgic_irq_needs_resampling(struct vgic_irq *irq)
{
- return irq->ops && (irq->ops->flags & VGIC_IRQ_SW_RESAMPLE);
+ return irq->ops && irq->ops->get_flags &&
+ (irq->ops->get_flags() & VGIC_IRQ_SW_RESAMPLE);
}
struct vgic_register_region;
@@ -557,7 +558,7 @@ void kvm_vgic_init_cpu_hardware(void);
int kvm_vgic_inject_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
unsigned int intid, bool level, void *owner);
void kvm_vgic_set_irq_ops(struct kvm_vcpu *vcpu, u32 vintid,
- struct irq_ops *ops);
+ const struct irq_ops *ops);
void kvm_vgic_clear_irq_ops(struct kvm_vcpu *vcpu, u32 vintid);
int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
u32 vintid);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 7/8] riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Wandun Chen @ 2026-05-20 9:18 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing
Cc: catalin.marinas, will, chenhuacai, kernel, pjw, palmer, aou, alex,
robh, saravanak, akpm, bhe, rppt, pasha.tatashin, pratyush,
ruirui.yang, m.szyprowski, robin.murphy, leitao, kees, coxu,
tangyouling, songshuaishuai
In-Reply-To: <20260520091844.592753-1-chenwandun@lixiang.com>
From: Wandun Chen <chenwandun1@gmail.com>
From: Wandun Chen <chenwandun@lixiang.com>
Apply the same non-dumpable reserved memory filtering to RISC-V kdump
as was done for arm64. Use of_reserved_mem_kdump_exclude() to drop
flagged regions from the elfcorehdr PT_LOAD segments, and
of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.
Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
---
arch/riscv/kernel/machine_kexec_file.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 54e2d9552e93..c359cf714c79 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -10,6 +10,7 @@
#include <linux/elf.h>
#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/of_reserved_mem.h>
#include <linux/libfdt.h>
#include <linux/types.h>
#include <linux/memblock.h>
@@ -63,6 +64,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
nr_ranges = 1; /* For exclusion of crashkernel region */
walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
+ nr_ranges += of_reserved_mem_kdump_nr_ranges();
cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
if (!cmem)
@@ -76,6 +78,8 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
/* Exclude crashkernel region */
ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
+ if (!ret)
+ ret = of_reserved_mem_kdump_exclude(cmem);
if (!ret)
ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 06/18] KVM: arm64: vgic: Consolidate vgic_allocate_private_irqs_locked()
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
vgic_allocate_private_irqs_locked() calls two helpers, oddly named
vgic_{,v5_}allocate_private_irq().
Not only these helpers don't allocate anything, but they also
contain duplicate init code that would be better placed in the
caller.
Consolidate the common init code in the caller, rename the helpers
to vgic_{,v5_}setup_private_irq(), and pass the irq pointer around
instead of the index of the interrupt.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-init.c | 45 +++++++++++++--------------------
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 933983bb20052..907057881b26a 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -271,18 +271,12 @@ int kvm_vgic_vcpu_nv_init(struct kvm_vcpu *vcpu)
return ret;
}
-static void vgic_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
+static void vgic_setup_private_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
+ u32 type)
{
- struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
+ irq->intid = irq - &vcpu->arch.vgic_cpu.private_irqs[0];
- INIT_LIST_HEAD(&irq->ap_list);
- raw_spin_lock_init(&irq->irq_lock);
- irq->vcpu = NULL;
- irq->target_vcpu = vcpu;
- refcount_set(&irq->refcount, 0);
-
- irq->intid = i;
- if (vgic_irq_is_sgi(i)) {
+ if (vgic_irq_is_sgi(irq->intid)) {
/* SGIs */
irq->enabled = 1;
irq->config = VGIC_CONFIG_EDGE;
@@ -303,18 +297,11 @@ static void vgic_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
}
}
-static void vgic_v5_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
+static void vgic_v5_setup_private_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq)
{
- struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
- u32 intid = vgic_v5_make_ppi(i);
-
- INIT_LIST_HEAD(&irq->ap_list);
- raw_spin_lock_init(&irq->irq_lock);
- irq->vcpu = NULL;
- irq->target_vcpu = vcpu;
- refcount_set(&irq->refcount, 0);
+ int i = irq - &vcpu->arch.vgic_cpu.private_irqs[0];
- irq->intid = intid;
+ irq->intid = vgic_v5_make_ppi(i);
/* The only Edge architected PPI is the SW_PPI */
if (i == GICV5_ARCH_PPI_SW_PPI)
@@ -323,7 +310,7 @@ static void vgic_v5_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
irq->config = VGIC_CONFIG_LEVEL;
/* Register the GICv5-specific PPI ops */
- vgic_v5_set_ppi_ops(vcpu, intid);
+ vgic_v5_set_ppi_ops(vcpu, irq->intid);
}
static int vgic_allocate_private_irqs_locked(struct kvm_vcpu *vcpu, u32 type)
@@ -349,15 +336,19 @@ static int vgic_allocate_private_irqs_locked(struct kvm_vcpu *vcpu, u32 type)
if (!vgic_cpu->private_irqs)
return -ENOMEM;
- /*
- * Enable and configure all SGIs to be edge-triggered and
- * configure all PPIs as level-triggered.
- */
for (i = 0; i < num_private_irqs; i++) {
+ struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
+
+ INIT_LIST_HEAD(&irq->ap_list);
+ raw_spin_lock_init(&irq->irq_lock);
+ irq->vcpu = NULL;
+ irq->target_vcpu = vcpu;
+ refcount_set(&irq->refcount, 0);
+
if (vgic_is_v5(vcpu->kvm))
- vgic_v5_allocate_private_irq(vcpu, i, type);
+ vgic_v5_setup_private_irq(vcpu, irq);
else
- vgic_allocate_private_irq(vcpu, i, type);
+ vgic_setup_private_irq(vcpu, irq, type);
}
return 0;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 18/18] KVM: arm64: Fix arch timer interrupts for GICv3-on-GICv5 guests
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
When running on a GICv5 host, we push an arch-timer-specific interrupt
domain for the timer interrupts. This interrupt domain is used to mask
the host interrupt when a GICv5 guest is running. However, this
interrupt domain is still in place when running with a GICv3 guest on
GICv5 hardware. The result is that some interrupt state changes are
not correctly propragated to the host irqchip driver for legacy
guests.
Explicitly pass irqchip state changes though to the host irqchip
driver when running a GICv3-based guest on a GICv5 host. This bypasses
all masking, and thereby operates just as a native GICv3 guest would,
with the exception of having an additional irq domain in the
hierarchy.
Fixes: 9491c63b6cd7 ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index f003df76fdda7..53b67b4d0bf24 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -1294,7 +1294,12 @@ static int timer_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
static int timer_irq_set_irqchip_state(struct irq_data *d,
enum irqchip_irq_state which, bool val)
{
- if (which != IRQCHIP_STATE_ACTIVE || !irqd_is_forwarded_to_vcpu(d))
+ bool passthrough = which != IRQCHIP_STATE_ACTIVE ||
+ !irqd_is_forwarded_to_vcpu(d) ||
+ (kvm_vgic_global_state.type == VGIC_V5 &&
+ vgic_is_v3(kvm_get_running_vcpu()->kvm));
+
+ if (passthrough)
return irq_chip_set_parent_state(d, which, val);
if (val)
@@ -1307,15 +1312,7 @@ static int timer_irq_set_irqchip_state(struct irq_data *d,
static void timer_irq_eoi(struct irq_data *d)
{
- /*
- * On a GICv5 host, we still need to call EOI on the parent for
- * PPIs. The host driver already handles irqs which are forwarded to
- * vcpus, and skips the GIC CDDI while still doing the GIC CDEOI. This
- * is required to emulate the EOIMode=1 on GICv5 hardware. Failure to
- * call EOI unsurprisingly results in *BAD* lock-ups.
- */
- if (!irqd_is_forwarded_to_vcpu(d) ||
- kvm_vgic_global_state.type == VGIC_V5)
+ if (!irqd_is_forwarded_to_vcpu(d))
irq_chip_eoi_parent(d);
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 17/18] irqchip/gic-v5: Immediately exec priority drop following activate
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
With GICv5 an interrupt of equal or lower priority cannot be signalled
until there has been a priority drop. This is done via the GIC CDEOI
system instruction. Once this has been executed, the hardware is able
to signal the next interrupt if there is one.
As all interrupts are programmed to have the same priority, no new
interrupts can be signalled until the priority drop has happened. This
can cause issues when, for example, an interrupt remains active while
a long running process takes place, such as when injecting a physical
interrupt into a guest VM in software.
The GICv5 driver has so far done the priority drop as part of
irq_eoi(), i.e., at the same time as deactivating the interrupt. This
means that any long running process (or VM) could block incoming
interrupts, effectively causing a denial of service for all other
interrupts.
Rather than doing the EOI as part of irq_eoi() (which the name would
suggest would be a good place for it), move it to happen immediately
after acknowledging an interrupt in the main GICv5 interrupt
handler. The deactivation of interrupts (GIC CDDI) remains implemented
as part of irq_eoi(), which means that the same interrupt cannot be
signalled a second time until deactivated by software.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/irqchip/irq-gic-v5.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
index 6b0903be8ebfd..58e457d4c1476 100644
--- a/drivers/irqchip/irq-gic-v5.c
+++ b/drivers/irqchip/irq-gic-v5.c
@@ -218,17 +218,13 @@ static void gicv5_hwirq_eoi(u32 hwirq_id, u8 hwirq_type)
FIELD_PREP(GICV5_GIC_CDDI_TYPE_MASK, hwirq_type);
gic_insn(cddi, CDDI);
-
- gic_insn(0, CDEOI);
}
static void gicv5_ppi_irq_eoi(struct irq_data *d)
{
/* Skip deactivate for forwarded PPI interrupts */
- if (irqd_is_forwarded_to_vcpu(d)) {
- gic_insn(0, CDEOI);
+ if (irqd_is_forwarded_to_vcpu(d))
return;
- }
gicv5_hwirq_eoi(d->hwirq, GICV5_HWIRQ_TYPE_PPI);
}
@@ -963,6 +959,13 @@ static void __exception_irq_entry gicv5_handle_irq(struct pt_regs *regs)
*/
isb();
+ /*
+ * Ensure that we can receive the next interrupts in the event that we
+ * have a long running handler or directly enter a guest by doing the
+ * priority drop immediately.
+ */
+ gic_insn(0, CDEOI);
+
hwirq = FIELD_GET(GICV5_HWIRQ_INTID, ia);
handle_irq_per_domain(hwirq);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 12/18] KVM: arm64: selftests: Add missing GIC CDEN to no-vgic-v5 selftest
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
The selftest mistakenly omitted the GIC CDEN instruction from the
testing. Add it in.
Fixes: ce29261ec648 ("KVM: arm64: selftests: Add no-vgic-v5 selftest")
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
tools/testing/selftests/kvm/arm64/no-vgic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/kvm/arm64/no-vgic.c b/tools/testing/selftests/kvm/arm64/no-vgic.c
index 25b2e3222f685..ab57902ce4293 100644
--- a/tools/testing/selftests/kvm/arm64/no-vgic.c
+++ b/tools/testing/selftests/kvm/arm64/no-vgic.c
@@ -159,6 +159,7 @@ static void guest_code_gicv5(void)
check_gicv5_gic_op(CDAFF);
check_gicv5_gic_op(CDDI);
check_gicv5_gic_op(CDDIS);
+ check_gicv5_gic_op(CDEN);
check_gicv5_gic_op(CDEOI);
check_gicv5_gic_op(CDHM);
check_gicv5_gic_op(CDPEND);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 07/18] KVM: arm64: vgic-v5: Drop defensive checks from vgic_v5_ppi_queue_irq_unlock()
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
vgic_v5_ppi_queue_irq_unlock() performs a bunch of sanity checks
that are pretty pointless as there is no code path that can
result in these invariants to be violated. And if they are, a nice
crash is just as instructive than a warning.
Drop what is evidently debug code and simplify the whole thing.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-v5.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 757484d2493b2..7916bd8d564ef 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -238,9 +238,9 @@ static u32 vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
/*
* For GICv5, the PPIs are mostly directly managed by the hardware. We (the
- * hypervisor) handle the pending, active, enable state save/restore, but don't
- * need the PPIs to be queued on a per-VCPU AP list. Therefore, sanity check the
- * state, unlock, and return.
+ * hypervisor) handle the pending, active, enable state save/restore, but
+ * don't need the PPIs to be queued on a per-VCPU AP list. Therefore,
+ * unlock, kick the vcpu and return.
*/
bool vgic_v5_ppi_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq,
unsigned long flags)
@@ -250,12 +250,7 @@ bool vgic_v5_ppi_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq,
lockdep_assert_held(&irq->irq_lock);
- if (WARN_ON_ONCE(!__irq_is_ppi(KVM_DEV_TYPE_ARM_VGIC_V5, irq->intid)))
- goto out_unlock_fail;
-
vcpu = irq->target_vcpu;
- if (WARN_ON_ONCE(!vcpu))
- goto out_unlock_fail;
raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
@@ -264,11 +259,6 @@ bool vgic_v5_ppi_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq,
kvm_vcpu_kick(vcpu);
return true;
-
-out_unlock_fail:
- raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
-
- return false;
}
/*
--
2.47.3
^ permalink raw reply related
* [PATCH v2 14/18] KVM: arm64: selftests: Improve error handling for GICv5 PPI selftest
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
Cases where the KVM_RUN ioctl returned an error were wrongly reported
as incorrect ucalls. Furthermore, potential failures when calling
KVM_IRQ_LINE were being hidden.
Improve the error handling to correctly propagate the error in both
cases.
Fixes: 0a9f38bf612b ("KVM: arm64: selftests: Introduce a minimal GICv5 PPI selftest")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
tools/testing/selftests/kvm/arm64/vgic_v5.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/arm64/vgic_v5.c b/tools/testing/selftests/kvm/arm64/vgic_v5.c
index a8707120de0d8..96cfd6bb32f6f 100644
--- a/tools/testing/selftests/kvm/arm64/vgic_v5.c
+++ b/tools/testing/selftests/kvm/arm64/vgic_v5.c
@@ -129,6 +129,8 @@ static void test_vgic_v5_ppis(u32 gic_dev_type)
while (1) {
ret = run_vcpu(vcpus[0]);
+ if (ret)
+ break;
switch (get_ucall(vcpus[0], &uc)) {
case UCALL_SYNC:
@@ -144,7 +146,7 @@ static void test_vgic_v5_ppis(u32 gic_dev_type)
irq = FIELD_PREP(KVM_ARM_IRQ_NUM_MASK, 3);
irq |= KVM_ARM_IRQ_TYPE_PPI << KVM_ARM_IRQ_TYPE_SHIFT;
- _kvm_irq_line(v.vm, irq, level);
+ kvm_irq_line(v.vm, irq, level);
} else if (uc.args[1] == GUEST_CMD_IS_AWAKE) {
pr_info("Guest skipping WFI due to pending IRQ\n");
} else if (uc.args[1] == GUEST_CMD_IRQ_CDIA) {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 16/18] Documentation: KVM: Clarify that PMU_V3_IRQ IntID requirements for GICv5
From: Marc Zyngier @ 2026-05-20 9:19 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-1-maz@kernel.org>
From: Sascha Bischoff <sascha.bischoff@arm.com>
When running a GICv5-based guest, the PMU must use PPI 23. This,
however, must be communicated via the
KVM_ARM_VCPU_PMU_V3_CTRL->KVM_ARM_VCPU_PMU_V3_IRQ ioctl as a full
GICv5-style Interrupt ID. That is, 0x20000017. Optionally, the whole
ioctl can be skipped for GICv5.
This was previously not clearly documented, so bump the documentation
accordingly.
Fixes: 7c31c06e2d2d ("KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
Documentation/virt/kvm/devices/vcpu.rst | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
index 5e38058200105..66e714f2fcfa7 100644
--- a/Documentation/virt/kvm/devices/vcpu.rst
+++ b/Documentation/virt/kvm/devices/vcpu.rst
@@ -37,8 +37,11 @@ Returns:
A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
type must be same for each vcpu. As a PPI, the interrupt number is the same for
-all vcpus, while as an SPI it must be a separate number per vcpu. For
-GICv5-based guests, the architected PPI (23) must be used.
+all vcpus, while as an SPI it must be a separate number per vcpu.
+
+For GICv5-based guests, the architected PPI (23) must be used, and must be
+communicated as the full GICv5-style Interrupt ID, i.e., 0x20000017. This ioctl
+can be omitted altogether for a GICv5-based guest.
1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
---------------------------------------
--
2.47.3
^ permalink raw reply related
* RE: [PATCH] coresight: fix resource leaks on path build failure
From: Mike Leach @ 2026-05-20 9:27 UTC (permalink / raw)
To: James Clark, Jie Gan
Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Suzuki Poulose, Leo Yan,
Alexander Shishkin, Mathieu Poirier, Tingwei Zhang,
Greg Kroah-Hartman, nd
In-Reply-To: <dea28a56-a5d8-46ef-a782-a95073714377@linaro.org>
> -----Original Message-----
> From: James Clark <james.clark@linaro.org>
> Sent: Wednesday, May 20, 2026 9:38 AM
> To: Jie Gan <jie.gan@oss.qualcomm.com>
> Cc: coresight@lists.linaro.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; Mike
> Leach <Mike.Leach@arm.com>; Leo Yan <Leo.Yan@arm.com>; Alexander
> Shishkin <alexander.shishkin@linux.intel.com>; Mathieu Poirier
> <mathieu.poirier@linaro.org>; Tingwei Zhang
> <tingwei.zhang@oss.qualcomm.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>
> Subject: Re: [PATCH] coresight: fix resource leaks on path build failure
>
>
>
> On 20/05/2026 2:55 am, Jie Gan wrote:
> >
> >
> > On 5/19/2026 9:57 PM, James Clark wrote:
> >>
> >>
> >> On 13/05/2026 2:32 am, Jie Gan wrote:
> >>> Two related leaks when _coresight_build_path() encounters an error after
> >>> coresight_grab_device() has already incremented the pm_runtime,
> module,
> >>> and device references for a node:
> >>>
> >>> 1. In _coresight_build_path(), if kzalloc_obj() for the path node fails
> >>> after coresight_grab_device() succeeds, coresight_drop_device() was
> >>> never called, permanently leaking all three references.
> >>>
> >>> 2. In coresight_build_path(), on failure the partial path was freed with
> >>> kfree(path) instead of coresight_release_path(path). kfree() only
> >>> frees the coresight_path struct itself; it does not iterate
> >>> path_list
> >>> to call coresight_drop_device() and kfree() for each coresight_node
> >>> already added by deeper recursive calls, leaking both the
> >>> pm_runtime,
> >>> module, and device references and the node memory for every element
> >>> on the partial path.
> >>>
> >>> Fix both by adding coresight_drop_device() in the OOM unwind of
> >>> _coresight_build_path(), and replacing kfree(path) with
> >>> coresight_release_path(path) in coresight_build_path().
> >>>
> >>> Fixes: 32b0707a4182 ("coresight: Add try_get_module() in
> >>> coresight_grab_device()")
> >>> Fixes: b3e94405941e ("coresight: associating path with session rather
> >>> than tracer")
> >>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> >>> ---
> >>> drivers/hwtracing/coresight/coresight-core.c | 6 ++++--
> >>> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/
> >>> hwtracing/coresight/coresight-core.c
> >>> index 46f247f73cf6..c1354ea8e11d 100644
> >>> --- a/drivers/hwtracing/coresight/coresight-core.c
> >>> +++ b/drivers/hwtracing/coresight/coresight-core.c
> >>> @@ -825,8 +825,10 @@ static int _coresight_build_path(struct
> >>> coresight_device *csdev,
> >>> return ret;
> >>> node = kzalloc_obj(struct coresight_node);
> >>> - if (!node)
> >>> + if (!node) {
> >>> + coresight_drop_device(csdev);
> >>> return -ENOMEM;
> >>> + }
> >>> node->csdev = csdev;
> >>> list_add(&node->link, &path->path_list);
> >>> @@ -851,7 +853,7 @@ struct coresight_path
> >>> *coresight_build_path(struct coresight_device *source,
> >>> rc = _coresight_build_path(source, source, sink, path);
> >>> if (rc) {
> >>> - kfree(path);
> >>> + coresight_release_path(path);
> >>> return ERR_PTR(rc);
> >>> }
> >>>
> >>> ---
> >>> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> >>> change-id: 20260513-fix-memory-leak-issue-034b4a45265e
> >>>
> >>> Best regards,
> >>
> >> Looks good to me, but sashiko is complaining: https://sashiko.dev/#/
> >> patchset/20260513-fix-memory-leak-issue-
> >> v1-1-49822d7bc7d4%40oss.qualcomm.com
> >>
> >> I'm trying to understand why it's saying that, but I think the
> >> scenario is that if there are multiple correct paths to a sink, when
> >> one path partially fails and a second path succeeds you could get a
> >> path_list with some garbage entries in it.
> >
> > I think the coresight_release_path is added to address this situation.
> > We suffered the path partially failure, and we need release all nodes
> > already added to the path.
> >
>
> It wouldn't call coresight_release_path() in this case though. If one
> path ends up building to success but a parallel path partially failed
> then _coresight_build_path() still returns success. During the search it
> would have still added the nodes from the partially failed path to the
> path_list. This is only an issue if there are multiple correct paths.
>
> >>
> >> That's kind of a different and existing issue to the one you've fixed,
> >> and assumes that multiple paths to one sink are possible, which I'm
> >> not sure is supported?
> >
> > Each path is unique. We only deal with the issue path for balancing the
> > reference count.
> >
> > Thanks,
> > Jie
> >
>
> I'm not exactly sure what you mean by unique, but the same source and
> sink could potentially be connected through two different sets of links.
>
Multiple paths between a source and sink are not permitted under the CoreSight spec.
If such a system was to be built - then a fix would need to be in the declaration of connections - e.g. miss one path out in the device tree for example. Not up to the Coresight drivers to handle out of specification hardware.
Mike
> >>
> >> It might be as easy as breaking the loop early for any return value
> >> other than -ENODEV, but I'll leave it to you to decide whether to do
> >> that here or not.
> >>
> >> Reviewed-by: James Clark <james.clark@linaro.org>
> >>
> >
^ permalink raw reply
* [PATCH v2] i2c: imx-lpi2c: fix resource leaks switching to devm_dma_request_chan()
From: Carlos Song (OSS) @ 2026-05-20 9:33 UTC (permalink / raw)
To: aisheng.dong, andi.shyti, Frank.Li, s.hauer, kernel, festevam,
carlos.song
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
From: Carlos Song <carlos.song@nxp.com>
The LPI2C driver requests DMA channels using dma_request_chan(), but
never releases them in lpi2c_imx_remove(), resulting in DMA channel
leaks every time the driver is unloaded.
Additionally, when lpi2c_dma_init() successfully requests the TX DMA
channel but fails to request the RX DMA channel, the probe falls back
to PIO mode and completes successfully. Since probe succeeds, the devres
framework will not trigger any cleanup, leaving the TX DMA channel and
the memory allocated for the dma structure held for the lifetime of the
device even though DMA is never used.
Switch to devm_dma_request_chan() to let the device core manage DMA
channel lifetime automatically. Wrap all allocations within a devres
group so that devres_release_group() can release all partially acquired
resources when DMA init fails and probe continues in PIO mode.
Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for LPI2C")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
Change for v2:
- Wrap all allocations in lpi2c_dma_init() within a devres group so
that devres_release_group() releases all partially acquired resources
(dma structure memory, TX DMA channel) when DMA init fails and probe
continues in PIO mode. Without this, a successful TX channel request
followed by a failed RX channel request would leave the TX channel
and dma structure held for the lifetime of the device.
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 53 ++++++++++++++++++------------
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 6e298424de5e..dedcc24e63ec 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1383,55 +1383,66 @@ static int lpi2c_imx_init_recovery_info(struct lpi2c_imx_struct *lpi2c_imx,
return 0;
}
-static void dma_exit(struct device *dev, struct lpi2c_imx_dma *dma)
-{
- if (dma->chan_rx)
- dma_release_channel(dma->chan_rx);
-
- if (dma->chan_tx)
- dma_release_channel(dma->chan_tx);
-
- devm_kfree(dev, dma);
-}
-
static int lpi2c_dma_init(struct device *dev, dma_addr_t phy_addr)
{
struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
struct lpi2c_imx_dma *dma;
+ void *group;
int ret;
- dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
- if (!dma)
+ /*
+ * Open a devres group so that all resources allocated within
+ * this function can be released together if DMA init fails but
+ * probe continues in PIO mode.
+ */
+ group = devres_open_group(dev, NULL, GFP_KERNEL);
+ if (!group)
return -ENOMEM;
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma) {
+ ret = -ENOMEM;
+ goto release_group;
+ }
+
dma->phy_addr = phy_addr;
/* Prepare for TX DMA: */
- dma->chan_tx = dma_request_chan(dev, "tx");
+ dma->chan_tx = devm_dma_request_chan(dev, "tx");
if (IS_ERR(dma->chan_tx)) {
ret = PTR_ERR(dma->chan_tx);
if (ret != -ENODEV && ret != -EPROBE_DEFER)
dev_err(dev, "can't request DMA tx channel (%d)\n", ret);
- dma->chan_tx = NULL;
- goto dma_exit;
+ goto release_group;
}
/* Prepare for RX DMA: */
- dma->chan_rx = dma_request_chan(dev, "rx");
+ dma->chan_rx = devm_dma_request_chan(dev, "rx");
if (IS_ERR(dma->chan_rx)) {
ret = PTR_ERR(dma->chan_rx);
if (ret != -ENODEV && ret != -EPROBE_DEFER)
dev_err(dev, "can't request DMA rx channel (%d)\n", ret);
- dma->chan_rx = NULL;
- goto dma_exit;
+ goto release_group;
}
+ /*
+ * DMA init succeeded. Remove the group marker but keep all resources
+ * bound to the device, they will be freed at device removal.
+ */
+ devres_remove_group(dev, group);
+
lpi2c_imx->can_use_dma = true;
lpi2c_imx->dma = dma;
return 0;
-dma_exit:
- dma_exit(dev, dma);
+release_group:
+ /*
+ * DMA init failed. Release ALL resources allocated inside this
+ * group (dma memory, TX channel if already acquired, etc.) so
+ * that a successful PIO-mode probe does not hold unused resources
+ * for the entire device lifetime.
+ */
+ devres_release_group(dev, group);
return ret;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] drm/bridge: dw-hdmi-qp: compute audio CTS from N when not in TMDS table
From: Simon Wright @ 2026-05-20 9:33 UTC (permalink / raw)
To: Luca Ceresoli, Cristian Ciocaltea
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Simona Vetter,
Heiko Stuebner, Andy Yan, Sebastian Reichel, Dmitry Baryshkov,
Algea Cao, dri-devel, linux-rockchip, linux-arm-kernel,
linux-kernel
In-Reply-To: <DILQTGH47XGL.1K6I6UI6IXP92@bootlin.com>
On 18/05/2026 10:50 pm, Luca Ceresoli wrote:
> Your patch got mangled by your mailer and cannot be applied.
> [...]
> Also your commit message is very detailed, and think it would be more
> readable if split in paragraphs.
Thanks Luca. v2 with paragraph breaks:
https://lore.kernel.org/linux-rockchip/00a34a82-213b-4b03-801c-3c10b163d643@symple.nz/
Simon
^ permalink raw reply
* [PATCH v2 1/2] Documentation: ABI: add sysfs interface for ZynqMP CSU registers
From: Ronak Jain @ 2026-05-20 9:36 UTC (permalink / raw)
To: michal.simek, senthilnathan.thangaraj
Cc: linux-kernel, linux-arm-kernel, ronak.jain
In-Reply-To: <20260520093654.3303917-1-ronak.jain@amd.com>
Document the new sysfs interface that exposes Configuration Security
Unit (CSU) registers through the zynqmp-firmware driver.
The interface is available under:
/sys/devices/platform/firmware:zynqmp-firmware/csu_registers/
The CSU registers are discovered at boot time using the PM_QUERY_DATA
firmware API. The following registers are currently supported:
- multiboot (CSU_MULTI_BOOT)
- idcode (CSU_IDCODE, read-only)
- pcap-status (CSU_PCAP_STATUS, read-only)
Read operations use the existing IOCTL_READ_REG firmware interface,
while write operations use IOCTL_MASK_WRITE_REG.
Access control is enforced by the firmware. Write attempts to
read-only registers are rejected by firmware even though the sysfs file
permissions allow writes.
Document the ABI entry accordingly.
Signed-off-by: Ronak Jain <ronak.jain@amd.com>
---
.../ABI/stable/sysfs-driver-firmware-zynqmp | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
index c3fec3c835af..f9b004e33696 100644
--- a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
+++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
@@ -254,3 +254,36 @@ Description:
The expected result is 500.
Users: Xilinx
+
+What: /sys/devices/platform/firmware\:zynqmp-firmware/csu_registers/*
+Date: May 2026
+KernelVersion: 7.1
+Contact: "Ronak Jain" <ronak.jain@amd.com>
+Description:
+ Read/Write CSU (Configuration Security Unit) registers.
+
+ This interface provides dynamic access to CSU registers that are
+ discovered from the firmware at boot time using PM_QUERY_DATA API.
+
+ The supported registers are:
+
+ - multiboot: CSU_MULTI_BOOT register
+ - idcode: CSU_IDCODE register (read-only)
+ - pcap-status: CSU_PCAP_STATUS register (read-only)
+
+ Read operations use the existing IOCTL_READ_REG API.
+ Write operations use the existing IOCTL_MASK_WRITE_REG API.
+
+ The firmware enforces access control - read-only registers will reject
+ write attempts even though the sysfs permissions show write access.
+
+ Usage for reading::
+
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/csu_registers/multiboot
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/csu_registers/idcode
+
+ Usage for writing (mask and value are in hexadecimal)::
+
+ # echo 0xFFFFFFF 0x0 > /sys/devices/platform/firmware\:zynqmp-firmware/csu_registers/multiboot
+
+Users: Xilinx/AMD
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/2] firmware: zynqmp: Add dynamic CSU register discovery and sysfs interface
From: Ronak Jain @ 2026-05-20 9:36 UTC (permalink / raw)
To: michal.simek, senthilnathan.thangaraj
Cc: linux-kernel, linux-arm-kernel, ronak.jain
In-Reply-To: <20260520093654.3303917-1-ronak.jain@amd.com>
Add support for dynamically discovering and exposing Configuration
Security Unit (CSU) registers through sysfs. Leverage the existing
PM_QUERY_DATA API to discover available registers at runtime, making
the interface flexible and maintainable.
Key features:
- Dynamic register discovery using PM_QUERY_DATA API
* PM_QID_GET_NODE_COUNT: Query number of available registers
* PM_QID_GET_NODE_NAME: Query register names by index
- Automatic sysfs attribute creation under csu_registers/ group
- Read operations via existing IOCTL_READ_REG API
- Write operations via existing IOCTL_MASK_WRITE_REG API
The sysfs interface is created at:
/sys/devices/platform/firmware:zynqmp-firmware/csu_registers/
Currently supported registers include:
- multiboot (CSU_MULTI_BOOT)
- idcode (CSU_IDCODE, read-only)
- pcap-status (CSU_PCAP_STATUS, read-only)
The dynamic discovery approach allows firmware to control which
registers are exposed without requiring kernel changes, improving
maintainability and security.
The firmware does not currently expose per-register access mode
information, so the kernel cannot distinguish read-only registers
from read-write ones at discovery time. All discovered registers are
therefore created with sysfs mode 0644, and the firmware is
responsible for rejecting writes to registers it treats as read-only
(for example idcode and pcap-status); that error is propagated back
to userspace from the store callback. If a per-register access-mode
query is added to the firmware in the future, sysfs permissions can
be tightened to match.
CSU register discovery is an optional feature: on firmware that lacks
support for PM_QID_GET_NODE_COUNT or PM_QID_GET_NODE_NAME, the probe
returns gracefully without exposing any sysfs entries. To keep the
memory footprint minimal on that path, partial devm allocations made
during discovery are explicitly released on failure so that no memory
lingers until device unbind when the feature is unavailable.
Signed-off-by: Ronak Jain <ronak.jain@amd.com>
---
MAINTAINERS | 10 +
drivers/firmware/xilinx/Makefile | 2 +-
drivers/firmware/xilinx/zynqmp-csu-reg.c | 258 +++++++++++++++++++++++
drivers/firmware/xilinx/zynqmp-csu-reg.h | 18 ++
drivers/firmware/xilinx/zynqmp.c | 6 +
include/linux/firmware/xlnx-zynqmp.h | 4 +-
6 files changed, 296 insertions(+), 2 deletions(-)
create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.c
create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.h
diff --git a/MAINTAINERS b/MAINTAINERS
index b3e05a3186aa..f1b42935b40d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29490,6 +29490,16 @@ F: drivers/dma/xilinx/xdma.c
F: include/linux/dma/amd_xdma.h
F: include/linux/platform_data/amd_xdma.h
+XILINX ZYNQMP CSU REGISTER DRIVER
+M: Senthil Nathan Thangaraj <senthilnathan.thangaraj@amd.com>
+R: Michal Simek <michal.simek@amd.com>
+R: Ronak Jain <ronak.jain@amd.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
+F: drivers/firmware/xilinx/zynqmp-csu-reg.c
+F: drivers/firmware/xilinx/zynqmp-csu-reg.h
+
XILINX ZYNQMP DPDMA DRIVER
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: dmaengine@vger.kernel.org
diff --git a/drivers/firmware/xilinx/Makefile b/drivers/firmware/xilinx/Makefile
index 8db0e66b6b7e..6203f41daaa6 100644
--- a/drivers/firmware/xilinx/Makefile
+++ b/drivers/firmware/xilinx/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for Xilinx firmwares
-obj-$(CONFIG_ZYNQMP_FIRMWARE) += zynqmp.o zynqmp-ufs.o zynqmp-crypto.o
+obj-$(CONFIG_ZYNQMP_FIRMWARE) += zynqmp.o zynqmp-ufs.o zynqmp-crypto.o zynqmp-csu-reg.o
obj-$(CONFIG_ZYNQMP_FIRMWARE_DEBUG) += zynqmp-debug.o
diff --git a/drivers/firmware/xilinx/zynqmp-csu-reg.c b/drivers/firmware/xilinx/zynqmp-csu-reg.c
new file mode 100644
index 000000000000..6e11a9b019f7
--- /dev/null
+++ b/drivers/firmware/xilinx/zynqmp-csu-reg.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Zynq MPSoC CSU Register Access
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ *
+ * Michal Simek <michal.simek@amd.com>
+ * Ronak Jain <ronak.jain@amd.com>
+ */
+
+#include <linux/firmware/xlnx-zynqmp.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+
+#include "zynqmp-csu-reg.h"
+
+/* Node ID for CSU module in firmware */
+#define CSU_NODE_ID 0
+
+/* Maximum number of CSU registers supported */
+#define MAX_CSU_REGS 50
+
+/* Size of register name returned by firmware (3 u32 words = 12 bytes) */
+#define CSU_REG_NAME_LEN 12
+
+/**
+ * struct zynqmp_csu_reg - CSU register information
+ * @id: Register index from firmware
+ * @name: Register name
+ * @attr: Device attribute for sysfs
+ */
+struct zynqmp_csu_reg {
+ u32 id;
+ char name[CSU_REG_NAME_LEN];
+ struct device_attribute attr;
+};
+
+/**
+ * struct zynqmp_csu_data - Per-device CSU data
+ * @csu_regs: Array of CSU registers
+ * @csu_attr_group: Attribute group for sysfs
+ */
+struct zynqmp_csu_data {
+ struct zynqmp_csu_reg *csu_regs;
+ struct attribute_group csu_attr_group;
+};
+
+/**
+ * zynqmp_pm_get_node_count() - Get number of supported nodes via QUERY_DATA
+ *
+ * Return: Number of nodes on success, or negative error code
+ */
+static int zynqmp_pm_get_node_count(void)
+{
+ struct zynqmp_pm_query_data qdata = {0};
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ qdata.qid = PM_QID_GET_NODE_COUNT;
+
+ ret = zynqmp_pm_query_data(qdata, ret_payload);
+ if (ret)
+ return ret;
+
+ return ret_payload[1];
+}
+
+/**
+ * zynqmp_pm_get_node_name() - Get node name via QUERY_DATA
+ * @index: Register index
+ * @name: Buffer to store register name
+ *
+ * Return: 0 on success, error code otherwise
+ */
+static int zynqmp_pm_get_node_name(u32 index, char *name)
+{
+ struct zynqmp_pm_query_data qdata = {0};
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ qdata.qid = PM_QID_GET_NODE_NAME;
+ qdata.arg1 = index;
+
+ ret = zynqmp_pm_query_data(qdata, ret_payload);
+ if (ret)
+ return ret;
+
+ memcpy(name, &ret_payload[1], CSU_REG_NAME_LEN);
+ name[CSU_REG_NAME_LEN - 1] = '\0';
+
+ return 0;
+}
+
+/**
+ * zynqmp_csu_reg_show() - Generic show function for all registers
+ * @dev: Device pointer
+ * @attr: Device attribute
+ * @buf: Output buffer
+ *
+ * Return: Number of bytes written to buffer, or error code
+ */
+static ssize_t zynqmp_csu_reg_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct zynqmp_csu_reg *reg;
+ u32 value;
+ int ret;
+
+ /* Use container_of to get register directly */
+ reg = container_of(attr, struct zynqmp_csu_reg, attr);
+
+ ret = zynqmp_pm_sec_read_reg(CSU_NODE_ID, reg->id, &value);
+ if (ret)
+ return ret;
+
+ return sysfs_emit(buf, "0x%08x\n", value);
+}
+
+/**
+ * zynqmp_csu_reg_store() - Generic store function for writable registers
+ * @dev: Device pointer
+ * @attr: Device attribute
+ * @buf: Input buffer
+ * @count: Buffer size
+ *
+ * Format: "mask value" - both mask and value required
+ * Example: echo "0xFFFFFFFF 0x12345678" > register
+ *
+ * Return: count on success, error code otherwise
+ */
+static ssize_t zynqmp_csu_reg_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct zynqmp_csu_reg *reg;
+ u32 mask, value;
+ int ret;
+
+ reg = container_of(attr, struct zynqmp_csu_reg, attr);
+
+ if (sscanf(buf, "%x %x", &mask, &value) != 2)
+ return -EINVAL;
+
+ ret = zynqmp_pm_sec_mask_write_reg(CSU_NODE_ID, reg->id, mask, value);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
+/**
+ * zynqmp_csu_discover_registers() - Discover CSU registers from firmware
+ * @pdev: Platform device pointer
+ *
+ * This function uses PM_QUERY_DATA to discover all available CSU registers
+ * and creates sysfs group under /sys/devices/platform/firmware:zynqmp-firmware/
+ *
+ * Return: 0 on success, error code otherwise
+ */
+int zynqmp_csu_discover_registers(struct platform_device *pdev)
+{
+ struct zynqmp_csu_data *csu_data;
+ struct attribute **attrs;
+ int count, ret, i;
+
+ ret = zynqmp_pm_is_function_supported(PM_QUERY_DATA, PM_QID_GET_NODE_COUNT);
+ if (ret) {
+ dev_dbg(&pdev->dev, "CSU register discovery not supported by current firmware\n");
+ return 0;
+ }
+
+ ret = zynqmp_pm_is_function_supported(PM_QUERY_DATA, PM_QID_GET_NODE_NAME);
+ if (ret) {
+ dev_dbg(&pdev->dev, "CSU register name query not supported by current firmware\n");
+ return 0;
+ }
+
+ count = zynqmp_pm_get_node_count();
+ if (count < 0)
+ return count;
+ if (count == 0) {
+ dev_dbg(&pdev->dev, "No nodes available from firmware\n");
+ return 0;
+ }
+
+ /* Validate count to prevent excessive memory allocation */
+ if (count > MAX_CSU_REGS) {
+ dev_err(&pdev->dev, "Register count %d exceeds maximum %d\n",
+ count, MAX_CSU_REGS);
+ return -EINVAL;
+ }
+
+ dev_dbg(&pdev->dev, "Discovered %d nodes from firmware\n", count);
+
+ csu_data = devm_kzalloc(&pdev->dev, sizeof(*csu_data), GFP_KERNEL);
+ if (!csu_data)
+ return -ENOMEM;
+
+ csu_data->csu_regs = devm_kcalloc(&pdev->dev, count, sizeof(*csu_data->csu_regs),
+ GFP_KERNEL);
+ if (!csu_data->csu_regs) {
+ devm_kfree(&pdev->dev, csu_data);
+ return -ENOMEM;
+ }
+
+ attrs = devm_kcalloc(&pdev->dev, count + 1, sizeof(*attrs), GFP_KERNEL);
+ if (!attrs) {
+ devm_kfree(&pdev->dev, csu_data->csu_regs);
+ devm_kfree(&pdev->dev, csu_data);
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < count; i++) {
+ struct zynqmp_csu_reg *reg = &csu_data->csu_regs[i];
+ struct device_attribute *dev_attr = ®->attr;
+
+ reg->id = i;
+
+ ret = zynqmp_pm_get_node_name(i, reg->name);
+ if (ret) {
+ dev_warn(&pdev->dev, "Failed to get name for register %d\n", i);
+ snprintf(reg->name, sizeof(reg->name), "csu_reg_%d", i);
+ }
+
+ /*
+ * The firmware does not expose per-register access mode via
+ * PM_QUERY_DATA today, so the kernel cannot tell read-only
+ * registers from read-write ones at discovery time. Expose
+ * every register as 0644 and rely on the firmware to reject
+ * IOCTL_MASK_WRITE_REG on read-only registers; the error is
+ * propagated back to userspace from the store callback.
+ */
+ sysfs_attr_init(&dev_attr->attr);
+ dev_attr->attr.name = reg->name;
+ dev_attr->attr.mode = 0644;
+ dev_attr->show = zynqmp_csu_reg_show;
+ dev_attr->store = zynqmp_csu_reg_store;
+
+ attrs[i] = &dev_attr->attr;
+
+ dev_dbg(&pdev->dev, "Register %d: id=%d name=%s\n", i, reg->id, reg->name);
+ }
+
+ csu_data->csu_attr_group.name = "csu_registers";
+ csu_data->csu_attr_group.attrs = attrs;
+
+ ret = devm_device_add_group(&pdev->dev, &csu_data->csu_attr_group);
+ if (ret) {
+ devm_kfree(&pdev->dev, attrs);
+ devm_kfree(&pdev->dev, csu_data->csu_regs);
+ devm_kfree(&pdev->dev, csu_data);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_csu_discover_registers);
diff --git a/drivers/firmware/xilinx/zynqmp-csu-reg.h b/drivers/firmware/xilinx/zynqmp-csu-reg.h
new file mode 100644
index 000000000000..b12415db3496
--- /dev/null
+++ b/drivers/firmware/xilinx/zynqmp-csu-reg.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Xilinx Zynq MPSoC CSU Register Access
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ *
+ * Michal Simek <michal.simek@amd.com>
+ * Ronak Jain <ronak.jain@amd.com>
+ */
+
+#ifndef __ZYNQMP_CSU_REG_H__
+#define __ZYNQMP_CSU_REG_H__
+
+#include <linux/platform_device.h>
+
+int zynqmp_csu_discover_registers(struct platform_device *pdev);
+
+#endif /* __ZYNQMP_CSU_REG_H__ */
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index af838b2dc327..155a7a9b3777 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -27,6 +27,7 @@
#include <linux/firmware/xlnx-zynqmp.h>
#include <linux/firmware/xlnx-event-manager.h>
+#include "zynqmp-csu-reg.h"
#include "zynqmp-debug.h"
/* Max HashMap Order for PM API feature check (1<<7 = 128) */
@@ -2148,6 +2149,11 @@ static int zynqmp_firmware_probe(struct platform_device *pdev)
dev_err_probe(&pdev->dev, PTR_ERR(em_dev), "EM register fail with error\n");
}
+ /* Discover CSU registers dynamically */
+ ret = zynqmp_csu_discover_registers(pdev);
+ if (ret)
+ dev_warn(&pdev->dev, "CSU register discovery failed: %d\n", ret);
+
return of_platform_populate(dev->of_node, NULL, NULL, dev);
}
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 7e27b0f7bf7e..a956e315be82 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -3,7 +3,7 @@
* Xilinx Zynq MPSoC Firmware layer
*
* Copyright (C) 2014-2021 Xilinx
- * Copyright (C) 2022 - 2025 Advanced Micro Devices, Inc.
+ * Copyright (C) 2022 - 2026 Advanced Micro Devices, Inc.
*
* Michal Simek <michal.simek@amd.com>
* Davorin Mista <davorin.mista@aggios.com>
@@ -262,6 +262,8 @@ enum pm_query_id {
PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
PM_QID_CLOCK_GET_MAX_DIVISOR = 13,
PM_QID_PINCTRL_GET_ATTRIBUTES = 15,
+ PM_QID_GET_NODE_NAME = 16,
+ PM_QID_GET_NODE_COUNT = 17,
};
enum rpu_oper_mode {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] Add dynamic CSU register sysfs interface
From: Ronak Jain @ 2026-05-20 9:36 UTC (permalink / raw)
To: michal.simek, senthilnathan.thangaraj
Cc: linux-kernel, linux-arm-kernel, ronak.jain
This patch series adds support for exposing CSU registers through a
sysfs interface. The implementation uses dynamic discovery via the
PM_QUERY_DATA firmware API to determine available registers at
runtime, making the interface flexible and maintainable without
requiring kernel changes when firmware capabilities evolve.
Background:
The ZynqMP platform has several CSU registers that are useful for
system configuration and debugging. Previously, accessing these
registers required direct memory access or custom tools. This series
provides a standardized sysfs interface that leverages existing
firmware APIs for secure access.
Key Features:
- Dynamic register discovery using PM_QUERY_DATA API
* PM_QID_GET_NODE_COUNT: Query number of available registers
* PM_QID_GET_NODE_NAME: Query register names by index
- Automatic sysfs attribute creation under csu_registers/ group
- Read operations via existing IOCTL_READ_REG firmware API
- Write operations via existing IOCTL_MASK_WRITE_REG firmware API
- Firmware-enforced access control for read-only registers
Currently Supported Registers:
- multiboot (CSU_MULTI_BOOT): Boot mode configuration
- idcode (CSU_IDCODE): Device identification (read-only)
- pcap-status (CSU_PCAP_STATUS): PCAP status (read-only)
The sysfs interface is available at:
/sys/devices/platform/firmware:zynqmp-firmware/csu_registers/
Usage Examples:
Reading a register:
# cat /sys/devices/platform/firmware:zynqmp-firmware/csu_registers/idcode
Writing a register (mask and value in hex):
# echo "0xFFFFFFFF 0x0" > /sys/devices/platform/firmware:zynqmp-firmware/csu_registers/multiboot
Testing:
- Verified register read operations return correct values
- Verified write operations update registers correctly
- Verified read-only registers reject write attempts
- Verified dynamic discovery works with different firmware versions
Changes in v2:
Patch #1
- Update date
Patch #2:
- Removed unused csu_reg_count field from struct zynqmp_csu_data and
its kernel-doc entry.
- Added explicit devm_kfree() on the csu_regs and attrs allocation
failure paths, plus on devm_device_add_group() failure — keeps the
footprint minimal when CSU is optional.
- Expanded the 0644 sysfs-mode inline comment into a block comment
explaining the firmware-enforced access-control limitation.Also,
update the commit message accordingly.
- Added zynqmp_pm_is_function_supported check for PM_QID_GET_NODE_NAME
ID to mirror the PM_QID_GET_NODE_COUNT verification.
Ronak Jain (2):
Documentation: ABI: add sysfs interface for ZynqMP CSU registers
firmware: zynqmp: Add dynamic CSU register discovery and sysfs
interface
.../ABI/stable/sysfs-driver-firmware-zynqmp | 33 +++
MAINTAINERS | 10 +
drivers/firmware/xilinx/Makefile | 2 +-
drivers/firmware/xilinx/zynqmp-csu-reg.c | 258 ++++++++++++++++++
drivers/firmware/xilinx/zynqmp-csu-reg.h | 18 ++
drivers/firmware/xilinx/zynqmp.c | 6 +
include/linux/firmware/xlnx-zynqmp.h | 4 +-
7 files changed, 329 insertions(+), 2 deletions(-)
create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.c
create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.h
--
2.34.1
^ permalink raw reply
* Re: [PATCH v7 04/23] drm: bridge: dw_hdmi: Hold bridge ref until connector cleanup
From: Jonas Karlman @ 2026-05-20 9:38 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Heiko Stuebner,
Laurent Pinchart, Jernej Skrabec, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Cristian Ciocaltea, Louis Chauvet, Liu Ying, Sandy Huang,
Andy Yan, Chen-Yu Tsai, Christian Hewitt, Diederik de Haas,
Nicolas Frattaroli, Dmitry Baryshkov, dri-devel, linux-arm-kernel,
linux-rockchip, linux-amlogic, linux-sunxi, imx, linux-kernel
In-Reply-To: <177925954999.1337464.14745526881417951688.b4-reply@b4>
Hello Luca,
On 5/20/2026 8:45 AM, Luca Ceresoli wrote:
> Hello Jonas,
>
> On 2026-05-19 17:18 +0200, Jonas Karlman wrote:
>> Hello Luca,
>>
>> On 5/19/2026 2:06 PM, Luca Ceresoli wrote:
>>> On Mon, 18 May 2026 18:01:40 +0000, Jonas Karlman <jonas@kwiboo.se> wrote:
>>>
>>> Hello Jonas,
>>>
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> index b7bfc0e9a6b2..9d795c550f8a 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> @@ -2600,10 +2609,14 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
>>>>
>>>> drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
>>>>
>>>> - drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
>>>> - &dw_hdmi_connector_funcs,
>>>> - DRM_MODE_CONNECTOR_HDMIA,
>>>> - hdmi->ddc);
>>>> + ret = drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
>>>> + &dw_hdmi_connector_funcs,
>>>> + DRM_MODE_CONNECTOR_HDMIA,
>>>> + hdmi->ddc);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + drm_bridge_get(&hdmi->bridge);
>>>
>>> I'm not fully following the code paths, but both the report and the fix
>>> make sense to me. Only I'd move the drm_bridge_get() before
>>> drm_connector_init_with_ddc(), to avoid a short window where no reference
>>> is held and the bridge might be destroyed before drm_bridge_get() is
>>> called. I'm not sure this can happen, but it's better to write the code in
>>> a way that clearly makes it impossible.
>>
>> dw_hdmi_connector_create() is only called from dw_hdmi_bridge_attach()
>> so the bridge should already have a ref for the lifetime of this call.
>
> Ah, that's true. So the patch is correct.
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Thanks.
> In case you send a new iteration, please add this extra explanation to the
> commit message, similar to the above paragraph.
Sure, I will include a note about this if/when I need to re-spin.
>> I explicitly chose the placement after drm_connector_init_with_ddc()
>> to ensure ref count is correctly balanced without having to add a
>> drm_bridge_put() call in any error path. I.e. connector destroy() is
>> only called when drm_connector_init_with_ddc() succeeds.
>>
>> This code/call is also planned to be removed in a future series,
>
> In order to remove the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case? That would be
> welcome!
That would be an end goal, however initial plan/step was to just change
to use drm_bridge_connector_init() inside this driver [1] or possible
move that to the consuming driver (imx6, rockchip and sun8i), in an
unpolished future series [2].
Fully change to use ATTACH_NO_CONNECTOR for those affected drivers may
possibly be pushed to a follow-up future series.
Main end goal of my current effort is to enable support for Deep Color
and YCbCr output modes on Rockchip RK32xx/RK33xx/RK356x devices [3].
[1] https://github.com/Kwiboo/linux-rockchip/commit/813b55961e5a8fa864ea157e2793e76ca4967bac
[2] https://github.com/Kwiboo/linux-rockchip/compare/7e9084cc75011ce28b1ceafec804091438eed1ff...3b5507aa260eb8306554c34a0c362e514ea41c3b
[3] https://github.com/Kwiboo/linux-rockchip/commits/next-20260518-rk-hdmi-v5/
Regards,
Jonas
>
> Luca
>
^ permalink raw reply
* Re: [PATCH v3 5/5] i2c: mt7621: make device reset optional
From: Benjamin Larsson @ 2026-05-20 9:41 UTC (permalink / raw)
To: Christian Marangi, Stefan Roese, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-i2c, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260519223253.1093-6-ansuelsmth@gmail.com>
Hi.
On 5/20/26 00:32, Christian Marangi wrote:
> Airoha SoC that makes use of the same Mediatek I2C driver/logic doesn't
> have reset line for I2C so use optional device_reset variant.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/i2c/busses/i2c-mt7621.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt7621.c b/drivers/i2c/busses/i2c-mt7621.c
> index 3cde43c57a2b..fb9d9701bb10 100644
> --- a/drivers/i2c/busses/i2c-mt7621.c
> +++ b/drivers/i2c/busses/i2c-mt7621.c
> @@ -91,7 +91,7 @@ static void mtk_i2c_reset(struct mtk_i2c *i2c)
> u32 reg;
> int ret;
>
> - ret = device_reset(i2c->adap.dev.parent);
> + ret = device_reset_optional(i2c->adap.dev.parent);
> if (ret)
> dev_err(i2c->dev, "I2C reset failed!\n");
>
Can you elaborate on this one? I get this:
root@XGX-B-00e092000160:~# devmem 0x1fbf8040
0x00C7800C
root@XGX-B-00e092000160:~# devmem 0x1FB00834 32 0x10000
root@XGX-B-00e092000160:~# devmem 0x1fbf8040
[ 396.658742] pbus timeout interrupt ERR ADDR=1fbf8040
[ 396.663845] CPU: 0 PID: 5622 Comm: sleep Tainted: P O 5.4.55 #0
[ 396.671117] Hardware name: XGX-B (DT)
[ 396.674884] Call trace:
[ 396.677394] dump_backtrace+0x0/0x120
[ 396.681111] show_stack+0x14/0x20
[ 396.684478] dump_stack+0xac/0xec
[ 396.687900] bus_timeout_interrupt+0x54/0x70
[ 396.692223] __handle_irq_event_percpu+0x3c/0x140
[ 396.696978] handle_irq_event+0x4c/0xec
[ 396.700920] handle_fasteoi_irq+0xbc/0x21c
[ 396.705069] __handle_domain_irq+0x6c/0xd0
[ 396.709218] gic_handle_irq+0x8c/0x190
[ 396.713019] el1_irq+0xf0/0x1c0
[ 396.716217] __do_softirq+0x98/0x264
[ 396.719847] irq_exit+0x98/0xe0
[ 396.723118] __handle_domain_irq+0x74/0xd0
[ 396.727268] gic_handle_irq+0x8c/0x190
[ 396.731070] el1_irq+0xf0/0x1c0
[ 396.734320] tlb_flush+0xf8/0x260
[ 396.737693] tlb_finish_mmu+0x48/0xe0
[ 396.741417] exit_mmap+0xc0/0x170
[ 396.744841] mmput+0x44/0x120
[ 396.747872] do_exit+0x2b4/0x8ec
[ 396.751161] do_group_exit+0x34/0x9c
[ 396.754794] __wake_up_parent+0x0/0x2c
[ 396.758651] el0_svc_handler+0x8c/0x150
[ 396.762545] el0_svc+0x8/0x208
0xDEADBEEF
root@XGX-B-00e092000160:~# devmem 0x1FB00834 32 0x00000
root@XGX-B-00e092000160:~# devmem 0x1fbf8040
0x0000800C
and
root@XGX-B-00e092000160:~# devmem 0x1fbf8140
0x00318013
root@XGX-B-00e092000160:~# devmem 0x1FB00830 32 0x00040
root@XGX-B-00e092000160:~# devmem 0x1fbf8140
[ 611.730070] pbus timeout interrupt ERR ADDR=1fbf8140
[ 611.735197] CPU: 0 PID: 2651 Comm: ux-manager Tainted: P O
5.4.55 #0
[ 611.742925] Hardware name: XGX-B (DT)
[ 611.746697] Call trace:
[ 611.749222] dump_backtrace+0x0/0x120
[ 611.752960] show_stack+0x14/0x20
[ 611.756424] dump_stack+0xac/0xec
[ 611.759801] bus_timeout_interrupt+0x54/0x70
[ 611.764145] __handle_irq_event_percpu+0x3c/0x140
[ 611.769001] handle_irq_event+0x4c/0xec
[ 611.772912] handle_fasteoi_irq+0xbc/0x21c
[ 611.777077] __handle_domain_irq+0x6c/0xd0
[ 611.781312] gic_handle_irq+0x8c/0x190
[ 611.785117] el1_irq+0xf0/0x1c0
[ 611.788335] __do_softirq+0x98/0x264
[ 611.792032] irq_exit+0x98/0xe0
[ 611.795249] __handle_domain_irq+0x74/0xd0
[ 611.799411] gic_handle_irq+0x8c/0x190
[ 611.803303] el1_irq+0xf0/0x1c0
[ 611.806518] bgpio_read32+0x4/0x20
[ 611.809995] gpiod_get_value_cansleep+0x44/0x100
[ 611.814742] value_show+0x2c/0x64
[ 611.818114] dev_attr_show+0x1c/0x54
[ 611.821760] sysfs_kf_read+0x54/0xc0
[ 611.825396] kernfs_fop_read+0xac/0x300
[ 611.829355] __vfs_read+0x18/0x3c
[ 611.832741] vfs_read+0xc8/0x150
[ 611.836028] ksys_read+0x58/0xd4
[ 611.839369] __arm64_sys_read+0x18/0x20
[ 611.843264] el0_svc_handler+0x8c/0x150
[ 611.847166] el0_svc+0x8/0x208
0xDEADBEEF
root@XGX-B-00e092000160:~# devmem 0x1FB00830 32 0x00000
root@XGX-B-00e092000160:~# devmem 0x1fbf8140
0x00008000
When I look at the current dts:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/airoha/en7581.dtsi?h=v7.1-rc4#n322
it looks like the resets are just crossed with regards to the nodes.
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH v2 7/7] mm/vmalloc: Stop scanning for compound pages after encountering small pages in vmap
From: Uladzislau Rezki @ 2026-05-20 9:44 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260514094108.2016201-8-jiangwen6@xiaomi.com>
On Thu, May 14, 2026 at 05:41:08PM +0800, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> Users typically allocate memory in descending orders, e.g.
> 8 → 4 → 0. Once an order-0 page is encountered, subsequent
> pages are likely to also be order-0, so we stop scanning
> for compound pages at that point.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index b3389c8f1..60579bfbf 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3576,6 +3576,12 @@ static int __vmap_huge(unsigned long addr, unsigned long end,
> map_addr = addr;
> idx = i;
> }
> + /*
> + * Once small pages are encountered, the remaining pages
> + * are likely small as well
> + */
> + if (shift == PAGE_SHIFT)
> + break;
>
> addr += 1UL << shift;
> i += 1U << (shift - PAGE_SHIFT);
> --
> 2.34.1
>
Can we squash this patch with
"mm/vmalloc: map contiguous pages in batches for vmap() if possible"?
--
Uladzislau Rezki
^ 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