[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.03.1304021325230.1171@syhkavp.arg>
Date: Tue, 2 Apr 2013 13:34:22 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Stefano Stabellini <stefano.stabellini@...citrix.com>
cc: xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Will Deacon <will.deacon@....com>,
Arnd Bergmann <arnd@...db.de>, rob.herring@...xeda.com
Subject: Re: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on
xen
On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> Split xen_guest_init in two functions, one of them (xen_early_init) is
> going to be called very early from setup_arch.
>
> Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> platform. xen_smp_init just sets smp_ops to psci_smp_ops.
>
> Introduce a dependency for ARM_PSCI in XEN.
The Kconfig stuff should be more understandable to "normal" users
configuring the kernel. Hence it might make more sense for Xen to
select PSCI rather than making it a prerequisite.
[...]
> @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int cpu)
> return 0;
> }
>
> +static void __init xen_smp_init(void)
> +{
> + if (psci_smp_available())
> + smp_set_ops(&psci_smp_ops);
> +}
> +
I still don't understand why you need to do this. Why can't you just
rely on the next priority which is to set PSCI ops by default if
available? Using this hook for Xen doesn't look justified. As it is,
you break MCPM.
As I explained to you, MCPM will end up using PSCI as well when
available, which I think should be sufficient for your concern.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists