linux-next: manual merge of the risc-v tree with the arm64 tree

linux-next: manual merge of the risc-v tree with the arm64 tree

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/mm/Makefile

between commit:

  072e3d96a79a ("arm64: hibernate: move page handling function to new trans_pgd.c")

from the arm64 tree and commit:

  ae3c107cd8be ("numa: Move numa implementation to common code")

from the risc-v 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/arm64/mm/Makefile
index 77222d92667a,cd60e4fed78f..000000000000
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@@ -6,8 -6,6 +6,7 @@@ obj-y				:= dma-mapping.o extable.o fau
  obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
  obj-$(CONFIG_PTDUMP_CORE)	+= ptdump.o
  obj-$(CONFIG_PTDUMP_DEBUGFS)	+= ptdump_debugfs.o
 +obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd.o
- obj-$(CONFIG_NUMA)		+= numa.o
  obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
  obj-$(CONFIG_ARM64_MTE)		+= mteswap.o
  KASAN_SANITIZE_physaddr.o	+= n

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

Re: linux-next: manual merge of the risc-v tree with the arm64 tree

[Stephen Rothwell]

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

Hi all,

On Thu, 28 Jan 2021 10:27:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the risc-v tree got a conflict in:
> 
>   arch/arm64/mm/Makefile
> 
> between commit:
> 
>   072e3d96a79a ("arm64: hibernate: move page handling function to new trans_pgd.c")
> 
> from the arm64 tree and commit:
> 
>   ae3c107cd8be ("numa: Move numa implementation to common code")
> 
> from the risc-v 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.
> 
> diff --cc arch/arm64/mm/Makefile
> index 77222d92667a,cd60e4fed78f..000000000000
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@@ -6,8 -6,6 +6,7 @@@ obj-y				:= dma-mapping.o extable.o fau
>   obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
>   obj-$(CONFIG_PTDUMP_CORE)	+= ptdump.o
>   obj-$(CONFIG_PTDUMP_DEBUGFS)	+= ptdump_debugfs.o
>  +obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd.o
> - obj-$(CONFIG_NUMA)		+= numa.o
>   obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
>   obj-$(CONFIG_ARM64_MTE)		+= mteswap.o
>   KASAN_SANITIZE_physaddr.o	+= n

With the merge window about to open, this is a reminder that this
conflict still exists.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the risc-v tree with the arm64 tree

[Catalin Marinas]

On Fri, Mar 15, 2024 at 10:21:13AM -0700, Palmer Dabbelt wrote:
> On Thu, 14 Mar 2024 16:31:46 PDT (-0700), Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the risc-v tree got a conflict in:
> > 
> >   drivers/perf/Kconfig
> > 
> > between commits:
> > 
> >   c2b24812f7bc ("perf: starfive: Add StarLink PMU support")
> >   f0dbc6d0de38 ("perf: starfive: Only allow COMPILE_TEST for 64-bit architectures")
> > 
> > from the arm64 tree and commit:
> > 
> >   bc969d6cc96a ("perf: RISC-V: Introduce Andes PMU to support perf event sampling")
> > 
> > from the risc-v 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.
> 
> Sorry, I guess maybe I should have looked at my queue before agreeing to
> send the starfive PMU patches via the arm64 tree.  The Andes stuff touches a
> bunch of other RISC-V bits, but I'm happy to do a shared tag or something if
> folks want.
> 
> Otherwise I'll just point this out to Linus when I send my PR -- I'm going
> to hold off on that this morning, as I just realized I should have taken
> this GUP fix and thus want to let things bake a little longer.

The arm64 tree went in yesterday already. If you want, you can merge
the arm64 for-next/perf tree into yours before sending the PR to Linus.
Otherwise, the conflict is trivial, just give Linus a heads-up.

-- 
Catalin

Re: linux-next: manual merge of the risc-v tree with the arm64 tree

[Palmer Dabbelt]

On Thu, 14 Mar 2024 16:31:46 PDT (-0700), Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the risc-v tree got a conflict in:
>
>   drivers/perf/Kconfig
>
> between commits:
>
>   c2b24812f7bc ("perf: starfive: Add StarLink PMU support")
>   f0dbc6d0de38 ("perf: starfive: Only allow COMPILE_TEST for 64-bit architectures")
>
> from the arm64 tree and commit:
>
>   bc969d6cc96a ("perf: RISC-V: Introduce Andes PMU to support perf event sampling")
>
> from the risc-v 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.

Sorry, I guess maybe I should have looked at my queue before agreeing to 
send the starfive PMU patches via the arm64 tree.  The Andes stuff 
touches a bunch of other RISC-V bits, but I'm happy to do a shared tag 
or something if folks want.

Otherwise I'll just point this out to Linus when I send my PR -- I'm 
going to hold off on that this morning, as I just realized I should have 
taken this GUP fix and thus want to let things bake a little longer.

>
> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/perf/Kconfig
> index 004d86230aa6,564e813d8c69..000000000000
> --- a/drivers/perf/Kconfig
> +++ b/drivers/perf/Kconfig
> @@@ -86,15 -86,20 +86,29 @@@ config RISCV_PMU_SB
>   	  full perf feature support i.e. counter overflow, privilege mode
>   	  filtering, counter configuration.
>   
>  +config STARFIVE_STARLINK_PMU
>  +	depends on ARCH_STARFIVE || (COMPILE_TEST && 64BIT)
>  +	bool "StarFive StarLink PMU"
>  +	help
>  +	   Provide support for StarLink Performance Monitor Unit.
>  +	   StarLink Performance Monitor Unit integrates one or more cores with
>  +	   an L3 memory system. The L3 cache events are added into perf event
>  +	   subsystem, allowing monitoring of various L3 cache perf events.
>  +
> + config ANDES_CUSTOM_PMU
> + 	bool "Andes custom PMU support"
> + 	depends on ARCH_RENESAS && RISCV_ALTERNATIVE && RISCV_PMU_SBI
> + 	default y
> + 	help
> + 	  The Andes cores implement the PMU overflow extension very
> + 	  similar to the standard Sscofpmf and Smcntrpmf extension.
> + 
> + 	  This will patch the overflow and pending CSRs and handle the
> + 	  non-standard behaviour via the regular SBI PMU driver and
> + 	  interface.
> + 
> + 	  If you don't know what to do here, say "Y".
> + 
>   config ARM_PMU_ACPI
>   	depends on ARM_PMU && ACPI
>   	def_bool y

linux-next: manual merge of the risc-v tree with the arm64 tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/perf/Kconfig

between commits:

  c2b24812f7bc ("perf: starfive: Add StarLink PMU support")
  f0dbc6d0de38 ("perf: starfive: Only allow COMPILE_TEST for 64-bit architectures")

from the arm64 tree and commit:

  bc969d6cc96a ("perf: RISC-V: Introduce Andes PMU to support perf event sampling")

from the risc-v 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 drivers/perf/Kconfig
index 004d86230aa6,564e813d8c69..000000000000
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@@ -86,15 -86,20 +86,29 @@@ config RISCV_PMU_SB
  	  full perf feature support i.e. counter overflow, privilege mode
  	  filtering, counter configuration.
  
 +config STARFIVE_STARLINK_PMU
 +	depends on ARCH_STARFIVE || (COMPILE_TEST && 64BIT)
 +	bool "StarFive StarLink PMU"
 +	help
 +	   Provide support for StarLink Performance Monitor Unit.
 +	   StarLink Performance Monitor Unit integrates one or more cores with
 +	   an L3 memory system. The L3 cache events are added into perf event
 +	   subsystem, allowing monitoring of various L3 cache perf events.
 +
+ config ANDES_CUSTOM_PMU
+ 	bool "Andes custom PMU support"
+ 	depends on ARCH_RENESAS && RISCV_ALTERNATIVE && RISCV_PMU_SBI
+ 	default y
+ 	help
+ 	  The Andes cores implement the PMU overflow extension very
+ 	  similar to the standard Sscofpmf and Smcntrpmf extension.
+ 
+ 	  This will patch the overflow and pending CSRs and handle the
+ 	  non-standard behaviour via the regular SBI PMU driver and
+ 	  interface.
+ 
+ 	  If you don't know what to do here, say "Y".
+ 
  config ARM_PMU_ACPI
  	depends on ARM_PMU && ACPI
  	def_bool y

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

Re: linux-next: manual merge of the risc-v tree with the arm64 tree

[Will Deacon]

On Tue, Aug 13, 2019 at 10:24:30PM +0000, Paul Walmsley wrote:
> On Tue, 13 Aug 2019, Will Deacon wrote:
> > On Tue, Aug 13, 2019 at 09:34:47AM +1000, Stephen Rothwell wrote:
> > > Today's linux-next merge of the risc-v tree got a conflict in:
> > > 
> > >   arch/arm64/kernel/topology.c
> > > 
> > > between commit:
> > > 
> > >   98dc19902a0b ("arm64: topology: Use PPTT to determine if PE is a thread")
> > > 
> > > from the arm64 tree and commit:
> > > 
> > >   60c1b220d8bc ("cpu-topology: Move cpu topology code to common code.")
> > > 
> > > from the risc-v 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.
> > 
> > Thanks, Stephen.
> > 
> > Paul, Palmer -- If it's not too late, then it would probably be best to
> > stick this commit (60c1b220d8bc) and any dependencies on their own stable
> > branch so that we can both pull it into our respective trees and I can
> > resolve this conflict in the arm64 tree, which I'll send early during the
> > merge window.
> > 
> > Looking at your tree, I guess I could just pull in
> > common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
> > that, you could fork a new branch from 60c1b220d8bc and I could just pull
> > that part instead.
> 
> How about if we treat common/for-v5.4-rc1/cpu-topology as a stable branch?  
> I wasn't planning to rebase it.  Then both of us can just merge it into 
> our for-next branches for the merge window?  (It looks like I will need to 
> rebuild the riscv for-next branch on top of v5.3-rc5, for unrelated 
> reasons.)
> 
> Sound reasonable?

Cheers, Paul. Sounds good to me.

Will

Re: linux-next: manual merge of the risc-v tree with the arm64 tree

[Paul Walmsley]

Hi folks,

On Tue, 13 Aug 2019, Will Deacon wrote:

> On Tue, Aug 13, 2019 at 09:34:47AM +1000, Stephen Rothwell wrote:
> > Today's linux-next merge of the risc-v tree got a conflict in:
> > 
> >   arch/arm64/kernel/topology.c
> > 
> > between commit:
> > 
> >   98dc19902a0b ("arm64: topology: Use PPTT to determine if PE is a thread")
> > 
> > from the arm64 tree and commit:
> > 
> >   60c1b220d8bc ("cpu-topology: Move cpu topology code to common code.")
> > 
> > from the risc-v 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.
> 
> Thanks, Stephen.
> 
> Paul, Palmer -- If it's not too late, then it would probably be best to
> stick this commit (60c1b220d8bc) and any dependencies on their own stable
> branch so that we can both pull it into our respective trees and I can
> resolve this conflict in the arm64 tree, which I'll send early during the
> merge window.
> 
> Looking at your tree, I guess I could just pull in
> common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
> that, you could fork a new branch from 60c1b220d8bc and I could just pull
> that part instead.

How about if we treat common/for-v5.4-rc1/cpu-topology as a stable branch?  
I wasn't planning to rebase it.  Then both of us can just merge it into 
our for-next branches for the merge window?  (It looks like I will need to 
rebuild the riscv for-next branch on top of v5.3-rc5, for unrelated 
reasons.)

Sound reasonable?


- Paul

Re: linux-next: manual merge of the risc-v tree with the arm64 tree

[Will Deacon]

On Tue, Aug 13, 2019 at 06:42:11PM +1000, Stephen Rothwell wrote:
> On Tue, 13 Aug 2019 09:24:23 +0100 Will Deacon <will@kernel.org> wrote:
> >
> > Paul, Palmer -- If it's not too late, then it would probably be best to
> > stick this commit (60c1b220d8bc) and any dependencies on their own stable
> > branch so that we can both pull it into our respective trees and I can
> > resolve this conflict in the arm64 tree, which I'll send early during the
> > merge window.
> > 
> > Looking at your tree, I guess I could just pull in
> > common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
> > that, you could fork a new branch from 60c1b220d8bc and I could just pull
> > that part instead.
> 
> It may not be worth it, the conflict is not that bad.  Unless you
> forsee more conflicts arising.

Hopefully not, but it looks like it should be dead easy to resolve in this
case since the riscv tree doesn't contain anything else and the arm64 stuff
is already on its own branch.

I'll leave it up to Paul/Palmer to see what they prefer.

Will

Re: linux-next: manual merge of the risc-v tree with the arm64 tree

[Stephen Rothwell]

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

Hi Will,

On Tue, 13 Aug 2019 09:24:23 +0100 Will Deacon <will@kernel.org> wrote:
>
> Paul, Palmer -- If it's not too late, then it would probably be best to
> stick this commit (60c1b220d8bc) and any dependencies on their own stable
> branch so that we can both pull it into our respective trees and I can
> resolve this conflict in the arm64 tree, which I'll send early during the
> merge window.
> 
> Looking at your tree, I guess I could just pull in
> common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
> that, you could fork a new branch from 60c1b220d8bc and I could just pull
> that part instead.

It may not be worth it, the conflict is not that bad.  Unless you
forsee more conflicts arising.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the risc-v tree with the arm64 tree

[Will Deacon]

On Tue, Aug 13, 2019 at 09:34:47AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the risc-v tree got a conflict in:
> 
>   arch/arm64/kernel/topology.c
> 
> between commit:
> 
>   98dc19902a0b ("arm64: topology: Use PPTT to determine if PE is a thread")
> 
> from the arm64 tree and commit:
> 
>   60c1b220d8bc ("cpu-topology: Move cpu topology code to common code.")
> 
> from the risc-v 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.

Thanks, Stephen.

Paul, Palmer -- If it's not too late, then it would probably be best to
stick this commit (60c1b220d8bc) and any dependencies on their own stable
branch so that we can both pull it into our respective trees and I can
resolve this conflict in the arm64 tree, which I'll send early during the
merge window.

Looking at your tree, I guess I could just pull in
common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
that, you could fork a new branch from 60c1b220d8bc and I could just pull
that part instead.

Please let me know.

Will

linux-next: manual merge of the risc-v tree with the arm64 tree

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/topology.c

between commit:

  98dc19902a0b ("arm64: topology: Use PPTT to determine if PE is a thread")

from the arm64 tree and commit:

  60c1b220d8bc ("cpu-topology: Move cpu topology code to common code.")

from the risc-v 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/arm64/kernel/topology.c
index 6106c49f84bc,6b95c91e7d67..000000000000
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@@ -296,72 -59,21 +59,32 @@@ topology_populated
  	update_siblings_masks(cpuid);
  }
  
- static void clear_cpu_topology(int cpu)
- {
- 	struct cpu_topology *cpu_topo = &cpu_topology[cpu];
- 
- 	cpumask_clear(&cpu_topo->llc_sibling);
- 	cpumask_set_cpu(cpu, &cpu_topo->llc_sibling);
- 
- 	cpumask_clear(&cpu_topo->core_sibling);
- 	cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
- 	cpumask_clear(&cpu_topo->thread_sibling);
- 	cpumask_set_cpu(cpu, &cpu_topo->thread_sibling);
- }
- 
- static void __init reset_cpu_topology(void)
- {
- 	unsigned int cpu;
- 
- 	for_each_possible_cpu(cpu) {
- 		struct cpu_topology *cpu_topo = &cpu_topology[cpu];
- 
- 		cpu_topo->thread_id = -1;
- 		cpu_topo->core_id = 0;
- 		cpu_topo->package_id = -1;
- 		cpu_topo->llc_id = -1;
- 
- 		clear_cpu_topology(cpu);
- 	}
- }
- 
- void remove_cpu_topology(unsigned int cpu)
- {
- 	int sibling;
- 
- 	for_each_cpu(sibling, topology_core_cpumask(cpu))
- 		cpumask_clear_cpu(cpu, topology_core_cpumask(sibling));
- 	for_each_cpu(sibling, topology_sibling_cpumask(cpu))
- 		cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling));
- 	for_each_cpu(sibling, topology_llc_cpumask(cpu))
- 		cpumask_clear_cpu(cpu, topology_llc_cpumask(sibling));
- 
- 	clear_cpu_topology(cpu);
- }
- 
  #ifdef CONFIG_ACPI
 +static bool __init acpi_cpu_is_threaded(int cpu)
 +{
 +	int is_threaded = acpi_pptt_cpu_is_thread(cpu);
 +
 +	/*
 +	 * if the PPTT doesn't have thread information, assume a homogeneous
 +	 * machine and return the current CPU's thread state.
 +	 */
 +	if (is_threaded < 0)
 +		is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
 +
 +	return !!is_threaded;
 +}
 +
  /*
   * Propagate the topology information of the processor_topology_node tree to the
   * cpu_topology array.
   */
- static int __init parse_acpi_topology(void)
+ int __init parse_acpi_topology(void)
  {
 -	bool is_threaded;
  	int cpu, topology_id;
  
+ 	if (acpi_disabled)
+ 		return 0;
+ 
 -	is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
 -
  	for_each_possible_cpu(cpu) {
  		int i, cache_id;
  

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