linux-toradex.git/arch/x86/include/asm/mpspec_def.h, branch v4.4.5 Linux kernel for Apalis and Colibri modules MCA: delete all remaining traces of microchannel bus support. 2012-05-17T23:06:13+00:00 Paul Gortmaker paul.gortmaker@windriver.com 2012-05-17T23:06:13+00:00 bb8187d35f820671d6dd76700d77a6b55f95e2c5 Hardware with MCA bus is limited to 386 and 486 class machines that are now 20+ years old and typically with less than 32MB of memory. A quick search on the internet, and you see that even the MCA hobbyist/enthusiast community has lost interest in the early 2000 era and never really even moved ahead from the 2.4 kernels to the 2.6 series. This deletes anything remaining related to CONFIG_MCA from core kernel code and from the x86 architecture. There is no point in carrying this any further into the future. One complication to watch for is inadvertently scooping up stuff relating to machine check, since there is overlap in the TLA name space (e.g. arch/x86/boot/mca.c). Cc: Thomas Gleixner <tglx@linutronix.de> Cc: James Bottomley <JBottomley@Parallels.com> Cc: x86@kernel.org Acked-by: Ingo Molnar <mingo@elte.hu> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 
Hardware with MCA bus is limited to 386 and 486 class machines
that are now 20+ years old and typically with less than 32MB
of memory.  A quick search on the internet, and you see that
even the MCA hobbyist/enthusiast community has lost interest
in the early 2000 era and never really even moved ahead from
the 2.4 kernels to the 2.6 series.

This deletes anything remaining related to CONFIG_MCA from core
kernel code and from the x86 architecture.  There is no point in
carrying this any further into the future.

One complication to watch for is inadvertently scooping up
stuff relating to machine check, since there is overlap in
the TLA name space (e.g. arch/x86/boot/mca.c).

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: James Bottomley <JBottomley@Parallels.com>
Cc: x86@kernel.org
Acked-by: Ingo Molnar <mingo@elte.hu>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
x86: Fix APIC ID sizing bug on larger systems, clean up MAX_APICS confusion 2011-01-05T13:09:23+00:00 Yinghai Lu yinghai@kernel.org 2011-01-05T00:38:52+00:00 cb2ded37fd2e1039f96c8c892da024a8f033add5 Found one x2apic pre-enabled system, x2apic_mode suddenly get corrupted after register some cpus, when compiled CONFIG_NR_CPUS=255 instead of 512. It turns out that generic_processor_info() ==> phyid_set(apicid, phys_cpu_present_map) causes the problem. phys_cpu_present_map is sized by MAX_APICS bits, and pre-enabled system some cpus have an apic id > 255. The variable after phys_cpu_present_map may get corrupted silently: ffffffff828e8420 B phys_cpu_present_map ffffffff828e8440 B apic_verbosity ffffffff828e8444 B local_apic_timer_c2_ok ffffffff828e8448 B disable_apic ffffffff828e844c B x2apic_mode ffffffff828e8450 B x2apic_disabled ffffffff828e8454 B num_processors ... Actually phys_cpu_present_map is referenced via apic id, instead index. We should use MAX_LOCAL_APIC instead MAX_APICS. For 64-bit it will be 32768 in all cases. BSS will increase by 4k bytes on 64-bit: text data bss dec filename 21696943 4193748 12787712 38678403 vmlinux.before 21696943 4193748 12791808 38682499 vmlinux.after No change on 32bit. Finally we can remove MAX_APCIS that was rather confusing. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: H. Peter Anvin <hpa@linux.intel.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> LKML-Reference: <4D23BD9C.3070102@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Found one x2apic pre-enabled system, x2apic_mode suddenly get
corrupted after register some cpus, when compiled
CONFIG_NR_CPUS=255 instead of 512.

It turns out that generic_processor_info() ==> phyid_set(apicid,
phys_cpu_present_map) causes the problem.

phys_cpu_present_map is sized by MAX_APICS bits, and pre-enabled
system some cpus have an apic id > 255.

The variable after phys_cpu_present_map may get corrupted
silently:

 ffffffff828e8420 B phys_cpu_present_map
 ffffffff828e8440 B apic_verbosity
 ffffffff828e8444 B local_apic_timer_c2_ok
 ffffffff828e8448 B disable_apic
 ffffffff828e844c B x2apic_mode
 ffffffff828e8450 B x2apic_disabled
 ffffffff828e8454 B num_processors
 ...

Actually phys_cpu_present_map is referenced via apic id, instead
index. We should use MAX_LOCAL_APIC instead MAX_APICS.

For 64-bit it will be 32768 in all cases. BSS will increase by 4k bytes
on 64-bit:

	text		data		bss		dec		filename
	21696943	4193748		12787712	38678403	vmlinux.before
	21696943	4193748		12791808	38682499	vmlinux.after

No change on 32bit.

Finally we can remove MAX_APCIS that was rather confusing.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
LKML-Reference: <4D23BD9C.3070102@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: rename all fields of mpf_intel mpf_X to X 2009-01-08T14:37:37+00:00 Jaswinder Singh Rajput jaswinder@infradead.org 2009-01-08T10:13:26+00:00 1eb1b3b65dc3e3ffcc6a60e115c085c0c11c1077 Impact: cleanup, solve 80 columns wrap problems It would be cleaner to rename all the mpf->mpf_X fields to mpf->X - that alone would give 4 characters per usage site. (we already know that it's an 'mpf' entity - no need to duplicate that in the field too) Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Impact: cleanup, solve 80 columns wrap problems

It would be cleaner to rename all the mpf->mpf_X fields to
mpf->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpf' entity -
no need to duplicate that in the field too)

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: rename intel_mp_floating to mpf_intel 2009-01-08T14:37:37+00:00 Jaswinder Singh Rajput jaswinder@infradead.org 2009-01-08T10:12:46+00:00 41401db698cbb5d1869776bf336881db267e7d19 Impact: cleanup, solve 80 columns wrap problems intel_mp_floating should be renamed to mpf_intel. The reason: the 'f' in MPF already means 'floating' which means MP Floating pointer structure - no need to repeat that in the type name. Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Impact: cleanup, solve 80 columns wrap problems

intel_mp_floating should be renamed to mpf_intel.

The reason: the 'f' in MPF already means 'floating'
which means MP Floating pointer structure -
no need to repeat that in the type name.

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: rename all fields of mpc_table mpc_X to X 2009-01-05T13:08:34+00:00 Jaswinder Singh Rajput jaswinder@infradead.org 2009-01-04T16:52:56+00:00 6c65da50bd4589b6b627d4842b8e6705a0ccaab5 Impact: cleanup, solve 80 columns wrap problems It would be cleaner to rename all the mpc->mpc_X fields to mpc->X - that alone would give 4 characters per usage site. (we already know that it's an 'mpc' entity - no need to duplicate that in the field too) Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Impact: cleanup, solve 80 columns wrap problems

It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: rename all fields of mpc_oemtable oem_X to X 2009-01-05T13:08:34+00:00 Jaswinder Singh Rajput jaswinder@infradead.org 2009-01-04T16:30:46+00:00 a1d0272a4676460787bcd7352414e0286763968d Impact: cleanup, solve 80 columns wrap problems It would be cleaner to rename all the mpc->oem_X fields to mpc->X - that alone would give 4 characters per usage site. (we already know that it's an 'oem' entity - no need to duplicate that in the field too) Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Impact: cleanup, solve 80 columns wrap problems

It would be cleaner to rename all the mpc->oem_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'oem' entity -
no need to duplicate that in the field too)

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: rename all fields of mpc_bus mpc_X to X 2009-01-05T13:08:33+00:00 Jaswinder Singh Rajput jaswinder@infradead.org 2009-01-04T16:29:26+00:00 d4c715fad5604f25ea1e5c90f280cb818851c10b Impact: cleanup, solve 80 columns wrap problems It would be cleaner to rename all the mpc->mpc_X fields to mpc->X - that alone would give 4 characters per usage site. (we already know that it's an 'mpc' entity - no need to duplicate that in the field too) Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Impact: cleanup, solve 80 columns wrap problems

It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: rename all fields of mpc_cpu mpc_X to X 2009-01-05T13:08:33+00:00 Jaswinder Singh Rajput jaswinder@infradead.org 2009-01-04T16:28:25+00:00 c4563826b72b0d12500260093179a660e79bf412 Impact: cleanup, solve 80 columns wrap problems It would be cleaner to rename all the mpc->mpc_X fields to mpc->X - that alone would give 4 characters per usage site. (we already know that it's an 'mpc' entity - no need to duplicate that in the field too) Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Impact: cleanup, solve 80 columns wrap problems

It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: rename all fields of mpc_intsrc mpc_X to X 2009-01-05T13:08:32+00:00 Jaswinder Singh Rajput jaswinder@infradead.org 2009-01-04T16:26:44+00:00 e253b396b145311477b23c176e868e5af6f79174 Impact: cleanup, solve 80 columns wrap problems It would be cleaner to rename all the mpc->mpc_X fields to mpc->X - that alone would give 4 characters per usage site. (we already know that it's an 'mpc' entity - no need to duplicate that in the field too) Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Impact: cleanup, solve 80 columns wrap problems

It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: rename all fields of mpc_lintsrc mpc_X to X 2009-01-05T13:08:31+00:00 Jaswinder Singh Rajput jaswinder@infradead.org 2009-01-04T16:25:53+00:00 b5ced7cdb018b8728ddcfb175c26f30cc185cf66 Impact: cleanup, solve 80 columns wrap problems It would be cleaner to rename all the mpc->mpc_X fields to mpc->X - that alone would give 4 characters per usage site. (we already know that it's an 'mpc' entity - no need to duplicate that in the field too) Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Impact: cleanup, solve 80 columns wrap problems

It would be cleaner to rename all the mpc->mpc_X fields to
mpc->X - that alone would give 4 characters per usage site.
(we already know that it's an 'mpc' entity -
no need to duplicate that in the field too)

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>