aboutsummaryrefslogtreecommitdiffstats
path: root/arch/i386/kernel/cpu/umc.c
diff options
context:
space:
mode:
authorThomas Renninger <trenn@suse.de>2007-05-02 19:27:22 +0200
committerAndi Kleen <andi@basil.nowhere.org>2007-05-02 19:27:22 +0200
commit35060b6a9a4e1c89bc6fbea61090e302dbc61847 (patch)
tree4f9ceb9b30e87799a011413523a332bc6bb262a8 /arch/i386/kernel/cpu/umc.c
parenta3193348d407baaa7aef79decfa0e9a7fef74a17 (diff)
downloadkernel_samsung_tuna-35060b6a9a4e1c89bc6fbea61090e302dbc61847.zip
kernel_samsung_tuna-35060b6a9a4e1c89bc6fbea61090e302dbc61847.tar.gz
kernel_samsung_tuna-35060b6a9a4e1c89bc6fbea61090e302dbc61847.tar.bz2
[PATCH] i386: Don't delete cpu_devs data to identify different x86 types in late_initcall
In arch/i386/cpu/common.c there is: cpu_devs[X86_VENDOR_INTEL] cpu_devs[X86_VENDOR_CYRIX] cpu_devs[X86_VENDOR_AMD] ... They are all filled with data early. The data (struct) got set to NULL for all, but Intel in different late_initcall (exit_cpu_vendor) calls. I don't see what sense this makes at all, maybe something that got forgotten with the HOTPLUG_CPU extenstions? Please check/review whether initdata, cpuinitdata is still ok and this still works with HOTPLUG_CPU and without, it should... Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Cc: davej@redhat.com
Diffstat (limited to 'arch/i386/kernel/cpu/umc.c')
-rw-r--r--arch/i386/kernel/cpu/umc.c10
1 files changed, 0 insertions, 10 deletions
diff --git a/arch/i386/kernel/cpu/umc.c b/arch/i386/kernel/cpu/umc.c
index 1bf3f87..a7a4e75 100644
--- a/arch/i386/kernel/cpu/umc.c
+++ b/arch/i386/kernel/cpu/umc.c
@@ -24,13 +24,3 @@ int __init umc_init_cpu(void)
cpu_devs[X86_VENDOR_UMC] = &umc_cpu_dev;
return 0;
}
-
-//early_arch_initcall(umc_init_cpu);
-
-static int __init umc_exit_cpu(void)
-{
- cpu_devs[X86_VENDOR_UMC] = NULL;
- return 0;
-}
-
-late_initcall(umc_exit_cpu);