Re: linux-next: manual merge of the risc-v tree with Linus' tree

[Palmer Dabbelt <palmer@dabbelt.com>]

On Sun, 07 Jan 2024 14:49:57 PST (-0800), Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the risc-v tree got a conflict in:
>
>   arch/riscv/kernel/sys_riscv.c
>
> between commit:
>
>   777c0d761be7 ("RISC-V: hwprobe: Always use u64 for extension bits")
>
> from Linus' tree and commit:
>
>   53b2b22850e1 ("RISC-V: Move the hwprobe syscall to its own file")
>
> from the risc-v tree.
>
> I fixed it up (I used the latter version of this file and applied the
> following merge fix 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 <sfr@canb.auug.org.au>
> Date: Mon, 8 Jan 2024 09:46:10 +1100
> Subject: [PATCH] fix up for "RISC-V: Move the hwprobe syscall to its own file"
>
> interacting with commit
>
>   777c0d761be7 ("RISC-V: hwprobe: Always use u64 for extension bits")
>
> from Linus' tree.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/riscv/kernel/sys_hwprobe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> index ccf61b040536..41f45acb156b 100644
> --- a/arch/riscv/kernel/sys_hwprobe.c
> +++ b/arch/riscv/kernel/sys_hwprobe.c
> @@ -136,7 +136,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
>  	pair->value &= ~missing;
>  }
>  
> -static bool hwprobe_ext0_has(const struct cpumask *cpus, unsigned long ext)
> +static bool hwprobe_ext0_has(const struct cpumask *cpus, u64 ext)
>  {
>  	struct riscv_hwprobe pair;
>  
> -- 
> 2.43.0
>
> -- 
> Cheers,
> Stephen Rothwell

Sorry, I think I screwed this up a few times.  I've got something on 
linux-next as of this morning that I think should be sane.