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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

Hi Guo,

Today's linux-next merge of the csky tree got a conflict in:

  Documentation/features/io/sg-chain/arch-support.txt

between commit:

  7c703e54cc71 ("arch: switch the default on ARCH_HAS_SG_CHAIN")

from Linus' tree and commit:

  ee8972b1ab82 ("Documentation/features: Add csky kernel features")

from the csky tree.

I fixed it up (the former removed the file, so I did that) 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.

You want to add "select ARCH_NO_SG_CHAIN" to your Kconfig somewhere
(see the commit from Linus' tree above).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Christoph Hellwig]

On Mon, Jan 07, 2019 at 10:27:27AM +1100, Stephen Rothwell wrote:
> You want to add "select ARCH_NO_SG_CHAIN" to your Kconfig somewhere
> (see the commit from Linus' tree above).

No, csky should not select it.  There is no code directly poking
into scatterlists internals in csky, so it can safely enable chained
sglists.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Hi Christoph,

On Mon, 7 Jan 2019 07:53:44 +0100 Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Jan 07, 2019 at 10:27:27AM +1100, Stephen Rothwell wrote:
> > You want to add "select ARCH_NO_SG_CHAIN" to your Kconfig somewhere
> > (see the commit from Linus' tree above).  
> 
> No, csky should not select it.  There is no code directly poking
> into scatterlists internals in csky, so it can safely enable chained
> sglists.

Thanks, good to know.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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@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.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

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).



-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

Hi all,

Today's linux-next merge of the csky tree got a conflict in:

  arch/riscv/kernel/signal.c

between commit:

  93917ad50972 ("RISC-V: Add support for restartable sequence")

from Linus' tree and commit:

  0f713062b0ee ("riscv: compat: signal: Add rt_frame implementation")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/riscv/kernel/signal.c
index 9f4e59f80551,27d8f39228c4..000000000000
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@@ -258,10 -264,13 +264,15 @@@ static void handle_signal(struct ksigna
  		}
  	}
  
 +	rseq_signal_deliver(ksig, regs);
 +
+ #ifdef CONFIG_COMPAT
  	/* Set up the stack frame */
- 	ret = setup_rt_frame(ksig, oldset, regs);
+ 	if (is_compat_task())
+ 		ret = compat_setup_rt_frame(ksig, oldset, regs);
+ 	else
+ #endif
+ 		ret = setup_rt_frame(ksig, oldset, regs);
  
  	signal_setup_done(ret, ksig, 0);
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

Hi all,

Today's linux-next merge of the csky tree got a conflict in:

  arch/csky/include/asm/Kbuild

between commit:

  630f289b7114 ("asm-generic: make more kernel-space headers mandatory")

from Linus' tree and commit:

  33e53ae1ce41 ("csky: Add kprobes supported")

from the csky tree.

I fixed it up (the former is a superset of the latter) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Guo Ren]

Fixed with new rebase on linux-5.5-rc4 for csky linux-next

Best Regards
  Guo Ren



> 在 2020年1月6日，上午6:20，Stephen Rothwell <sfr@canb.auug.org.au> 写道：
> 
> Hi all,
> 
> FIXME: Add owner of second tree to To:
>       Add author(s)/SOB of conflicting commits.
> 
> Today's linux-next merge of the csky tree got a conflict in:
> 
>  arch/csky/kernel/vmlinux.lds.S
> 
> between commit:
> 
>  eaf937075c9a ("vmlinux.lds.h: Move NOTES into RO_DATA")
> 
> from Linus' tree and commit:
> 
>  338ef1d06f0c ("csky: Tightly-Coupled Memory or Sram support")
> 
> 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/csky/kernel/vmlinux.lds.S
> index 2ff37beaf2bf,02b35d916fe7..000000000000
> --- a/arch/csky/kernel/vmlinux.lds.S
> +++ b/arch/csky/kernel/vmlinux.lds.S
> @@@ -49,10 -51,59 +51,58 @@@ SECTION
> 
> 
>  	_sdata = .;
> -	RO_DATA_SECTION(PAGE_SIZE)
> -	RW_DATA_SECTION(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE)
> +	RO_DATA(PAGE_SIZE)
> +	RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE)
>  	_edata = .;
> 
> + #ifdef CONFIG_HAVE_TCM
> + 	.tcm_start : {
> + 		. = ALIGN(PAGE_SIZE);
> + 		__tcm_start = .;
> + 	}
> + 
> + 	.text_data_tcm FIXADDR_TCM : AT(__tcm_start)
> + 	{
> + 		. = ALIGN(4);
> + 		__stcm_text_data = .;
> + 		*(.tcm.text)
> + 		*(.tcm.rodata)
> + #ifndef CONFIG_HAVE_DTCM
> + 		*(.tcm.data)
> + #endif
> + 		. = ALIGN(4);
> + 		__etcm_text_data = .;
> + 	}
> + 
> + 	. = ADDR(.tcm_start) + SIZEOF(.tcm_start) + SIZEOF(.text_data_tcm);
> + 
> + #ifdef CONFIG_HAVE_DTCM
> + 	#define ITCM_SIZE	CONFIG_ITCM_NR_PAGES * PAGE_SIZE
> + 
> + 	.dtcm_start : {
> + 		__dtcm_start = .;
> + 	}
> + 
> + 	.data_tcm FIXADDR_TCM + ITCM_SIZE : AT(__dtcm_start)
> + 	{
> + 		. = ALIGN(4);
> + 		__stcm_data = .;
> + 		*(.tcm.data)
> + 		. = ALIGN(4);
> + 		__etcm_data = .;
> + 	}
> + 
> + 	. = ADDR(.dtcm_start) + SIZEOF(.data_tcm);
> + 
> + 	.tcm_end : AT(ADDR(.dtcm_start) + SIZEOF(.data_tcm)) {
> + #else
> + 	.tcm_end : AT(ADDR(.tcm_start) + SIZEOF(.text_data_tcm)) {
> + #endif
> + 		. = ALIGN(PAGE_SIZE);
> + 		__tcm_end = .;
> + 	}
> + #endif
> + 
> -	NOTES
>  	EXCEPTION_TABLE(L1_CACHE_BYTES)
>  	BSS_SECTION(L1_CACHE_BYTES, PAGE_SIZE, L1_CACHE_BYTES)
>  	VBR_BASE

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

Hi all,

FIXME: Add owner of second tree to To:
       Add author(s)/SOB of conflicting commits.

Today's linux-next merge of the csky tree got a conflict in:

  arch/csky/kernel/vmlinux.lds.S

between commit:

  eaf937075c9a ("vmlinux.lds.h: Move NOTES into RO_DATA")

from Linus' tree and commit:

  338ef1d06f0c ("csky: Tightly-Coupled Memory or Sram support")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/csky/kernel/vmlinux.lds.S
index 2ff37beaf2bf,02b35d916fe7..000000000000
--- a/arch/csky/kernel/vmlinux.lds.S
+++ b/arch/csky/kernel/vmlinux.lds.S
@@@ -49,10 -51,59 +51,58 @@@ SECTION
  
  
  	_sdata = .;
 -	RO_DATA_SECTION(PAGE_SIZE)
 -	RW_DATA_SECTION(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE)
 +	RO_DATA(PAGE_SIZE)
 +	RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE)
  	_edata = .;
  
+ #ifdef CONFIG_HAVE_TCM
+ 	.tcm_start : {
+ 		. = ALIGN(PAGE_SIZE);
+ 		__tcm_start = .;
+ 	}
+ 
+ 	.text_data_tcm FIXADDR_TCM : AT(__tcm_start)
+ 	{
+ 		. = ALIGN(4);
+ 		__stcm_text_data = .;
+ 		*(.tcm.text)
+ 		*(.tcm.rodata)
+ #ifndef CONFIG_HAVE_DTCM
+ 		*(.tcm.data)
+ #endif
+ 		. = ALIGN(4);
+ 		__etcm_text_data = .;
+ 	}
+ 
+ 	. = ADDR(.tcm_start) + SIZEOF(.tcm_start) + SIZEOF(.text_data_tcm);
+ 
+ #ifdef CONFIG_HAVE_DTCM
+ 	#define ITCM_SIZE	CONFIG_ITCM_NR_PAGES * PAGE_SIZE
+ 
+ 	.dtcm_start : {
+ 		__dtcm_start = .;
+ 	}
+ 
+ 	.data_tcm FIXADDR_TCM + ITCM_SIZE : AT(__dtcm_start)
+ 	{
+ 		. = ALIGN(4);
+ 		__stcm_data = .;
+ 		*(.tcm.data)
+ 		. = ALIGN(4);
+ 		__etcm_data = .;
+ 	}
+ 
+ 	. = ADDR(.dtcm_start) + SIZEOF(.data_tcm);
+ 
+ 	.tcm_end : AT(ADDR(.dtcm_start) + SIZEOF(.data_tcm)) {
+ #else
+ 	.tcm_end : AT(ADDR(.tcm_start) + SIZEOF(.text_data_tcm)) {
+ #endif
+ 		. = ALIGN(PAGE_SIZE);
+ 		__tcm_end = .;
+ 	}
+ #endif
+ 
 -	NOTES
  	EXCEPTION_TABLE(L1_CACHE_BYTES)
  	BSS_SECTION(L1_CACHE_BYTES, PAGE_SIZE, L1_CACHE_BYTES)
  	VBR_BASE

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]