From: geoff@infradead.org (Geoff Levand)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 08/18] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way
Date: Mon, 18 Aug 2014 11:56:52 -0700 [thread overview]
Message-ID: <1408388212.22761.100.camel@smoke> (raw)
In-Reply-To: <1407166105-17675-9-git-send-email-hanjun.guo@linaro.org>
Hi Hanjun,
On Mon, 2014-08-04 at 23:28 +0800, Hanjun Guo wrote:
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -14,6 +14,27 @@
>
> /* Basic configuration for ACPI */
> #ifdef CONFIG_ACPI
By having this preprocessor conditional in the header leads
to a proliferation of preprocessor conditionals since any
code that includes this header will also need to have
preprocessor conditionals. Another down side of having
this is that this code will not get a build test for
builds with CONFIG_ACPI=n.
> +/*
> + * ACPI 5.1 only has two explicit methods to
> + * boot up SMP, PSCI and Parking protocol,
> + * but the Parking protocol is only defined
> + * 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.
> + *
> + * This enum is intend to make the boot method
> + * scalable when above updates are happended,
> + * which NOT means to support all of them.
> + */
> +enum acpi_smp_boot_protocol {
> + ACPI_SMP_BOOT_PSCI,
> + ACPI_SMP_BOOT_PARKING_PROTOCOL,
> + ACPI_SMP_BOOT_PROTOCOL_MAX
> +};
> +
> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
The name smp_boot_protocol() seems like it would be a generic
routine, but it is acpi specific. Maybe:
enum acpi_boot_protocol_type {...};
enum acpi_boot_protocol_type acpi_boot_protocol(void);
> --- a/arch/arm64/kernel/cpu_ops.c
> +++ b/arch/arm64/kernel/cpu_ops.c
> @@ -49,12 +51,44 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
> return NULL;
> }
>
> +#ifdef CONFIG_ACPI
> +/*
> + * Get a cpu's boot method in the ACPI way.
> + */
> +static char * __init acpi_get_cpu_boot_method(void)
> +{
> + /*
> + * For ACPI 5.1, only two kind of methods are provided,
> + * Parking protocol and PSCI, but Parking protocol is
> + * specified for ARMv7 only, so make PSCI as the only method
> + * for SMP initialization before the ACPI spec or Parking
> + * protocol spec is updated.
> + */
> + switch (smp_boot_protocol()) {
> + case ACPI_SMP_BOOT_PSCI:
> + return "psci";
> + case ACPI_SMP_BOOT_PARKING_PROTOCOL:
> + default:
> + return NULL;
> + }
> +}
> +#else
> +static inline char * __init acpi_get_cpu_boot_method(void) { return NULL; }
> +#endif
Since this is inside a C source file, the inline keyword
isn't needed since the optimizer will inline regardless.
With that said, I think it would be cleaner to have this
as:
static char * __init acpi_get_cpu_boot_method(void)
{
#ifdef CONFIG_ACPI
return NULL;
#else
...
#endif
}
Or better to make smp_boot_protocol() callable regardless
of CONFIG_ACPI and then no preprocessor conditionals at all
would be needed.
> +
> /*
> - * Read a cpu's enable method from the device tree and record it in cpu_ops.
> + * Read a cpu's enable method and record it in cpu_ops.
> */
> int __init cpu_read_ops(struct device_node *dn, int cpu)
> {
> - const char *enable_method = of_get_property(dn, "enable-method", NULL);
> + const char *enable_method;
> +
> + if (!acpi_disabled) {
> + enable_method = acpi_get_cpu_boot_method();
> + goto get_ops;
> + }
> +
> + enable_method = of_get_property(dn, "enable-method", NULL);
> if (!enable_method) {
> /*
> * The boot CPU may not have an enable method (e.g. when
> @@ -66,10 +100,17 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
> return -ENOENT;
> }
>
> +get_ops:
> cpu_ops[cpu] = cpu_get_ops(enable_method);
> if (!cpu_ops[cpu]) {
> - pr_warn("%s: unsupported enable-method property: %s\n",
> - dn->full_name, enable_method);
> + if (acpi_disabled) {
> + pr_warn("%s: unsupported enable-method property: %s\n",
> + dn->full_name, enable_method);
> + } else {
> + pr_warn("CPU %d: boot protocol unsupported or unknown\n",
> + cpu);
> + }
> +
Can't we have this more integrated, maybe something like this?
enable_method = acpi_disabled ? of_get_property(dn, "enable-method", NULL)
: acpi_get_cpu_boot_method();
message = acpi_disabled ? dn->full_name : "";
...
pr_warn("CPU %d: %s unsupported enable-method property: %s\n",
cpu, message, enable_method)
-Geoff
next prev parent reply other threads:[~2014-08-18 18:56 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-04 15:28 [PATCH v2 00/18] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 01/18] ARM64: Move the init of cpu_logical_map(0) before unflatten_device_tree() Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 02/18] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo
2014-08-18 18:30 ` Sudeep Holla
2014-08-19 9:35 ` Hanjun Guo
2014-08-19 9:47 ` Sudeep Holla
2014-08-04 15:28 ` [PATCH v2 03/18] ARM64 / ACPI: Introduce lowlevel suspend function Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 04/18] ARM64 / ACPI: Make PCI optional for ACPI on ARM64 Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 05/18] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init Hanjun Guo
2014-08-18 14:27 ` Catalin Marinas
2014-08-19 3:50 ` Hanjun Guo
2014-08-19 11:10 ` Mark Rutland
2014-08-19 12:13 ` Hanjun Guo
2014-08-19 22:55 ` Moore, Robert
2014-08-20 4:12 ` Hanjun Guo
2014-08-18 18:32 ` Sudeep Holla
2014-08-19 10:39 ` Hanjun Guo
2014-08-19 11:07 ` Sudeep Holla
2014-08-04 15:28 ` [PATCH v2 06/18] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map Hanjun Guo
2014-08-18 14:27 ` Catalin Marinas
2014-08-19 7:36 ` Hanjun Guo
2014-08-20 14:38 ` Catalin Marinas
2014-08-21 2:51 ` Hanjun Guo
2014-08-18 18:33 ` Sudeep Holla
2014-08-19 11:00 ` Hanjun Guo
2014-08-19 16:46 ` [Linaro-acpi] " Zi Shen Lim
2014-08-20 3:24 ` Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 07/18] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo
2014-08-07 1:41 ` Zheng, Lv
2014-08-07 10:28 ` Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 08/18] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way Hanjun Guo
2014-08-18 14:27 ` Catalin Marinas
2014-08-19 8:32 ` Hanjun Guo
2014-08-20 14:52 ` Catalin Marinas
2014-08-21 3:06 ` Hanjun Guo
2014-08-18 18:34 ` Sudeep Holla
2014-08-19 11:26 ` Hanjun Guo
2014-08-18 18:56 ` Geoff Levand [this message]
2014-08-19 12:11 ` Hanjun Guo
2014-08-19 19:25 ` Geoff Levand
2014-08-20 3:25 ` Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 09/18] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo
2014-08-18 14:27 ` Catalin Marinas
2014-08-19 8:37 ` Hanjun Guo
2014-08-20 14:56 ` Catalin Marinas
2014-08-21 3:25 ` Hanjun Guo
2014-08-18 18:34 ` Sudeep Holla
2014-08-19 11:29 ` Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 10/18] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo
2014-08-18 18:34 ` Sudeep Holla
2014-08-19 11:36 ` Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 11/18] ACPI / table: Add new function to get table entries Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 12/18] ARM64 / ACPI: Add GICv2 specific ACPI boot support Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 13/18] ARM64 / ACPI: Parse GTDT to initialize arch timer Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 14/18] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 15/18] ARM64 / ACPI: Introduce early_param for "acpi" and set ACPI default off Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 16/18] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 17/18] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2014-08-18 14:27 ` Catalin Marinas
2014-08-19 8:38 ` Hanjun Guo
2014-08-04 15:28 ` [PATCH v2 18/18] Documentation: ACPI for ARM64 Hanjun Guo
2014-08-04 20:48 ` Randy Dunlap
2014-08-05 3:36 ` Hanjun Guo
[not found] ` <CAJRNFK+UfJhGR65tOecy=X+YdHQHiNPZ4p_p8LUxhRL3GW5gFw@mail.gmail.com>
2014-08-05 3:34 ` [Linaro-acpi] [PATCH v2 00/18] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2014-08-18 17:08 ` Alexander Spyridakis
2014-08-18 18:11 ` Graeme Gregory
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=1408388212.22761.100.camel@smoke \
--to=geoff@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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