[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3E5A0FA7E9CA944F9D5414FEC6C7122007737623@ORSMSX105.amr.corp.intel.com>
Date: Tue, 19 Jun 2012 23:10:14 +0000
From: "Yu, Fenghua" <fenghua.yu@...el.com>
To: X86-ML <x86@...nel.org>
CC: "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Andreas Herrmann <andreas.herrmann3@....com>,
Borislav Petkov <borislav.petkov@....com>,
Henrique de Moraes Holschuh <hmh@....eng.br>,
Peter Zijlstra <peterz@...radead.org>
Subject: RE: [PATCH 2/2] x86, microcode: Make reload interface per system
> From: Borislav Petkov <bp@...64.org>
> Date: Tue, 19 Jun 2012 18:03:31 +0200
> Subject: [PATCH 2/2] x86, microcode: Make reload interface per system
> To: X86-ML <x86@...nel.org>
> Cc: "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
> Thomas Gleixner <tglx@...utronix.de>, LKML
> <linux-kernel@...r.kernel.org>, Andreas Herrmann
> <andreas.herrmann3@....com>, Borislav Petkov
> <borislav.petkov@....com>, Henrique de Moraes Holschuh
> <hmh@....eng.br>, Peter Zijlstra <peterz@...radead.org>
>
> From: Borislav Petkov <borislav.petkov@....com>
>
> The reload interface should be per-system so that a full system ucode
> reload happens (on each core) when doing
>
> echo 1 > /sys/devices/system/cpu/microcode/reload
>
> Move it to the cpu subsys directory instead of it being per-cpu.
>
> Cc: Henrique de Moraes Holschuh <hmh@....eng.br>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Signed-off-by: Borislav Petkov <borislav.petkov@....com>
> ---
> arch/x86/kernel/microcode_core.c | 32 ++++++++++++++++++++++++++++----
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/microcode_core.c
> b/arch/x86/kernel/microcode_core.c
> index 24b852b61be3..4c6f3b37ed3c 100644
> --- a/arch/x86/kernel/microcode_core.c
> +++ b/arch/x86/kernel/microcode_core.c
> @@ -351,7 +351,6 @@ static DEVICE_ATTR(version, 0400, version_show,
> NULL);
> static DEVICE_ATTR(processor_flags, 0400, pf_show, NULL);
>
> static struct attribute *mc_default_attrs[] = {
> - &dev_attr_reload.attr,
> &dev_attr_version.attr,
> &dev_attr_processor_flags.attr,
> NULL
> @@ -528,6 +527,16 @@ static const struct x86_cpu_id microcode_id[] = {
> MODULE_DEVICE_TABLE(x86cpu, microcode_id);
> #endif
>
> +static struct attribute *cpu_root_microcode_attrs[] = {
> + &dev_attr_reload.attr,
> + NULL
> +};
> +
> +static struct attribute_group cpu_root_microcode_group = {
> + .name = "microcode",
> + .attrs = cpu_root_microcode_attrs,
> +};
> +
> static int __init microcode_init(void)
> {
> struct cpuinfo_x86 *c = &cpu_data(0);
> @@ -559,9 +568,17 @@ static int __init microcode_init(void)
> if (error)
> goto out_pdev;
>
> + error = sysfs_create_group(&cpu_subsys.dev_root->kobj,
> + &cpu_root_microcode_group);
> +
> + if (error) {
> + pr_err("Error creating microcode group!\n");
> + goto out_driver;
> + }
> +
> error = microcode_dev_init();
> if (error)
> - goto out_driver;
> + goto out_ucode_group;
>
If you put sysfs_create_group() after microcode_dev_init(), out_ucode_group is unnecessary and code is a bit simpler. Microcode_dev_init() doesn't rely on sysfs_create_group() and it's a NULL function any way.
> register_syscore_ops(&mc_syscore_ops);
> register_hotcpu_notifier(&mc_cpu_notifier);
> @@ -571,7 +588,11 @@ static int __init microcode_init(void)
>
> return 0;
>
> -out_driver:
> + out_ucode_group:
> + sysfs_remove_group(&cpu_subsys.dev_root->kobj,
> + &cpu_root_microcode_group);
> +
> + out_driver:
> get_online_cpus();
> mutex_lock(µcode_mutex);
>
> @@ -580,7 +601,7 @@ out_driver:
> mutex_unlock(µcode_mutex);
> put_online_cpus();
>
> -out_pdev:
> + out_pdev:
> platform_device_unregister(microcode_pdev);
> return error;
>
> @@ -596,6 +617,9 @@ static void __exit microcode_exit(void)
> unregister_hotcpu_notifier(&mc_cpu_notifier);
> unregister_syscore_ops(&mc_syscore_ops);
>
> + sysfs_remove_group(&cpu_subsys.dev_root->kobj,
> + &cpu_root_microcode_group);
> +
> get_online_cpus();
> mutex_lock(µcode_mutex);
--
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