Signed-off-by: Adrian Bunk <[email protected]>
---
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
