Fixes 12 occurrences in all.
diff -ur a/arch/m68knommu/platform/68360/ints.c b/arch/m68knommu/platform/68360/ints.c
--- a/arch/m68knommu/platform/68360/ints.c	Mon Feb 24 11:05:04 2003
+++ b/arch/m68knommu/platform/68360/ints.c	Tue Feb 25 18:44:00 2003
@@ -291,7 +291,7 @@
 
 	/* unsigned long pend = *(volatile unsigned long *)pquicc->intr_cipr; */
 
-	/* Bugger all that wierdness. For the moment, I seem to know where I came from;
+	/* Bugger all that weirdness. For the moment, I seem to know where I came from;
 	 * vec is passed from a specific ISR, so I'll use it. */
 
 	if (int_irq_list[irq] && int_irq_list[irq]->handler) {
diff -ur a/arch/v850/kernel/rte_cb_multi.c b/arch/v850/kernel/rte_cb_multi.c
--- a/arch/v850/kernel/rte_cb_multi.c	Mon Feb 24 11:05:15 2003
+++ b/arch/v850/kernel/rte_cb_multi.c	Tue Feb 25 18:44:06 2003
@@ -67,7 +67,7 @@
 
 			if ((word & 0xFC0) == 0x780) {
 				/* A `jr' insn, fix up its offset (and yes, the
-				   wierd half-word swapping is intentional). */
+				   weird half-word swapping is intentional). */
 				unsigned short hi = word & 0xFFFF;
 				unsigned short lo = word >> 16;
 				unsigned long udisp22
diff -ur a/drivers/net/fec.c b/drivers/net/fec.c
--- a/drivers/net/fec.c	Mon Feb 24 11:05:07 2003
+++ b/drivers/net/fec.c	Tue Feb 25 18:44:08 2003
@@ -828,7 +828,7 @@
 /* 
  * I had some nice ideas of running the MDIO faster...
  * The 971 should support 8MHz and I tried it, but things acted really
- * wierd, so 2.5 MHz ought to be enough for anyone...
+ * weird, so 2.5 MHz ought to be enough for anyone...
  */
 
 static void mii_parse_lxt971_sr2(uint mii_reg, struct net_device *dev)
diff -ur a/include/asm-i386/mach-visws/cobalt.h b/include/asm-i386/mach-visws/cobalt.h
--- a/include/asm-i386/mach-visws/cobalt.h	Mon Feb 24 11:05:08 2003
+++ b/include/asm-i386/mach-visws/cobalt.h	Tue Feb 25 18:44:10 2003
@@ -60,7 +60,7 @@
 #define	CO_APIC_PCIA_BASE0	0 /* and 1 */	/* slot 0, line 0 */
 #define	CO_APIC_PCIA_BASE123	5 /* and 6 */	/* slot 0, line 1 */
 
-#define	CO_APIC_PIIX4_USB	7		/* this one is wierd */
+#define	CO_APIC_PIIX4_USB	7		/* this one is weird */
 
 /* Lithium PCI Bridge B -- "the one with PIIX4" */
 #define	CO_APIC_PCIB_BASE0	8 /* and 9-12 *//* slot 0, line 0 */
diff -ur a/include/asm-v850/sim.h b/include/asm-v850/sim.h
--- a/include/asm-v850/sim.h	Mon Feb 24 11:05:11 2003
+++ b/include/asm-v850/sim.h	Tue Feb 25 18:44:12 2003
@@ -22,7 +22,7 @@
 #define PLATFORM_LONG		"GDB V850E simulator"
 
 
-/* We use a wierd value for RAM, not just 0, for testing purposes.
+/* We use a weird value for RAM, not just 0, for testing purposes.
    These must match the values used in the linker script.  */
 #define RAM_ADDR		0x8F000000
 #define RAM_SIZE		0x01000000
diff -ur a/include/sound/wavefront.h b/include/sound/wavefront.h
--- a/include/sound/wavefront.h	Mon Feb 24 11:05:15 2003
+++ b/include/sound/wavefront.h	Tue Feb 25 18:44:14 2003
@@ -687,7 +687,7 @@
 
 /* Allow direct user-space control over FX memory/coefficient data.
    In theory this could be used to download the FX microprogram,
-   but it would be a little slower, and involve some wierd code.
+   but it would be a little slower, and involve some weird code.
  */
 
 #define WFFX_MEMSET              69
diff -ur a/sound/isa/wavefront/wavefront_fx.c b/sound/isa/wavefront/wavefront_fx.c
--- a/sound/isa/wavefront/wavefront_fx.c	Mon Feb 24 11:05:36 2003
+++ b/sound/isa/wavefront/wavefront_fx.c	Tue Feb 25 18:44:18 2003
@@ -227,7 +227,7 @@
    This code was developed using DOSEMU. The Turtle Beach SETUPSND
    utility was run with I/O tracing in DOSEMU enabled, and a reconstruction
    of the port I/O done, using the Yamaha faxback document as a guide
-   to add more logic to the code. Its really pretty wierd.
+   to add more logic to the code. Its really pretty weird.
 
    There was an alternative approach of just dumping the whole I/O
    sequence as a series of port/value pairs and a simple loop
@@ -692,7 +692,7 @@
 	return (0);
 }
 
-/* wierd stuff, derived from port I/O tracing with dosemu */
+/* weird stuff, derived from port I/O tracing with dosemu */
 
 static unsigned char page_zero[] __initdata = {
 0x01, 0x7c, 0x00, 0x1e, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf5, 0x00,
diff -ur a/sound/isa/wavefront/wavefront_synth.c b/sound/isa/wavefront/wavefront_synth.c
--- a/sound/isa/wavefront/wavefront_synth.c	Mon Feb 24 11:05:16 2003
+++ b/sound/isa/wavefront/wavefront_synth.c	Tue Feb 25 18:44:25 2003
@@ -518,7 +518,7 @@
 /***********************************************************************
 WaveFront data munging   
 
-Things here are wierd. All data written to the board cannot 
+Things here are weird. All data written to the board cannot 
 have its most significant bit set. Any data item with values 
 potentially > 0x7F (127) must be split across multiple bytes.
 
@@ -527,7 +527,7 @@
 that is represented on the x86 side as an array of bytes. The most
 efficient approach to handling both cases seems to be to use 2
 different functions for munging and 2 for de-munging. This avoids
-wierd casting and worrying about bit-level offsets.
+weird casting and worrying about bit-level offsets.
 
 **********************************************************************/
 
@@ -1034,7 +1034,7 @@
 	shptr = munge_int32 (*((u32 *) &header->hdr.s.sampleEndOffset),
 			     shptr, 4);
 	
-	/* This one is truly wierd. What kind of wierdo decided that in
+	/* This one is truly weird. What kind of weirdo decided that in
 	   a system dominated by 16 and 32 bit integers, they would use
 	   a just 12 bits ?
 	*/
diff -ur a/sound/oss/dmasound/dmasound_core.c b/sound/oss/dmasound/dmasound_core.c
--- a/sound/oss/dmasound/dmasound_core.c	Mon Feb 24 11:05:10 2003
+++ b/sound/oss/dmasound/dmasound_core.c	Tue Feb 25 18:44:37 2003
@@ -1212,7 +1212,7 @@
 		return result ;
 		break ;
 	case SNDCTL_DSP_SPEED:
-		/* changing this on the fly will have wierd effects on the sound.
+		/* changing this on the fly will have weird effects on the sound.
 		   Where there are rate conversions implemented in soft form - it
 		   will cause the _ctx_xxx() functions to be substituted.
 		   However, there doesn't appear to be any reason to dis-allow it from
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/