arch/arm64/kernel/machine_kexec_file.c | 9 +++++++++ drivers/of/fdt.c | 19 +++++++++++++++++++ drivers/of/kexec.c | 19 +++++++++++++++++++ 3 files changed, 47 insertions(+)
Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds
LUKS-encrypted device dump target support to ARM64 by addressing two
challenges [1],
- Kdump kernel may not be able to decrypt the LUKS partition. For some
machines, a system administrator may not have a chance to enter the
password to decrypt the device in kdump initramfs after the 1st kernel
crashes
- LUKS2 by default use the memory-hard Argon2 key derivation function
which is quite memory-consuming compared to the limited memory reserved
for kdump.
1st kernel will add device tree property dmcryptkeys as similar to
elfcorehdr to pass the memory address of the stored info of dm-crypt
keys to the kdump kernel.
[1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
Cc: Baoquan he <bhe@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Kairui Song <ryncsn@gmail.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Coiby Xu <coxu@redhat.com>
---
arch/arm64/kernel/machine_kexec_file.c | 9 +++++++++
drivers/of/fdt.c | 19 +++++++++++++++++++
drivers/of/kexec.c | 19 +++++++++++++++++++
3 files changed, 47 insertions(+)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 410060ebd86d..5f3bad8ca96d 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -134,6 +134,15 @@ int load_other_segments(struct kimage *image,
kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
+
+ ret = crash_load_dm_crypt_keys(image);
+
+ if (ret == -ENOENT) {
+ kexec_dprintk("No dm crypt key to load\n");
+ } else if (ret) {
+ pr_err("Failed to load dm crypt keys\n");
+ goto out_err;
+ }
}
#endif
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 331646d667b9..2b22dc7e2b5f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -866,6 +866,24 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
elfcorehdr_addr, elfcorehdr_size);
}
+static void __init early_init_dt_check_for_dmcryptkeys(unsigned long node)
+{
+ const __be32 *prop;
+
+ if (!IS_ENABLED(CONFIG_CRASH_DM_CRYPT))
+ return;
+
+ pr_debug("Looking for dmcryptkeys property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,dmcryptkeys", NULL);
+ if (!prop)
+ return;
+
+ dm_crypt_keys_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+
+ pr_debug("dm_crypt_keys_addr=0x%llx\n", dm_crypt_keys_addr);
+}
+
static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
/*
@@ -1097,6 +1115,7 @@ int __init early_init_dt_scan_chosen(char *cmdline)
early_init_dt_check_for_initrd(node);
early_init_dt_check_for_elfcorehdr(node);
+ early_init_dt_check_for_dmcryptkeys(node);
rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
if (rng_seed && l > 0) {
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 1ee2d31816ae..4bfb1ea5744e 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -432,6 +432,25 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
if (ret)
goto out;
+ if (image->dm_crypt_keys_addr != 0) {
+ ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
+ "linux,dmcryptkeys",
+ image->dm_crypt_keys_addr,
+ image->dm_crypt_keys_sz);
+
+ if (ret)
+ goto out;
+
+ /*
+ * Avoid dmcryptkeys from being stomped on in kdump kernel by
+ * setting up memory reserve map.
+ */
+ ret = fdt_add_mem_rsv(fdt, image->dm_crypt_keys_addr,
+ image->dm_crypt_keys_sz);
+ if (ret)
+ goto out;
+ }
+
#ifdef CONFIG_CRASH_DUMP
/* add linux,usable-memory-range */
ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
base-commit: ccd1cdca5cd433c8a5dff78b69a79b31d9b77ee1
prerequisite-patch-id: af871421d3653569c735073a3d2d4915412736d7
prerequisite-patch-id: 536241bdf9240e12a5b038415875d4ce417a0892
--
2.52.0On Fri, Dec 26, 2025 at 8:11 AM Coiby Xu <coxu@redhat.com> wrote: > > Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds > LUKS-encrypted device dump target support to ARM64 by addressing two > challenges [1], > - Kdump kernel may not be able to decrypt the LUKS partition. For some > machines, a system administrator may not have a chance to enter the > password to decrypt the device in kdump initramfs after the 1st kernel > crashes > > - LUKS2 by default use the memory-hard Argon2 key derivation function > which is quite memory-consuming compared to the limited memory reserved > for kdump. > > 1st kernel will add device tree property dmcryptkeys as similar to > elfcorehdr to pass the memory address of the stored info of dm-crypt > keys to the kdump kernel. Is there not any security issue with putting the key into the DT? The DT is provided to userspace. There's provisions already to not expose "security-*" properties to userspace (see __of_add_property_sysfs). Though I think that has a hole in that the FDT is also provided as-is. However, I don't even know who or what uses these properties. Rob
On Tue, Jan 06, 2026 at 09:44:37AM -0600, Rob Herring wrote: >On Fri, Dec 26, 2025 at 8:11 AM Coiby Xu <coxu@redhat.com> wrote: >> >> Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds >> LUKS-encrypted device dump target support to ARM64 by addressing two >> challenges [1], >> - Kdump kernel may not be able to decrypt the LUKS partition. For some >> machines, a system administrator may not have a chance to enter the >> password to decrypt the device in kdump initramfs after the 1st kernel >> crashes >> >> - LUKS2 by default use the memory-hard Argon2 key derivation function >> which is quite memory-consuming compared to the limited memory reserved >> for kdump. >> >> 1st kernel will add device tree property dmcryptkeys as similar to >> elfcorehdr to pass the memory address of the stored info of dm-crypt >> keys to the kdump kernel. > >Is there not any security issue with putting the key into the DT? The >DT is provided to userspace. There's provisions already to not expose >"security-*" properties to userspace (see __of_add_property_sysfs). >Though I think that has a hole in that the FDT is also provided as-is. >However, I don't even know who or what uses these properties. > >Rob Hi Rob, Thanks for raising the concern! If I understand DT correctly, this property is only accessible to the kexec'ed kdump kernel. A new DT is allocated and set up by of_kexec_alloc_and_setup_fdt. Btw, to be precise, it's putting the memory address where the key is stored but not the key itself into DT. The key is stored in the memory exclusively reserved for kdump. For more info on by who and how this property will used, I've created a dt-schema pull request as suggested by Krzysztof, https://github.com/devicetree-org/dt-schema/pull/181 And yes, there is no need for even userspace of the kdump kernel to access it. So this idea of "security-*" properties/__of_add_property_sysfs seems desirable. Thanks for bringing it up! I'll give it a try. -- Best regards, Coiby
On Wed, Jan 07, 2026 at 07:39:24PM +0800, Coiby Xu wrote: > On Tue, Jan 06, 2026 at 09:44:37AM -0600, Rob Herring wrote: > > On Fri, Dec 26, 2025 at 8:11 AM Coiby Xu <coxu@redhat.com> wrote: > > > > > > Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds > > > LUKS-encrypted device dump target support to ARM64 by addressing two > > > challenges [1], > > > - Kdump kernel may not be able to decrypt the LUKS partition. For some > > > machines, a system administrator may not have a chance to enter the > > > password to decrypt the device in kdump initramfs after the 1st kernel > > > crashes > > > > > > - LUKS2 by default use the memory-hard Argon2 key derivation function > > > which is quite memory-consuming compared to the limited memory reserved > > > for kdump. > > > > > > 1st kernel will add device tree property dmcryptkeys as similar to > > > elfcorehdr to pass the memory address of the stored info of dm-crypt > > > keys to the kdump kernel. > > > > Is there not any security issue with putting the key into the DT? The > > DT is provided to userspace. There's provisions already to not expose > > "security-*" properties to userspace (see __of_add_property_sysfs). > > Though I think that has a hole in that the FDT is also provided as-is. > > However, I don't even know who or what uses these properties. > > > > Rob > > Hi Rob, > > Thanks for raising the concern! If I understand DT correctly, this > property is only accessible to the kexec'ed kdump kernel. A new DT is > allocated and set up by of_kexec_alloc_and_setup_fdt. Btw, to be > precise, it's putting the memory address where the key is stored but > not the key itself into DT. The key is stored in the memory exclusively > reserved for kdump. For more info on by who and how this property will > used, I've created a dt-schema pull request as suggested by Krzysztof, > https://github.com/devicetree-org/dt-schema/pull/181 Okay, that's a bit less sensitive. That still could expose a memory address to user space which has generally been locked down in recent years. Though I'm not sure we'd consider addresses of blobs passed by kexec sensitive or secure. > > And yes, there is no need for even userspace of the kdump kernel to > access it. So this idea of "security-*" properties/__of_add_property_sysfs > seems desirable. Thanks for bringing it up! I'll give it a try. Since it is just the memory address, kdump just moving the key would be sufficient. Or the property can be removed early on. I think we do that with kaslr seed IIRC. Rob
On Wed, Jan 14, 2026 at 03:08:59PM -0600, Rob Herring wrote: >On Wed, Jan 07, 2026 at 07:39:24PM +0800, Coiby Xu wrote: >> On Tue, Jan 06, 2026 at 09:44:37AM -0600, Rob Herring wrote: >> > On Fri, Dec 26, 2025 at 8:11 AM Coiby Xu <coxu@redhat.com> wrote: >> > > >> > > Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds >> > > LUKS-encrypted device dump target support to ARM64 by addressing two >> > > challenges [1], >> > > - Kdump kernel may not be able to decrypt the LUKS partition. For some >> > > machines, a system administrator may not have a chance to enter the >> > > password to decrypt the device in kdump initramfs after the 1st kernel >> > > crashes >> > > >> > > - LUKS2 by default use the memory-hard Argon2 key derivation function >> > > which is quite memory-consuming compared to the limited memory reserved >> > > for kdump. >> > > >> > > 1st kernel will add device tree property dmcryptkeys as similar to >> > > elfcorehdr to pass the memory address of the stored info of dm-crypt >> > > keys to the kdump kernel. >> > >> > Is there not any security issue with putting the key into the DT? The >> > DT is provided to userspace. There's provisions already to not expose >> > "security-*" properties to userspace (see __of_add_property_sysfs). >> > Though I think that has a hole in that the FDT is also provided as-is. >> > However, I don't even know who or what uses these properties. >> > >> > Rob >> >> Hi Rob, >> >> Thanks for raising the concern! If I understand DT correctly, this >> property is only accessible to the kexec'ed kdump kernel. A new DT is >> allocated and set up by of_kexec_alloc_and_setup_fdt. Btw, to be >> precise, it's putting the memory address where the key is stored but >> not the key itself into DT. The key is stored in the memory exclusively >> reserved for kdump. For more info on by who and how this property will >> used, I've created a dt-schema pull request as suggested by Krzysztof, >> https://github.com/devicetree-org/dt-schema/pull/181 > >Okay, that's a bit less sensitive. That still could expose a memory >address to user space which has generally been locked down in recent >years. Though I'm not sure we'd consider addresses of blobs passed by >kexec sensitive or secure. > >> >> And yes, there is no need for even userspace of the kdump kernel to >> access it. So this idea of "security-*" properties/__of_add_property_sysfs >> seems desirable. Thanks for bringing it up! I'll give it a try. > >Since it is just the memory address, kdump just moving the key would be >sufficient. Or the property can be removed early on. I think we do that >with kaslr seed IIRC. A security-* property is still exposed to user space. I think simply removing the property is an elegant solution! It's also much simpler than moving the key. I did a test and somehow wiping the old memory in read_from_oldmem_iter made it fail to read the keys. So I'll apply your suggestion of removing the property to next version. Thanks! > >Rob > -- Best regards, Coiby
On Fri, Dec 26, 2025 at 10:11:15PM +0800, Coiby Xu wrote:
> Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds
Don't use "this patch". See submitting patches.
> LUKS-encrypted device dump target support to ARM64 by addressing two
> challenges [1],
...
> +static void __init early_init_dt_check_for_dmcryptkeys(unsigned long node)
> +{
> + const __be32 *prop;
> +
> + if (!IS_ENABLED(CONFIG_CRASH_DM_CRYPT))
> + return;
> +
> + pr_debug("Looking for dmcryptkeys property... ");
> +
> + prop = of_get_flat_dt_prop(node, "linux,dmcryptkeys", NULL);
Where did you document the ABI?
Best regards,
Krzysztof
Hi Krzysztof,
Thanks for your prompt feedback!
On Sat, Dec 27, 2025 at 02:14:16PM +0100, Krzysztof Kozlowski wrote:
>On Fri, Dec 26, 2025 at 10:11:15PM +0800, Coiby Xu wrote:
>> Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds
>
>Don't use "this patch". See submitting patches.
I'll use imperative mood in next version, thanks for the reminder!
>
>> LUKS-encrypted device dump target support to ARM64 by addressing two
>> challenges [1],
>
>
>...
>
>> +static void __init early_init_dt_check_for_dmcryptkeys(unsigned long node)
>> +{
>> + const __be32 *prop;
>> +
>> + if (!IS_ENABLED(CONFIG_CRASH_DM_CRYPT))
>> + return;
>> +
>> + pr_debug("Looking for dmcryptkeys property... ");
>> +
>> + prop = of_get_flat_dt_prop(node, "linux,dmcryptkeys", NULL);
>
>Where did you document the ABI?
Thanks for raising the concern! I'll send a PR to
https://github.com/devicetree-org/dt-schema
and include the link in next version.
>
>
>Best regards,
>Krzysztof
>
>
--
Best regards,
Coiby
CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted
device dump target by addressing two challenges [1],
- Kdump kernel may not be able to decrypt the LUKS partition. For some
machines, a system administrator may not have a chance to enter the
password to decrypt the device in kdump initramfs after the 1st kernel
crashes
- LUKS2 by default use the memory-hard Argon2 key derivation function
which is quite memory-consuming compared to the limited memory reserved
for kdump.
To also enable this feature for ARM64, we only need to add device tree
property dmcryptkeys [2] as similar to elfcorehdr to pass the memory
address of the stored info of dm-crypt keys to the kdump kernel.
[1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
[2] https://github.com/devicetree-org/dt-schema/pull/181
Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
Cc: Baoquan he <bhe@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Kairui Song <ryncsn@gmail.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Coiby Xu <coxu@redhat.com>
---
v2
- Krzysztof
- Use imperative mood for commit message
- Add dt-schema ABI Documentation
- Don't print dm-crypt keys address via pr_debug
arch/arm64/kernel/machine_kexec_file.c | 9 +++++++++
drivers/of/fdt.c | 17 +++++++++++++++++
drivers/of/kexec.c | 19 +++++++++++++++++++
3 files changed, 45 insertions(+)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 410060ebd86d..5f3bad8ca96d 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -134,6 +134,15 @@ int load_other_segments(struct kimage *image,
kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
+
+ ret = crash_load_dm_crypt_keys(image);
+
+ if (ret == -ENOENT) {
+ kexec_dprintk("No dm crypt key to load\n");
+ } else if (ret) {
+ pr_err("Failed to load dm crypt keys\n");
+ goto out_err;
+ }
}
#endif
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 331646d667b9..9b6a6a402cb7 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -866,6 +866,22 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
elfcorehdr_addr, elfcorehdr_size);
}
+static void __init early_init_dt_check_for_dmcryptkeys(unsigned long node)
+{
+ const __be32 *prop;
+
+ if (!IS_ENABLED(CONFIG_CRASH_DM_CRYPT))
+ return;
+
+ pr_debug("Looking for dmcryptkeys property... ");
+
+ prop = of_get_flat_dt_prop(node, "linux,dmcryptkeys", NULL);
+ if (!prop)
+ return;
+
+ dm_crypt_keys_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
+}
+
static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
/*
@@ -1097,6 +1113,7 @@ int __init early_init_dt_scan_chosen(char *cmdline)
early_init_dt_check_for_initrd(node);
early_init_dt_check_for_elfcorehdr(node);
+ early_init_dt_check_for_dmcryptkeys(node);
rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
if (rng_seed && l > 0) {
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 1ee2d31816ae..4bfb1ea5744e 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -432,6 +432,25 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
if (ret)
goto out;
+ if (image->dm_crypt_keys_addr != 0) {
+ ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
+ "linux,dmcryptkeys",
+ image->dm_crypt_keys_addr,
+ image->dm_crypt_keys_sz);
+
+ if (ret)
+ goto out;
+
+ /*
+ * Avoid dmcryptkeys from being stomped on in kdump kernel by
+ * setting up memory reserve map.
+ */
+ ret = fdt_add_mem_rsv(fdt, image->dm_crypt_keys_addr,
+ image->dm_crypt_keys_sz);
+ if (ret)
+ goto out;
+ }
+
#ifdef CONFIG_CRASH_DUMP
/* add linux,usable-memory-range */
ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
base-commit: ccd1cdca5cd433c8a5dff78b69a79b31d9b77ee1
--
2.52.0On Tue, Jan 06, 2026 at 02:22:30PM +0800, Coiby Xu wrote: > CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted > device dump target by addressing two challenges [1], > - Kdump kernel may not be able to decrypt the LUKS partition. For some > machines, a system administrator may not have a chance to enter the > password to decrypt the device in kdump initramfs after the 1st kernel > crashes > > - LUKS2 by default use the memory-hard Argon2 key derivation function > which is quite memory-consuming compared to the limited memory reserved > for kdump. > > To also enable this feature for ARM64, we only need to add device tree > property dmcryptkeys [2] as similar to elfcorehdr to pass the memory > address of the stored info of dm-crypt keys to the kdump kernel. > > [1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/ > [2] https://github.com/devicetree-org/dt-schema/pull/181 > > Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com> > Cc: Baoquan he <bhe@redhat.com> > Cc: Dave Young <dyoung@redhat.com> > Cc: Kairui Song <ryncsn@gmail.com> > Cc: Pingfan Liu <kernelfans@gmail.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Krzysztof Kozlowski <krzk@kernel.org> > Signed-off-by: Coiby Xu <coxu@redhat.com> > --- > v2 > - Krzysztof > - Use imperative mood for commit message > - Add dt-schema ABI Documentation > - Don't print dm-crypt keys address via pr_debug Your changelog should explicitly document that this has external dependency on dtschema pull request, so that maintainers know that. Also, in the future: Do not attach (thread) your patchsets to some other threads (unrelated or older versions). This buries them deep in the mailbox and might interfere with applying entire sets. See also: https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830 Best regards, Krzysztof
On Tue, Jan 06, 2026 at 09:05:49AM +0100, Krzysztof Kozlowski wrote: >On Tue, Jan 06, 2026 at 02:22:30PM +0800, Coiby Xu wrote: >> CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted >> device dump target by addressing two challenges [1], >> - Kdump kernel may not be able to decrypt the LUKS partition. For some >> machines, a system administrator may not have a chance to enter the >> password to decrypt the device in kdump initramfs after the 1st kernel >> crashes >> >> - LUKS2 by default use the memory-hard Argon2 key derivation function >> which is quite memory-consuming compared to the limited memory reserved >> for kdump. >> >> To also enable this feature for ARM64, we only need to add device tree >> property dmcryptkeys [2] as similar to elfcorehdr to pass the memory >> address of the stored info of dm-crypt keys to the kdump kernel. >> >> [1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/ >> [2] https://github.com/devicetree-org/dt-schema/pull/181 >> >> Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com> >> Cc: Baoquan he <bhe@redhat.com> >> Cc: Dave Young <dyoung@redhat.com> >> Cc: Kairui Song <ryncsn@gmail.com> >> Cc: Pingfan Liu <kernelfans@gmail.com> >> Cc: Andrew Morton <akpm@linux-foundation.org> >> Cc: Krzysztof Kozlowski <krzk@kernel.org> >> Signed-off-by: Coiby Xu <coxu@redhat.com> >> --- >> v2 >> - Krzysztof >> - Use imperative mood for commit message >> - Add dt-schema ABI Documentation >> - Don't print dm-crypt keys address via pr_debug > >Your changelog should explicitly document that this has external >dependency on dtschema pull request, so that maintainers know that. Thanks for the lightning-fast reply! And thanks for the reminder! I didn't know the dtschema pull request is regarded as a dependency. Currently, I only add the dtschema pull request URL to the commit message. I'll also include it in the changelog. > >Also, in the future: >Do not attach (thread) your patchsets to some other threads (unrelated >or older versions). This buries them deep in the mailbox and might >interfere with applying entire sets. See also: >https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830 Thanks for pointing me to the above documentation! I thought adding In-Reply-To to the V1 patch can provide better context since it's a single patch. It seems this is not true for Devicetree. Is it because of the documentation change thus we should treat it more like a multi-patch series? > >Best regards, >Krzysztof > -- Best regards, Coiby
© 2016 - 2026 Red Hat, Inc.