From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 6/6] [RFC] arm: use PSCI if available
Date: Tue, 26 Mar 2013 15:04:44 +0000 [thread overview]
Message-ID: <20130326150444.GI20252@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <1364308875-26484-6-git-send-email-stefano.stabellini@eu.citrix.com>
Hi Stefano,
On Tue, Mar 26, 2013 at 02:41:15PM +0000, Stefano Stabellini wrote:
> Check for the presence of PSCI before setting smp_ops, use PSCI if it is
> available.
>
> This is useful because at least when running on Xen it's possible to have a
> PSCI node for example on a Versatile Express or an Exynos5 machine. In these
> cases the PSCI SMP calls should be the ones to be called.
>
> Remove virt_smp_ops and platsmp.c from mach-virt because they aren't needed
> anymore.
[...]
> +struct smp_operations __initdata psci_smp_ops = {
> + .smp_init_cpus = psci_smp_init_cpus,
> + .smp_prepare_cpus = psci_smp_prepare_cpus,
> + .smp_secondary_init = psci_secondary_init,
> + .smp_boot_secondary = psci_boot_secondary,
> +};
Whilst I like the idea of this, I don't think things will pan out this
nicely in practice. There will almost always be a level of indirection
required between the internal Linux SMP operations and the expectations of
the PSCI firmware, whether this is in CPU numbering or other,
platform-specific fields in various parameters.
Tying these two things together like this confuses the layering in my
opinion and will likely lead to potentially subtle breakages if platforms
start trying to adopt this.
If this can indeed work for the virtual platforms (Xen and KVM), then I
think it would be better expressed using `virt' smp_ops, which map directly
to PSCI, rather than putting them here. Even then, it's tying KVM and Xen
together on the firmware side of things...
Will
next prev parent reply other threads:[~2013-03-26 15:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 14:40 [PATCH v2 0/6] xen/arm: move to mach-virt and support SMP Stefano Stabellini
2013-03-26 14:41 ` [PATCH v2 1/6] xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq Stefano Stabellini
2013-03-26 14:41 ` [PATCH v2 2/6] xen/arm: SMP support Stefano Stabellini
2013-03-26 14:41 ` [PATCH v2 3/6] xen: move the xenvm machine to mach-virt Stefano Stabellini
2013-03-26 14:41 ` [PATCH v2 4/6] xen/arm: implement HYPERVISOR_vcpu_op Stefano Stabellini
2013-03-26 14:41 ` [PATCH v2 5/6] xenvm: add a simple PSCI node and a second cpu Stefano Stabellini
2013-03-26 15:00 ` Arnd Bergmann
2013-03-26 16:39 ` Stefano Stabellini
2013-03-26 14:41 ` [PATCH v2 6/6] [RFC] arm: use PSCI if available Stefano Stabellini
2013-03-26 14:58 ` Arnd Bergmann
2013-03-26 15:09 ` Stefano Stabellini
2013-03-26 15:04 ` Will Deacon [this message]
2013-03-26 15:25 ` Stefano Stabellini
2013-03-26 15:37 ` Will Deacon
2013-03-26 15:46 ` Arnd Bergmann
2013-03-26 15:55 ` Stefano Stabellini
2013-03-26 16:03 ` Nicolas Pitre
2013-03-27 11:15 ` Stefano Stabellini
2013-03-26 15:49 ` Stefano Stabellini
2013-03-26 16:01 ` Nicolas Pitre
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=20130326150444.GI20252@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--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;
as well as URLs for NNTP newsgroup(s).