From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Will Deacon <Will.Deacon@arm.com>,
Olof Johansson <olof@lixom.net>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
Mark Rutland <Mark.Rutland@arm.com>,
"graeme.gregory@linaro.org" <graeme.gregory@linaro.org>,
Sudeep Holla <Sudeep.Holla@arm.com>,
"jcm@redhat.com" <jcm@redhat.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Mark Brown <broonie@kernel.org>, Robert Richter <rric@kernel.org>,
Timur Tabi <timur@codeaurora.org>,
Ashwin Chaugule <ashwinc@codeaurora.org>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.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 v10 10/21] ARM64 / ACPI: Get PSCI flags in FADT for PSCI init
Date: Mon, 16 Mar 2015 18:41:30 +0000 [thread overview]
Message-ID: <20150316184130.GB13335@red-moon> (raw)
In-Reply-To: <5506C255.3020307@linaro.org>
On Mon, Mar 16, 2015 at 11:45:25AM +0000, Hanjun Guo wrote:
> On 2015年03月13日 22:51, Lorenzo Pieralisi wrote:
> > On Wed, Mar 11, 2015 at 12:39:36PM +0000, Hanjun Guo wrote:
> >
> > [...]
> >
> >> +static void __init psci_0_2_set_functions(void)
> >> +{
> >> + pr_info("Using standard PSCI v0.2 function IDs\n");
> >> + psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> >> + psci_ops.cpu_suspend = psci_cpu_suspend;
> >> +
> >> + psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> >> + psci_ops.cpu_off = psci_cpu_off;
> >> +
> >> + psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> >> + psci_ops.cpu_on = psci_cpu_on;
> >> +
> >> + psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> >> + psci_ops.migrate = psci_migrate;
> >> +
> >> + psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> >> + psci_ops.affinity_info = psci_affinity_info;
> >> +
> >> + psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> >> + PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> >> + psci_ops.migrate_info_type = psci_migrate_info_type;
> >> +
> >> + arm_pm_restart = psci_sys_reset;
> >> +
> >> + pm_power_off = psci_sys_poweroff;
> >> +}
> >> +
> >> /*
> >> * PSCI Function IDs for v0.2+ are well defined so use
> >> * standard values.
> >> @@ -306,29 +335,7 @@ static int __init psci_0_2_init(struct device_node *np)
> >> }
> >> }
> >>
> >> - pr_info("Using standard PSCI v0.2 function IDs\n");
> >> - psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> >> - psci_ops.cpu_suspend = psci_cpu_suspend;
> >> -
> >> - psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> >> - psci_ops.cpu_off = psci_cpu_off;
> >> -
> >> - psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> >> - psci_ops.cpu_on = psci_cpu_on;
> >> -
> >> - psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> >> - psci_ops.migrate = psci_migrate;
> >> -
> >> - psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> >> - psci_ops.affinity_info = psci_affinity_info;
> >> -
> >> - psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> >> - PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> >> - psci_ops.migrate_info_type = psci_migrate_info_type;
> >> -
> >> - arm_pm_restart = psci_sys_reset;
> >> -
> >> - pm_power_off = psci_sys_poweroff;
> >> + psci_0_2_set_functions();
> >
> > You should have factored out the firmware version probing too, that's
> > the only way we can detect the PSCI firmware version when booting through
> > ACPI. You can end up initializing pointers for v0.2+ with a mismatching
> > version implemented in PSCI firmware, eg 0.1.
> >
> > We should do that incrementally, I will put together a patch to
> > factor out the FW version probing first, you can rebase on top of it.
>
> Incrementally patches on top of this patch set? I think v10 of this
> patch set is ready for merge, but I'm open for suggestions if we will
> not miss the merge window for Catalin.
I gave you my suggestion, I will try to get the prerequisite patch
queued asap, it is not a big deal but that's something that should be
fixed otherwise I would not have flagged this up.
I will post the patch asap, if we fail to get that in we will see what
to do, I do not expect this to be a blocking point.
> >
> >> out_put_node:
> >> of_node_put(np);
> >> @@ -381,7 +388,7 @@ static const struct of_device_id psci_of_match[] __initconst = {
> >> {},
> >> };
> >>
> >> -int __init psci_init(void)
> >> +int __init psci_dt_init(void)
> >> {
> >> struct device_node *np;
> >> const struct of_device_id *matched_np;
> >> @@ -396,6 +403,29 @@ int __init psci_init(void)
> >> return init_fn(np);
> >> }
> >>
> >> +/*
> >> + * We use PSCI 0.2+ when ACPI is deployed on ARM64 and it's
> >> + * explicitly clarified in SBBR
> >> + */
> >> +int __init psci_acpi_init(void)
> >> +{
> >> + if (!acpi_psci_present()) {
> >> + pr_info("is not implemented in ACPI.\n");
> >> + return -EOPNOTSUPP;
> >> + }
> >
> > If PSCI is not present, that's a problem related to SMP init, right ?
> > That's where a warning should be printed if any, not here, the SBBR
> > mandates PSCI as secondaries bring up method, warn otherwise.
>
> The SBBR is also said that if PSCI is not available, Parking protocol
> will be used as secondaries bring up method, so I said that it is ok
> to me that we don't print warn message for no PSCI support when parsing
> FADT.
>
> So maybe we can go back to the previous solution, print some warning
> message if no PSCI when parsing FADT?
You answered your own question. It is not what it is mandated, but if
a platform boots with parking protocol, do you think the information
you are printing in:
if (!acpi_psci_present()) {
pr_info("is not implemented in ACPI.\n");
^^^
is useful to them ?
What should be flagged up is a missing boot method for secondaries,
a missing PSCI is not per-se an error, that's why I said it should
be done when preparing CPUs for SMP init.
No big deal at all, but I would remove the pr_info above.
Lorenzo
next prev parent reply other threads:[~2015-03-16 18:41 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 12:39 [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 01/21] ACPI / table: Use pr_debug() instead of pr_info() for MADT table scanning Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 02/21] ACPI: add arm64 to the platforms that use ioremap Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 03/21] ARM64: allow late use of early_ioremap Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 04/21] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 05/21] ACPI: fix acpi_os_ioremap for arm64 Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 06/21] ACPI / sleep: Introduce CONFIG_ACPI_GENERIC_SLEEP Hanjun Guo
2015-03-12 9:32 ` Lorenzo Pieralisi
2015-03-12 22:57 ` Rafael J. Wysocki
2015-03-13 3:31 ` Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 07/21] ARM64 / ACPI: Introduce PCI stub functions for ACPI Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 08/21] ARM64 / ACPI: Introduce early_param "acpi=" to enable/disable ACPI Hanjun Guo
2015-03-18 11:35 ` Lorenzo Pieralisi
2015-03-18 20:07 ` Ard Biesheuvel
2015-03-19 2:30 ` Hanjun Guo
2015-03-19 10:04 ` Lorenzo Pieralisi
2015-03-11 12:39 ` [PATCH v10 09/21] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo
2015-03-18 16:52 ` Catalin Marinas
2015-03-11 12:39 ` [PATCH v10 10/21] ARM64 / ACPI: Get PSCI flags in FADT for PSCI init Hanjun Guo
2015-03-13 14:51 ` Lorenzo Pieralisi
2015-03-16 11:45 ` Hanjun Guo
2015-03-16 18:41 ` Lorenzo Pieralisi [this message]
2015-03-11 12:39 ` [PATCH v10 11/21] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 12/21] ARM64 / ACPI: Parse MADT for SMP initialization Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 13/21] ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID Hanjun Guo
2015-03-12 9:51 ` Lorenzo Pieralisi
2015-03-12 10:16 ` Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 14/21] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo
2015-03-12 15:41 ` Lorenzo Pieralisi
2015-03-12 23:02 ` Rafael J. Wysocki
2015-03-11 12:39 ` [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo
2015-03-18 18:41 ` Will Deacon
2015-03-19 3:45 ` Hanjun Guo
2015-03-19 10:12 ` Lorenzo Pieralisi
2015-03-19 19:37 ` Will Deacon
2015-03-20 13:07 ` Hanjun Guo
2015-03-20 14:25 ` Lorenzo Pieralisi
2015-03-21 21:38 ` Lorenzo Pieralisi
2015-03-11 12:39 ` [PATCH v10 16/21] irqchip: Add GICv2 specific ACPI boot support Hanjun Guo
[not found] ` <CACxGe6uWwts6X=Yc2ioBdQizXkF1_YgoNNOsREWirk2MFBVDHg@mail.gmail.com>
2015-03-11 23:11 ` Jason Cooper
2015-03-12 1:46 ` Hanjun Guo
2015-03-12 5:12 ` Jason Cooper
2015-03-12 7:31 ` Hanjun Guo
2015-03-13 17:15 ` Jason Cooper
2015-03-14 8:47 ` Grant Likely
2015-03-14 11:43 ` Catalin Marinas
2015-03-12 10:14 ` Marc Zyngier
2015-03-14 18:44 ` Jason Cooper
2015-03-11 12:39 ` [PATCH v10 17/21] clocksource / arch_timer: Parse GTDT to initialize arch timer Hanjun Guo
2015-03-18 18:34 ` Will Deacon
2015-03-20 13:49 ` Daniel Lezcano
2015-03-11 12:39 ` [PATCH v10 18/21] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2015-03-12 18:21 ` Lorenzo Pieralisi
2015-03-13 3:28 ` Hanjun Guo
2015-03-13 11:04 ` Lorenzo Pieralisi
2015-03-16 11:33 ` Hanjun Guo
2015-03-17 12:50 ` Lorenzo Pieralisi
2015-03-18 9:18 ` Lorenzo Pieralisi
2015-03-18 15:06 ` Rafael J. Wysocki
2015-03-19 1:16 ` Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 19/21] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 20/21] Documentation: ACPI for ARM64 Hanjun Guo
2015-03-11 12:39 ` [PATCH v10 21/21] ARM64 / ACPI: additions of ACPI documentation for arm64 Hanjun Guo
2015-03-12 13:26 ` [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1 Timur Tabi
2015-03-16 5:07 ` Suthikulpanit, Suravee
2015-03-18 19:05 ` Will Deacon
2015-03-18 19:09 ` Will Deacon
2015-03-19 4:09 ` Hanjun Guo
2015-03-19 10:17 ` Lorenzo Pieralisi
2015-03-19 19:39 ` Will Deacon
2015-03-24 22:02 ` Grant Likely
2015-03-25 11:24 ` Will Deacon
2015-03-25 11:54 ` Rafael J. Wysocki
2015-03-25 11:38 ` Will Deacon
2015-03-25 12:16 ` Rafael J. Wysocki
2015-03-28 12:34 ` Grant Likely
2015-03-26 10:24 ` Lorenzo Pieralisi
2015-03-20 18:54 ` Will Deacon
2015-03-21 3:17 ` Hanjun Guo
2015-03-21 7:03 ` Hanjun Guo
[not found] ` <CAFoFrHatzS3MwGVeOPPjY1R1sfBRYnJjgbQjvfzi6xS+XYD14g@mail.gmail.com>
2015-03-22 21:05 ` Julien Grall
2015-03-22 21:49 ` Rafael J. Wysocki
2015-03-22 21:32 ` Julien Grall
2015-03-22 22:11 ` Rafael J. Wysocki
2015-03-23 1:37 ` Hanjun Guo
2015-03-23 18:39 ` Stefano Stabellini
2015-03-23 18:32 ` Stefano Stabellini
2015-03-24 13:46 ` Hanjun Guo
2015-03-20 13:18 ` Mark Salter
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=20150316184130.GB13335@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=Sudeep.Holla@arm.com \
--cc=Will.Deacon@arm.com \
--cc=arnd@arndb.de \
--cc=ashwinc@codeaurora.org \
--cc=broonie@kernel.org \
--cc=graeme.gregory@linaro.org \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--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=olof@lixom.net \
--cc=rjw@rjwysocki.net \
--cc=rric@kernel.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=timur@codeaurora.org \
--cc=tomasz.nowicki@linaro.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;
as well as URLs for NNTP newsgroup(s).