[2.6 patch] typo fixes: specfic -> specific

[Adrian Bunk]

Signed-off-by: Adrian Bunk <bunk@xxxxxxxxx>

---

 arch/i386/mm/discontig.c                |    2 +-
 include/asm-arm/arch-at91rm9200/board.h |    2 +-
 sound/sparc/dbri.c                      |    2 +-
 usr/klibc/zlib/FAQ                      |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.17-mm3-full/arch/i386/mm/discontig.c.old	2006-06-27 20:36:43.000000000 +0200
+++ linux-2.6.17-mm3-full/arch/i386/mm/discontig.c	2006-06-27 20:37:07.000000000 +0200
@@ -43,7 +43,7 @@
 bootmem_data_t node0_bdata;
 
 /*
- * numa interface - we expect the numa architecture specfic code to have
+ * numa interface - we expect the numa architecture specific code to have
  *                  populated the following initialisation.
  *
  * 1) node_online_map  - the map of all nodes configured (online) in the system
--- linux-2.6.17-mm3-full/include/asm-arm/arch-at91rm9200/board.h.old	2006-06-27 20:37:17.000000000 +0200
+++ linux-2.6.17-mm3-full/include/asm-arm/arch-at91rm9200/board.h	2006-06-27 20:37:21.000000000 +0200
@@ -20,7 +20,7 @@
 
 /*
  * These are data structures found in platform_device.dev.platform_data,
- * and describing board-specfic data needed by drivers.  For example,
+ * and describing board-specific data needed by drivers.  For example,
  * which pin is used for a given GPIO role.
  *
  * In 2.6, drivers should strongly avoid board-specific knowledge so
--- linux-2.6.17-mm3-full/sound/sparc/dbri.c.old	2006-06-27 20:37:31.000000000 +0200
+++ linux-2.6.17-mm3-full/sound/sparc/dbri.c	2006-06-27 20:37:34.000000000 +0200
@@ -46,7 +46,7 @@
  *
  * I've tried to stick to the following function naming conventions:
  * snd_*	ALSA stuff
- * cs4215_*	CS4215 codec specfic stuff
+ * cs4215_*	CS4215 codec specific stuff
  * dbri_*	DBRI high-level stuff
  * other	DBRI low-level stuff
  */
--- linux-2.6.17-mm3-full/usr/klibc/zlib/FAQ.old	2006-06-27 20:37:41.000000000 +0200
+++ linux-2.6.17-mm3-full/usr/klibc/zlib/FAQ	2006-06-27 20:37:44.000000000 +0200
@@ -318,7 +318,7 @@
     correctly points to the zlib specification in RFC 1950 for the "deflate"
     transfer encoding, there have been reports of servers and browsers that
     incorrectly produce or expect raw deflate data per the deflate
-    specficiation in RFC 1951, most notably Microsoft. So even though the
+    specificiation in RFC 1951, most notably Microsoft. So even though the
     "deflate" transfer encoding using the zlib format would be the more
     efficient approach (and in fact exactly what the zlib format was designed
     for), using the "gzip" transfer encoding is probably more reliable due to

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/