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.
