summaryrefslogtreecommitdiffstats
path: root/arch/x86_64/kernel/apic.c
diff options
context:
space:
mode:
authorAdam Henley <adamazing@gmail.com>2006-09-26 10:52:28 +0200
committerAndi Kleen <andi@basil.nowhere.org>2006-09-26 10:52:28 +0200
commitd5d9ca6d882f7c8d47ef91a701fc042cbebbc334 (patch)
tree0b1505bb1e2186f8026ae4bb37fc1771db386225 /arch/x86_64/kernel/apic.c
parent3034d11c930f795d61321c9244c4ffaaabf0c282 (diff)
downloadop-kernel-dev-d5d9ca6d882f7c8d47ef91a701fc042cbebbc334.zip
op-kernel-dev-d5d9ca6d882f7c8d47ef91a701fc042cbebbc334.tar.gz
[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: Adam Henley <adamazing@gmail.com> Signed-off-by: Andi Kleen <ak@suse.de> - adam
Diffstat (limited to 'arch/x86_64/kernel/apic.c')
-rw-r--r--arch/x86_64/kernel/apic.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 692e9b5..63d9b03 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -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),
OpenPOWER on IntegriCloud