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

[Palmer Dabbelt]

On Sun, 03 Apr 2022 20:54:55 PDT (-0700), guoren@xxxxxxxxxx wrote:
> Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 于 2022年4月4日周一 06:24写道：
>
> > Hi all,
> >
> > Today's linux-next merge of the csky tree got a conflict in:
> >
> >   arch/riscv/configs/rv32_defconfig
> >
> > between commits:
> >
> >   d56201d9440d ("riscv: defconfig: enable hugetlbfs option")
> >   f6e64b66629e ("RISC-V: Enable CPU_IDLE drivers")
> >   c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
> > machine")
> >   2e7451fb5763 ("RISC-V: Enable profiling by default")
> >   6f562570b9c5 ("RISC-V: defconfig: Drop redundant SBI HVC and earlycon")
> >
> > from Linus' tree and commit:
> >
> >   0f6ffeaeed8f ("riscv: Fixup difference with defconfig")
> >
> > from the csky tree.
> >
> > I fixed it up (see below) 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.
> >
> > I am trying to figure out why all these commits affecting the riscv
> > architecture have suddenly turned up in the csky tree (and just before
> > the merge window closed).
> It's not for csky pull request. I just missed the 5.18 chance to merge
> compat feature for riscv. This series also contains several other arches'
> cleanup. I just want to see any other conflicts in the series. Thanks pay
> the effort to take care.

[Sorry for missing this, Lenovo keeps putting broken motherboards in my 
laptop so things on my end have been a mess for the past week.]

IIUC that's not usually how this is done: linux-next is really meant for 
stuff that's ready to go in (and into the upcoming release), not for 
experimentation (doubly so for the next release).  I usually push stuff 
to another branch on one of my repos where autobuilders pick stuff up, 
which is how I've been seeing the build issues.

IMO it gets kind of confusing for everyone when patch sets get mixed up 
like this (spinning a v2 of the generic ticket locks with some SOBs 
missing was similarly confusing, is that single-patch multi-arch fix).  
It's already a bit of a headache getting these multi-arch patches 
through, having extra confusion on when things are ready to go 

Specifically: I'd been operating under the assumption that this would go 
in through the RISC-V tree, as it's mostly diff in arch/riscv/.  There's 
some refactoring in other arch ports that's not been acked, which I 
don't really like to do, but I figured Christoph and Arnd having 
written/acked it was close enough.  That said, I'm definately not going 
to put it into my for-next when I'm getting build errors from arm64 
autobuilders on the standalone branch.

LMK if you had something different in mind, otherwise I'm just going to 
proceed under the assumption this is going in through the RISC-V tree -- 
I see a v11, I'm going to comment on that.