* [PATCH v16 07/10] LoongArch: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-1-ruanjinjie@huawei.com>
Use the newly introduced crash_prepare_headers() function to replace
the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
memory in the crash core, which reduce code duplication.
Only the following two architecture functions need to be implemented:
- arch_get_system_nr_ranges(). Use for_each_mem_range to traverse
and pre-count the max number of memory ranges.
- arch_crash_populate_cmem(). Use for_each_mem_range to traverse
and collect the memory ranges and fills them into cmem.
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Youling Tang <tangyouling@kylinos.cn>
Cc: Baoquan He <bhe@redhat.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/loongarch/kernel/machine_kexec_file.c | 40 +++++++---------------
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
index 5584b798ba46..5412aa9f3568 100644
--- a/arch/loongarch/kernel/machine_kexec_file.c
+++ b/arch/loongarch/kernel/machine_kexec_file.c
@@ -56,46 +56,30 @@ static void cmdline_add_initrd(struct kimage *image, unsigned long *cmdline_tmpl
}
#ifdef CONFIG_CRASH_DUMP
-
-static int prepare_elf_headers(void **addr, unsigned long *sz)
+unsigned int arch_get_system_nr_ranges(void)
{
- int ret, nr_ranges;
- uint64_t i;
+ int nr_ranges = 2; /* for exclusion of crashkernel region */
phys_addr_t start, end;
- struct crash_mem *cmem;
+ uint64_t i;
- nr_ranges = 2; /* for exclusion of crashkernel region */
for_each_mem_range(i, &start, &end)
nr_ranges++;
- cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
- if (!cmem)
- return -ENOMEM;
+ return nr_ranges;
+}
+
+int arch_crash_populate_cmem(struct crash_mem *cmem)
+{
+ phys_addr_t start, end;
+ uint64_t i;
- cmem->max_nr_ranges = nr_ranges;
- cmem->nr_ranges = 0;
for_each_mem_range(i, &start, &end) {
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
}
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (ret < 0)
- goto out;
-
- if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
- if (ret < 0)
- goto out;
- }
-
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
-
-out:
- kfree(cmem);
- return ret;
+ return 0;
}
/*
@@ -163,7 +147,7 @@ int load_other_segments(struct kimage *image,
void *headers;
unsigned long headers_sz;
- ret = prepare_elf_headers(&headers, &headers_sz);
+ ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
if (ret < 0) {
pr_err("Preparing elf core header failed\n");
goto out_err;
--
2.34.1
^ permalink raw reply related
* [PATCH v16 08/10] powerpc/kexec_file: Use crash_exclude_core_ranges() helper
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-1-ruanjinjie@huawei.com>
The crash memory exclude of crashk_res and crashk_cma memory on powerpc
are almost identical to the generic crash_exclude_core_ranges().
By introducing the architecture-specific arch_crash_exclude_mem_range()
function with a default implementation of crash_exclude_mem_range(),
and using crash_exclude_mem_range_guarded as powerpc's separate
implementation, the generic crash_exclude_core_ranges() helper function
can be reused.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/include/asm/kexec_ranges.h | 3 ---
arch/powerpc/kexec/crash.c | 2 +-
arch/powerpc/kexec/ranges.c | 16 ++++------------
include/linux/crash_core.h | 4 ++++
kernel/crash_core.c | 19 +++++++++++++------
5 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec_ranges.h b/arch/powerpc/include/asm/kexec_ranges.h
index ad95e3792d10..8489e844b447 100644
--- a/arch/powerpc/include/asm/kexec_ranges.h
+++ b/arch/powerpc/include/asm/kexec_ranges.h
@@ -7,9 +7,6 @@
void sort_memory_ranges(struct crash_mem *mrngs, bool merge);
struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges);
int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
-int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
- unsigned long long mstart,
- unsigned long long mend);
int get_exclude_memory_ranges(struct crash_mem **mem_ranges);
int get_reserved_memory_ranges(struct crash_mem **mem_ranges);
int get_crash_memory_ranges(struct crash_mem **mem_ranges);
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index 2e88ec5c4356..60a917a6beaa 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -513,7 +513,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
base_addr = PFN_PHYS(mn->start_pfn);
size = mn->nr_pages * PAGE_SIZE;
end = base_addr + size - 1;
- ret = crash_exclude_mem_range_guarded(&cmem, base_addr, end);
+ ret = arch_crash_exclude_mem_range(&cmem, base_addr, end);
if (ret) {
pr_err("Failed to remove hot-unplugged memory from crash memory ranges\n");
goto out;
diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
index 6c58bcc3e130..e5fea23b191b 100644
--- a/arch/powerpc/kexec/ranges.c
+++ b/arch/powerpc/kexec/ranges.c
@@ -553,9 +553,9 @@ int get_usable_memory_ranges(struct crash_mem **mem_ranges)
#endif /* CONFIG_KEXEC_FILE */
#ifdef CONFIG_CRASH_DUMP
-int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
- unsigned long long mstart,
- unsigned long long mend)
+int arch_crash_exclude_mem_range(struct crash_mem **mem_ranges,
+ unsigned long long mstart,
+ unsigned long long mend)
{
struct crash_mem *tmem = *mem_ranges;
@@ -604,18 +604,10 @@ int get_crash_memory_ranges(struct crash_mem **mem_ranges)
sort_memory_ranges(*mem_ranges, true);
}
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range_guarded(mem_ranges, crashk_res.start, crashk_res.end);
+ ret = crash_exclude_core_ranges(mem_ranges);
if (ret)
goto out;
- for (i = 0; i < crashk_cma_cnt; ++i) {
- ret = crash_exclude_mem_range_guarded(mem_ranges, crashk_cma_ranges[i].start,
- crashk_cma_ranges[i].end);
- if (ret)
- goto out;
- }
-
/*
* FIXME: For now, stay in parity with kexec-tools but if RTAS/OPAL
* regions are exported to save their context at the time of
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 583ffcc703d4..bc087124cd78 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -61,6 +61,7 @@ extern int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_ma
void **addr, unsigned long *sz);
extern int crash_prepare_headers(int need_kernel_map, void **addr,
unsigned long *sz, unsigned long *nr_mem_ranges);
+extern int crash_exclude_core_ranges(struct crash_mem **cmem);
struct kimage;
struct kexec_segment;
@@ -81,6 +82,9 @@ extern int kimage_crash_copy_vmcoreinfo(struct kimage *image);
extern unsigned int arch_get_system_nr_ranges(void);
extern int arch_crash_populate_cmem(struct crash_mem *cmem);
extern int arch_crash_exclude_ranges(struct crash_mem *cmem);
+extern int arch_crash_exclude_mem_range(struct crash_mem **mem,
+ unsigned long long mstart,
+ unsigned long long mend);
#else /* !CONFIG_CRASH_DUMP*/
struct pt_regs;
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 481babc29131..2b36aa9fade0 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -285,24 +285,31 @@ unsigned int __weak arch_get_system_nr_ranges(void) { return 0; }
int __weak arch_crash_populate_cmem(struct crash_mem *cmem) { return -1; }
int __weak arch_crash_exclude_ranges(struct crash_mem *cmem) { return 0; }
-static int crash_exclude_core_ranges(struct crash_mem *cmem)
+int __weak arch_crash_exclude_mem_range(struct crash_mem **mem,
+ unsigned long long mstart,
+ unsigned long long mend)
+{
+ return crash_exclude_mem_range(*mem, mstart, mend);
+}
+
+int crash_exclude_core_ranges(struct crash_mem **cmem)
{
int ret, i;
/* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
if (ret)
return ret;
if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
if (ret)
return ret;
}
for (i = 0; i < crashk_cma_cnt; ++i) {
- ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
- crashk_cma_ranges[i].end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
+ crashk_cma_ranges[i].end);
if (ret)
return ret;
}
@@ -329,7 +336,7 @@ int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
if (ret)
goto out;
- ret = crash_exclude_core_ranges(cmem);
+ ret = crash_exclude_core_ranges(&cmem);
if (ret)
goto out;
--
2.34.1
^ permalink raw reply related
* [PATCH v16 06/10] riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-1-ruanjinjie@huawei.com>
Use the newly introduced crash_prepare_headers() function to replace
the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
memory in the crash core, which reduce code duplication.
Only the following two architecture functions need to be implemented:
- arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
to pre-counts the max number of memory ranges.
- arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
to collects the memory ranges and fills them into cmem.
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Guo Ren <guoren@kernel.org>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/kernel/machine_kexec_file.c | 47 +++++++-------------------
1 file changed, 12 insertions(+), 35 deletions(-)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 3f7766057cac..439cbc50dfa6 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -44,6 +44,15 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
return 0;
}
+unsigned int arch_get_system_nr_ranges(void)
+{
+ unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
+
+ walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
+
+ return nr_ranges;
+}
+
static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
{
struct crash_mem *cmem = arg;
@@ -55,41 +64,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
return 0;
}
-static int prepare_elf_headers(void **addr, unsigned long *sz)
+int arch_crash_populate_cmem(struct crash_mem *cmem)
{
- struct crash_mem *cmem;
- unsigned int nr_ranges;
- int ret;
-
- nr_ranges = 2; /* For exclusion of crashkernel region */
- walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
-
- cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
- if (!cmem)
- return -ENOMEM;
-
- cmem->max_nr_ranges = nr_ranges;
- cmem->nr_ranges = 0;
- ret = walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
- if (ret)
- goto out;
-
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (ret)
- goto out;
-
- if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
- if (ret)
- goto out;
- }
-
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
-
-out:
- kfree(cmem);
- return ret;
+ return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
}
static char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
@@ -281,7 +258,7 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,
if (image->type == KEXEC_TYPE_CRASH) {
void *headers;
unsigned long headers_sz;
- ret = prepare_elf_headers(&headers, &headers_sz);
+ ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
if (ret) {
pr_err("Preparing elf core header failed\n");
goto out;
--
2.34.1
^ permalink raw reply related
* [PATCH v16 05/10] x86: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-1-ruanjinjie@huawei.com>
Use the newly introduced crash_prepare_headers() function to replace
the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
memory in the crash core, which reduce code duplication.
Only the following three architecture functions need to be implemented:
- arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
to pre-count the max number of memory ranges.
- arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
to collect the memory ranges and fills them into cmem.
- arch_crash_exclude_ranges(). Exclude the low 1M for x86.
By the way, remove the unused "nr_mem_ranges" in
arch_crash_handle_hotplug_event().
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/x86/kernel/crash.c | 89 +++++------------------------------------
1 file changed, 11 insertions(+), 78 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index cd796818d94d..cb2ce7acfec4 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -153,16 +153,8 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
return 0;
}
-/* Gather all the required information to prepare elf headers for ram regions */
-static struct crash_mem *fill_up_crash_elf_data(void)
+unsigned int arch_get_system_nr_ranges(void)
{
- unsigned int nr_ranges = 0;
- struct crash_mem *cmem;
-
- walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
- if (!nr_ranges)
- return NULL;
-
/*
* Exclusion of crash region, crashk_low_res and/or crashk_cma_ranges
* may cause range splits. So add extra slots here.
@@ -177,49 +169,16 @@ static struct crash_mem *fill_up_crash_elf_data(void)
* But in order to lest the low 1M could be changed in the future,
* (e.g. [start, 1M]), add a extra slot.
*/
- nr_ranges += 3 + crashk_cma_cnt;
- cmem = vzalloc(struct_size(cmem, ranges, nr_ranges));
- if (!cmem)
- return NULL;
-
- cmem->max_nr_ranges = nr_ranges;
+ unsigned int nr_ranges = 3 + crashk_cma_cnt;
- return cmem;
+ walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
+ return nr_ranges;
}
-/*
- * Look for any unwanted ranges between mstart, mend and remove them. This
- * might lead to split and split ranges are put in cmem->ranges[] array
- */
-static int elf_header_exclude_ranges(struct crash_mem *cmem)
+int arch_crash_exclude_ranges(struct crash_mem *cmem)
{
- int ret = 0;
- int i;
-
/* Exclude the low 1M because it is always reserved */
- ret = crash_exclude_mem_range(cmem, 0, SZ_1M - 1);
- if (ret)
- return ret;
-
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (ret)
- return ret;
-
- if (crashk_low_res.end)
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start,
- crashk_low_res.end);
- if (ret)
- return ret;
-
- for (i = 0; i < crashk_cma_cnt; ++i) {
- ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
- crashk_cma_ranges[i].end);
- if (ret)
- return ret;
- }
-
- return 0;
+ return crash_exclude_mem_range(cmem, 0, SZ_1M - 1);
}
static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
@@ -233,35 +192,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
return 0;
}
-/* Prepare elf headers. Return addr and size */
-static int prepare_elf_headers(void **addr, unsigned long *sz,
- unsigned long *nr_mem_ranges)
+int arch_crash_populate_cmem(struct crash_mem *cmem)
{
- struct crash_mem *cmem;
- int ret;
-
- cmem = fill_up_crash_elf_data();
- if (!cmem)
- return -ENOMEM;
-
- ret = walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
- if (ret)
- goto out;
-
- /* Exclude unwanted mem ranges */
- ret = elf_header_exclude_ranges(cmem);
- if (ret)
- goto out;
-
- /* Return the computed number of memory ranges, for hotplug usage */
- *nr_mem_ranges = cmem->nr_ranges;
-
- /* By default prepare 64bit headers */
- ret = crash_prepare_elf64_headers(cmem, IS_ENABLED(CONFIG_X86_64), addr, sz);
-
-out:
- vfree(cmem);
- return ret;
+ return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
}
#endif
@@ -419,7 +352,8 @@ int crash_load_segments(struct kimage *image)
.buf_max = ULONG_MAX, .top_down = false };
/* Prepare elf headers and add a segment */
- ret = prepare_elf_headers(&kbuf.buffer, &kbuf.bufsz, &pnum);
+ ret = crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &kbuf.buffer,
+ &kbuf.bufsz, &pnum);
if (ret)
return ret;
@@ -512,7 +446,6 @@ unsigned int arch_crash_get_elfcorehdr_size(void)
void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
{
void *elfbuf = NULL, *old_elfcorehdr;
- unsigned long nr_mem_ranges;
unsigned long mem, memsz;
unsigned long elfsz = 0;
@@ -530,7 +463,7 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
* Create the new elfcorehdr reflecting the changes to CPU and/or
* memory resources.
*/
- if (prepare_elf_headers(&elfbuf, &elfsz, &nr_mem_ranges)) {
+ if (crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz, NULL)) {
pr_err("unable to create new elfcorehdr");
goto out;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v16 04/10] arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-1-ruanjinjie@huawei.com>
Use the newly introduced crash_prepare_headers() function to replace
the existing prepare_elf_headers(), allocate cmem and exclude crash
kernel memory in the crash core, which reduce code duplication.
Only the following two architecture functions need to be implemented:
- arch_get_system_nr_ranges(). Use for_each_mem_range() to traverse
and pre-count the max number of memory ranges.
- arch_crash_populate_cmem(). Use for_each_mem_range to traverse
and collect the memory ranges and fills them into cmem.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/kernel/machine_kexec_file.c | 40 ++++++++------------------
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index e31fabed378a..b019b31df48c 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -40,46 +40,30 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
}
#ifdef CONFIG_CRASH_DUMP
-static int prepare_elf_headers(void **addr, unsigned long *sz)
+unsigned int arch_get_system_nr_ranges(void)
{
- struct crash_mem *cmem;
- unsigned int nr_ranges;
- int ret;
- u64 i;
+ unsigned int nr_ranges = 2; /* for exclusion of crashkernel region */
phys_addr_t start, end;
+ u64 i;
- nr_ranges = 2; /* for exclusion of crashkernel region */
for_each_mem_range(i, &start, &end)
nr_ranges++;
- cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
- if (!cmem)
- return -ENOMEM;
+ return nr_ranges;
+}
+
+int arch_crash_populate_cmem(struct crash_mem *cmem)
+{
+ phys_addr_t start, end;
+ u64 i;
- cmem->max_nr_ranges = nr_ranges;
- cmem->nr_ranges = 0;
for_each_mem_range(i, &start, &end) {
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
}
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (ret)
- goto out;
-
- if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
- if (ret)
- goto out;
- }
-
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
-
-out:
- kfree(cmem);
- return ret;
+ return 0;
}
#endif
@@ -109,7 +93,7 @@ int load_other_segments(struct kimage *image,
void *headers;
unsigned long headers_sz;
if (image->type == KEXEC_TYPE_CRASH) {
- ret = prepare_elf_headers(&headers, &headers_sz);
+ ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
if (ret) {
pr_err("Preparing elf core header failed\n");
goto out_err;
--
2.34.1
^ permalink raw reply related
* [PATCH v16 02/10] powerpc/crash: sort crash memory ranges before preparing elfcorehdr
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-1-ruanjinjie@huawei.com>
From: Sourabh Jain <sourabhjain@linux.ibm.com>
During a memory hot-remove event, the elfcorehdr is rebuilt to exclude
the removed memory. While updating the crash memory ranges for this
operation, the crash memory ranges array can become unsorted. This
happens because remove_mem_range() may split a memory range into two
parts and append the higher-address part as a separate range at the end
of the array.
So far, no issues have been observed due to the unsorted crash memory
ranges. However, this could lead to problems once crash memory range
removal is handled by generic code, as introduced in the upcoming
patches in this series.
Currently, powerpc uses a platform-specific function,
remove_mem_range(), to exclude hot-removed memory from the crash memory
ranges. This function performs the same task as the generic
crash_exclude_mem_range() in crash_core.c. The generic helper also
ensures that the crash memory ranges remain sorted. So remove the
redundant powerpc-specific implementation and instead call
crash_exclude_mem_range_guarded() (which internally calls
crash_exclude_mem_range()) to exclude the hot-removed memory ranges.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan he <bhe@redhat.com>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org
Acked-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/include/asm/kexec_ranges.h | 4 +-
arch/powerpc/kexec/crash.c | 5 +-
arch/powerpc/kexec/ranges.c | 87 +------------------------
3 files changed, 7 insertions(+), 89 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec_ranges.h b/arch/powerpc/include/asm/kexec_ranges.h
index 14055896cbcb..ad95e3792d10 100644
--- a/arch/powerpc/include/asm/kexec_ranges.h
+++ b/arch/powerpc/include/asm/kexec_ranges.h
@@ -7,7 +7,9 @@
void sort_memory_ranges(struct crash_mem *mrngs, bool merge);
struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges);
int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
-int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
+int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
+ unsigned long long mstart,
+ unsigned long long mend);
int get_exclude_memory_ranges(struct crash_mem **mem_ranges);
int get_reserved_memory_ranges(struct crash_mem **mem_ranges);
int get_crash_memory_ranges(struct crash_mem **mem_ranges);
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index e6539f213b3d..2e88ec5c4356 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -493,7 +493,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
struct crash_mem *cmem = NULL;
struct kexec_segment *ksegment;
void *ptr, *mem, *elfbuf = NULL;
- unsigned long elfsz, memsz, base_addr, size;
+ unsigned long elfsz, memsz, base_addr, size, end;
ksegment = &image->segment[image->elfcorehdr_index];
mem = (void *) ksegment->mem;
@@ -512,7 +512,8 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
if (image->hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY) {
base_addr = PFN_PHYS(mn->start_pfn);
size = mn->nr_pages * PAGE_SIZE;
- ret = remove_mem_range(&cmem, base_addr, size);
+ end = base_addr + size - 1;
+ ret = crash_exclude_mem_range_guarded(&cmem, base_addr, end);
if (ret) {
pr_err("Failed to remove hot-unplugged memory from crash memory ranges\n");
goto out;
diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
index 867135560e5c..6c58bcc3e130 100644
--- a/arch/powerpc/kexec/ranges.c
+++ b/arch/powerpc/kexec/ranges.c
@@ -553,7 +553,7 @@ int get_usable_memory_ranges(struct crash_mem **mem_ranges)
#endif /* CONFIG_KEXEC_FILE */
#ifdef CONFIG_CRASH_DUMP
-static int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
+int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
unsigned long long mstart,
unsigned long long mend)
{
@@ -641,89 +641,4 @@ int get_crash_memory_ranges(struct crash_mem **mem_ranges)
pr_err("Failed to setup crash memory ranges\n");
return ret;
}
-
-/**
- * remove_mem_range - Removes the given memory range from the range list.
- * @mem_ranges: Range list to remove the memory range to.
- * @base: Base address of the range to remove.
- * @size: Size of the memory range to remove.
- *
- * (Re)allocates memory, if needed.
- *
- * Returns 0 on success, negative errno on error.
- */
-int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size)
-{
- u64 end;
- int ret = 0;
- unsigned int i;
- u64 mstart, mend;
- struct crash_mem *mem_rngs = *mem_ranges;
-
- if (!size)
- return 0;
-
- /*
- * Memory range are stored as start and end address, use
- * the same format to do remove operation.
- */
- end = base + size - 1;
-
- for (i = 0; i < mem_rngs->nr_ranges; i++) {
- mstart = mem_rngs->ranges[i].start;
- mend = mem_rngs->ranges[i].end;
-
- /*
- * Memory range to remove is not part of this range entry
- * in the memory range list
- */
- if (!(base >= mstart && end <= mend))
- continue;
-
- /*
- * Memory range to remove is equivalent to this entry in the
- * memory range list. Remove the range entry from the list.
- */
- if (base == mstart && end == mend) {
- for (; i < mem_rngs->nr_ranges - 1; i++) {
- mem_rngs->ranges[i].start = mem_rngs->ranges[i+1].start;
- mem_rngs->ranges[i].end = mem_rngs->ranges[i+1].end;
- }
- mem_rngs->nr_ranges--;
- goto out;
- }
- /*
- * Start address of the memory range to remove and the
- * current memory range entry in the list is same. Just
- * move the start address of the current memory range
- * entry in the list to end + 1.
- */
- else if (base == mstart) {
- mem_rngs->ranges[i].start = end + 1;
- goto out;
- }
- /*
- * End address of the memory range to remove and the
- * current memory range entry in the list is same.
- * Just move the end address of the current memory
- * range entry in the list to base - 1.
- */
- else if (end == mend) {
- mem_rngs->ranges[i].end = base - 1;
- goto out;
- }
- /*
- * Memory range to remove is not at the edge of current
- * memory range entry. Split the current memory entry into
- * two half.
- */
- else {
- size = mem_rngs->ranges[i].end - end + 1;
- mem_rngs->ranges[i].end = base - 1;
- ret = add_mem_range(mem_ranges, end + 1, size);
- }
- }
-out:
- return ret;
-}
#endif /* CONFIG_CRASH_DUMP */
--
2.34.1
^ permalink raw reply related
* [PATCH v16 03/10] crash: Add crash_prepare_headers() to exclude crash kernel memory
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-1-ruanjinjie@huawei.com>
The crash memory alloc, and the exclude of crashk_res, crashk_low_res
and crashk_cma memory are almost identical across different architectures,
handling them in the crash core would eliminate a lot of duplication, so
add crash_prepare_headers() helper to handle them in the common code.
To achieve the above goal, three architecture-specific functions are
introduced:
- arch_get_system_nr_ranges(). Pre-counts the max number of memory ranges.
- arch_crash_populate_cmem(). Collects the memory ranges and fills them
into cmem.
- arch_crash_exclude_ranges(). Architecture's additional crash memory
ranges exclusion, defaulting to empty.
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
include/linux/crash_core.h | 5 +++
kernel/crash_core.c | 82 ++++++++++++++++++++++++++++++++++++--
2 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index c1dee3f971a9..583ffcc703d4 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -59,6 +59,8 @@ extern int crash_exclude_mem_range(struct crash_mem *mem,
unsigned long long mend);
extern int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
void **addr, unsigned long *sz);
+extern int crash_prepare_headers(int need_kernel_map, void **addr,
+ unsigned long *sz, unsigned long *nr_mem_ranges);
struct kimage;
struct kexec_segment;
@@ -76,6 +78,9 @@ int kexec_should_crash(struct task_struct *p);
int kexec_crash_loaded(void);
void crash_save_cpu(struct pt_regs *regs, int cpu);
extern int kimage_crash_copy_vmcoreinfo(struct kimage *image);
+extern unsigned int arch_get_system_nr_ranges(void);
+extern int arch_crash_populate_cmem(struct crash_mem *cmem);
+extern int arch_crash_exclude_ranges(struct crash_mem *cmem);
#else /* !CONFIG_CRASH_DUMP*/
struct pt_regs;
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 4f21fc3b108b..481babc29131 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -168,9 +168,6 @@ static inline resource_size_t crash_resource_size(const struct resource *res)
return !res->end ? 0 : resource_size(res);
}
-
-
-
int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
void **addr, unsigned long *sz)
{
@@ -272,6 +269,85 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
return 0;
}
+static struct crash_mem *alloc_cmem(unsigned int nr_ranges)
+{
+ struct crash_mem *cmem;
+
+ cmem = kvzalloc_flex(*cmem, ranges, nr_ranges);
+ if (!cmem)
+ return NULL;
+
+ cmem->max_nr_ranges = nr_ranges;
+ return cmem;
+}
+
+unsigned int __weak arch_get_system_nr_ranges(void) { return 0; }
+int __weak arch_crash_populate_cmem(struct crash_mem *cmem) { return -1; }
+int __weak arch_crash_exclude_ranges(struct crash_mem *cmem) { return 0; }
+
+static int crash_exclude_core_ranges(struct crash_mem *cmem)
+{
+ int ret, i;
+
+ /* Exclude crashkernel region */
+ ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
+ if (ret)
+ return ret;
+
+ if (crashk_low_res.end) {
+ ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ if (ret)
+ return ret;
+ }
+
+ for (i = 0; i < crashk_cma_cnt; ++i) {
+ ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
+ crashk_cma_ranges[i].end);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
+ unsigned long *nr_mem_ranges)
+{
+ unsigned int max_nr_ranges;
+ struct crash_mem *cmem;
+ int ret;
+
+ max_nr_ranges = arch_get_system_nr_ranges();
+ if (!max_nr_ranges)
+ return -ENOMEM;
+
+ cmem = alloc_cmem(max_nr_ranges);
+ if (!cmem)
+ return -ENOMEM;
+
+ ret = arch_crash_populate_cmem(cmem);
+ if (ret)
+ goto out;
+
+ ret = crash_exclude_core_ranges(cmem);
+ if (ret)
+ goto out;
+
+ ret = arch_crash_exclude_ranges(cmem);
+ if (ret)
+ goto out;
+
+ /* Return the computed number of memory ranges, for hotplug usage */
+ if (nr_mem_ranges)
+ *nr_mem_ranges = cmem->nr_ranges;
+
+ ret = crash_prepare_elf64_headers(cmem, need_kernel_map, addr, sz);
+
+out:
+ kvfree(cmem);
+ return ret;
+}
+
/**
* crash_exclude_mem_range - exclude a mem range for existing ranges
* @mem: mem->range contains an array of ranges sorted in ascending order
--
2.34.1
^ permalink raw reply related
* [PATCH v16 00/10] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
The crash memory allocation, and the exclude of crashk_res, crashk_low_res
and crashk_cma memory are almost identical across different architectures,
This patch set handle them in crash core in a general way, which eliminate
a lot of duplication code.
And add support for crashkernel CMA reservation for arm64 and riscv.
This patch set is rebased on v7.1-rc1.
Basic second kernel boot test were performed on QEMU platforms for x86,
ARM64 and RISC-V architectures with the following parameters:
"cma=256M crashkernel=4G crashkernel=64M,cma"
For first kernel, there will be such log:
# dmesg | grep crash
[ 0.000000] crashkernel low memory reserved: 0xe8000000 - 0xf0000000 (128 MB)
[ 0.000000] crashkernel reserved: 0x000000023e600000 - 0x000000033e600000 (4096 MB)
[ 0.000000] crashkernel CMA reserved: 64 MB in 1 ranges
# dmesg | grep cma
[ 0.000000] cma: Reserved 256 MiB at 0x00000000f0000000
[ 0.000000] cma: Reserved 64 MiB at 0x0000000100000000
For second kernel, there will be such log:
[ 0.000000] OF: fdt: Looking for usable-memory-range property...
[ 0.000000] OF: fdt: cap_mem_regions[0]: base=0x000000023e600000, size=0x0000000100000000
[ 0.000000] OF: fdt: cap_mem_regions[1]: base=0x00000000e8000000, size=0x0000000008000000
[ 0.000000] OF: fdt: cap_mem_regions[2]: base=0x0000000100000000, size=0x0000000004000000
Changes in v16:
- Split out the unrelated bugfixes as Baoquan suggested, which will
be a separate patch set later.
- Link to v15: https://lore.kernel.org/all/20260601094805.2928614-1-ruanjinjie@huawei.com/
Changes in v15:
- Unify the subject prefix formats as Huacai suggested.
- Fix powerpc pre-existing NULL pointer dereference [Sashiko [1]]
- Fix powerpc pre-existing __merge_memory_ranges() memory range
truncation [Sashiko [1]].
- Fix pre-existing arm64 CMA page leaks [Sashiko[2]].
- Fix pre-existing crash_load_dm_crypt_keys() Use-After-Free and
Double Free issue [Sashiko[3]].
- Fix vfree(headers) and uninitialized variables issue
and simplify the fix [Sashiko[2]].
- As walk_system_ram_res() and for_each_mem_range() use different
lock, unify and simplify the fix of TOCTOU buffer overflow via memory
region padding [Sashiko[4]].
- Fix the arm64 crash dump issues in Sashiko[5].
- Link to v14: https://lore.kernel.org/all/20260525084932.934910-1-ruanjinjie@huawei.com/
[1]: https://lore.kernel.org/all/20260525092207.96B9D1F000E9@smtp.kernel.org/
[2]: https://lore.kernel.org/all/20260525091149.1A1E01F00A3D@smtp.kernel.org/
[3]: https://lore.kernel.org/all/20260525105227.3C2421F000E9@smtp.kernel.org/
[4]: https://lore.kernel.org/all/20260525095447.944E11F000E9@smtp.kernel.org/
[5]: https://lore.kernel.org/all/20260525101746.9959D1F000E9@smtp.kernel.org/
Changes in v14:
- Fix image->elf_headers memory leak during retry loop for arm64 as Sashiko
AI code review pointed out.
- Solve the hotplug notifier arch_crash_handle_hotplug_event() AA
self-deadlock problem as Sashiko AI code review pointed out.
- Fix the TOCTOU issue in prepare_elf_headers() by get_online_mems().
- -ENOMEM -> -EAGAIN as Breno suggested.
- Add support for arm64 crash hotplug.
- Link to v13: https://lore.kernel.org/all/20260511030454.1730881-1-ruanjinjie@huawei.com/
Changes in v13:
- Rebased on v7.1-rc1.
- Update the commit message.
- Add Reviewed-by.
- Link to v12: https://lore.kernel.org/all/20260402072701.628293-1-ruanjinjie@huawei.com/
Changes in v12:
- Remove the unused "nr_mem_ranges" for x86.
- Add "Fix crashk_low_res not exclude bug" test log.
- Provide a separate patch for each architecture for using
crash_prepare_headers(), which will make the review more convenient.
- Add Reviewed-by and Tested-by.
- Link to v11: https://lore.kernel.org/all/20260328074013.3589544-1-ruanjinjie@huawei.com/
Changes in v11:
- Avoid silently drop crash memory if the crash kernel is built without
CONFIG_CMA.
- Remove unnecessary "cmem->nr_ranges = 0" for arch_crash_populate_cmem()
as we use kvzalloc().
- Provide a separate patch for each architecture to fix the existing
buffer overflow issue.
- Add Acked-bys for arm64.
Changes in v10:
- Fix crashk_low_res not excluded bug in the existing
RISC-V code.
- Fix an existing memory leak issue in the existing PowerPC code.
- Fix the ordering issue of adding CMA ranges to
"linux,usable-memory-range".
- Fix an existing concurrency issue. A Concurrent memory hotplug may occur
between reading memblock and attempting to fill cmem during kexec_load()
for almost all existing architectures.
- Link to v9: https://lore.kernel.org/all/20260323072745.2481719-1-ruanjinjie@huawei.com/
Changes in v9:
- Collect Reviewed-by and Acked-by, and prepare for Sashiko AI review.
- Link to v8: https://lore.kernel.org/all/20260302035315.3892241-1-ruanjinjie@huawei.com/
Changes in v8:
- Fix the build issues reported by kernel test robot and Sourabh.
- Link to v7: https://lore.kernel.org/all/20260226130437.1867658-1-ruanjinjie@huawei.com/
Changes in v7:
- Correct the inclusion of CMA-reserved ranges for kdump kernel in of/kexec
for arm64 and riscv.
- Add Acked-by.
- Link to v6: https://lore.kernel.org/all/20260224085342.387996-1-ruanjinjie@huawei.com/
Changes in v6:
- Update the crash core exclude code as Mike suggested.
- Rebased on v7.0-rc1.
- Add acked-by.
- Link to v5: https://lore.kernel.org/all/20260212101001.343158-1-ruanjinjie@huawei.com/
Jinjie Ruan (9):
riscv: kexec_file: Fix crashk_low_res not exclude bug
crash: Add crash_prepare_headers() to exclude crash kernel memory
arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
x86: kexec_file: Use crash_prepare_headers() helper to simplify code
riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
LoongArch: kexec_file: Use crash_prepare_headers() helper to simplify
code
powerpc/kexec_file: Use crash_exclude_core_ranges() helper
arm64: kexec_file: Add support for crashkernel CMA reservation
riscv: kexec_file: Add support for crashkernel CMA reservation
Sourabh Jain (1):
powerpc/crash: sort crash memory ranges before preparing elfcorehdr
.../admin-guide/kernel-parameters.txt | 16 +--
arch/arm64/kernel/machine_kexec_file.c | 40 +++----
arch/arm64/mm/init.c | 5 +-
arch/loongarch/kernel/machine_kexec_file.c | 40 +++----
arch/powerpc/include/asm/kexec_ranges.h | 1 -
arch/powerpc/kexec/crash.c | 5 +-
arch/powerpc/kexec/ranges.c | 101 +-----------------
arch/riscv/kernel/machine_kexec_file.c | 39 +++----
arch/riscv/mm/init.c | 5 +-
arch/x86/kernel/crash.c | 89 ++-------------
drivers/of/fdt.c | 9 +-
drivers/of/kexec.c | 9 ++
include/linux/crash_core.h | 9 ++
include/linux/crash_reserve.h | 4 +-
kernel/crash_core.c | 89 ++++++++++++++-
15 files changed, 180 insertions(+), 281 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v16 01/10] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Jinjie Ruan @ 2026-06-08 7:34 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
ruanjinjie, leitao, coxu, Liam.Howlett, ryan.roberts, osandov,
jbohac, cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-1-ruanjinjie@huawei.com>
As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
riscv should have excluded the "crashk_low_res" reserved ranges from
the crash kernel memory to prevent them from being exported through
/proc/vmcore, and the exclusion would need an extra crash_mem range.
Just simply tested on qemu with crashkernel=4G with kexec in [1] mentioned
in [2]. And the second kernel can be started normally.
# dmesg | grep crash
[ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB)
[ 0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe00000 (4096 MB)
Cc: Guo Ren <guoren@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
[1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
[2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/
Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
Reviewed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 54e2d9552e93..3f7766057cac 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
unsigned int nr_ranges;
int ret;
- nr_ranges = 1; /* For exclusion of crashkernel region */
+ nr_ranges = 2; /* For exclusion of crashkernel region */
walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
@@ -76,8 +76,16 @@ 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 = crash_prepare_elf64_headers(cmem, true, addr, sz);
+ if (ret)
+ goto out;
+
+ if (crashk_low_res.end) {
+ ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ if (ret)
+ goto out;
+ }
+
+ ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
out:
kfree(cmem);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 5/5] arm64: dts: qcom: Add GP M/N clock controller node for SA8775P and QCS8300
From: Luca Weiss @ 2026-06-08 7:33 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Richard Cochran, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-gpio, netdev
In-Reply-To: <20260602-pdm_clk_gp_mnd_v1-v1-5-1522662b6c53@oss.qualcomm.com>
On Tue Jun 2, 2026 at 5:21 PM CEST, Taniya Das wrote:
> Add the GP M/N divider clock controller node at 0x088d3000 to the
> SA8775P (kodiak, lemans) and QCS8300 (monaco) SoC device trees.
forgot this in the previous email, another kodiak==sc7280
Regards
Luca
>
> The node uses the qcom,clk-gp-mnd compatible, is clocked by the PDM
> XO4 and AHB clocks from GCC, and exposes a single clock output
> (gp_mn_clk) on the dedicated gp_mn pin mux function. The XO4 clock
> is pre-assigned to 4.8 MHz (XO/4).
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: qcom: Add GP M/N clock controller node for SA8775P and QCS8300
From: Luca Weiss @ 2026-06-08 7:32 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Richard Cochran, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-gpio, netdev
In-Reply-To: <20260602-pdm_clk_gp_mnd_v1-v1-5-1522662b6c53@oss.qualcomm.com>
Hi Taniya,
On Tue Jun 2, 2026 at 5:21 PM CEST, Taniya Das wrote:
> Add the GP M/N divider clock controller node at 0x088d3000 to the
> SA8775P (kodiak, lemans) and QCS8300 (monaco) SoC device trees.
>
> The node uses the qcom,clk-gp-mnd compatible, is clocked by the PDM
> XO4 and AHB clocks from GCC, and exposes a single clock output
> (gp_mn_clk) on the dedicated gp_mn pin mux function. The XO4 clock
> is pre-assigned to 4.8 MHz (XO/4).
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 14 ++++++++++++++
> arch/arm64/boot/dts/qcom/lemans.dtsi | 14 ++++++++++++++
> arch/arm64/boot/dts/qcom/monaco.dtsi | 14 ++++++++++++++
> 3 files changed, 42 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 1ff9e1598d00429c03b2bcae41fa370ab2c892bd..cbc13ac37f8aeb0b1071ad0609ec11e829d2c798 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -4412,6 +4412,20 @@ usb2_role_switch: endpoint {
> };
> };
>
> + gp_mn: clock-controller@88d3000 {
> + compatible = "qcom,clk-gp-mnd";
> + reg = <0x0 0x088d3000 0x0 0xc>;
> + clocks = <&gcc GCC_PDM_XO4_CLK>,
> + <&gcc GCC_PDM_AHB_CLK>;
> + clock-names = "pdm_clk", "ahb_clk";
> + clock-output-names = "gp_mn_clk";
> + #clock-cells = <0>;
> + pinctrl-names = "active";
> + pinctrl-0 = <&gp_mn_active>;
> + assigned-clocks = <&gcc GCC_PDM_XO4_CLK>;
> + assigned-clock-rates = <4800000>;
> + };
Am I missing something, or would this just configure gpio60 for all
boards for this clock controller output? On QCM6490 Fairphone 5 this pin
is connected to FP_3P3_EN, so it's definitely not unused.
Maybe disable them by default and let the board enable it, if it wants
to make use of this clock?
Regards
Luca
> +
> qspi: spi@88dc000 {
> compatible = "qcom,sc7280-qspi", "qcom,qspi-v1";
> reg = <0 0x088dc000 0 0x1000>;
> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 19f8cf4e15482947f6049188050c370340afaead..d192f92a896bb13017abdf82062e8305aab3e5d5 100644
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
> @@ -4353,6 +4353,20 @@ opp-384000000 {
> };
> };
>
> + gp_mn: clock-controller@88d3000 {
> + compatible = "qcom,clk-gp-mnd";
> + reg = <0x0 0x088d3000 0x0 0xc>;
> + clocks = <&gcc GCC_PDM_XO4_CLK>,
> + <&gcc GCC_PDM_AHB_CLK>;
> + clock-names = "pdm_clk", "ahb_clk";
> + clock-output-names = "gp_mn_clk";
> + #clock-cells = <0>;
> + pinctrl-names = "active";
> + pinctrl-0 = <&gp_mn_active>;
> + assigned-clocks = <&gcc GCC_PDM_XO4_CLK>;
> + assigned-clock-rates = <4800000>;
> + };
> +
> usb_0_hsphy: phy@88e4000 {
> compatible = "qcom,sa8775p-usb-hs-phy",
> "qcom,usb-snps-hs-5nm-phy";
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index ebe5889daa5300efa7857314e9170d7d2fc33ef7..f6c5ec38c7491b7a16ebfb853f8af88bdf1f0db3 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -4867,6 +4867,20 @@ opp-384000000 {
> };
> };
>
> + gp_mn: clock-controller@88d3000 {
> + compatible = "qcom,clk-gp-mnd";
> + reg = <0x0 0x088d3000 0x0 0xc>;
> + clocks = <&gcc GCC_PDM_XO4_CLK>,
> + <&gcc GCC_PDM_AHB_CLK>;
> + clock-names = "pdm_clk", "ahb_clk";
> + clock-output-names = "gp_mn_clk";
> + #clock-cells = <0>;
> + pinctrl-names = "active";
> + pinctrl-0 = <&gp_mn_active>;
> + assigned-clocks = <&gcc GCC_PDM_XO4_CLK>;
> + assigned-clock-rates = <4800000>;
> + };
> +
> usb_1_hsphy: phy@8904000 {
> compatible = "qcom,qcs8300-usb-hs-phy",
> "qcom,usb-snps-hs-7nm-phy";
^ permalink raw reply
* Re: [PATCH net-next v4 16/16] Documentation: networking: Add timestamp related APIs to OA TC6 framework
From: Andrew Lunn @ 2026-06-08 7:22 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: Randy Dunlap, Piergiorgio Beruto, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, Parthiban Veerasooran, Richard Cochran, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Simon Horman, Jonathan Corbet,
Shuah Khan, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerry Ray
In-Reply-To: <DM4PR02MB9263A6240C8D09E368B6F980831C2@DM4PR02MB9263.namprd02.prod.outlook.com>
On Mon, Jun 08, 2026 at 05:10:23AM +0000, Selvamani Rajagopal wrote:
>
> > Subject: RE: [PATCH net-next v4 16/16] Documentation: networking: Add timestamp
> > related APIs to OA TC6 framework
> >
> > >
> > > Hi,
> > > These needs a few additional blank lines to avoid docs build warnings:
> >
> > Will do. My bad that I didn't verify with make htmldocs after editing the file.
> >
> > >
> > > Documentation/networking/oa-tc6-framework.rst:554: WARNING: Explicit markup ends
> > > without a blank line; unexpected unindent. [docutils]
> > > Documentation/networking/oa-tc6-framework.rst:561: WARNING: Explicit markup ends
> > > without a blank line; unexpected unindent. [docutils]
> > > Documentation/networking/oa-tc6-framework.rst:566: WARNING: Explicit markup ends
> > > without a blank line; unexpected unindent. [docutils]
> > > Documentation/networking/oa-tc6-framework.rst:573: WARNING: Explicit markup ends
> > > without a blank line; unexpected unindent. [docutils]
> > >
>
> Randy,
>
> Though I fixed the issues you pointed out, I couldn't reproduce this issue with either "make htmldocs"
> or with "sphinx-build" commands.
>
> Am I missing something with respect to how document generation/verification is done?
Try
files=$(git show --pretty="" --name-only HEAD)
./scripts/kernel-doc -Wall -none $files
This is what the CI system does.
Andrew
^ permalink raw reply
* Re: [PATCH 4/5] arm64: dts: qcom: Add gp_mn pin state for GP M/N clock output
From: Luca Weiss @ 2026-06-08 7:22 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Richard Cochran, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-gpio, netdev
In-Reply-To: <20260602-pdm_clk_gp_mnd_v1-v1-4-1522662b6c53@oss.qualcomm.com>
On Tue Jun 2, 2026 at 5:21 PM CEST, Taniya Das wrote:
> Add pinctrl states for the GP M/N divider clock output pin across
> multiple Qualcomm SoCs:
>
> wire it to the GP M/N clock controller node via pinctrl-0.
> - kodiak (sa8775p): Add gp_mn_active state on gpio35 (gp_mn function).
kodiak (sc7280) - this should be gpio60?
> - lemans (sa8775p): Add gp_mn_active state on gpio35 (gp_mn function).
> - monaco (qcs8300): Add gp_mn_active state on gpio32 (gp_mn function).
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 7 +++++++
> arch/arm64/boot/dts/qcom/lemans.dtsi | 7 +++++++
> arch/arm64/boot/dts/qcom/monaco.dtsi | 7 +++++++
> 3 files changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index fa540d8c2615dc02d941eb16bc7253204c2750bd..1ff9e1598d00429c03b2bcae41fa370ab2c892bd 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5908,6 +5908,13 @@ edp_hot_plug_det: edp-hot-plug-det-state {
> function = "edp_hot";
> };
>
> + gp_mn_active: gp_mn_active-state {
> + pins = "gpio35";
gpio60?
I still find it incredible that the QCM6490 datasheet (80-20659-1 Rev.
AJ) doesn't even mention this functionality on GPIO_60.. I wonder what
else is hidden on these SoCs.
Regards
Luca
> + function = "gp_mn";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> mi2s0_data0: mi2s0-data0-state {
> pins = "gpio98";
> function = "mi2s0_data0";
> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 353a6e6fd3acb22ef228bee340212b8b2c300957..19f8cf4e15482947f6049188050c370340afaead 100644
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
> @@ -6022,6 +6022,13 @@ dp1_hot_plug_det: dp1-hot-plug-det-state {
> bias-disable;
> };
>
> + gp_mn_active: gp_mn_active-state {
> + pins = "gpio35";
> + function = "gp_mn";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> hs0_mi2s_active: hs0-mi2s-active-state {
> pins = "gpio114", "gpio115", "gpio116", "gpio117";
> function = "hs0_mi2s";
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index e4c8466f941bdba04f99b988fd7bf5afd926b31d..ebe5889daa5300efa7857314e9170d7d2fc33ef7 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -6433,6 +6433,13 @@ dp_hot_plug_det: dp-hot-plug-det-state {
> bias-disable;
> };
>
> + gp_mn_active: gp_mn_active-state {
> + pins = "gpio32";
> + function = "gp_mn";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> hs0_mi2s_active: hs0-mi2s-active-state {
> pins = "gpio106", "gpio107", "gpio108", "gpio109";
> function = "hs0_mi2s";
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: display: msm: qcm2290: Add Shikra MDSS
From: Dmitry Baryshkov @ 2026-06-08 7:19 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260608-shikra-display-v4-1-88a846afdd5d@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 12:31:42PM +0530, Nabige Aala wrote:
> Shikra reuses the same MDSS/DPU 6.5 hardware as QCM2290. Extend
> the existing qcm2290 bindings to cover Shikra by adding fallback
> compatible chains for MDSS, DPU and DSI controller nodes rather
> than introducing a separate binding file.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> .../bindings/display/msm/dsi-controller-main.yaml | 4 ++++
> .../bindings/display/msm/qcom,qcm2290-dpu.yaml | 6 +++++-
> .../bindings/display/msm/qcom,qcm2290-mdss.yaml | 19 ++++++++++++-------
> 3 files changed, 21 insertions(+), 8 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low, level triggered
From: Andrew Lunn @ 2026-06-08 7:15 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: Parthiban.Veerasooran@microchip.com, conor@kernel.org,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, Piergiorgio Beruto,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Conor.Dooley@microchip.com, devicetree@vger.kernel.org
In-Reply-To: <DM4PR02MB926317F64B5A3827009B66A9831C2@DM4PR02MB9263.namprd02.prod.outlook.com>
> I agree. When we change to level triggered interrupt, current mechanism won't work as
> we are not disabling the interrupt when we handle them.
I'm kind of surprised about that. If you only provide a thread context
handler, but not a interrupt context handler, i would of expected the
IRQ core to leave the interrupt disabled until the threaded handler
exited. But maybe it is historic behaviour.
Andrew
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: display: msm: qcm2290: Add Shikra MDSS
From: sashiko-bot @ 2026-06-08 7:13 UTC (permalink / raw)
To: Nabige Aala; +Cc: dri-devel, robh, devicetree, conor+dt
In-Reply-To: <20260608-shikra-display-v4-1-88a846afdd5d@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The compatible string `qcom,qcm2290-dsi-ctrl` (and the newly added `qcom,shikra-dsi-ctrl` fallback) is missing from the conditional `if-then` constraint blocks in `dsi-controller-main.yaml`, preventing strict validation.
--
commit 605ca9e1f594a8d64bb53c70c6ef6319fc95eeed
Author: Nabige Aala <nabige.aala@oss.qualcomm.com>
dt-bindings: display: msm: qcm2290: Add Shikra MDSS
Shikra reuses the same MDSS/DPU 6.5 hardware as QCM2290. Extend
the existing qcm2290 bindings to cover Shikra by adding fallback
compatible chains for MDSS, DPU and DSI controller nodes rather
than introducing a separate binding file.
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> index a24fcb9144181..08a6668d3ca78 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> @@ -46,6 +46,10 @@ properties:
> - qcom,sm8650-dsi-ctrl
> - qcom,sm8750-dsi-ctrl
> - const: qcom,mdss-dsi-ctrl
> + - items:
> + - const: qcom,shikra-dsi-ctrl
> + - const: qcom,qcm2290-dsi-ctrl
> + - const: qcom,mdss-dsi-ctrl
[Severity: Medium]
Should qcom,shikra-dsi-ctrl and qcom,qcm2290-dsi-ctrl be added to the
conditional constraint blocks lower down in this file?
Because they are omitted from the conditional blocks governing 6-clock setups,
the schema falls back to permissive defaults (3 to 12 clocks). This allows
incomplete or invalid device tree nodes for Shikra to silently pass validation.
While the missing qcom,qcm2290-dsi-ctrl constraint was a pre-existing issue,
adding the new qcom,shikra-dsi-ctrl compatible without ensuring it has strict
validation introduces this permissive validation bug for the new platform.
The block enforcing these strict limits starts like this:
- if:
properties:
compatible:
contains:
enum:
- qcom,msm8998-dsi-ctrl
- qcom,sa8775p-dsi-ctrl
- qcom,sar2130p-dsi-ctrl
> - items:
> - enum:
> - qcom,qcs8300-dsi-ctrl
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-shikra-display-v4-0-88a846afdd5d@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v2 1/7] PCI: qcom: fix parsing of PERST# in the legacy case
From: sashiko-bot @ 2026-06-08 7:13 UTC (permalink / raw)
To: Dmitry Baryshkov; +Cc: devicetree, robh, linux-pci, conor+dt
In-Reply-To: <20260608-sm8350-wifi-v2-1-efb68f1ff04c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Direct return on `devm_gpiod_get_optional` failure in `qcom_pcie_probe` bypasses `pm_runtime` cleanup.
--
commit a1eb87e2fab2443f5d8889e3755038df391d4632
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
PCI: qcom: fix parsing of PERST# in the legacy case
This commit moves the parsing of the RC's perst-gpios into qcom_pcie_probe()
to share it between mixed and legacy platforms. This prevents -EBUSY errors
when acquiring the PERST# GPIO in legacy cases.
Link: https://lore.kernel.org/r/gieaybsg2ckxpctvqj77nlwu7utama2yeyvebkonmexsxrra3v@v3fobqasxnmy/
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 11fc604898926..7664c7c28c0e3 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
[ ... ]
> @@ -2107,6 +2093,15 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>
> pp->ops = &qcom_pcie_dw_ops;
>
> + if (of_find_property(dev->of_node, "perst-gpios", NULL)) {
> + pcie->reset = devm_gpiod_get_optional(dev, "perst",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(pcie->reset))
> + return PTR_ERR(pcie->reset);
[Severity: High]
Does this direct return leak the runtime PM usage count?
Earlier in qcom_pcie_probe(), pm_runtime_get_sync() is called to increment
the PM usage count. If devm_gpiod_get_optional() fails here, returning
directly bypasses the err_pm_runtime_put cleanup path, which leaves runtime
PM enabled and causes an unbalanced count.
Should this be setting ret = PTR_ERR(pcie->reset) and jumping to
err_pm_runtime_put instead?
> +
> + dev_warn(dev, "Reusing PERST# from Root Complex node. DT needs to be updated!\n");
> + }
> +
> ret = qcom_pcie_parse_ports(pcie);
> if (ret) {
> if (ret != -ENODEV) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-sm8350-wifi-v2-0-efb68f1ff04c@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v2 2/7] wifi: ath11k: enable support for WCN6851
From: sashiko-bot @ 2026-06-08 7:08 UTC (permalink / raw)
To: Dmitry Baryshkov; +Cc: conor+dt, devicetree, robh, linux-pci
In-Reply-To: <20260608-sm8350-wifi-v2-2-efb68f1ff04c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added WCN6855 hw1.1 support is missing a corresponding MODULE_FIRMWARE() declaration in pci.c.
--
commit f54482207008ed0cfb8ad9e52b108a170f4c03af
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
wifi: ath11k: enable support for WCN6851
The WCN6851, found e.g. on SM8350 platforms, is an earlier version of
WCN6855 platform. It identifies itself as hw1.1. Copy WCN6855 hw 2.0
configuration to support hw1.1 version.
> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> index 8dacc878c0068..78a226ca081c7 100644
> --- a/drivers/net/wireless/ath/ath11k/core.c
> +++ b/drivers/net/wireless/ath/ath11k/core.c
> @@ -393,6 +393,98 @@ static const struct ath11k_hw_params ath11k_hw_params[] = {
> .cfr_num_stream_bufs = 0,
> .cfr_stream_buf_size = 0,
> },
> + {
> + .name = "wcn6855 hw1.1",
> + .hw_rev = ATH11K_HW_WCN6855_HW11,
> + .fw = {
> + .dir = "WCN6855/hw1.1",
[Severity: Medium]
Since this adds a new firmware directory for hw1.1, should there be a
corresponding MODULE_FIRMWARE(ATH11K_FW_DIR "/WCN6855/hw1.1/*") declaration
added to drivers/net/wireless/ath/ath11k/pci.c alongside the existing
entries for hw2.0 and hw2.1?
Missing this might cause tools like modinfo or dracut to not recognize the
dependency, potentially leaving the firmware out of the initramfs.
> + .board_size = 256 * 1024,
> + .cal_offset = 128 * 1024,
> + },
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-sm8350-wifi-v2-0-efb68f1ff04c@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH 08/23] driver core: platform: provide platform_device_set_of_node_from_dev()
From: Johan Hovold @ 2026-06-08 7:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Lee Jones, Mark Brown, Thierry Reding,
Sebastian Hesselbarth, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Srinivas Kandagatla,
Greg Kroah-Hartman, Vinod Koul, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <aiLi0KZskrCyEYO5@ashevche-desk.local>
On Fri, Jun 05, 2026 at 05:53:04PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 05, 2026 at 02:16:17PM +0200, Johan Hovold wrote:
> > On Wed, Jun 03, 2026 at 12:44:55AM +0300, Andy Shevchenko wrote:
> > > On Thu, May 21, 2026 at 10:36:31AM +0200, Bartosz Golaszewski wrote:
> > > > Provide a platform-specific variant of device_set_of_node_from_dev(). In
> > > > addition to bumping the reference count of the OF node being assigned,
> > > > it also assigns the fwnode of the platform device.
> > >
> > > Can we rather investigate the way how to make that of node reuse thingy
> > > (which is used solely by pin control) differently and then drop this confusing
> > > device_set_of_node_from_dev() call altogether?
> >
> > No, that call is needed. See commit 4e75e1d7dac9 ("driver core: add
> > helper to reuse a device-tree node") for details.
>
> Bart fixes the problem with the platform driver. At the result this will be
> the only device_set_node() + 'reused = true'. As for 'reused' flag, the need
> is only for pinmux/pin control stuff.
And any other resource which may (eventually) be claimed by driver core
or bus code.
> The question here is if there is a better
> way to make that 'reused' be done automatically without need of setting some
> flag explicitly.
That's not really relevant to the series at hand.
If this is something we want to merge then you need to continue setting
the flag in order not to cause regressions.
Johan
^ permalink raw reply
* Re: [PATCH v7 2/2] media: i2c: add Aptina MT9M113 1.3 Mpx SoC sensor driver
From: Krzysztof Kozlowski @ 2026-06-08 7:02 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, linux-media, devicetree, linux-kernel
In-Reply-To: <20260607-submit-media-mt9m113-v7-2-5da397a3d2a5@herrie.org>
On Sun, Jun 07, 2026 at 07:34:05AM +0200, Herman van Hazendonk wrote:
> Add a V4L2 subdev driver for the Aptina MT9M113 1.3 Megapixel SoC
> image sensor (1280x1024 active pixel array) with on-chip ISP. The
> sensor exposes:
>
> - dual context operation: Context A (640x480 preview, binned) and
> Context B (1280x1024 capture) selectable at runtime;
> - single-lane MIPI CSI-2 output, YUV422 in UYVY or YUYV byte order
> (the byte order is selected via the chroma/luma swap bit in
> MODE_OUTPUT_FORMAT_{A,B});
> - I2C MCU-indirect register access through the 0x098C/0x0990 page
> indirection pair, in addition to the directly addressable
> register space;
> - V4L2 controls: H/V flip, color effects (none / mono / sepia /
> negative / solarization), power-line frequency, saturation,
> manual or auto exposure, analog gain, auto white balance, and
> a four-entry test pattern selector;
> - a 24 MHz EXTCLK and 1.8/2.8 V supplies.
>
> The MT9M113 MCU intermittently wedges on stream start (SEQ_CMD
> stuck, SEQ_STATE never reaching preview/capture; only a full power
> cycle recovers it). The driver works around this in two layers:
> runtime-PM resume always performs a full power-cycle plus init-table
> replay - matching the legacy vendor kernel's per-open behaviour -
> so a wedged MCU is recovered each session; and the s_stream(1) path
> retries a bounded number of times with a runtime-PM power cycle
> between attempts as fallback insurance for the residual failure
> rate.
>
> Found on the HP TouchPad (Tenderloin) as the front-facing camera
> and on a number of other 1280x1024 mobile/embedded boards.
>
> Assisted-by: Claude:claude-opus-4-7 Sashiko:claude-haiku-4-5 Sparse:0.6.4 Coccinelle:1.1.1
> Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
> ---
> .../bindings/media/i2c/aptina,mt9m113.yaml | 8 +
> MAINTAINERS | 8 +
> drivers/media/i2c/Kconfig | 13 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/mt9m113.c | 3394 ++++++++++++++++++++
> 5 files changed, 3424 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9m113.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9m113.yaml
> index 72b827c47b1d..cfd6711e8250 100644
> --- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9m113.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9m113.yaml
> @@ -70,6 +70,14 @@ properties:
> const: 4
> description: MIPI CSI-2 D-PHY
>
> + data-lanes:
> + description:
> + The MT9M113 has a single CSI-2 data lane. Reject DT entries
> + that try to assign more than one lane so a misconfiguration
> + is caught at schema-validation time rather than at runtime
> + when the driver enforces num_data_lanes == 1.
> + maxItems: 1
> +
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: media: i2c: add aptina,mt9m113
From: Krzysztof Kozlowski @ 2026-06-08 7:02 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, linux-media, devicetree, linux-kernel
In-Reply-To: <20260607-submit-media-mt9m113-v7-1-5da397a3d2a5@herrie.org>
On Sun, Jun 07, 2026 at 07:34:04AM +0200, Herman van Hazendonk wrote:
> Add the binding for the Aptina (now ON Semiconductor) MT9M113 1.3
> megapixel SoC image sensor with on-die ISP. The chip is used as the
> front (user-facing) camera on the HP TouchPad tablet and connects
> to the host SoC over MIPI CSI-2.
>
> The binding describes the chip's i2c address, optional reset and
> standby GPIOs, the per-supply regulators (VDD, VDD_IO, VDDA), the
> external clock input, and the CSI-2 endpoint pads exposed via the
> "port" subnode.
>
> Assisted-by: Claude:claude-opus-4-7 Sashiko:claude-haiku-4-5 Sparse:0.6.4 Coccinelle:1.1.1
> Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
> ---
> .../bindings/media/i2c/aptina,mt9m113.yaml | 122 +++++++++++++++++++++
> 1 file changed, 122 insertions(+)
>
Please slow down your submissions. One patchset per 24h.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 2/2] soc: qcom: ubwc: Add Shikra UBWC config
From: Nabige Aala @ 2026-06-08 7:01 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD)
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
iommu, linux-arm-kernel, Nabige Aala, Dmitry Baryshkov
In-Reply-To: <20260608-shikra-display-v4-0-88a846afdd5d@oss.qualcomm.com>
Add UBWC configuration for the Shikra platform. Shikra shares the
same hardware as QCM2290 (Agatti), so reuse qcm2290_data for the
UBWC settings
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
---
drivers/soc/qcom/ubwc_config.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/qcom/ubwc_config.c b/drivers/soc/qcom/ubwc_config.c
index 3fe47d8f0f63..1a2e54c6480d 100644
--- a/drivers/soc/qcom/ubwc_config.c
+++ b/drivers/soc/qcom/ubwc_config.c
@@ -278,6 +278,7 @@ static const struct of_device_id qcom_ubwc_configs[] __maybe_unused = {
{ .compatible = "qcom,sdm660", .data = &msm8937_data },
{ .compatible = "qcom,sdm670", .data = &sdm670_data, },
{ .compatible = "qcom,sdm845", .data = &sdm845_data, },
+ { .compatible = "qcom,shikra", .data = &qcm2290_data, },
{ .compatible = "qcom,sm4250", .data = &sm6115_data, },
{ .compatible = "qcom,sm6115", .data = &sm6115_data, },
{ .compatible = "qcom,sm6125", .data = &sm6125_data, },
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: display: msm: qcm2290: Add Shikra MDSS
From: Nabige Aala @ 2026-06-08 7:01 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD)
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
iommu, linux-arm-kernel, Nabige Aala
In-Reply-To: <20260608-shikra-display-v4-0-88a846afdd5d@oss.qualcomm.com>
Shikra reuses the same MDSS/DPU 6.5 hardware as QCM2290. Extend
the existing qcm2290 bindings to cover Shikra by adding fallback
compatible chains for MDSS, DPU and DSI controller nodes rather
than introducing a separate binding file.
Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
---
.../bindings/display/msm/dsi-controller-main.yaml | 4 ++++
.../bindings/display/msm/qcom,qcm2290-dpu.yaml | 6 +++++-
.../bindings/display/msm/qcom,qcm2290-mdss.yaml | 19 ++++++++++++-------
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index dbc0613e427e..fd0834d09ad6 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -47,6 +47,10 @@ properties:
- qcom,sm8650-dsi-ctrl
- qcom,sm8750-dsi-ctrl
- const: qcom,mdss-dsi-ctrl
+ - items:
+ - const: qcom,shikra-dsi-ctrl
+ - const: qcom,qcm2290-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
- items:
- enum:
- qcom,qcs8300-dsi-ctrl
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
index be6cd8adb3b6..034d3df8d247 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
@@ -13,7 +13,11 @@ $ref: /schemas/display/msm/dpu-common.yaml#
properties:
compatible:
- const: qcom,qcm2290-dpu
+ oneOf:
+ - const: qcom,qcm2290-dpu
+ - items:
+ - const: qcom,shikra-dpu
+ - const: qcom,qcm2290-dpu
reg:
items:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
index bb09ecd1a5b4..49a7b5c4c678 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-mdss.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm QCM220 Display MDSS
+title: Qualcomm QCM2290 and Shikra Display MDSS
maintainers:
- Loic Poulain <loic.poulain@linaro.org>
@@ -12,13 +12,18 @@ maintainers:
description:
Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS
- are mentioned for QCM2290 target.
+ are mentioned for QCM2290 and Shikra targets. Shikra uses the same MDSS/DPU/DSI
+ hardware as QCM2290 (DPU 6.5) and shares the same register layout.
$ref: /schemas/display/msm/mdss-common.yaml#
properties:
compatible:
- const: qcom,qcm2290-mdss
+ oneOf:
+ - const: qcom,qcm2290-mdss
+ - items:
+ - const: qcom,shikra-mdss
+ - const: qcom,qcm2290-mdss
clocks:
items:
@@ -52,7 +57,8 @@ patternProperties:
properties:
compatible:
- const: qcom,qcm2290-dpu
+ contains:
+ const: qcom,qcm2290-dpu
"^dsi@[0-9a-f]+$":
type: object
@@ -60,9 +66,8 @@ patternProperties:
properties:
compatible:
- items:
- - const: qcom,qcm2290-dsi-ctrl
- - const: qcom,mdss-dsi-ctrl
+ contains:
+ const: qcom,qcm2290-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/2] Add Shikra (QCM2390) display support
From: Nabige Aala @ 2026-06-08 7:01 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD)
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
iommu, linux-arm-kernel, Nabige Aala, Dmitry Baryshkov
Shikra (QCM2390) is a Qualcomm SoC based on the QCM2290 family that
reuses the same MDSS/DPU 6.5 hardware as QCM2290. This series enables
the display subsystem for Shikra by adding DT binding updates for MDSS,
DSI controller and DPU and UBWC configuration mapping Shikra to
qcm2290_data.
Driver and SMMU support are covered by the existing qcom,qcm2290-mdss
fallback compatible string — no separate drm/msm or IOMMU patches are
required.
Tested on Shikra CQM EVK board with ILI7807S DSI panel. Display
pipeline probes cleanly and panel renders correctly.
Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
---
Nabige Aala (2):
dt-bindings: display: msm: qcm2290: Add Shikra MDSS
soc: qcom: ubwc: Add Shikra UBWC config
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 4 ++++
Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml | 6 +++++-
Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 19 ++++++++++++-------
drivers/soc/qcom/ubwc_config.c | 1 +
4 files changed, 22 insertions(+), 8 deletions(-)
---
Prerequisite-Message-Id: <20260518-ili7807s-panel-v1-0-d7b048163b1c@oss.qualcomm.com>
---
Changes in v4:
- Fix sort order of qcom,shikra-dsi-ctrl entry in
dsi-controller-main.yaml
- Replace oneOf in qcm2290-mdss patternProperties DPU compatible with
contains: qcom,qcm2290-dpu, consistent with DSI child node pattern
- Drop arm64: defconfig: Enable ILI7807S DSI panel driver from this
series; will be sent separately alongside device tree changes
- Link to v3: https://patch.msgid.link/20260605-shikra-display-v3-0-9846ba5fe635@oss.qualcomm.com
Changes in v3:
- Use a fallback compatible chain for qcom,shikra-dsi-ctrl
in dsi-controller-main.yaml instead of a standalone enum entry, with
qcom,qcm2290-dsi-ctrl and qcom,mdss-dsi-ctrl as fallbacks
- Replace oneOf in qcm2290-mdss patternProperties DSI compatible with
contains: qcom,qcm2290-dsi-ctrl to avoid duplicating full chain
validation already handled by dsi-controller-main.yaml
- Drop unnecessary select: block from qcom,qcm2290-mdss.yaml; default
dt-validate compatible matching is sufficient
- Remove self from qcom,qcm2290-mdss.yaml maintainers list
- Link to v2: https://patch.msgid.link/20260604-shikra-display-v2-0-b3c1b2b67edc@oss.qualcomm.com
Changes in v2:
- Drop drm/msm/mdss: Shikra support patch; driver reuse is handled via
the qcom,qcm2290-mdss fallback compatible string (per Dmitry's review)
- Drop iommu/arm-smmu: Shikra SMMU client table patch; not required with
fallback compatible approach
- Fix UBWC config to map qcom,shikra to qcm2290_data instead of
no_ubwc_data; Shikra shares UBWC support with QCM2290
- Refactor series from 5 patches to 3 patches
- Link to v1: https://patch.msgid.link/20260603-shikra-display-v1-0-aeac1b94faa7@oss.qualcomm.com
---
Nabige Aala (2):
dt-bindings: display: msm: qcm2290: Add Shikra MDSS
soc: qcom: ubwc: Add Shikra UBWC config
.../bindings/display/msm/dsi-controller-main.yaml | 4 ++++
.../bindings/display/msm/qcom,qcm2290-dpu.yaml | 6 +++++-
.../bindings/display/msm/qcom,qcm2290-mdss.yaml | 19 ++++++++++++-------
drivers/soc/qcom/ubwc_config.c | 1 +
4 files changed, 22 insertions(+), 8 deletions(-)
---
base-commit: 3a34f9c13cc0688f8db2a0db8506bf8c0d90737d
change-id: 20260603-shikra-display-07767208fa90
Best regards,
--
Nabige Aala <nabige.aala@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 7/7] arm64: dts: qcom: sm8350-hdk: describe WiFi/BT chip
From: Dmitry Baryshkov @ 2026-06-08 6:59 UTC (permalink / raw)
To: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth,
Bartosz Golaszewski
In-Reply-To: <20260608-sm8350-wifi-v2-0-efb68f1ff04c@oss.qualcomm.com>
The SM8350 HDK has onboard WiFi/BT chip, WCN6851. It is an earlier
version of well-known WCN6855 WiFI/BT SoC. Describe the PMU, BT and WiFI
parts of the device.
The firmware isn't (yet) available as a part of linux-firmware, so it
was verified with the firmware files from the vendor-supplied package
(wcn prefix was applied to Bluetooth firmware files to make them follow
upstream driver changes, vendor provided hpbtfw10.tlv and hpnv10.b06).
Bluetooth: hci0: QCA Product ID :0x00000013
Bluetooth: hci0: QCA SOC Version :0x400c0110
Bluetooth: hci0: QCA ROM Version :0x00000100
Bluetooth: hci0: QCA Patch Version:0x00001017
Bluetooth: hci0: QCA controller version 0x01100100
Bluetooth: hci0: QCA Downloading qca/wcnhpbtfw10.tlv
Bluetooth: hci0: QCA Downloading qca/wcnhpnv10.b06
Bluetooth: hci0: QCA setup on UART is completed
Bluetooth: hci0: HFP non-HCI data transport is supported
ath11k_pci 0000:01:00.0: BAR 0 [mem 0x60400000-0x605fffff 64bit]: assigned
ath11k_pci 0000:01:00.0: MSI vectors: 32
ath11k_pci 0000:01:00.0: wcn6855 hw1.1
mhi mhi0: Requested to power ON
mhi mhi0: Power on setup success
mhi mhi0: Wait for device to enter SBL or Mission mode
ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x6 soc_id 0x400c0110
ath11k_pci 0000:01:00.0: fw_version 0x110c80c8 fw_build_timestamp 2021-05-25 21:43 fw_build_id WLAN.HSP.1.1.c3-00200-QCAHSPSWPL_V1_V2_SILICONZ-1
ath11k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
For the reference, the driver looks for the board data for
bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=0,qmi-board-id=6,variant=QC_8350_HDK
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 126 ++++++++++++++++++++++++++++++++
1 file changed, 126 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
index 4973a3eb11b5..8e35216e4272 100644
--- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
@@ -115,6 +115,70 @@ lt9611_3v3: lt9611-3v3-regulator {
regulator-boot-on;
regulator-always-on;
};
+
+ wcn6855-pmu {
+ compatible = "qcom,wcn6851-pmu", "qcom,wcn6855-pmu";
+
+ pinctrl-0 = <&bt_en>, <&wlan_en>, <&swctrl>;
+ pinctrl-names = "default";
+
+ wlan-enable-gpios = <&tlmm 64 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 65 GPIO_ACTIVE_HIGH>;
+ swctrl-gpios = <&tlmm 153 GPIO_ACTIVE_HIGH>;
+
+ vddio-supply = <&vreg_s10b_1p8>;
+ vddaon-supply = <&vreg_s11b_0p95>;
+ vddpmu-supply = <&vreg_s11b_0p95>;
+ vddpmumx-supply = <&vreg_s2e_0p85>;
+ vddpmucx-supply = <&vreg_s11b_0p95>;
+ vddrfa0p95-supply = <&vreg_s11b_0p95>;
+ vddrfa1p3-supply = <&vreg_s12b_1p25>;
+ vddrfa1p9-supply = <&vreg_s1c_1p86>;
+ vddpcie1p3-supply = <&vreg_s12b_1p25>;
+ vddpcie1p9-supply = <&vreg_s1c_1p86>;
+
+ regulators {
+ vreg_pmu_rfa_cmn_0p8: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn_0p8";
+ };
+
+ vreg_pmu_aon_0p8: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p8";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p8: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p8";
+ };
+
+ vreg_pmu_btcmx_0p8: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p8";
+ };
+
+ vreg_pmu_pcie_1p8: ldo5 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+
+ vreg_pmu_pcie_0p9: ldo6 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_rfa_0p8: ldo7 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo8 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p7: ldo9 {
+ regulator-name = "vreg_pmu_rfa_1p7";
+ };
+ };
+ };
};
&adsp {
@@ -373,6 +437,13 @@ vreg_l7e_2p8: ldo7 {
regulator-name = "vreg_l7e_2p8";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
+
+ /*
+ * This is used by the RF front-end for which there is
+ * no way to represent it in DT (yet?).
+ */
+ regulator-boot-on;
+ regulator-always-on;
};
};
};
@@ -499,6 +570,23 @@ &pcie0 {
&pcie0_port0 {
reset-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+
+ wifi@0 {
+ compatible = "pci17cb,1103";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
+ vddaon-supply = <&vreg_pmu_aon_0p8>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>;
+
+ qcom,calibration-variant = "QC_8350_HDK";
+ };
};
&pcie0_phy {
@@ -763,6 +851,20 @@ &tlmm {
"HST_WLAN_UART_TX",
"HST_WLAN_UART_RX";
+ wlan_en: wlan-en-state {
+ pins = "gpio64";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ bt_en: bt-en-state {
+ pins = "gpio65";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
pcie0_default_state: pcie0-default-state {
perst-pins {
pins = "gpio94";
@@ -815,12 +917,36 @@ sdc2_card_det_n: sd-card-det-n-state {
drive-strength = <2>;
bias-pull-up;
};
+
+ swctrl: swctrl-state {
+ pins = "gpio153";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
};
&uart2 {
status = "okay";
};
+&uart18 {
+ status = "okay";
+
+ bluetooth {
+ compatible = "qcom,wcn6851-bt", "qcom,wcn6855-bt";
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
+ vddaon-supply = <&vreg_pmu_aon_0p8>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
+ vddbtcmx-supply = <&vreg_pmu_btcmx_0p8>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+ };
+};
+
&ufs_mem_hc {
status = "okay";
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox