lkml.org 
[lkml]   [2022]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: linux-next: manual merge of the csky tree with Linus' tree
From
On Sun, 03 Apr 2022 20:54:55 PDT (-0700), guoren@kernel.org wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> 于 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.

\
 
 \ /
  Last update: 2022-04-05 01:15    [W:0.628 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site