linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: "hanjun.guo@linaro.org" <hanjun.guo@linaro.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	Will Deacon <Will.Deacon@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"graeme.gregory@linaro.org" <graeme.gregory@linaro.org>,
	Sudeep Holla <Sudeep.Holla@arm.com>,
	"jcm@redhat.com" <jcm@redhat.com>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
	Robert Richter <rric@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>,
	"phoenix.liyi@huawei.com" <phoenix.liyi@huawei.com>,
	Timur Tabi <timur@codeaurora.org>,
	Ashwin Chaugule <ashwinc@codeaurora.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	Mark Langsdorf <mlangsdo@redhat.com>,
	"wangyijing@huawei.com" <wangyijing@huawei.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	Tomasz Nowicki <tomasz.nowicki@linaro.org>
Subject: Re: [PATCH v8 13/21] ARM64 / ACPI: Parse MADT for SMP initialization
Date: Tue, 3 Feb 2015 13:53:48 +0000	[thread overview]
Message-ID: <20150203135348.GA31837@leverpostej> (raw)
In-Reply-To: <1422881149-8177-14-git-send-email-hanjun.guo@linaro.org>

On Mon, Feb 02, 2015 at 12:45:41PM +0000, Hanjun Guo wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map.
>
> ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and
> Parking protocol, but the Parking protocol is only specified for
> ARMv7 now, so make PSCI as the only way for the SMP boot protocol
> before some updates for the ACPI spec or the Parking protocol spec.
>
> Parking protocol patches for SMP boot will be sent to upstream when
> the new version of Parking protocol is ready.
>
> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> CC: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Tested-by: Yijing Wang <wangyijing@huawei.com>
> Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
> Tested-by: Jon Masters <jcm@redhat.com>
> Tested-by: Timur Tabi <timur@codeaurora.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h    |   2 +
>  arch/arm64/include/asm/cpu_ops.h |   1 +
>  arch/arm64/include/asm/smp.h     |   5 +-
>  arch/arm64/kernel/acpi.c         | 150 ++++++++++++++++++++++++++++++++++++++-
>  arch/arm64/kernel/cpu_ops.c      |   2 +-
>  arch/arm64/kernel/setup.c        |   7 +-
>  arch/arm64/kernel/smp.c          |   2 +-
>  7 files changed, 161 insertions(+), 8 deletions(-)

[...]

> +/**
> + * acpi_map_gic_cpu_interface - generates a logical cpu number
> + * and map to MPIDR represented by GICC structure
> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logical cpu number which maps to MPIDR
> + */
> +static int __init acpi_map_gic_cpu_interface(u64 mpidr, u8 enabled)
> +{
> +       int cpu;
> +
> +       if (mpidr == INVALID_HWID) {
> +               pr_info("Skip MADT cpu entry with invalid MPIDR\n");
> +               return -EINVAL;
> +       }
> +
> +       total_cpus++;
> +       if (!enabled)
> +               return -EINVAL;
> +
> +       if (enabled_cpus >=  NR_CPUS) {
> +               pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
> +                       NR_CPUS, total_cpus, mpidr);
> +               return -EINVAL;
> +       }
> +
> +       /* No need to check duplicate MPIDRs for the first CPU */
> +       if (enabled_cpus) {
> +               /*
> +                * Duplicate MPIDRs are a recipe for disaster. Scan
> +                * all initialized entries and check for
> +                * duplicates. If any is found just ignore the CPU.
> +                */
> +               for_each_possible_cpu(cpu) {
> +                       if (cpu_logical_map(cpu) == mpidr) {
> +                               pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +                                      mpidr);
> +                               return -EINVAL;
> +                       }
> +               }
> +
> +               /* allocate a logical cpu id for the new comer */
> +               cpu = cpumask_next_zero(-1, cpu_possible_mask);
> +       } else {
> +               /*
> +                * First GICC entry must be BSP as ACPI spec said
> +                * in section 5.2.12.15
> +                */
> +               if  (cpu_logical_map(0) != mpidr) {
> +                       pr_err("First GICC entry with MPIDR 0x%llx is not BSP\n",
> +                              mpidr);
> +                       return -EINVAL;
> +               }
> +
> +               /*
> +                * boot_cpu_init() already hold bit 0 in cpu_possible_mask
> +                * for BSP, no need to allocate again.
> +                */
> +               cpu = 0;
> +       }

If/when kexec comes, on systems where CPU0 can be hotplugged the next
kernel might boot on an AP rather than the BSP. Is there a requirement
Linux-side that CPU0 is the BSP, or is this just intended as a sanity
check of the tables the FW provided?

> +
> +       if (!acpi_psci_present())
> +               return -EOPNOTSUPP;
> +
> +       cpu_ops[cpu] = cpu_get_ops("psci");
> +       /* CPU 0 was already initialized */
> +       if (cpu) {
> +               if (!cpu_ops[cpu])
> +                       return -EINVAL;
> +
> +               if (cpu_ops[cpu]->cpu_init(NULL, cpu))
> +                       return -EOPNOTSUPP;
> +
> +               /* map the logical cpu id to cpu MPIDR */
> +               cpu_logical_map(cpu) = mpidr;
> +
> +               set_cpu_possible(cpu, true);
> +       }

In the OF case we only set CPUs possible once we've scanned all the
nodes, and only when the boot CPU was actually found in a table. We
should keep the ACPI case consistent with that.

Can we not handle all of this in a later call once we've scanned all of
the GICC structures?

[...]

> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 43ae914..1099ddc 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -449,13 +449,16 @@ void __init setup_arch(char **cmdline_p)
>         if (acpi_disabled) {
>                 unflatten_device_tree();
>                 psci_dt_init();
> +               cpu_read_bootcpu_ops();
> +#ifdef CONFIG_SMP
> +               of_smp_init_cpus();
> +#endif

I was going to say that it would be a little nicer if we had empty stubs
for functions in the !SMP case, rather than #ifdefs all over the place.
Unfortunately it looks like the way asm/smp.h is handled is generally a
mess, so this isn't so bad for now.

Thanks,
Mark.

  reply	other threads:[~2015-02-03 13:54 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-02 12:45 [PATCH v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 01/21] acpi: add arm64 to the platforms that use ioremap Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 02/21] acpi: fix acpi_os_ioremap for arm64 Hanjun Guo
2015-02-02 22:14   ` Rafael J. Wysocki
2015-02-03  9:08     ` Hanjun Guo
2015-02-03 11:37       ` Catalin Marinas
2015-02-03 11:41         ` Ard Biesheuvel
2015-02-03 17:29     ` Mark Salter
2015-02-03 22:04       ` Rafael J. Wysocki
2015-02-04 10:48         ` Russell King - ARM Linux
2015-02-04 13:22           ` Rafael J. Wysocki
2015-02-04 15:53           ` Bjorn Helgaas
2015-02-04 16:25             ` Russell King - ARM Linux
2015-02-04 16:38               ` David Woodhouse
2015-02-04 16:41               ` Bjorn Helgaas
2015-02-04 11:25       ` Catalin Marinas
2015-02-04 16:08         ` Mark Salter
2015-02-04 16:16           ` Timur Tabi
2015-02-04 17:52             ` Catalin Marinas
2015-02-04 17:57           ` Catalin Marinas
2015-02-04 18:58             ` Mark Salter
2015-02-05 10:41               ` Catalin Marinas
2015-02-05 10:47                 ` Ard Biesheuvel
2015-02-05 10:59                   ` Catalin Marinas
2015-02-05 11:14                     ` Graeme Gregory
2015-02-05 12:07                       ` Catalin Marinas
2015-02-05 12:52                         ` Graeme Gregory
2015-02-05 14:50                           ` Catalin Marinas
2015-02-05 12:55                         ` Ard Biesheuvel
2015-02-05 13:54                 ` Mark Salter
2015-02-05 16:42                   ` [Linaro-acpi] " Al Stone
2015-02-05 17:48                     ` Catalin Marinas
2015-02-05 22:16                       ` Ard Biesheuvel
2015-02-06 10:36                         ` Catalin Marinas
2015-02-06 11:08                           ` Ard Biesheuvel
2015-02-06 14:16                             ` Catalin Marinas
2015-02-07  1:44                               ` Ard Biesheuvel
2015-02-05  1:24       ` Rafael J. Wysocki
2015-02-02 12:45 ` [PATCH v8 03/21] arm64: allow late use of early_ioremap Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 04/21] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 05/21] ACPI / sleep: Introduce sleep_arm.c Hanjun Guo
2015-02-02 22:18   ` Rafael J. Wysocki
2015-02-03 16:18     ` Graeme Gregory
2015-02-02 12:45 ` [PATCH v8 06/21] ARM64 / ACPI: Introduce PCI stub functions for ACPI Hanjun Guo
2015-02-03 12:15   ` Catalin Marinas
2015-02-03 13:30     ` Hanjun Guo
2015-02-03 14:55       ` Rafael J. Wysocki
2015-02-04  9:06         ` Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 07/21] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property Hanjun Guo
2015-02-02 13:40   ` Leif Lindholm
2015-02-02 13:50     ` Graeme Gregory
2015-02-02 16:32       ` Mark Rutland
2015-02-06 10:34         ` G Gregory
2015-02-07  3:36           ` Hanjun Guo
2015-02-07  5:03             ` Ard Biesheuvel
2015-02-07  6:51               ` Hanjun Guo
2015-02-09 11:46               ` Mark Rutland
2015-02-11  2:44                 ` Ard Biesheuvel
2015-02-11  6:33                   ` Stefano Stabellini
2015-02-11  6:53                     ` Ard Biesheuvel
2015-02-11  7:07                       ` Stefano Stabellini
2015-02-02 12:45 ` [PATCH v8 09/21] ARM64 / ACPI: Disable ACPI if FADT revision is less than 5.1 Hanjun Guo
2015-02-03 17:20   ` Catalin Marinas
2015-02-04  9:38     ` Hanjun Guo
2015-02-04 13:06       ` Lorenzo Pieralisi
2015-02-05  9:45         ` Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 10/21] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 11/21] ARM64 / ACPI: Get PSCI flags in FADT for PSCI init Hanjun Guo
2015-02-04 16:43   ` Lorenzo Pieralisi
2015-02-05  9:48     ` Hanjun Guo
2015-02-05 17:11     ` [Linaro-acpi] " Al Stone
2015-02-05 17:49       ` Lorenzo Pieralisi
2015-02-05 19:03         ` Al Stone
2015-02-06  7:56           ` Hanjun Guo
2015-02-06 16:21             ` Lorenzo Pieralisi
2015-02-02 12:45 ` [PATCH v8 12/21] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 13/21] ARM64 / ACPI: Parse MADT for SMP initialization Hanjun Guo
2015-02-03 13:53   ` Mark Rutland [this message]
2015-02-04  9:05     ` Hanjun Guo
2015-02-04 10:30       ` Mark Rutland
2015-02-05  9:20         ` Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 14/21] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo
2015-02-03 14:17   ` Mark Rutland
2015-02-03 20:09     ` Catalin Marinas
2015-02-04  9:48       ` Hanjun Guo
2015-02-04 11:21         ` Catalin Marinas
2015-02-05  9:27           ` Hanjun Guo
2015-02-05 10:52             ` Catalin Marinas
2015-02-09  6:55   ` Will Deacon
2015-02-09  9:52     ` Catalin Marinas
2015-02-02 12:45 ` [PATCH v8 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo
2015-02-09  6:34   ` Will Deacon
2015-02-09  6:53     ` Hanjun Guo
2015-02-09  7:07       ` Will Deacon
2015-02-02 12:45 ` [PATCH v8 16/21] irqchip: Add GICv2 specific ACPI boot support Hanjun Guo
2015-02-02 22:23   ` Rafael J. Wysocki
2015-02-03 15:38   ` Tomasz Nowicki
2015-02-02 12:45 ` [PATCH v8 17/21] clocksource / arch_timer: Parse GTDT to initialize arch timer Hanjun Guo
2015-02-02 22:23   ` Rafael J. Wysocki
2015-02-03 13:28     ` Hanjun Guo
2015-02-04 18:59   ` Lorenzo Pieralisi
2015-02-05 10:11     ` Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 18/21] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 19/21] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 20/21] Documentation: ACPI for ARM64 Hanjun Guo
2015-02-02 19:01   ` Timur Tabi
2015-02-03  8:44     ` Hanjun Guo
2015-02-02 12:45 ` [PATCH v8 21/21] arm64: ACPI: additions of ACPI documentation for arm64 Hanjun Guo
2015-02-04  0:40   ` Al Stone
2015-02-04 18:12     ` Mark Brown
2015-02-04 19:06       ` Al Stone
2015-02-05  2:02         ` Mark Brown
2015-02-03 16:47 ` [PATCH v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1 Mark Rutland
2015-02-03 17:43   ` [Linaro-acpi] " Al Stone
2015-02-04  9:41     ` Hanjun Guo
2015-02-04 20:29 ` Timur Tabi
2015-02-05 10:16   ` Hanjun Guo
2015-02-12 10:02 ` Robert Richter
2015-02-13  2:48   ` Hanjun Guo
2015-02-19 16:10     ` Robert Richter
     [not found] ` <a314cdbbefb349acbb8f47d6e806989f@NASANEXM01D.na.qualcomm.com>
2015-02-13  0:50   ` Jonathan (Zhixiong) Zhang
2015-02-13  7:50     ` Hanjun Guo

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=20150203135348.GA31837@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Charles.Garcia-Tobin@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=Sudeep.Holla@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=arnd@arndb.de \
    --cc=ashwinc@codeaurora.org \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=graeme.gregory@linaro.org \
    --cc=grant.likely@linaro.org \
    --cc=hanjun.guo@linaro.org \
    --cc=jason@lakedaemon.net \
    --cc=jcm@redhat.com \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlangsdo@redhat.com \
    --cc=olof@lixom.net \
    --cc=phoenix.liyi@huawei.com \
    --cc=rdunlap@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=rric@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=timur@codeaurora.org \
    --cc=tomasz.nowicki@linaro.org \
    --cc=wangyijing@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).