[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f0aeb0a-5e72-8327-2406-a78ad783f6f2@kernel.org>
Date: Fri, 7 Oct 2016 12:31:41 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Chen Yu <yu.c.chen@...el.com>, linux-pm@...r.kernel.org,
x86@...nel.org
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...e.de>,
Pavel Machek <pavel@....cz>, Brian Gerst <brgerst@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
Varun Koyyalagunta <cpudebug@...ttech.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4][RFC v2] PM / sleep: Introduce arch-specific hook for
disable/enable nonboot cpus
On 06/25/2016 09:18 AM, Chen Yu wrote:
> There is requirement that we need to do some arch-specific
> operations before putting the nonboot CPUs offline/online.
> One of the requirements comes from the hibernation resume
> process on x86_64, we need to kick all the offlin-CPUs
> online and offline again, in order to put them in a safe
> state, thus to avoid possible unwilling wake up during
> hibernation resume.
>
> Signed-off-by: Chen Yu <yu.c.chen@...el.com>
> ---
> kernel/cpu.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index d25266e..ce6e5e4 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -1017,6 +1017,16 @@ EXPORT_SYMBOL_GPL(cpu_up);
> #ifdef CONFIG_PM_SLEEP_SMP
> static cpumask_var_t frozen_cpus;
>
> +void __weak arch_disable_nonboot_cpus_pre(void)
I don't like using __weak. It penalizes code size on architectures that
don't hook these functions. My preferred pattern is:
include/linux/something.h:
#include <asm/something.h>
#ifndef arch_do_xyz
static inline void arch_do_xyz() {}
#endif
arch/whatever/asm/something.h:
extern void arch_do_xyz(); /* or static inline... */
#define arch_do_xyz
This is totally free for architectures that don't have the hooks and it
can potentially be inlined on architectures that do have the hooks.
Everyone wins except that it's about five additional lines of code.
--Andy
Powered by blists - more mailing lists