* Re: [PATCH v3 11/12] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
From: Krzysztof Kozlowski @ 2026-05-21 10:17 UTC (permalink / raw)
To: Lothar Rubusch, thorsten.blum, herbert, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, tudor.ambarus, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520155703.23018-12-l.rubusch@gmail.com>
On 20/05/2026 17:57, Lothar Rubusch wrote:
> When a non-blocking read operation is requested, the driver dynamically
> allocates memory to track asynchronous transfer status. If the underlying
> I2C transmission fails, atmel_sha204a_rng_done() logs a rate-limited
> warning but incorrectly proceeds to cache the pointer to this uninitialized
> buffer inside the rng->priv data field anyway.
>
> On subsequent execution passes, atmel_sha204a_rng_read_nonblocking()
> detects the stale rng->priv value, skips executing a hardware data read,
> and copies up to 32 bytes of uninitialized kernel heap data from this
> garbage memory pool straight back into the system's hwrng data stream.
>
> Fix this information disclosure vector by immediately releasing the
> allocated asynchronous work data buffer and explicitly clearing the
> tracking pointer context whenever an I2C transaction returns a non-zero
> error status.
>
> Additionally, duplicate the tfm counter decrement within the new error
> path to ensure the reference counter is properly released before executing
> the early return, maintaining the driver's availability for subsequent
> requests.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
This and other fixes should be first in the patchset. Or even separate
patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v14 01/44] kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h
From: Marc Zyngier @ 2026-05-21 10:19 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Suzuki K Poulose, Catalin Marinas, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-2-steven.price@arm.com>
On Wed, 13 May 2026 14:17:09 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> From: Suzuki K Poulose <suzuki.poulose@arm.com>
>
> Fix a potential build error (like below, when asm/kvm_emulate.h gets
> included after the kvm/arm_psci.h) by including the missing header file
> in kvm/arm_psci.h:
>
> ./include/kvm/arm_psci.h: In function ‘kvm_psci_version’:
> ./include/kvm/arm_psci.h:29:13: error: implicit declaration of function
> ‘vcpu_has_feature’; did you mean ‘cpu_have_feature’? [-Werror=implicit-function-declaration]
> 29 | if (vcpu_has_feature(vcpu, KVM_ARM_VCPU_PSCI_0_2)) {
> | ^~~~~~~~~~~~~~~~
> | cpu_have_feature
>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
Unrelated to this patch, but really easy to fix: the standard prefix
for patches targeting KVM/arm64 is:
"KVM: arm64: [opt subsys:] Something starting with a capital letter"
where "opt subsys" could be "CCA" where applicable.
It'd be good to have some consistency.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [soc:zx/soc] BUILD SUCCESS 220ae5d36dba278003d265aabd080ffa78553f5a
From: kernel test robot @ 2026-05-21 10:21 UTC (permalink / raw)
To: Stefan Dösinger ; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git zx/soc
branch HEAD: 220ae5d36dba278003d265aabd080ffa78553f5a ARM: zte: Add zx297520v3 platform support
elapsed time: 807m
configs tested: 201
configs skipped: 3
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-20260521 gcc-8.5.0
arc randconfig-002-20260521 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm footbridge_defconfig clang-17
arm randconfig-001-20260521 gcc-8.5.0
arm randconfig-002-20260521 gcc-8.5.0
arm randconfig-003-20260521 gcc-8.5.0
arm randconfig-004-20260521 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260521 gcc-8.5.0
arm64 randconfig-002-20260521 gcc-8.5.0
arm64 randconfig-003-20260521 gcc-8.5.0
arm64 randconfig-004-20260521 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260521 gcc-8.5.0
csky randconfig-002-20260521 gcc-8.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260521 gcc-11.5.0
hexagon randconfig-002-20260521 gcc-11.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260521 clang-20
i386 buildonly-randconfig-002-20260521 clang-20
i386 buildonly-randconfig-003-20260521 clang-20
i386 buildonly-randconfig-004-20260521 clang-20
i386 buildonly-randconfig-005-20260521 clang-20
i386 buildonly-randconfig-006-20260521 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260521 clang-20
i386 randconfig-002-20260521 clang-20
i386 randconfig-003-20260521 clang-20
i386 randconfig-004-20260521 clang-20
i386 randconfig-005-20260521 clang-20
i386 randconfig-006-20260521 clang-20
i386 randconfig-007-20260521 clang-20
i386 randconfig-011-20260521 gcc-14
i386 randconfig-012-20260521 gcc-14
i386 randconfig-013-20260521 gcc-14
i386 randconfig-014-20260521 gcc-14
i386 randconfig-015-20260521 gcc-14
i386 randconfig-016-20260521 gcc-14
i386 randconfig-017-20260521 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260521 gcc-11.5.0
loongarch randconfig-002-20260521 gcc-11.5.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
mips cavium_octeon_defconfig gcc-15.2.0
mips rt305x_defconfig clang-23
nios2 10m50_defconfig gcc-11.5.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260521 gcc-11.5.0
nios2 randconfig-002-20260521 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260521 gcc-12.5.0
parisc randconfig-002-20260521 gcc-12.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mgcoge_defconfig clang-23
powerpc mpc837x_rdb_defconfig gcc-15.2.0
powerpc randconfig-001-20260521 gcc-12.5.0
powerpc randconfig-002-20260521 gcc-12.5.0
powerpc sam440ep_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260521 gcc-12.5.0
powerpc64 randconfig-002-20260521 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-15.2.0
riscv randconfig-001-20260521 gcc-15.2.0
riscv randconfig-002 gcc-15.2.0
riscv randconfig-002-20260521 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260521 gcc-15.2.0
s390 randconfig-002 gcc-15.2.0
s390 randconfig-002-20260521 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001 gcc-15.2.0
sh randconfig-001-20260521 gcc-15.2.0
sh randconfig-002 gcc-15.2.0
sh randconfig-002-20260521 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260521 gcc-8.5.0
sparc randconfig-002-20260521 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260521 gcc-8.5.0
sparc64 randconfig-002-20260521 gcc-8.5.0
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-20260521 gcc-8.5.0
um randconfig-002-20260521 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260521 clang-20
x86_64 buildonly-randconfig-002-20260521 clang-20
x86_64 buildonly-randconfig-003-20260521 clang-20
x86_64 buildonly-randconfig-004-20260521 clang-20
x86_64 buildonly-randconfig-005-20260521 clang-20
x86_64 buildonly-randconfig-006-20260521 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260521 clang-20
x86_64 randconfig-002-20260521 clang-20
x86_64 randconfig-003-20260521 clang-20
x86_64 randconfig-004-20260521 clang-20
x86_64 randconfig-005-20260521 clang-20
x86_64 randconfig-006-20260521 clang-20
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260521 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260521 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260521 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260521 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260521 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260521 gcc-14
x86_64 randconfig-071 clang-20
x86_64 randconfig-071-20260521 clang-20
x86_64 randconfig-072 clang-20
x86_64 randconfig-072-20260521 clang-20
x86_64 randconfig-073 clang-20
x86_64 randconfig-073-20260521 clang-20
x86_64 randconfig-074 clang-20
x86_64 randconfig-074-20260521 clang-20
x86_64 randconfig-075 clang-20
x86_64 randconfig-075-20260521 clang-20
x86_64 randconfig-076 clang-20
x86_64 randconfig-076-20260521 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 allyesconfig clang-23
xtensa randconfig-001-20260521 gcc-8.5.0
xtensa randconfig-002-20260521 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2 0/3] Fix __pkvm_init_vm error path
From: Vincent Donnefort @ 2026-05-21 10:21 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort
Sashiko reported a potential refcount leak in the unlikely case where
insert_vm_table_entry fails.
While at it, I have added a fail-safe to __pkvm_hyp_donate_host to ensure this
function doesn't allow leaking refcounted pages.
Changes since v2:
* Proactively init hyp_page order field in hyp_pool_init
v1 (https://lore.kernel.org/all/20260521081250.655226-1-vdonnefort@google.com/)
*** BLURB HERE ***
Vincent Donnefort (3):
KVM: arm64: Reset page order in pKVM hyp_pool_init
KVM: arm64: Fix __pkvm_init_vm error path
KVM: arm64: Add fail-safe for refcounted pages in
__pkvm_hyp_donate_host
arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 1 +
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 34 ++++++++++++++-----
arch/arm64/kvm/hyp/nvhe/page_alloc.c | 6 +++-
arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++-
4 files changed, 34 insertions(+), 11 deletions(-)
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply
* [PATCH v2 2/3] KVM: arm64: Fix __pkvm_init_vm error path
From: Vincent Donnefort @ 2026-05-21 10:21 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort, Sashiko
In-Reply-To: <20260521102149.804874-1-vdonnefort@google.com>
In the unlikely case where insert_vm_table_entry fails, __pkvm_init_vm
release the memory donated by the host for the PGD, but as the stage-2
is still set-up the hypervisor keeps a refcount on those pages,
effectively leaking the references.
Fix the rollback with the newly added kvm_guest_destroy_stage2().
Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
index 3cbfae0e3dda..4f2b871199cb 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
@@ -56,6 +56,7 @@ int host_stage2_idmap_locked(phys_addr_t addr, u64 size, enum kvm_pgtable_prot p
int host_stage2_set_owner_locked(phys_addr_t addr, u64 size, u8 owner_id);
int kvm_host_prepare_stage2(void *pgt_pool_base);
int kvm_guest_prepare_stage2(struct pkvm_hyp_vm *vm, void *pgd);
+void kvm_guest_destroy_stage2(struct pkvm_hyp_vm *vm);
void handle_host_mem_abort(struct kvm_cpu_context *host_ctxt);
int hyp_pin_shared_mem(void *from, void *to);
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 89eb20d4fee4..42b0b648f32f 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -306,16 +306,21 @@ int kvm_guest_prepare_stage2(struct pkvm_hyp_vm *vm, void *pgd)
return 0;
}
+void kvm_guest_destroy_stage2(struct pkvm_hyp_vm *vm)
+{
+ guest_lock_component(vm);
+ kvm_pgtable_stage2_destroy(&vm->pgt);
+ vm->kvm.arch.mmu.pgd_phys = 0ULL;
+ guest_unlock_component(vm);
+}
+
void reclaim_pgtable_pages(struct pkvm_hyp_vm *vm, struct kvm_hyp_memcache *mc)
{
struct hyp_page *page;
void *addr;
/* Dump all pgtable pages in the hyp_pool */
- guest_lock_component(vm);
- kvm_pgtable_stage2_destroy(&vm->pgt);
- vm->kvm.arch.mmu.pgd_phys = 0ULL;
- guest_unlock_component(vm);
+ kvm_guest_destroy_stage2(vm);
/* Drain the hyp_pool into the memcache */
addr = hyp_alloc_pages(&vm->pool, 0);
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index eb1c10120f9f..3b2c4fbc34d8 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -853,10 +853,12 @@ int __pkvm_init_vm(struct kvm *host_kvm, unsigned long vm_hva,
/* Must be called last since this publishes the VM. */
ret = insert_vm_table_entry(handle, hyp_vm);
if (ret)
- goto err_remove_mappings;
+ goto err_destroy_stage2;
return 0;
+err_destroy_stage2:
+ kvm_guest_destroy_stage2(hyp_vm);
err_remove_mappings:
unmap_donated_memory(hyp_vm, vm_size);
unmap_donated_memory(pgd, pgd_size);
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH v2 3/3] KVM: arm64: Add fail-safe for refcounted pages in __pkvm_hyp_donate_host
From: Vincent Donnefort @ 2026-05-21 10:21 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort
In-Reply-To: <20260521102149.804874-1-vdonnefort@google.com>
A previous bug in __pkvm_init_vm error path showed that the hypervisor
could leak refcounted pages, (i.e. losing access to a page while its
refcount is still elevated). This poses a threat to the pKVM state
machine.
Address this by introducing a fail-safe in n __pkvm_hyp_donate_host.
Transitions are not a hot path so added security is worth the extra
check.
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 42b0b648f32f..bb97d05b9b25 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -855,6 +855,16 @@ static int __hyp_check_page_state_range(phys_addr_t phys, u64 size, enum pkvm_pa
return 0;
}
+static int __hyp_check_page_count_range(phys_addr_t phys, u64 size)
+{
+ for_each_hyp_page(page, phys, size) {
+ if (page->refcount)
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
static bool guest_pte_is_poisoned(kvm_pte_t pte)
{
if (kvm_pte_valid(pte))
@@ -1053,7 +1063,6 @@ int __pkvm_guest_unshare_host(struct pkvm_hyp_vcpu *vcpu, u64 gfn)
int __pkvm_host_unshare_hyp(u64 pfn)
{
u64 phys = hyp_pfn_to_phys(pfn);
- u64 virt = (u64)__hyp_va(phys);
u64 size = PAGE_SIZE;
int ret;
@@ -1066,10 +1075,9 @@ int __pkvm_host_unshare_hyp(u64 pfn)
ret = __hyp_check_page_state_range(phys, size, PKVM_PAGE_SHARED_BORROWED);
if (ret)
goto unlock;
- if (hyp_page_count((void *)virt)) {
- ret = -EBUSY;
+ ret = __hyp_check_page_count_range(phys, size);
+ if (ret)
goto unlock;
- }
__hyp_set_page_state_range(phys, size, PKVM_NOPAGE);
WARN_ON(__host_set_page_state_range(phys, size, PKVM_PAGE_OWNED));
@@ -1132,6 +1140,10 @@ int __pkvm_hyp_donate_host(u64 pfn, u64 nr_pages)
if (ret)
goto unlock;
+ ret = __hyp_check_page_count_range(phys, size);
+ if (ret)
+ goto unlock;
+
__hyp_set_page_state_range(phys, size, PKVM_NOPAGE);
WARN_ON(kvm_pgtable_hyp_unmap(&pkvm_pgtable, virt, size) != size);
WARN_ON(host_stage2_set_owner_locked(phys, size, PKVM_ID_HOST));
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH v2 1/3] KVM: arm64: Reset page order in pKVM hyp_pool_init
From: Vincent Donnefort @ 2026-05-21 10:21 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort, Sashiko
In-Reply-To: <20260521102149.804874-1-vdonnefort@google.com>
When a VM fails to initialise after its stage-2 hyp_pool has been
initialised, that stage-2 must be torn down entirely. This requires
resetting both the refcount and the order of its pages back to 0.
Currently, reclaim_pgtable_pages() implicitly resets the page order by
allocating the entire pool with order-0 granularity. However, in the VM
initialisation error path, the addresses of the donated memory (the PGD)
are already known, making it unnecessary to iterate over all pages in
the pool.
Since the vmemmap page order is a hyp_pool-specific field, leaving a
non-zero order on hyp_pool destruction is harmless until another pool
attempts to admit the page. Instead of resetting this field during
destruction, reset it during pool initialization in hyp_pool_init().
Note that pages added to the pool outside of the initial pool range
(e.g., via guest_s2_zalloc_page()) must still have their order managed
manually.
While at it, add a WARN_ON() in the hyp_pool attach path to catch
unexpected page orders that exceed the pool's max_order.
Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 25f04629014e..89eb20d4fee4 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -322,7 +322,6 @@ void reclaim_pgtable_pages(struct pkvm_hyp_vm *vm, struct kvm_hyp_memcache *mc)
while (addr) {
page = hyp_virt_to_page(addr);
page->refcount = 0;
- page->order = 0;
push_hyp_memcache(mc, addr, hyp_virt_to_phys);
WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(addr), 1));
addr = hyp_alloc_pages(&vm->pool, 0);
diff --git a/arch/arm64/kvm/hyp/nvhe/page_alloc.c b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
index a1eb27a1a747..c3b3dc5a8ea7 100644
--- a/arch/arm64/kvm/hyp/nvhe/page_alloc.c
+++ b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
@@ -97,6 +97,8 @@ static void __hyp_attach_page(struct hyp_pool *pool,
u8 order = p->order;
struct hyp_page *buddy;
+ WARN_ON(p->order > pool->max_order);
+
memset(hyp_page_to_virt(p), 0, PAGE_SIZE << p->order);
/* Skip coalescing for 'external' pages being freed into the pool. */
@@ -237,8 +239,10 @@ int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
/* Init the vmemmap portion */
p = hyp_phys_to_page(phys);
- for (i = 0; i < nr_pages; i++)
+ for (i = 0; i < nr_pages; i++) {
hyp_set_page_refcounted(&p[i]);
+ p[i].order = 0;
+ }
/* Attach the unused pages to the buddy tree */
for (i = reserved_pages; i < nr_pages; i++)
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* Re: [PATCH v14 02/44] kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h
From: Marc Zyngier @ 2026-05-21 10:26 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-3-steven.price@arm.com>
On Wed, 13 May 2026 14:17:10 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> To avoid future include cycles, drop the linux/kvm_host.h include in
> kvm_pgtable.h and include two _types.h headers for the types that are
> actually used. Additionally provide a forward declaration for struct
> kvm_s2_mmu as it's only used as a pointer in this file.
>
> Both pgtable.c and kvm_pkvm.h relied on the indirect inclusion of
> kvm_host.h, so make that explicit.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> New patch in v13
> ---
> arch/arm64/include/asm/kvm_pgtable.h | 5 ++++-
> arch/arm64/include/asm/kvm_pkvm.h | 2 +-
> arch/arm64/kvm/hyp/pgtable.c | 1 +
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index 41a8687938eb..e4770ce2ccf6 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -8,9 +8,12 @@
> #define __ARM64_KVM_PGTABLE_H__
>
> #include <linux/bits.h>
> -#include <linux/kvm_host.h>
> +#include <linux/kvm_types.h>
> +#include <linux/rbtree_types.h>
I'm surprised by this. Where is the rbtree_type.h requirement coming
from?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 4/5] KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()
From: Mostafa Saleh @ 2026-05-21 10:30 UTC (permalink / raw)
To: Marc Zyngier
Cc: op-tee, linux-kernel, kvmarm, linux-arm-kernel, oupton,
joey.gouly, suzuki.poulose, catalin.marinas, jens.wiklander,
sumit.garg, sebastianene, vdonnefort, sudeep.holla
In-Reply-To: <86ldddw4ht.wl-maz@kernel.org>
Hi Marc,
On Thu, May 21, 2026 at 09:28:46AM +0100, Marc Zyngier wrote:
> On Wed, 20 May 2026 21:49:47 +0100,
> Mostafa Saleh <smostafa@google.com> wrote:
> >
> > Sashiko (locally) reports out of bound write possiblity if SPMD
> > returns an invalid data.
> >
> > While SPMD is considered trusted, pKVM does some basic checks,
> > for offset to be less than or equal len.
> >
> > However, that is incorrect as even if the offset is smaller than
> > len pKVM can still access out of bound memory in the next
> > ffa_host_unshare_ranges().
> >
> > Split this check into 2:
> > 1- Check that the fixed portion of the descriptor fits.
> > 2- After getting reg, check the variable array size addr_range_cnt
> > fits.
> >
> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 1af722771178..e6aa2bfa63b1 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -607,7 +607,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > * check that we end up with something that doesn't look _completely_
> > * bogus.
> > */
> > - if (WARN_ON(offset > len ||
> > + if (WARN_ON(offset + CONSTITUENTS_OFFSET(0) > len ||
> > fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) {
>
> Do you really want to keep this a WARN_ON(), given that this results
> in a panic in most pKVM configurations?
Which kind of configuration will that check fail on?
Does that mean at the moment pKVM does out-of-bound access for
the header?
Thanks,
Mostafa
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH v3] i2c: imx-lpi2c: reset controller in probe stage
From: Carlos Song (OSS) @ 2026-05-21 10:35 UTC (permalink / raw)
To: aisheng.dong, andi.shyti, Frank.Li, s.hauer, kernel, festevam
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
From: Carlos Song <carlos.song@nxp.com>
Reset I2C controller in probe stage to avoid unexpected LPI2C controller
state left from previous stages and hang system boot.
Per the LPI2C reference manual, section 7.1.4 "Controller Control (MCR)"
and 7.1.20 Target Control (SCR), the RST bit (bit 1) description states:
"The reset takes effect immediately and remains asserted until negated
by software. There is no minimum delay required before clearing the
software reset."
Therefore, it is safe to write 0 to MCR and SCR immediately after
asserting the RST bit without any additional delay.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
Change for v3:
- Reset the Target logic via LPI2C_SCR.
- Replacing pm_runtime_put_sync() with pm_runtime_disable() +
pm_runtime_set_suspended() + pm_runtime_put_noidle() to avoid
triggering the suspend callback, and explicitly calling
clk_bulk_disable_unprepare() for clock cleanup.
- Add new error path free_irq and clk_disable to cover more
complete error recovery.
- Remake commit log adding SCR RST section.
Change for v2:
- Jump to rpm_disable instread of returning directly if the IRQ request
fails
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 52 +++++++++++++++++++++---------
1 file changed, 37 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index e6c24a9d934d..4929f85ab485 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1510,11 +1510,6 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
if (ret)
lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
- ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
- pdev->name, lpi2c_imx);
- if (ret)
- return dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
-
i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
platform_set_drvdata(pdev, lpi2c_imx);
@@ -1527,14 +1522,18 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
* each transfer
*/
ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
- if (ret)
- return dev_err_probe(&pdev->dev, ret,
- "can't lock I2C peripheral clock rate\n");
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret,
+ "can't lock I2C peripheral clock rate\n");
+ goto clk_disable;
+ }
lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
- if (!lpi2c_imx->rate_per)
- return dev_err_probe(&pdev->dev, -EINVAL,
- "can't get I2C peripheral clock rate\n");
+ if (!lpi2c_imx->rate_per) {
+ ret = dev_err_probe(&pdev->dev, -EINVAL,
+ "can't get I2C peripheral clock rate\n");
+ goto clk_disable;
+ }
if (lpi2c_imx->hwdata->need_prepare_unprepare_clk)
pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_LONG_TIMEOUT_MS);
@@ -1546,27 +1545,43 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
+ /*
+ * Reset all internal controller logic and registers to avoid effects of previous status
+ * Reset both Master and Target logic to prevent interrupt storms
+ */
+ writel(MCR_RST, lpi2c_imx->base + LPI2C_MCR);
+ writel(SCR_RST, lpi2c_imx->base + LPI2C_SCR);
+ writel(0, lpi2c_imx->base + LPI2C_MCR);
+ writel(0, lpi2c_imx->base + LPI2C_SCR);
+
temp = readl(lpi2c_imx->base + LPI2C_PARAM);
lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
+ ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
+ pdev->name, lpi2c_imx);
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
+ goto rpm_disable;
+ }
+
/* Init optional bus recovery function */
ret = lpi2c_imx_init_recovery_info(lpi2c_imx, pdev);
/* Give it another chance if pinctrl used is not ready yet */
if (ret == -EPROBE_DEFER)
- goto rpm_disable;
+ goto free_irq;
/* Init DMA */
ret = lpi2c_dma_init(&pdev->dev, phy_addr);
if (ret) {
if (ret == -EPROBE_DEFER)
- goto rpm_disable;
+ goto free_irq;
dev_info(&pdev->dev, "use pio mode\n");
}
ret = i2c_add_adapter(&lpi2c_imx->adapter);
if (ret)
- goto rpm_disable;
+ goto free_irq;
pm_runtime_put_autosuspend(&pdev->dev);
@@ -1574,10 +1589,17 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
return 0;
+free_irq:
+ devm_free_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx);
+
rpm_disable:
pm_runtime_dont_use_autosuspend(&pdev->dev);
- pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+
+clk_disable:
+ clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
return ret;
}
--
2.43.0
^ permalink raw reply related
* Re: (subset) [PATCH 0/4] power: sys-off: fix Pixel C shutdown via MAX77620
From: Lee Jones @ 2026-05-21 10:41 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mark Rutland, Lorenzo Pieralisi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, linux-arm-kernel,
linux-kernel, devicetree, linux-tegra
In-Reply-To: <31ef61bd-6672-440a-a52e-eedb950d3d03@tecnico.ulisboa.pt>
On Thu, 21 May 2026, Diogo Ivo wrote:
> Hi Lee,
>
> On 5/20/26 18:25, Lee Jones wrote:
> > On Thu, 14 May 2026 16:47:18 +0200, Diogo Ivo wrote:
> > > This series migrates PSCI and MAX77620 poweroff handling to the
> > > sys-off framework and fixes shutdown on the Pixel C (Smaug).
> > >
> > > The first two patches replace legacy pm_power_off usage in the PSCI
> > > and MAX77620 drivers with sys-off handlers. Besides aligning both
> > > drivers with the modern poweroff infrastructure, this removes the
> > > global callback dependency and allows multiple handlers to coexist
> > > with explicit priorities.
> > >
> > > [...]
> >
> > Applied, thanks!
>
> Thanks for applying the patches! Just a question and an observation:
>
> - I'm assuming you were ok with merging [2/4] despite the possible
> deadlock since this risk is already present in mainline in the same
> form so we're not actually making things worse, is that so?
Did you see the text below?
Both patches 2 and 3 are applied.
> - The observation is that the comment about overriding PSCI is only
> true after (and if) a reworked [1/4] is actually merged.
> If it isn't then patch [3/4] is actually working around another handler
> in soc/tegra/pmc.c where a handler that only does work for the Nexus
> 7 is actually registered at FIRMWARE level for all platforms that
> probe that driver (I will send out a patch shortly to only register
> the handler on the Nexus 7).
I assume the other patches will be applied soon.
If this causes some kind of issue - let me know later on in the cycle
and I'll remove whatever patches you ask me to.
--
Lee Jones
^ permalink raw reply
* [soc:xz/dt] BUILD SUCCESS 7d1f68e87b7302d0bd22c001e6c0511d0e827875
From: kernel test robot @ 2026-05-21 10:43 UTC (permalink / raw)
To: Stefan Dösinger ; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git xz/dt
branch HEAD: 7d1f68e87b7302d0bd22c001e6c0511d0e827875 ARM: dts: zte: Add D-Link DWR-932M support
elapsed time: 829m
configs tested: 197
configs skipped: 3
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-20260521 gcc-8.5.0
arc randconfig-002-20260521 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm footbridge_defconfig clang-17
arm randconfig-001-20260521 gcc-8.5.0
arm randconfig-002-20260521 gcc-8.5.0
arm randconfig-003-20260521 gcc-8.5.0
arm randconfig-004-20260521 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260521 gcc-8.5.0
arm64 randconfig-002-20260521 gcc-8.5.0
arm64 randconfig-003-20260521 gcc-8.5.0
arm64 randconfig-004-20260521 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260521 gcc-8.5.0
csky randconfig-002-20260521 gcc-8.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260521 gcc-11.5.0
hexagon randconfig-002-20260521 gcc-11.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260521 clang-20
i386 buildonly-randconfig-002-20260521 clang-20
i386 buildonly-randconfig-003-20260521 clang-20
i386 buildonly-randconfig-004-20260521 clang-20
i386 buildonly-randconfig-005-20260521 clang-20
i386 buildonly-randconfig-006-20260521 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260521 clang-20
i386 randconfig-002-20260521 clang-20
i386 randconfig-003-20260521 clang-20
i386 randconfig-004-20260521 clang-20
i386 randconfig-005-20260521 clang-20
i386 randconfig-006-20260521 clang-20
i386 randconfig-007-20260521 clang-20
i386 randconfig-011-20260521 gcc-14
i386 randconfig-012-20260521 gcc-14
i386 randconfig-013-20260521 gcc-14
i386 randconfig-014-20260521 gcc-14
i386 randconfig-015-20260521 gcc-14
i386 randconfig-016-20260521 gcc-14
i386 randconfig-017-20260521 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260521 gcc-11.5.0
loongarch randconfig-002-20260521 gcc-11.5.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
mips cavium_octeon_defconfig gcc-15.2.0
mips rt305x_defconfig clang-23
nios2 10m50_defconfig gcc-11.5.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260521 gcc-11.5.0
nios2 randconfig-002-20260521 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260521 gcc-12.5.0
parisc randconfig-002-20260521 gcc-12.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mgcoge_defconfig clang-23
powerpc mpc837x_rdb_defconfig gcc-15.2.0
powerpc randconfig-001-20260521 gcc-12.5.0
powerpc randconfig-002-20260521 gcc-12.5.0
powerpc sam440ep_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260521 gcc-12.5.0
powerpc64 randconfig-002-20260521 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-15.2.0
riscv randconfig-001-20260521 gcc-15.2.0
riscv randconfig-002 gcc-15.2.0
riscv randconfig-002-20260521 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260521 gcc-15.2.0
s390 randconfig-002 gcc-15.2.0
s390 randconfig-002-20260521 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 gcc-15.2.0
sh randconfig-001-20260521 gcc-15.2.0
sh randconfig-002 gcc-15.2.0
sh randconfig-002-20260521 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260521 gcc-8.5.0
sparc randconfig-002-20260521 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260521 gcc-8.5.0
sparc64 randconfig-002-20260521 gcc-8.5.0
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-20260521 gcc-8.5.0
um randconfig-002-20260521 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260521 clang-20
x86_64 buildonly-randconfig-002-20260521 clang-20
x86_64 buildonly-randconfig-003-20260521 clang-20
x86_64 buildonly-randconfig-004-20260521 clang-20
x86_64 buildonly-randconfig-005-20260521 clang-20
x86_64 buildonly-randconfig-006-20260521 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260521 clang-20
x86_64 randconfig-002-20260521 clang-20
x86_64 randconfig-003-20260521 clang-20
x86_64 randconfig-004-20260521 clang-20
x86_64 randconfig-005-20260521 clang-20
x86_64 randconfig-006-20260521 clang-20
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260521 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260521 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260521 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260521 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260521 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260521 gcc-14
x86_64 randconfig-071 clang-20
x86_64 randconfig-071-20260521 clang-20
x86_64 randconfig-072 clang-20
x86_64 randconfig-072-20260521 clang-20
x86_64 randconfig-073 clang-20
x86_64 randconfig-073-20260521 clang-20
x86_64 randconfig-074 clang-20
x86_64 randconfig-074-20260521 clang-20
x86_64 randconfig-075 clang-20
x86_64 randconfig-075-20260521 clang-20
x86_64 randconfig-076 clang-20
x86_64 randconfig-076-20260521 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 allyesconfig clang-23
xtensa randconfig-001-20260521 gcc-8.5.0
xtensa randconfig-002-20260521 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 4/5] KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()
From: Mostafa Saleh @ 2026-05-21 10:43 UTC (permalink / raw)
To: Marc Zyngier
Cc: op-tee, linux-kernel, kvmarm, linux-arm-kernel, oupton,
joey.gouly, suzuki.poulose, catalin.marinas, jens.wiklander,
sumit.garg, sebastianene, vdonnefort, sudeep.holla
In-Reply-To: <ag7eq3bfBOxfaZ59@google.com>
On Thu, May 21, 2026 at 11:30 AM Mostafa Saleh <smostafa@google.com> wrote:
>
> Hi Marc,
>
> On Thu, May 21, 2026 at 09:28:46AM +0100, Marc Zyngier wrote:
> > On Wed, 20 May 2026 21:49:47 +0100,
> > Mostafa Saleh <smostafa@google.com> wrote:
> > >
> > > Sashiko (locally) reports out of bound write possiblity if SPMD
> > > returns an invalid data.
> > >
> > > While SPMD is considered trusted, pKVM does some basic checks,
> > > for offset to be less than or equal len.
> > >
> > > However, that is incorrect as even if the offset is smaller than
> > > len pKVM can still access out of bound memory in the next
> > > ffa_host_unshare_ranges().
> > >
> > > Split this check into 2:
> > > 1- Check that the fixed portion of the descriptor fits.
> > > 2- After getting reg, check the variable array size addr_range_cnt
> > > fits.
> > >
> > > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/ffa.c | 7 ++++++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > index 1af722771178..e6aa2bfa63b1 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > @@ -607,7 +607,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > * check that we end up with something that doesn't look _completely_
> > > * bogus.
> > > */
> > > - if (WARN_ON(offset > len ||
> > > + if (WARN_ON(offset + CONSTITUENTS_OFFSET(0) > len ||
> > > fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) {
> >
> > Do you really want to keep this a WARN_ON(), given that this results
> > in a panic in most pKVM configurations?
>
> Which kind of configuration will that check fail on?
> Does that mean at the moment pKVM does out-of-bound access for
> the header?
>
I might have misunderstood the point. I thought you meant the new
change would cause a panic on most configurations, or were you
suggesting just removing the WARN_ON?
I can do that, I just updated the current faulty check and left the
WARN_ON as is.
Thanks,
Mostafa
> Thanks,
> Mostafa
>
> >
> > Thanks,
> >
> > M.
> >
> > --
> > Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory
From: Balbir Singh @ 2026-05-21 10:46 UTC (permalink / raw)
To: Ryan Roberts
Cc: Alistair Popple, linux-arm-kernel, linux-kernel, linux-mm,
catalin.marinas, will, david, anshuman.khandual, dev.jain,
jhubbard
In-Reply-To: <bc96d822-bb68-4945-9f74-68f77e389ac6@arm.com>
On Thu, May 21, 2026 at 09:50:04AM +0100, Ryan Roberts wrote:
> On 21/05/2026 05:24, Alistair Popple wrote:
> > Hot unplugging memory on ARM64 requires a TLB invalidate after unmapping
> > the page to be hot unplugged from the direct map. Currently that happens
> > one page at a time, meaning range based invalidates cannot be used. The
> > result of this is that removing large amounts of memory takes a long
> > time and in some cases can trigger an RCU stall warning.
> >
> > For example on one system hot unplugging 480GB of memory takes ~1
> > minute. With this change the same operation took ~1 second, a 60x
> > improvement.
> >
> > Signed-off-by: Alistair Popple <apopple@nvidia.com>
> >
> > ---
> >
> > This is an RFC, because I'm not sure the change is correct as it frees
> > the PTE page before flushing the TLB. I'm not familiar enough with ARM64
> > architecture to be sure this is safe, for example I don't know if HW
> > can update PTE bits such as access/dirty in the page through a stale
> > TLB entry.
> >
> > If so this would open a window during which the page is free but could
> > still be written to. Likely the safe option would be to collect all the
> > pages to be free on a list and free them after doing the range based TLB
> > flush, but wanted to get feedback on the approach before implementing it
> > which is the goal of this RFC.
>
> Hi Alistair,
>
> This patch doesn't apply on v7.1-rc4 because it conflicts with this patch:
>
> Commit 48478b9f79137 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
>
> which has a very similar performance improvement, so hopefully it solves your
> problem?
>
> There are two paths which use this logic; unmapping the linear map and unmapping
> the corresponding vmemmap. In the latter case, the memory is also freed, so we
> can't safely do the range optimizaiton there since the TLB needs to be flushed
> before freeing the memory. But the linear map is the big, slow bit so hopefully
> it's sufficent for you?
>
I assume vmemmap path is for tearing down the struct pages corresponding
to the physical memory and vmemmap teardowns taking a flush should be
OK. It is worth checking if the issue is already fixed.
Balbir
<snip>
^ permalink raw reply
* RE: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Carlos Song (OSS) @ 2026-05-21 10:51 UTC (permalink / raw)
To: Mukesh Savaliya, Carlos Song (OSS), o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <22af0378-a3c9-4403-a0ee-da794847f41d@oss.qualcomm.com>
> -----Original Message-----
> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
> Sent: Thursday, May 21, 2026 6:17 PM
> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>; Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com>; o.rempel@pengutronix.de;
> kernel@pengutronix.de; andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> stable@vger.kernel.org
> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered
> down
>
> [You don't often get email from mukesh.savaliya@oss.qualcomm.com. Learn
> why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Thanks Carlos !
>
> On 5/21/2026 1:57 PM, Carlos Song (OSS) wrote:
> >
> >
> >> -----Original Message-----
> >> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
> >> Sent: Thursday, May 21, 2026 3:40 PM
> >> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>;
> >> o.rempel@pengutronix.de; kernel@pengutronix.de;
> >> andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
> >> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
> >> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> >> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> >> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> >> stable@vger.kernel.org
> >> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is
> >> powered down
> >>
> >> [You don't often get email from mukesh.savaliya@oss.qualcomm.com.
> >> Learn why this is important at
> >> https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> Hi Carlos,
> >>
> >> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
> >>> From: Carlos Song <carlos.song@nxp.com>
> >>>
> >>> Mark the I2C adapter as suspended during system suspend to block
> >>> further transfers, and resume it on system resume. This prevents
> >>> potential hangs when the hardware is powered down but clients still
> >>> attempt
> >> I2C transfers.
> >>>
> what was the reason of this hang ? I was thinking you don't have interrupts
> working when client requested transfer but adapter was suspended. Please
> correct me if wrong.
>
> And it would be good to mention the actual problem and why/how it occurred.
> >> Code changes looks fine to me but have comment on commit log.
> >>
> >> It seems, you are adding support of _noirq() callbacks to allow
> >> transfers during suspend/resume noirq phase of PM.
> >>
> >> Would it make sense if you can write "Replace system PM callbacks
> >> with noirq PM callbacks" OR "Allow transfers during _noirq phase of
> >> the PM ops" instead of "mark I2C adapter when hardware is powered
> down" ?
> >>
> >
> > Hi,
> >
> > Thank you for your comments!
> >
> > But this patch is added is not for support noirq PM callback or transfer in noirq
> phase.
> >
> Okay, may be actual problem description can help me.
> > In fact, this fix is to mark the I2C adapter as suspended during
> > system noirq suspend to block further transfers, and resume it on
> > system noirq resume. This is to prohibit I2C device calling the I2C
> > controller after the system noirq suspend and before noirq resume, because at
> this time the I2C instance is powered off or the clock is disabled ... So I want to
> keep current commit. How do you think?
> completely Makes sense. Please help add how this problem occurred and why ?
> So the change/fix will be good to understand against it.
Hi,
In some I.MX platform, some I2C devices will keep a work queue all time, the work queue will
trigger I2C xfer every once in a while, but the work queue shouldn't be free in system suspend.
Within a very short time window, possibly from noirq_suspend to the system actually being suspended,
or possibly from the system starting to resume to before noirq_resume, this work queue will trigger an
I2C transfer, and at this time the I2C controller's clk and pinctrl have not yet been restored, reading and
writing I2C registers causes the system to hang. This patch make all I2C operations are performed in a safe
hardware state.
Is it better if I add these comment to patch commit log?
> >
> > Carlos Song
>
^ permalink raw reply
* Re: [PATCH v8 net-next 00/15] Add preliminary NETC switch support for i.MX94
From: patchwork-bot+netdevbpf @ 2026-05-21 11:10 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
f.fainelli, frank.li, chleroy, horms, linux, maxime.chevallier,
andrew, olteanv, netdev, linux-kernel, devicetree, linuxppc-dev,
linux-arm-kernel, imx
In-Reply-To: <20260518082506.1318236-1-wei.fang@nxp.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 18 May 2026 16:24:51 +0800 you wrote:
> i.MX94 NETC (v4.3) integrates 802.1Q Ethernet switch functionality, the
> switch provides advanced QoS with 8 traffic classes and a full range of
> TSN standards capabilities. It has 3 user ports and 1 CPU port, and the
> CPU port is connected to an internal ENETC through the pseduo link, so
> instead of a back-to-back MAC, the lightweight "pseudo MAC" is used at
> both ends of the pseudo link to transfer Ethernet frames. The pseudo
> link provides a zero-copy interface (no serialization delay) and lower
> power (less logic and memory).
>
> [...]
Here is the summary with links:
- [v8,net-next,01/15] dt-bindings: net: dsa: update the description of 'dsa,member' property
https://git.kernel.org/netdev/net-next/c/0c89a779c373
- [v8,net-next,02/15] dt-bindings: net: dsa: add NETC switch
https://git.kernel.org/netdev/net-next/c/6d019124be60
- [v8,net-next,03/15] net: enetc: add pre-boot initialization for i.MX94 switch
https://git.kernel.org/netdev/net-next/c/f059d55fd8a0
- [v8,net-next,04/15] net: enetc: add basic operations to the FDB table
https://git.kernel.org/netdev/net-next/c/4566269803ff
- [v8,net-next,05/15] net: enetc: add support for the "Add" operation to VLAN filter table
https://git.kernel.org/netdev/net-next/c/d0ac4d4bd299
- [v8,net-next,06/15] net: enetc: add support for the "Update" operation to buffer pool table
https://git.kernel.org/netdev/net-next/c/cb4d95d79d85
- [v8,net-next,07/15] net: enetc: add support for "Add" and "Delete" operations to IPFT
https://git.kernel.org/netdev/net-next/c/123db6a27511
- [v8,net-next,08/15] net: enetc: add multiple command BD rings support
https://git.kernel.org/netdev/net-next/c/c5aed83ddc53
- [v8,net-next,09/15] net: dsa: add NETC switch tag support
https://git.kernel.org/netdev/net-next/c/0850005c26d2
- [v8,net-next,10/15] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
https://git.kernel.org/netdev/net-next/c/187fbae024c8
- [v8,net-next,11/15] net: dsa: netc: add phylink MAC operations
https://git.kernel.org/netdev/net-next/c/bbe97e347219
- [v8,net-next,12/15] net: dsa: netc: add FDB, STP, MTU, port setup and host flooding support
https://git.kernel.org/netdev/net-next/c/46d6407692c8
- [v8,net-next,13/15] net: dsa: netc: initialize buffer pool table and implement flow-control
https://git.kernel.org/netdev/net-next/c/a5ccb7f5e067
- [v8,net-next,14/15] net: dsa: netc: add support for the standardized counters
https://git.kernel.org/netdev/net-next/c/25049d8b6e6b
- [v8,net-next,15/15] net: dsa: netc: add support for ethtool private statistics
https://git.kernel.org/netdev/net-next/c/beb0e54f3806
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Mukesh Savaliya @ 2026-05-21 11:14 UTC (permalink / raw)
To: Carlos Song (OSS), Mukesh Savaliya, o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <AM0PR04MB6802FE8B0E0BEF8CDA6DAD5EE80E2@AM0PR04MB6802.eurprd04.prod.outlook.com>
On 5/21/2026 4:21 PM, Carlos Song (OSS) wrote:
[...]
>>>> -----Original Message-----
>>>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
>>>> Sent: Thursday, May 21, 2026 3:40 PM
>>>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>;
>>>> o.rempel@pengutronix.de; kernel@pengutronix.de;
>>>> andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
>>>> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
>>>> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
>>>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
>>>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>>>> stable@vger.kernel.org
>>>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is
>>>> powered down
>>>>
>>>> Hi Carlos,
>>>>
>>>> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
>>>>> From: Carlos Song <carlos.song@nxp.com>
>>>>>
>>>>> Mark the I2C adapter as suspended during system suspend to block
>>>>> further transfers, and resume it on system resume. This prevents
>>>>> potential hangs when the hardware is powered down but clients still
>>>>> attempt
>>>> I2C transfers.
>>>>>
>> what was the reason of this hang ? I was thinking you don't have interrupts
>> working when client requested transfer but adapter was suspended. Please
>> correct me if wrong.
>>
>> And it would be good to mention the actual problem and why/how it occurred.
>>>> Code changes looks fine to me but have comment on commit log.
>>>>
>>>> It seems, you are adding support of _noirq() callbacks to allow
>>>> transfers during suspend/resume noirq phase of PM.
>>>>
>>>> Would it make sense if you can write "Replace system PM callbacks
>>>> with noirq PM callbacks" OR "Allow transfers during _noirq phase of
>>>> the PM ops" instead of "mark I2C adapter when hardware is powered
>> down" ?
>>>>
>>>
>>> Hi,
>>>
>>> Thank you for your comments!
>>>
>>> But this patch is added is not for support noirq PM callback or transfer in noirq
>> phase.
>>>
>> Okay, may be actual problem description can help me.
>>> In fact, this fix is to mark the I2C adapter as suspended during
>>> system noirq suspend to block further transfers, and resume it on
>>> system noirq resume. This is to prohibit I2C device calling the I2C
>>> controller after the system noirq suspend and before noirq resume, because at
>> this time the I2C instance is powered off or the clock is disabled ... So I want to
>> keep current commit. How do you think?
>> completely Makes sense. Please help add how this problem occurred and why ?
>> So the change/fix will be good to understand against it.
>
> Hi,
>
> In some I.MX platform, some I2C devices will keep a work queue all time, the work queue will
> trigger I2C xfer every once in a while, but the work queue shouldn't be free in system suspend.
>
work queue has transfers queued even if system is suspended ? IMO, the
client i2c devices should not let system go to suspend.
> Within a very short time window, possibly from noirq_suspend to the system actually being suspended,
> or possibly from the system starting to resume to before noirq_resume, this work queue will trigger an
> I2C transfer, and at this time the I2C controller's clk and pinctrl have not yet been restored, reading and
Right, this kind of explains the problem to me. I think you are trying
to serve i2c transfers when your resources(clk, pinctrl) are not turned
ON and also interrupt remains disabled. And that's why you need to add
_noir() PM callbacks supports along with IRQF_NO_SUSPEND |
IRQF_EARLY_RESUME flags.
> writing I2C registers causes the system to hang. This patch make all I2C operations are performed in a safe
> hardware state.
>
> Is it better if I add these comment to patch commit log?
>>>
if my latest comments makes sense against the issue, you may write
accordingly. if i am wrong, then your explanation makes sense. Cause of
the hang needs to be clearly mention int the commit log in your next patch.
>>> Carlos Song
>>
>
^ permalink raw reply
* Re: [RFC PATCH 2/2] arm64: mm: add SMCCC-backed cache invalidate provider
From: Jonathan Cameron @ 2026-05-21 11:18 UTC (permalink / raw)
To: Srirangan Madhavan
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
conor, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams
In-Reply-To: <20260521073047.320614-3-smadhavan@nvidia.com>
On Thu, 21 May 2026 07:30:47 +0000
Srirangan Madhavan <smadhavan@nvidia.com> wrote:
> Add an arm64 cache maintenance backend that discovers SMCCC cache
> clean+invalidate support, queries attributes, handles transient BUSY and
> RATE_LIMITED responses with bounded retries, and registers with the generic
> cache coherency framework.
>
> Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
Hi Srirangan,
Other than the file location and Kconfig option comments, everything else
is really trivial. + some musings about maybe being worth more clever
fusing of ops in the future if it turns out to be useful.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++++++
File location wise, this is a driver for a subsystem, be it one closely
coupled to arm. Arm maintainers, do you want it in there or in drivers/cache ?
My personal preference is always to keep drivers with subsystems but I don't
care that much.
> 3 files changed, 182 insertions(+)
> create mode 100644 arch/arm64/mm/cache_maint.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2fb1c75afd16..33c35f8e6e40 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25383,6 +25383,7 @@ M: Jonathan Cameron <jic23@kernel.org>
> S: Maintained
> T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
> F: Documentation/devicetree/bindings/cache/
> +F: arch/arm64/mm/cache_maint.c
I wonder if this should just have a separate maintainers entry?
We did that for the hisi driver.
If not maybe add yourself as at least a Reviewer so that you get +CC'd
on relevant changes.
Conor, what do you think makes sense here.
> F: drivers/cache
> F: include/linux/cache_coherency.h
> F: lib/cache_maint.c
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index c26489cf96cd..b247dc5dfd45 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_TRANS_TABLE) += trans_pgd-asm.o
> obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
> obj-$(CONFIG_ARM64_MTE) += mteswap.o
> obj-$(CONFIG_ARM64_GCS) += gcs.o
> +obj-$(CONFIG_ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION) += cache_maint.o
I think this should have a separate CONFIG because it is only one option
for how to do it on arm64. The Hisi driver being the other one already
upstream. That will be easier if this is in drivers/cache as can go
in the existing menu.
> KASAN_SANITIZE_physaddr.o += n
>
> obj-$(CONFIG_KASAN) += kasan_init.o
> diff --git a/arch/arm64/mm/cache_maint.c b/arch/arm64/mm/cache_maint.c
> new file mode 100644
> index 000000000000..ea7dd30d5dfa
> --- /dev/null
> +++ b/arch/arm64/mm/cache_maint.c
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026 NVIDIA Corporation
> + *
> + * Arm64 cache maintenance provider using SMCCC cache clean+invalidate calls.
> + */
> +
> +#include <linux/arm-smccc.h>
> +#include <linux/cache_coherency.h>
> +#include <linux/cleanup.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/mutex.h>
> +#include <linux/nmi.h>
> +
> +#define SMCCC_CACHE_MAX_RETRIES 5
> +#define SMCCC_CACHE_MAX_DELAY_US 20000
> +
> +/* DEN0028 v1.7: bit[0] == 1 means implementation flushes all caches globally */
> +#define SMCCC_CACHE_ATTR_GLOBAL_OP BIT(0)
> +
> +struct arm64_smccc_cache {
> + /* Must be first member */
> + struct cache_coherency_ops_inst cci;
> + struct mutex lock; /* Serializes SMCCC cache maintenance calls. */
> + u32 latency_us;
> + u32 rate_limit;
> + bool global_op;
> + u64 global_flush_gen;
> +};
> +
> +static struct arm64_smccc_cache *arm64_smccc_cache;
Whilst it is harmless, why do we need the global? I don't think anything outside
of init() ever uses it. Given there is no exit() anyway, might as well just leak
the pointer.
> +
> +static int smccc_cache_status_to_errno(s32 status)
> +{
> + switch (status) {
> + case SMCCC_RET_SUCCESS:
> + return 0;
> + case SMCCC_RET_NOT_SUPPORTED:
> + case SMCCC_RET_NOT_REQUIRED:
I'm not seeing this in the list of possible errors and
I'm far from sure what it would mean in this case if we got it!
Maybe it would indicate that the cache was known not dirty for
some reason. I'd left default deal with this one probably.
> + return -EOPNOTSUPP;
> + case SMCCC_RET_INVALID_PARAMETER:
> + return -EINVAL;
> + case SMCCC_RET_RATE_LIMITED:
> + return -EAGAIN;
> + case SMCCC_RET_BUSY:
> + return -EBUSY;
> + default:
> + return -EIO;
> + }
> +}
> +
> +static int smccc_cache_delay_us(const struct arm64_smccc_cache *cache)
> +{
> + u64 delay_us = 0;
> +
> + if (cache->rate_limit)
> + delay_us = DIV_ROUND_UP_ULL(USEC_PER_SEC, cache->rate_limit);
> +
> + if (cache->latency_us)
> + delay_us = max_t(u64, delay_us, cache->latency_us);
max() should be fine here I think.
> +
> + if (!delay_us)
> + delay_us = 1000;
Why? Needs a comment I think.
> +
> + return min_t(u64, delay_us, SMCCC_CACHE_MAX_DELAY_US);
The type forcing needed? I might be missing why min() isn't fine here.
Doesn't seem to be in the list in the minmax.h docs for when you can't
just use min().
> +}
> +
> +static int arm64_smccc_cache_wbinv(struct cache_coherency_ops_inst *cci,
> + struct cc_inval_params *invp)
> +{
> + struct arm64_smccc_cache *cache =
> + container_of(cci, struct arm64_smccc_cache, cci);
> + struct arm_smccc_res res = {};
> + int delay_us = smccc_cache_delay_us(cache);
> + u64 gen = 0;
> + s32 status;
> + int ret;
> + int i;
> +
> + if (!invp->size)
> + return -EINVAL;
> +
> + if (cache->global_op)
> + gen = READ_ONCE(cache->global_flush_gen);
> +
> + guard(mutex)(&cache->lock);
> +
> + /*
> + * If firmware reports a global operation type, a successful operation
> + * covers every request that was already waiting behind it. Skip if the
> + * generation advanced while this request was waiting to enter the
> + * serialized firmware call path.
Perhaps call out that the serialization is on the lock. I read this as
there being another level of serialization going on and got confused ;)
Can see there might be further improvements to the non global case
using same principle you have here. I guess leave those until we have
any info on whether they are useful.
> + */
> + if (cache->global_op && gen != READ_ONCE(cache->global_flush_gen))
> + return 0;
> +
> + for (i = 0; i < SMCCC_CACHE_MAX_RETRIES; i++) {
Can drag the int i in here, maybe make it unsigned too.
for (unsigned int i = 0; i <...
This is becoming widely accepted in kernel code these days.
> + /* Long firmware operations can trigger watchdog checks. */
> + touch_nmi_watchdog();
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION,
> + invp->addr, invp->size, 0UL, &res);
> + status = (s32)res.a0;
> + ret = smccc_cache_status_to_errno(status);
Given status isn't used for anything else - tiny bit neater perhaps as
ret = smccc_cache_status_to_errno((s32)res.a0);
> + if (!ret) {
> + if (cache->global_op) {
> + WRITE_ONCE(cache->global_flush_gen,
> + cache->global_flush_gen + 1);
> + }
> + return 0;
> + }
> +
> + if (ret != -EBUSY && ret != -EAGAIN)
> + return ret;
> +
> + usleep_range(delay_us, delay_us + 100);
fsleep() for this sort of thing in modern code.
> + }
> +
> + return -EBUSY;
> +}
> +
> +static int __init arm64_smccc_cache_init(void)
> +{
> + struct arm_smccc_res res = {};
> + s32 status;
> + int ret;
> +
> + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_1)
> + return -ENODEV;
> +
> + if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
> + return -ENODEV;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION, &res);
> + status = (s32)res.a0;
> + if (status < 0)
> + return -ENODEV;
Maybe there is convention for this, but feels a bit odd to return -ENODEV
for a feature check on a 'device' we are talking to. Maybe -EOPNOTSUPP?
Anyhow, that's a question for SMCCC folk. The only error that could
be returned is NOT_SUPPORTED and you do that above for the returns from
actual calls.
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
> + status = (s32)res.a0;
> + if (status < 0)
> + return -ENODEV;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
> + status = (s32)res.a0;
> + if (status)
> + return -ENODEV;
> +
> + arm64_smccc_cache =
> + cache_coherency_ops_instance_alloc(&arm64_smccc_cache_ops,
> + struct arm64_smccc_cache,
> + cci);
I'd go long on that just for readability but not important.
> + if (!arm64_smccc_cache)
> + return -ENOMEM;
> +
> + mutex_init(&arm64_smccc_cache->lock);
> + arm64_smccc_cache->latency_us = lower_32_bits(res.a2);
> + arm64_smccc_cache->rate_limit = lower_32_bits(res.a3);
> + arm64_smccc_cache->global_op = !!(res.a1 & SMCCC_CACHE_ATTR_GLOBAL_OP);
> +
> + ret = cache_coherency_ops_instance_register(&arm64_smccc_cache->cci);
> + if (ret) {
> + cache_coherency_ops_instance_put(&arm64_smccc_cache->cci);
> + arm64_smccc_cache = NULL;
> + return ret;
> + }
> +
> + pr_info("SMCCC cache clean+invalidate provider registered\n")
Trivial: blank line here. Just helps the error path stand out vs the
print.
> + return 0;
> +}
> +arch_initcall(arm64_smccc_cache_init);
^ permalink raw reply
* Re: [PATCH 2/2] kselftest/arm64: Add test for atomic futex uaccess with POE
From: Mark Brown @ 2026-05-21 11:22 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, Catalin Marinas, Joey Gouly, Shuah Khan,
Will Deacon, linux-kernel, linux-kselftest
In-Reply-To: <20260521-poe_futex-v1-2-1da286b8f9b2@arm.com>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Thu, May 21, 2026 at 10:42:31AM +0100, Kevin Brodsky wrote:
> Add a new test to ensure that atomic futex uaccess succeeds on
> memory mapped with a non-default POIndex/pkey.
> + ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
> + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> + ASSERT_NE(ptr, MAP_FAILED);
Doesn't matter while there's only one test but we should probably
munmap() this when we're done.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory
From: Ryan Roberts @ 2026-05-21 11:24 UTC (permalink / raw)
To: Balbir Singh
Cc: Alistair Popple, linux-arm-kernel, linux-kernel, linux-mm,
catalin.marinas, will, david, anshuman.khandual, dev.jain,
jhubbard
In-Reply-To: <ag7fy4Q9foBBlUcd@parvat>
On 21/05/2026 11:46, Balbir Singh wrote:
> On Thu, May 21, 2026 at 09:50:04AM +0100, Ryan Roberts wrote:
>> On 21/05/2026 05:24, Alistair Popple wrote:
>>> Hot unplugging memory on ARM64 requires a TLB invalidate after unmapping
>>> the page to be hot unplugged from the direct map. Currently that happens
>>> one page at a time, meaning range based invalidates cannot be used. The
>>> result of this is that removing large amounts of memory takes a long
>>> time and in some cases can trigger an RCU stall warning.
>>>
>>> For example on one system hot unplugging 480GB of memory takes ~1
>>> minute. With this change the same operation took ~1 second, a 60x
>>> improvement.
>>>
>>> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>>>
>>> ---
>>>
>>> This is an RFC, because I'm not sure the change is correct as it frees
>>> the PTE page before flushing the TLB. I'm not familiar enough with ARM64
>>> architecture to be sure this is safe, for example I don't know if HW
>>> can update PTE bits such as access/dirty in the page through a stale
>>> TLB entry.
>>>
>>> If so this would open a window during which the page is free but could
>>> still be written to. Likely the safe option would be to collect all the
>>> pages to be free on a list and free them after doing the range based TLB
>>> flush, but wanted to get feedback on the approach before implementing it
>>> which is the goal of this RFC.
>>
>> Hi Alistair,
>>
>> This patch doesn't apply on v7.1-rc4 because it conflicts with this patch:
>>
>> Commit 48478b9f79137 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
>>
>> which has a very similar performance improvement, so hopefully it solves your
>> problem?
>>
>> There are two paths which use this logic; unmapping the linear map and unmapping
>> the corresponding vmemmap. In the latter case, the memory is also freed, so we
>> can't safely do the range optimizaiton there since the TLB needs to be flushed
>> before freeing the memory. But the linear map is the big, slow bit so hopefully
>> it's sufficent for you?
>>
>
> I assume vmemmap path is for tearing down the struct pages corresponding
> to the physical memory and vmemmap teardowns taking a flush should be
> OK. It is worth checking if the issue is already fixed.
Yes, exactly. Assuming you're using 64K pages, I think vmemmap is mapped using
base pages. So you'd get 1024 struct pages on a page, so 1 TLBI per 64M of
memory that is being unplugged on the vmemmap path.
On the linear map path, it's a single range tlbi operation to over the entire range.
Alistair's patch is doing it per 512M in both cases, but is unsafe for vmemmap
as currently written.
>
> Balbir
> <snip>
^ permalink raw reply
* Re: [PATCH] irqchip/exynos-combiner: switch to raw_spinlock
From: Marek Szyprowski @ 2026-05-21 11:26 UTC (permalink / raw)
To: Thomas Gleixner, linux-arm-kernel, linux-samsung-soc,
linux-rt-devel
Cc: Krzysztof Kozlowski, Alim Akhtar, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt
In-Reply-To: <87ecj5w2qf.ffs@tglx>
On 21.05.2026 11:06, Thomas Gleixner wrote:
> On Thu, May 21 2026 at 00:04, Marek Szyprowski wrote:
>> The exynos-combiner driver uses a regular spinlock to protect access to
>> the combiner interrupt status register in combiner_handle_cascade_irq(),
>> which is invoked in hard IRQ context as a chained interrupt handler.
>>
>> When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a
>> sleeping lock (mutex-based), which must not be used in atomic context
>> such as hard interrupt handlers. Switch the irq_controller_lock to
>> raw_spinlock, which remains a true non-sleeping spinlock even under
>> PREEMPT_RT.
> Mechanically this makes sense, but out of curiosity I have to ask:
>
>> -static DEFINE_SPINLOCK(irq_controller_lock);
>> +static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>>
>> struct combiner_chip_data {
>> unsigned int hwirq_offset;
>> @@ -72,9 +72,9 @@ static void combiner_handle_cascade_irq(struct irq_desc *desc)
>>
>> chained_irq_enter(chip, desc);
>>
>> - spin_lock(&irq_controller_lock);
>> + raw_spin_lock(&irq_controller_lock);
>> status = readl_relaxed(chip_data->base + COMBINER_INT_STATUS);
>> - spin_unlock(&irq_controller_lock);
>> + raw_spin_unlock(&irq_controller_lock);
> What is this lock actually protecting?
>
> Each combiner has it's own @base address, so there is no concurrency
> problem between two cascade interrupts being handled at the same time.
>
> That means the only possible problem would be that the same cascade
> interrupt is handled on two CPUs concurrently. Is that even possible?
Frankly speaking I did this conversion mechanically, late in the evening to fix
the bug warning I've spotted. Indeed this spinlock looks like a copy&paste or
development leftover. The only side-effect of it I see is a memory barrier,
which might affect how the register access happens, but this should not affect
cascade operation imho. Do You want me to send a patch removing it completely?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Lee Jones @ 2026-05-21 11:26 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Sebastian Reichel, Mark Rutland, Lorenzo Pieralisi,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer,
Bartosz Golaszewski, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <20260514-arm-psci-system_reset2-vendor-reboots-v22-8-28a5bde07483@oss.qualcomm.com>
On Thu, 14 May 2026, Shivendra Pratap wrote:
> MFD core has no way to register a child device using an explicit firmware
> node. This prevents drivers from registering child nodes when those nodes
> do not define a compatible string. One such example is the PSCI
> "reboot-mode" node, which omits a compatible string as it describes
> boot-states provided by the underlying firmware.
>
> Extend struct mfd_cell with a callback that allows drivers to provide an
> explicit firmware node. The node is added to the MFD child device during
> registration when none is assigned by device tree, ACPI, or software
> matching.
>
> Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
> drivers/mfd/mfd-core.c | 30 ++++++++++++++++++++++++++++++
> include/linux/mfd/core.h | 14 ++++++++++++++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 7aa32b90cf1eb7fa0a05bf3dc506e60a262c9850..cc2a2a924d6d3044e29a9f864b536ee325ed797b 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -10,6 +10,7 @@
> #include <linux/kernel.h>
> #include <linux/platform_device.h>
> #include <linux/acpi.h>
> +#include <linux/fwnode.h>
> #include <linux/list.h>
> #include <linux/property.h>
> #include <linux/mfd/core.h>
> @@ -148,6 +149,11 @@ static int mfd_match_of_node_to_dev(struct platform_device *pdev,
> return 0;
> }
>
> +static void mfd_child_fwnode_put(void *data)
> +{
> + fwnode_handle_put(data);
> +}
> +
> static int mfd_add_device(struct device *parent, int id,
> const struct mfd_cell *cell,
> struct resource *mem_base,
> @@ -156,6 +162,7 @@ static int mfd_add_device(struct device *parent, int id,
> struct resource *res;
> struct platform_device *pdev;
> struct mfd_of_node_entry *of_entry, *tmp;
> + struct fwnode_handle *fwnode;
> bool disabled = false;
> int ret = -ENOMEM;
> int platform_id;
> @@ -224,6 +231,29 @@ static int mfd_add_device(struct device *parent, int id,
>
> mfd_acpi_add_device(cell, pdev);
>
> + if (!pdev->dev.fwnode && cell->get_child_fwnode) {
> + fwnode = cell->get_child_fwnode(parent);
> + if (fwnode) {
> + device_set_node(&pdev->dev, fwnode);
> +
> + /*
> + * platform_device_release() drops only of_node refs.
> + * Track non-OF fwnodes explicitly so they are put on
> + * all teardown paths.
> + */
> + if (!to_of_node(fwnode)) {
> + ret = devm_add_action(&pdev->dev,
> + mfd_child_fwnode_put,
> + fwnode);
> + if (ret) {
> + device_set_node(&pdev->dev, NULL);
> + fwnode_handle_put(fwnode);
> + goto fail_of_entry;
> + }
> + }
> + }
> + }
mfd_add_device() is getting very busy now with support for all of these
different registration APIs. Suggest that we start breaking them out.
> +
> if (cell->pdata_size) {
> ret = platform_device_add_data(pdev,
> cell->platform_data, cell->pdata_size);
> diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> index faeea7abd688f223fb0b31cde0a9b69dfe2a61ff..abfc26c057d6ee46947ba2b6f2e99f420e74b127 100644
> --- a/include/linux/mfd/core.h
> +++ b/include/linux/mfd/core.h
> @@ -50,6 +50,7 @@
> #define MFD_DEP_LEVEL_HIGH 1
>
> struct irq_domain;
> +struct fwnode_handle;
> struct software_node;
>
> /* Matches ACPI PNP id, either _HID or _CID, or ACPI _ADR */
> @@ -80,6 +81,19 @@ struct mfd_cell {
>
> /* Software node for the device. */
> const struct software_node *swnode;
> + /*
> + * Callback to return an explicit firmware node.
> + * @parent: MFD parent device passed to mfd_add_devices().
> + *
> + * Called only if OF/ACPI matching did not assign a fwnode.
> + * Ownership of the returned reference is transferred to MFD core.
> + *
> + * Return a referenced fwnode or NULL if none is available.
> + *
> + * mfd_cell must be zero-initialized or get_child_fwnode must be NULL
> + * when unused.
> + */
> + struct fwnode_handle *(*get_child_fwnode)(struct device *parent);
I'm very much against pointers to functions if they can be avoided. Why
does fwnode need this and none of the other APIs do?
> /*
> * Device Tree compatible string
>
> --
> 2.34.1
>
--
Lee Jones
^ permalink raw reply
* Re: [RFC PATCH 0/2] arm64: add SMCCC cache invalidation backend for memregion users
From: Jonathan Cameron @ 2026-05-21 11:28 UTC (permalink / raw)
To: Srirangan Madhavan
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
conor, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams
In-Reply-To: <20260521073047.320614-1-smadhavan@nvidia.com>
On Thu, 21 May 2026 07:30:45 +0000
Srirangan Madhavan <smadhavan@nvidia.com> wrote:
> This series adds an arm64 backend for memregion cache invalidation users
> based on the Arm SMCCC cache clean+invalidate interface.
>
> Per DEN0028, this interface targets systems where a Normal Cacheable
> memory region can be modified in ways that are not handled by usual PE
> coherency mechanisms, and where VA-based CMOs may be too slow or
> insufficient for large ranges and/or system-cache implementations.
>
> Representative use cases include device-backed memory state transitions
> where stale CPU/system cache lines must be invalidated reliably (for
> example secure erase, reset/offline flows, and dynamic memory
> reconfiguration).
>
Hi Srirangan,
Great to see this moving forwards. I was wondering when it would
surface upstream :)
Usual thing for an RFC is to have some reference to why it is an RFC.
I'm not immediately spotting any open questions or dependencies to
stop this going upstream now (if review of actual code goes well).
So why RFC? Is the spec still in beta?
> Patch 1 introduces the Arm SMCCC cache clean/invalidate function IDs and
> transient return codes needed by callers [1].
>
> Patch 2 adds an arm64 cache maintenance provider that:
> - discovers SMCCC support and attributes at init time
> - registers with the generic cache coherency framework used by
> cpu_cache_invalidate_memregion()
> - handles transient BUSY/RATE_LIMITED responses with bounded retries
> - coalesces waiters when firmware reports a global operation type
>
> This patch set does not add a software fallback path; when firmware does
> not implement the SMCCC cache maintenance interface, the provider is not
> registered and existing behavior is preserved.
By which you mean it kicks out an error? This kind of hints there
might be a software fallback (assuming no other implementation has
registered). In many cases there isn't a safe software solution.
Jonathan
>
> Reference:
> [1] https://developer.arm.com/documentation/den0028/latest
>
> Srirangan Madhavan (2):
> arm64: smccc: add cache clean/invalidate IDs and return codes
> arm64: mm: add SMCCC-backed cache invalidate provider
>
> MAINTAINERS | 1 +
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++
> include/linux/arm-smccc.h | 17 ++-
> tools/include/linux/arm-smccc.h | 17 ++-
> 5 files changed, 212 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm64/mm/cache_maint.c
>
>
> base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
^ permalink raw reply
* Re: [PATCH v5 4/6] dt-bindings: display: mediatek: tdshp: Add support for MT8196
From: Jay Liu (刘博) @ 2026-05-21 11:40 UTC (permalink / raw)
To: chunkuang.hu@kernel.org, tzimmermann@suse.de, simona@ffwll.ch,
mripard@kernel.org, p.zabel@pengutronix.de,
CK Hu (胡俊光),
maarten.lankhorst@linux.intel.com, conor+dt@kernel.org,
robh@kernel.org, airlied@gmail.com, matthias.bgg@gmail.com,
krzk+dt@kernel.org, AngeloGioacchino Del Regno
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <c9ed6676f1ae77e21b2ba2daf75a76f3a9a13389.camel@mediatek.com>
On Wed, 2026-05-13 at 08:03 +0000, CK Hu (胡俊光) wrote:
> On Mon, 2026-04-27 at 19:20 +0800, Jay Liu wrote:
> > Add tdshp hardware description for MediaTek MT8196 SoC
> >
> > Signed-off-by: Jay Liu <jay.liu@mediatek.com>
> > ---
> > .../display/mediatek/mediatek,tdshp.yaml | 46
> > +++++++++++++++++++
> > 1 file changed, 46 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp.y
> > aml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp
> > .yaml
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp
> > .yaml
> > new file mode 100644
> > index 000000000000..50b24cc22420
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp
> > .yaml
> > @@ -0,0 +1,46 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://urldefense.com/v3/__http://devicetree.org/schemas/display/mediatek/mediatek,tdshp.yaml*__;Iw!!CTRNKA9wMg0ARbw!jvLiL6w7ScJqhkM0IyiLok4cwzb-e1gME-mO9r5lLT3JTrgaBBiiV1j8LFkmJkIafaGiBya2GJN6h38e$
> >
> > +$schema:
> > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!jvLiL6w7ScJqhkM0IyiLok4cwzb-e1gME-mO9r5lLT3JTrgaBBiiV1j8LFkmJkIafaGiBya2GCPflrFz$
> >
> > +
> > +title: MediaTek display 2D sharpness processor
> > +
> > +maintainers:
> > + - Chun-Kuang Hu <chunkuang.hu@kernel.org>
> > + - Philipp Zabel <p.zabel@pengutronix.de>
> > +
> > +description: |
> > + MediaTek display 2D sharpness processor, namely TDSHP, provides
> > a
>
> a -> an
>
> > + operation used to adjust sharpness in display system.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - mediatek,mt8196-disp-tdshp
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
>
> Refer to other display block binding document, and find out the
> common property.
> Such as power-domains, gce-client-reg, ports.
>
> Regards,
> CK
>
Thank you for your review and helpful suggestions.
I will review other display block binding documents and identify the
common properties, such as power-domains, gce-client-reg, and ports.
If I have further questions or need clarification, I will reach out.
Thanks again for your guidance.
Best regards,
Jay
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + tdshp@321e0000 {
> > + compatible = "mediatek,mt8196-disp-tdshp";
> > + reg = <0 0x321e0000 0 0x1000>;
> > + clocks = <&dispsys_config_clk 107>;
> > + };
> > + };
>
>
^ permalink raw reply
* [PATCH v2 0/3] Add eDP lane mapping support
From: Damon Ding @ 2026-05-21 11:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
This series adds configurable eDP/DP physical lane mapping support
via device tree data-lanes property.
Lane mapping is mainly used for below scenarios:
1. Correct PCB lane swap and differential line routing crossover
without hardware changes;
2. Adapt mismatched lane pin definitions between SoC and eDP panel;
3. Support multiple panel hardware variants on the same board
by configuring data-lanes in device tree only.
The series includes driver implementation and device tree binding
updates to support custom lane mapping configuration from endpoint
node, and keeps default linear lane order if no configuration is given.
Patch 1: Add endpoint data-lanes property to analogix-dp binding
Patch 2: Add data-lanes property example in rockchip analogix-dp binding
Patch 3: Implement lane mapping in analogix_dp driver
Damon Ding (3):
dt-bindings: display: bridge: analogix-dp: Add data-lanes support for
endpoint
dt-bindings: rockchip: analogix-dp: Add data-lanes example
drm/bridge: analogix_dp: Add support for optional data-lanes mapping
.../bindings/display/bridge/analogix,dp.yaml | 17 ++++--
.../rockchip/rockchip,analogix-dp.yaml | 1 +
.../drm/bridge/analogix/analogix_dp_core.c | 56 +++++++++++++++++++
.../drm/bridge/analogix/analogix_dp_core.h | 4 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 +++--
.../gpu/drm/bridge/analogix/analogix_dp_reg.h | 4 ++
6 files changed, 83 insertions(+), 14 deletions(-)
---
Changes in v2:
- Add lane mapping application scenarios in commit message.
- Remove redundant deprecated property 'data-lanes' for eDP node.
- Update port@1 $ref to /schemas/graph.yaml#/$defs/port-base.
--
2.34.1
^ 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