[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20251125094027.62b358b4ba98e599a366eb3b@linux-foundation.org>
Date: Tue, 25 Nov 2025 09:40:27 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Paul Walmsley <pjw@...nel.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>, Palmer Dabbelt
<palmer@...belt.com>, david@...hat.com, Paul Walmsley <paul@...an.com>,
Chunyan Zhang <zhangchunyan@...as.ac.cn>, Linux Kernel Mailing List
<linux-kernel@...r.kernel.org>, Linux Next Mailing List
<linux-next@...r.kernel.org>, Xu Lu <luxu.kernel@...edance.com>
Subject: Re: linux-next: manual merge of the risc-v tree with the
mm-unstable tree
On Tue, 25 Nov 2025 02:12:26 -0700 (MST) Paul Walmsley <pjw@...nel.org> wrote:
> Hi Andrew,
>
> On Mon, 24 Nov 2025, Stephen Rothwell wrote:
>
> > Today's linux-next merge of the risc-v tree got a conflict in:
> >
> > arch/riscv/include/asm/hwcap.h
> >
> > between commit:
> >
> > a2fb99195ca8 ("riscv: add RISC-V Svrsw60t59b extension support")
> >
> > from the mm-unstable tree and commit:
> >
> > 0597b9c8627e ("riscv: Add ISA extension parsing for Zalasr")
> >
> > from the risc-v tree.
>
> [ ... ]
>
> > diff --cc arch/riscv/include/asm/hwcap.h
> > index f98fcb5c17d5,ae3852c4f2ca..000000000000
> > --- a/arch/riscv/include/asm/hwcap.h
> > +++ b/arch/riscv/include/asm/hwcap.h
> > @@@ -106,7 -106,7 +106,8 @@@
> > #define RISCV_ISA_EXT_ZAAMO 97
> > #define RISCV_ISA_EXT_ZALRSC 98
> > #define RISCV_ISA_EXT_ZICBOP 99
> > -#define RISCV_ISA_EXT_ZALASR 100
> > +#define RISCV_ISA_EXT_SVRSW60T59B 100
> > ++#define RISCV_ISA_EXT_ZALASR 101
> >
> > #define RISCV_ISA_EXT_XLINUXENVCFG 127
>
> I think it might be easier for us, and would result in fewer merge
> conflicts, if we took this series through the RISC-V tree. We're merging
> in quite a few changes to this hwcap.h file, and touching it in -mm is
> likely to result in some unnecessary merge conflicts when we send it to
> Linus.
>
> If you'd still prefer to take it via -mm, we could also establish a shared
> base.
Is it worth the fuss? This patchset hits on mm/ quite a lot, it's now
in mm.git's allegedly-nonrebasing mm-stable branch and it's a trivial
one-liner fixup.
Unless you have a lot of material pending merge (at -rc7??) then I'd
say just let this be.
Powered by blists - more mailing lists