All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: Jan Henrik Weinstock <jan.weinstock@rwth-aachen.de>
Cc: jonas@southpole.se, stefan.kristiansson@saunalahti.fi,
	openrisc@lists.librecores.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] openrisc: use device tree to determine present cpus
Date: Sat, 30 Jan 2021 07:16:43 +0900	[thread overview]
Message-ID: <20210129221643.GZ2002709@lianli.shorne-pla.net> (raw)
In-Reply-To: <0b26eda7-229d-3dc9-f2ae-19b9212fb0ea@rwth-aachen.de>

On Fri, Jan 29, 2021 at 07:29:31PM +0100, Jan Henrik Weinstock wrote:
> This patch proposes to use the device tree to determine the present cpus
> instead of assuming all CONFIG_NRCPUS are actually present in the system.
> 
> Signed-off-by: Jan Henrik Weinstock <jan.weinstock@rwth-aachen.de>
> ---
>  arch/openrisc/kernel/smp.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/openrisc/kernel/smp.c b/arch/openrisc/kernel/smp.c
> index 29c82ef2e..75be7e34f 100644
> --- a/arch/openrisc/kernel/smp.c
> +++ b/arch/openrisc/kernel/smp.c
> @@ -16,6 +16,7 @@
>  #include <linux/sched.h>
>  #include <linux/sched/mm.h>
>  #include <linux/irq.h>
> +#include <linux/of.h>
>  #include <asm/cpuinfo.h>
>  #include <asm/mmu_context.h>
>  #include <asm/tlbflush.h>
> @@ -68,14 +69,25 @@ void __init smp_init_cpus(void)
> 
>  void __init smp_prepare_cpus(unsigned int max_cpus)
>  {
> -	int i;
> +	u32 cpu_id;
> +	struct device_node *cpu, *cpus;
> 
>  	/*
>  	 * Initialise the present map, which describes the set of CPUs
>  	 * actually populated at the present time.
>  	 */
> -	for (i = 0; i < max_cpus; i++)
> -		set_cpu_present(i, true);
> +	cpus = of_find_node_by_path("/cpus");
> +	for_each_child_of_node(cpus, cpu) {
> +		if (of_property_read_u32(cpu, "reg", &cpu_id)) {
> +			pr_warn("%s missing reg property", cpu->full_name);
> +			continue;
> +		}
> +
> +		if (cpu_id >= max_cpus)
> +			continue;
> +
> +		set_cpu_present(cpu_id, true);
> +	}

Hello, I looked into what other architectures do.  Risc-V does something similar
but it does the setup in 2 parts:

 - it uses the device tree to set possible CPU's in setup_smp. Using
   for_each_of_cpu_node and set_cpu_possible.

 - Then in smp_prepare_cpus, it loops over possible cpus with
   for_each_possible_cpu.

Note, it seems risc-v does't actually check max_cpus when setting
set_cpu_present which may be a bug.

I think the two part approach is what we want to do:

 - we should do set_cpu_possible in smp_init_cpus based on device tree.
   Basically the same as your loop above but using for_each_of_cpu_node
   and NR_CPUS.
 - we can then do set_cpu_present using for_each_possible_cpu in
   smp_prepare_cpus.

What do you think?

-Stafford

>  }
> 
>  void __init smp_cpus_done(unsigned int max_cpus)
> -- 
> 2.17.1
> 



WARNING: multiple messages have this Message-ID (diff)
From: Stafford Horne <shorne@gmail.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH] openrisc: use device tree to determine present cpus
Date: Sat, 30 Jan 2021 07:16:43 +0900	[thread overview]
Message-ID: <20210129221643.GZ2002709@lianli.shorne-pla.net> (raw)
In-Reply-To: <0b26eda7-229d-3dc9-f2ae-19b9212fb0ea@rwth-aachen.de>

On Fri, Jan 29, 2021 at 07:29:31PM +0100, Jan Henrik Weinstock wrote:
> This patch proposes to use the device tree to determine the present cpus
> instead of assuming all CONFIG_NRCPUS are actually present in the system.
> 
> Signed-off-by: Jan Henrik Weinstock <jan.weinstock@rwth-aachen.de>
> ---
>  arch/openrisc/kernel/smp.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/openrisc/kernel/smp.c b/arch/openrisc/kernel/smp.c
> index 29c82ef2e..75be7e34f 100644
> --- a/arch/openrisc/kernel/smp.c
> +++ b/arch/openrisc/kernel/smp.c
> @@ -16,6 +16,7 @@
>  #include <linux/sched.h>
>  #include <linux/sched/mm.h>
>  #include <linux/irq.h>
> +#include <linux/of.h>
>  #include <asm/cpuinfo.h>
>  #include <asm/mmu_context.h>
>  #include <asm/tlbflush.h>
> @@ -68,14 +69,25 @@ void __init smp_init_cpus(void)
> 
>  void __init smp_prepare_cpus(unsigned int max_cpus)
>  {
> -	int i;
> +	u32 cpu_id;
> +	struct device_node *cpu, *cpus;
> 
>  	/*
>  	 * Initialise the present map, which describes the set of CPUs
>  	 * actually populated at the present time.
>  	 */
> -	for (i = 0; i < max_cpus; i++)
> -		set_cpu_present(i, true);
> +	cpus = of_find_node_by_path("/cpus");
> +	for_each_child_of_node(cpus, cpu) {
> +		if (of_property_read_u32(cpu, "reg", &cpu_id)) {
> +			pr_warn("%s missing reg property", cpu->full_name);
> +			continue;
> +		}
> +
> +		if (cpu_id >= max_cpus)
> +			continue;
> +
> +		set_cpu_present(cpu_id, true);
> +	}

Hello, I looked into what other architectures do.  Risc-V does something similar
but it does the setup in 2 parts:

 - it uses the device tree to set possible CPU's in setup_smp. Using
   for_each_of_cpu_node and set_cpu_possible.

 - Then in smp_prepare_cpus, it loops over possible cpus with
   for_each_possible_cpu.

Note, it seems risc-v does't actually check max_cpus when setting
set_cpu_present which may be a bug.

I think the two part approach is what we want to do:

 - we should do set_cpu_possible in smp_init_cpus based on device tree.
   Basically the same as your loop above but using for_each_of_cpu_node
   and NR_CPUS.
 - we can then do set_cpu_present using for_each_possible_cpu in
   smp_prepare_cpus.

What do you think?

-Stafford

>  }
> 
>  void __init smp_cpus_done(unsigned int max_cpus)
> -- 
> 2.17.1
> 



  reply	other threads:[~2021-01-29 22:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 18:29 [PATCH] openrisc: use device tree to determine present cpus Jan Henrik Weinstock
2021-01-29 18:29 ` [OpenRISC] " Jan Henrik Weinstock
2021-01-29 22:16 ` Stafford Horne [this message]
2021-01-29 22:16   ` Stafford Horne
2021-01-30 11:00   ` Jan Henrik Weinstock
2021-01-30 11:00     ` [OpenRISC] " Jan Henrik Weinstock
2021-01-30 23:03     ` Stafford Horne
2021-01-30 23:03       ` [OpenRISC] " Stafford Horne
2021-01-30 23:11       ` Stafford Horne
2021-01-30 23:11         ` [OpenRISC] " Stafford Horne
2021-01-31  8:22       ` Jan Henrik Weinstock
2021-01-31  8:22         ` [OpenRISC] " Jan Henrik Weinstock
2021-01-31 21:27         ` Stafford Horne
2021-01-31 21:27           ` [OpenRISC] " Stafford Horne
2021-02-01 11:49           ` [PATCH v2] " Jan Henrik Weinstock
2021-02-01 11:49             ` [OpenRISC] " Jan Henrik Weinstock
2021-02-05 14:43             ` Stafford Horne
2021-02-05 14:43               ` [OpenRISC] " Stafford Horne
2021-02-05 16:07               ` Geert Uytterhoeven
2021-02-05 16:07                 ` [OpenRISC] " Geert Uytterhoeven
2021-02-05 22:36                 ` Stafford Horne
2021-02-05 22:36                   ` [OpenRISC] " Stafford Horne
2021-02-06  9:33                   ` Geert Uytterhoeven
2021-02-06  9:33                     ` [OpenRISC] " Geert Uytterhoeven
2021-02-08 12:16                     ` Stafford Horne
2021-02-08 12:22                       ` Geert Uytterhoeven
2021-02-08 12:22                         ` [OpenRISC] " Geert Uytterhoeven
2021-01-30 10:37 ` [PATCH] " Geert Uytterhoeven
2021-01-30 10:37   ` [OpenRISC] " Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210129221643.GZ2002709@lianli.shorne-pla.net \
    --to=shorne@gmail.com \
    --cc=jan.weinstock@rwth-aachen.de \
    --cc=jonas@southpole.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openrisc@lists.librecores.org \
    --cc=stefan.kristiansson@saunalahti.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.