[PATCH] x86: fix 32-bit *_cpu_data initializers

[Krzysztof Mazur]

The commit 27be457000211a6903968dfce06d5f73f051a217
(x86 idle: remove 32-bit-only "no-hlt" parameter, hlt_works_ok flag)
removed the hlt_works_ok flag from struct cpuinfo_x86, but
boot_cpu_data and new_cpu_data initializers were not changed causing
setting f00f_bug flag, instead of fdiv_bug. If CONFIG_X86_F00F_BUG
is not set the f00f_bug flag is never cleared.

To avoid such problems in future C99-style initialization is now used.

Signed-off-by: Krzysztof Mazur <krzysiek@xxxxxxxxxxxx>
---
$ cat < /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 13
model name	: Intel(R) Pentium(R) M processor 1.73GHz
stepping	: 8
microcode	: 0x20
cpu MHz		: 800.000
cache size	: 2048 KB
fdiv_bug	: no
f00f_bug	: yes
...
	
By the way now in struct cpuinfo_x86 for 32-bit systems pad0
should be extended to 2 bytes or removed, because now 32-bit
specific bugs area have now 6 bytes + pad0.

 arch/x86/kernel/setup.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 84d3285..90d8cc9 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -171,9 +171,15 @@ static struct resource bss_resource = {
 
 #ifdef CONFIG_X86_32
 /* cpu data as detected by the assembly code in head.S */
-struct cpuinfo_x86 new_cpu_data __cpuinitdata = {0, 0, 0, 0, -1, 1, 0, 0, -1};
+struct cpuinfo_x86 new_cpu_data __cpuinitdata = {
+	.wp_works_ok = -1,
+	.fdiv_bug = -1,
+};
 /* common cpu data for all cpus */
-struct cpuinfo_x86 boot_cpu_data __read_mostly = {0, 0, 0, 0, -1, 1, 0, 0, -1};
+struct cpuinfo_x86 boot_cpu_data __read_mostly = {
+	.wp_works_ok = -1,
+	.fdiv_bug = -1,
+};
 EXPORT_SYMBOL(boot_cpu_data);
 
 unsigned int def_to_bigsmp;
-- 
1.8.2.rc1.362.gc8d5142

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/