Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit d5d9ca6d authored by Adam Henley's avatar Adam Henley Committed by Andi Kleen
Browse files

[PATCH] A few trivial spelling and grammar fixes 



A few trivial spelling and grammar mistakes picked up in
"arch/x86_64/aperture.c", "arch/x86_64/crash.c" and
"arch/x86_64/apic.c". I think all are correct fixes but am ever aware
of my fallibility :o) This is my first patch submission so all
feedback is appreciated, esp. WRT CCing to Linus, Andi and
trivial@kernel.org, is this correct? And which is the most appropriate
kernel version to diff against? If any.

Should apply cleanly to 2.6.18-rc1

Signed-off-by: default avatarAdam Henley <adamazing@gmail.com>
Signed-off-by: default avatarAndi Kleen <ak@suse.de>

-  adam
parent 3034d11c

arch/x86_64/kernel/aperture.c

+1 −1
Original line number Diff line number Diff line
@@ -48,7 +48,7 @@ static u32 __init allocate_aperture(void) 


	/* 

	 * Aperture has to be naturally aligned. This means an 2GB aperture won't

	 * have much chances to find a place in the lower 4GB of memory.

	 * have much chance of finding a place in the lower 4GB of memory.

	 * Unfortunately we cannot move it up because that would make the

	 * IOMMU useless.

	 */

arch/x86_64/kernel/apic.c

+2 −2
Original line number Diff line number Diff line
@@ -400,7 +400,7 @@ void __cpuinit setup_local_APIC (void) 
	value |= APIC_SPIV_APIC_ENABLED;



	/*

	 * Some unknown Intel IO/APIC (or APIC) errata is biting us with

	 * Some unknown Intel IO/APIC (or APIC) errata are biting us with

	 * certain networking cards. If high frequency interrupts are

	 * happening on a particular IOAPIC pin, plus the IOAPIC routing

	 * entry is masked/unmasked at a high rate as well then sooner or
@@ -950,7 +950,7 @@ void smp_local_timer_interrupt(struct pt_regs *regs) 
	 * We take the 'long' return path, and there every subsystem

	 * grabs the appropriate locks (kernel lock/ irq lock).

	 *

	 * we might want to decouple profiling from the 'long path',

	 * We might want to decouple profiling from the 'long path',

	 * and do the profiling totally in assembly.

	 *

	 * Currently this isn't too much of an issue (performance wise),

arch/x86_64/kernel/crash.c

+1 −1
Original line number Diff line number Diff line
@@ -69,7 +69,7 @@ static void crash_save_this_cpu(struct pt_regs *regs, int cpu) 
	 * for the data I pass, and I need tags

	 * on the data to indicate what information I have

	 * squirrelled away.  ELF notes happen to provide

	 * all of that that no need to invent something new.

	 * all of that, no need to invent something new.

	 */



	buf = (u32*)per_cpu_ptr(crash_notes, cpu);