Subject: Re: linux-next: manual merge of the memblock tree with the mm-nonmm-stable tree

From: Stephen Rothwell <[email-masked]>
Date: Fri, 5 Dec 2025 10:00:07 +1100

Hi all,

On Mon, 1 Dec 2025 12:37:22 +1100 Stephen Rothwell <[email-masked]> wrote:
>
> Today's linux-next merge of the memblock tree got a conflict in:
> 
>   kernel/Kconfig.kexec
> 
> between commit:
> 
>   48a1b2321d76 ("liveupdate: kho: move to kernel/liveupdate")
> 
> from the mm-nonmm-stable tree and commit:
> 
>   ab65699f9add ("memblock: remove CONFIG_MEMBLOCK_KHO_SCRATCH option")
> 
> from the memblock tree.
> 
> I fixed it up (I used the former version of the above file and then
> added the following merge resolution patch) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
> From: Stephen Rothwell <[email-masked]>
> Date: Mon, 1 Dec 2025 12:33:52 +1100
> Subject: [PATCH] fix for "memblock: remove CONFIG_MEMBLOCK_KHO_SCRATCH option"
> 
> interacting with commit
> 
>   48a1b2321d76 ("liveupdate: kho: move to kernel/liveupdate")
> 
> from the mm-nonmm-stable tree.
> 
> Signed-off-by: Stephen Rothwell <[email-masked]>
> ---
>  kernel/liveupdate/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/liveupdate/Kconfig b/kernel/liveupdate/Kconfig
> index 9b2515f31afb..86a58eaf433a 100644
> --- a/kernel/liveupdate/Kconfig
> +++ b/kernel/liveupdate/Kconfig
> @@ -7,7 +7,6 @@ config KEXEC_HANDOVER
>  	bool "kexec handover"
>  	depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE
>  	depends on !DEFERRED_STRUCT_PAGE_INIT
> -	select MEMBLOCK_KHO_SCRATCH
>  	select KEXEC_FILE
>  	select LIBFDT
>  	select CMA
> -- 
> 2.52.0

It appears that the above memblock tree commit has been removed from
the memblock tree, so this resolution is not longer needed.

-- 
Cheers,
Stephen Rothwell