]> pilppa.com Git - linux-2.6-omap-h63xx.git/commitdiff
[PATCH] A few trivial spelling and grammar fixes
authorAdam Henley <adamazing@gmail.com>
Tue, 26 Sep 2006 08:52:28 +0000 (10:52 +0200)
committerAndi Kleen <andi@basil.nowhere.org>
Tue, 26 Sep 2006 08:52:28 +0000 (10:52 +0200)
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

arch/x86_64/kernel/aperture.c
arch/x86_64/kernel/apic.c
arch/x86_64/kernel/crash.c

index 58af8e73738bd5cf51dc9b0a7884bb0fbb66d154..04dbf166252361e15a7807cf2e4a057dd86c971d 100644 (file)
@@ -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.
         */
index 692e9b579743c5e928b66bffb4cf403b355916b3..63d9b037afc62cd097219e22dc6d282c2c0139c9 100644 (file)
@@ -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),
index fc57a139123e348c4adc84fa37475a4e7ca059c4..7d7a9e75f70c809c7f965515854ed5864c17589a 100644 (file)
@@ -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);