Hello,
This patch against 2.6.18 fixes spelling errors detected
by running "aspell -H -c" on each .tmpl file in Documentation/DocBook
The next step is to run aspell on all regular text files
in the Documentation directory!
Michael.
---
Signed-off-by: Michael Opdenacker <[email protected]>
diff -Nurp linux-2.6.18/Documentation/DocBook/gadget.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/gadget.tmpl
--- linux-2.6.18/Documentation/DocBook/gadget.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/gadget.tmpl 2006-09-21
13:54:36.000000000 +0200
@@ -585,11 +585,11 @@ over time, as this driver framework evol
for usb controller hardware), other gadget drivers exist.
</para>
-<para>There's an <emphasis>ethernet</emphasis> gadget
+<para>There's an <emphasis>Ethernet</emphasis> gadget
driver, which implements one of the most useful
<emphasis>Communications Device Class</emphasis> (CDC) models.
One of the standards for cable modem interoperability even
-specifies the use of this ethernet model as one of two
+specifies the use of this Ethernet model as one of two
mandatory options.
Gadgets using this code look to a USB host as if they're
an Ethernet adapter.
@@ -667,7 +667,7 @@ hardware level details could be very dif
<para>Systems need specialized hardware support to implement OTG,
notably including a special <emphasis>Mini-AB</emphasis> jack
-and associated transciever to support <emphasis>Dual-Role</emphasis>
+and associated transceiver to support <emphasis>Dual-Role</emphasis>
operation:
they can act either as a host, using the standard
Linux-USB host side driver stack,
diff -Nurp linux-2.6.18/Documentation/DocBook/genericirq.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/genericirq.tmpl
--- linux-2.6.18/Documentation/DocBook/genericirq.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/genericirq.tmpl
2006-09-21 21:42:18.000000000 +0200
@@ -177,7 +177,7 @@
<para>
Each interrupt is described by an interrupt descriptor structure
irq_desc. The interrupt is referenced by an 'unsigned int' numeric
- value which selects the corresponding interrupt decription structure
+ value which selects the corresponding interrupt description structure
in the descriptor structures array.
The descriptor structure contains status information and pointers
to the interrupt flow method and the interrupt chip structure
@@ -411,7 +411,7 @@ desc->chip->end();
<para>
This handler turned out to be not suitable for all
interrupt hardware and was therefore reimplemented with split
- functionality for egde/level/simple/percpu interrupts. This is not
+ functionality for edge/level/simple/percpu interrupts. This is not
only a functional optimization. It also shortens code paths for
interrupts.
</para>
diff -Nurp linux-2.6.18/Documentation/DocBook/journal-api.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/journal-api.tmpl
--- linux-2.6.18/Documentation/DocBook/journal-api.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/journal-api.tmpl
2006-09-21 21:48:37.000000000 +0200
@@ -4,7 +4,7 @@
<book id="LinuxJBDAPI">
<bookinfo>
- <title>The Linux Journalling API</title>
+ <title>The Linux Journaling API</title>
<authorgroup>
<author>
<firstname>Roger</firstname>
@@ -71,7 +71,7 @@
<sect1>
<title>Details</title>
<para>
-The journalling layer is easy to use. You need to
+The journaling layer is easy to use. You need to
first of all create a journal_t data structure. There are
two calls to do this dependent on how you decide to allocate the physical
media on which the journal resides. The journal_init_inode() call
@@ -136,7 +136,7 @@ quota support.
Inside each transaction you need to wrap the modifications to the
individual buffers (blocks). Before you start to modify a buffer you
need to call journal_get_{create,write,undo}_access() as appropriate,
-this allows the journalling layer to copy the unmodified data if it
+this allows the journaling layer to copy the unmodified data if it
needs to. After all the buffer may be part of a previously uncommitted
transaction.
At this point you are at last ready to modify a buffer, and once
@@ -163,7 +163,7 @@ The first thing to note is that each tas
a single outstanding transaction at any one time, remember nothing
commits until the outermost journal_stop(). This means
you must complete the transaction at the end of each file/inode/address
-etc. operation you perform, so that the journalling system isn't re-entered
+etc. operation you perform, so that the journaling system isn't re-entered
on another journal. Since transactions can't be nested/batched
across differing journals, and another filesystem other than
yours (say ext3) may be modified in a later syscall.
@@ -218,7 +218,7 @@ calls.
<para>
A new feature of jbd since 2.5.25 is commit callbacks with the new
-journal_callback_set() function you can now ask the journalling layer
+journal_callback_set() function you can now ask the journaling layer
to call you back when the transaction is finally committed to disk, so that
you can do some of your own management. The key to this is the
journal_callback
struct, this maintains the internal callback information but you can
@@ -246,7 +246,7 @@ particular inode.
<para>
Using the journal is a matter of wrapping the different context changes,
being each mount, each modification (transaction) and each changed buffer
-to tell the journalling layer about them.
+to tell the journaling layer about them.
</para>
<para>
@@ -286,7 +286,7 @@ an example.
<chapter id="adt">
<title>Data Types</title>
<para>
- The journalling layer uses typedefs to 'hide' the concrete definitions
+ The journaling layer uses typedefs to 'hide' the concrete definitions
of the structures used. As a client of the JBD layer you can
just rely on the using the pointer as a magic cookie of some sort.
@@ -308,7 +308,7 @@ an example.
!Efs/jbd/journal.c
!Ifs/jbd/recovery.c
</sect1>
- <sect1><title>Transasction Level</title>
+ <sect1><title>Transaction Level</title>
!Efs/jbd/transaction.c
</sect1>
</chapter>
@@ -324,7 +324,7 @@ an example.
<para>
<citation>
<ulink
url="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html">
- Ext3 Journalling FileSystem , OLS 2000, Dr. Stephen Tweedie
+ Ext3 Journaling FileSystem , OLS 2000, Dr. Stephen Tweedie
</ulink>
</citation>
</para>
diff -Nurp linux-2.6.18/Documentation/DocBook/kernel-hacking.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/kernel-hacking.tmpl
--- linux-2.6.18/Documentation/DocBook/kernel-hacking.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/kernel-hacking.tmpl
2006-09-21 22:01:17.000000000 +0200
@@ -123,7 +123,7 @@
<para>
We'll see a number of ways that the user context can block
- interrupts, to become truly non-preemptable.
+ interrupts, to become truly non-preemptible.
</para>
<sect1 id="basics-usercontext">
@@ -796,7 +796,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n",
</para>
<para>
- Most registerable structures have an
+ Most registrable structures have an
<structfield>owner</structfield> field, such as in the
<structname>file_operations</structname> structure. Set this field
to the macro <symbol>THIS_MODULE</symbol>.
@@ -1028,7 +1028,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n",
<para>
The preferred method of initializing structures is to use
- designated initialisers, as defined by ISO C99, eg:
+ designated initializers, as defined by ISO C99, eg:
</para>
<programlisting>
static struct block_device_operations opt_fops = {
diff -Nurp linux-2.6.18/Documentation/DocBook/kernel-locking.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/kernel-locking.tmpl
--- linux-2.6.18/Documentation/DocBook/kernel-locking.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/kernel-locking.tmpl
2006-09-21 22:06:56.000000000 +0200
@@ -1717,10 +1717,10 @@ as it would be on UP.
</para>
<para>
-There is a furthur optimization possible here: remember our original
+There is a further optimization possible here: remember our original
cache code, where there were no reference counts and the caller simply
held the lock whenever using the object? This is still possible: if
-you hold the lock, noone can delete the object, so you don't need to
+you hold the lock, no one can delete the object, so you don't need to
get and put the reference count.
</para>
diff -Nurp linux-2.6.18/Documentation/DocBook/libata.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/libata.tmpl
--- linux-2.6.18/Documentation/DocBook/libata.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/libata.tmpl 2006-09-21
22:14:56.000000000 +0200
@@ -252,7 +252,7 @@ void (*dev_select)(struct ata_port *ap,
<para>
Most drivers for taskfile-based hardware use
ata_std_dev_select() for this hook. Controllers which do not
- support second drives on a port (such as SATA contollers) will
+ support second drives on a port (such as SATA controllers) will
use ata_noop_dev_select().
</para>
@@ -332,7 +332,7 @@ int (*qc_issue) (struct ata_queued_cmd *
</programlisting>
<para>
- Higher-level hooks, these two hooks can potentially supercede
+ Higher-level hooks, these two hooks can potentially supersede
several of the above taskfile/DMA engine hooks. ->qc_prep is
called after the buffers have been DMA-mapped, and is typically
used to populate the hardware's DMA scatter-gather table.
@@ -683,7 +683,7 @@ and other resources, etc.
<listitem>
<para>
- ATA_QCFLAG_ACTIVE is clared from qc->flags.
+ ATA_QCFLAG_ACTIVE is cleared from qc->flags.
</para>
</listitem>
@@ -714,7 +714,7 @@ and other resources, etc.
<listitem>
<para>
- qc->waiting is claread & completed (in that order).
+ qc->waiting is cleared & completed (in that order).
</para>
</listitem>
@@ -924,7 +924,7 @@ and other resources, etc.
<title>HSM violation</title>
<para>
This error is indicated when STATUS value doesn't match HSM
- requirement during issuing or excution any ATA/ATAPI command.
+ requirement during issuing or executing any ATA/ATAPI command.
</para>
<itemizedlist>
@@ -951,7 +951,7 @@ and other resources, etc.
<listitem>
<para>
- !BSY && ERR after CDB tranfer starts but before the
+ !BSY && ERR after CDB transfer starts but before the
last byte of CDB is transferred. ATA/ATAPI standard states
that "The device shall not terminate the PACKET command
with an error before the last byte of the command packet has
@@ -1054,9 +1054,9 @@ and other resources, etc.
Upto ATA/ATAPI-7, the standard specifies that ABRT could be
set on ICRC errors and on cases where a device is not able
to complete a command. Combined with the fact that MWDMA
- and PIO transfer errors aren't allowed to use ICRC bit upto
+ and PIO transfer errors aren't allowed to use ICRC bit up to
ATA/ATAPI-7, it seems to imply that ABRT bit alone could
- indicate tranfer errors.
+ indicate transfer errors.
</para>
<para>
However, ATA/ATAPI-8 draft revision 1f removes the part
@@ -1128,7 +1128,7 @@ and other resources, etc.
<para>
Depending on commands, not all STATUS/ERROR bits are
applicable. These non-applicable bits are marked with
- "na" in the output descriptions but upto ATA/ATAPI-7
+ "na" in the output descriptions but up to ATA/ATAPI-7
no definition of "na" can be found. However,
ATA/ATAPI-8 draft revision 1f describes "N/A" as
follows.
@@ -1169,7 +1169,7 @@ and other resources, etc.
<para>
Once sense data is acquired, this type of errors can be
- handled similary to other SCSI errors. Note that sense data
+ handled similarly to other SCSI errors. Note that sense data
may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR
&& ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such
cases, the error should be considered as an ATA bus error and
@@ -1415,7 +1415,7 @@ and other resources, etc.
<para>
HBA resetting is implementation specific. For a controller
complying to taskfile/BMDMA PCI IDE, stopping active DMA
- transaction may be sufficient iff BMDMA state is the only HBA
+ transaction may be sufficient if BMDMA state is the only HBA
context. But even mostly taskfile/BMDMA PCI IDE complying
controllers may have implementation specific requirements and
mechanism to reset themselves. This must be addressed by
diff -Nurp linux-2.6.18/Documentation/DocBook/librs.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/librs.tmpl
--- linux-2.6.18/Documentation/DocBook/librs.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/librs.tmpl 2006-09-21
22:18:07.000000000 +0200
@@ -101,7 +101,7 @@ static struct rs_control *rs_decoder;
* Primitve polynomial is x^10+x^3+1
* first consecutive root is 0
* primitve element to generate roots = 1
- * generator polinomial degree (number of roots) = 6
+ * generator polynomial degree (number of roots) = 6
*/
rs_decoder = init_rs (10, 0x409, 0, 1, 6);
</programlisting>
@@ -121,7 +121,7 @@ rs_decoder = init_rs (10, 0x409, 0, 1, 6
ECC, where the all 0xFF is inverted to an all 0x00.
The Reed-Solomon code for all 0x00 is all 0x00. The
code is inverted before storing to FLASH so it is 0xFF
- too. This prevent's that reading from an erased FLASH
+ too. This prevents that reading from an erased FLASH
results in ECC errors.
</para>
<para>
diff -Nurp linux-2.6.18/Documentation/DocBook/mcabook.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/mcabook.tmpl
--- linux-2.6.18/Documentation/DocBook/mcabook.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/mcabook.tmpl 2006-09-21
22:20:18.000000000 +0200
@@ -82,7 +82,7 @@
</para>
<para>
Finally the MCA bus functions provide a parallel set of DMA
- functions mimicing the ISA bus DMA functions as closely as possible,
+ functions mimicking the ISA bus DMA functions as closely as possible,
although also supporting the additional DMA functionality on the
MCA bus controllers.
</para>
diff -Nurp linux-2.6.18/Documentation/DocBook/mtdnand.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/mtdnand.tmpl
--- linux-2.6.18/Documentation/DocBook/mtdnand.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/mtdnand.tmpl 2006-09-21
22:32:00.000000000 +0200
@@ -91,7 +91,7 @@
<listitem><para>
[MTD Interface]</para><para>
These functions provide the interface to the MTD kernel API.
- They are not replacable and provide functionality
+ They are not replaceable and provide functionality
which is complete hardware independent.
</para></listitem>
<listitem><para>
@@ -100,14 +100,14 @@
</para></listitem>
<listitem><para>
[GENERIC]</para><para>
- Generic functions are not replacable and provide functionality
+ Generic functions are not replaceable and provide functionality
which is complete hardware independent.
</para></listitem>
<listitem><para>
[DEFAULT]</para><para>
Default functions provide hardware related functionality which is suitable
for most of the implementations. These functions can be replaced by the
- board driver if neccecary. Those functions are called via pointers in the
+ board driver if necessary. Those functions are called via pointers in the
NAND chip description structure. The board driver can set the functions
which
should be replaced by board dependent functions before calling nand_scan().
If the function pointer is NULL on entry to nand_scan() then the pointer
@@ -250,7 +250,7 @@ static void board_hwcontrol(struct mtd_i
<title>Device ready function</title>
<para>
If the hardware interface has the ready busy pin of the NAND chip
connected to a
- GPIO or other accesible I/O pin, this function is used to read back the
state of the
+ GPIO or other accessible I/O pin, this function is used to read back the
state of the
pin. The function has no arguments and should return 0, if the device is
busy (R/B pin
is low) and 1, if the device is ready (R/B pin is high).
If the hardware interface does not give access to the ready busy pin, then
@@ -265,7 +265,7 @@ static void board_hwcontrol(struct mtd_i
is set up nand_scan() is called. This function tries to
detect and identify then chip. If a chip is found all the
internal data fields are initialized accordingly.
- The structure(s) have to be zeroed out first and then filled with the
neccecary
+ The structure(s) have to be zeroed out first and then filled with the
necessary
information about the device.
</para>
<programlisting>
@@ -285,7 +285,7 @@ int __init board_init (void)
/* Initialize structures */
memset ((char *) board_mtd, 0, sizeof(struct mtd_info) + sizeof(struct
nand_chip));
- /* map physical adress */
+ /* map physical address */
baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
if(!baseaddr){
printk("Ioremap to access NAND chip failed\n");
@@ -309,7 +309,7 @@ int __init board_init (void)
this->dev_ready = board_dev_ready;
this->eccmode = NAND_ECC_SOFT;
- /* Scan to find existance of the device */
+ /* Scan to find existence of the device */
if (nand_scan (board_mtd, 1)) {
err = -ENXIO;
goto out_ior;
@@ -331,7 +331,7 @@ module_init(board_init);
<sect1>
<title>Exit function</title>
<para>
- The exit function is only neccecary if the driver is
+ The exit function is only necessary if the driver is
compiled as a module. It releases all resources which
are held by the chip driver and unregisters the partitions
in the MTD layer.
@@ -343,7 +343,7 @@ static void __exit board_cleanup (void)
/* Release resources, unregister device */
nand_release (board_mtd);
- /* unmap physical adress */
+ /* unmap physical address */
iounmap((void *)baseaddr);
/* Free the MTD device structure */
@@ -488,17 +488,17 @@ static void board_select_chip (struct mt
Reed-Solomon library.
</para>
<para>
- The ECC bytes must be placed immidiately after the data
+ The ECC bytes must be placed immediately after the data
bytes in order to make the syndrome generator work. This
is contrary to the usual layout used by software ECC. The
- seperation of data and out of band area is not longer
+ separation of data and out of band area is not longer
possible. The nand driver code handles this layout and
the remaining free bytes in the oob area are managed by
the autoplacement code. Provide a matching oob-layout
in this case. See rts_from4.c and diskonchip.c for
implementation reference. In those cases we must also
use bad block tables on FLASH, because the ECC layout is
- interferring with the bad block marker positions.
+ interfering with the bad block marker positions.
See bad block table support for details.
</para>
</sect2>
@@ -546,7 +546,7 @@ static void board_select_chip (struct mt
<para>
nand_scan() calls the function nand_default_bbt().
nand_default_bbt() selects appropriate default
- bad block table desriptors depending on the chip information
+ bad block table descriptors depending on the chip information
which was retrieved by nand_scan().
</para>
<para>
@@ -558,7 +558,7 @@ static void board_select_chip (struct mt
<sect2>
<title>Flash based tables</title>
<para>
- It may be desired or neccecary to keep a bad block table in FLASH.
+ It may be desired or necessary to keep a bad block table in FLASH.
For AG-AND chips this is mandatory, as they have no factory marked
bad blocks. They have factory marked good blocks. The marker pattern
is erased when the block is erased to be reused. So in case of
@@ -569,10 +569,10 @@ static void board_select_chip (struct mt
of the blocks.
</para>
<para>
- The blocks in which the tables are stored are procteted against
+ The blocks in which the tables are stored are protected against
accidental access by marking them bad in the memory bad block
- table. The bad block table managment functions are allowed
- to circumvernt this protection.
+ table. The bad block table management functions are allowed
+ to circumvent this protection.
</para>
<para>
The simplest way to activate the FLASH based bad block table support
@@ -596,7 +596,7 @@ static void board_select_chip (struct mt
User defined tables are created by filling out a
nand_bbt_descr structure and storing the pointer in the
nand_chip structure member bbt_td before calling nand_scan().
- If a mirror table is neccecary a second structure must be
+ If a mirror table is necessary a second structure must be
created and a pointer to this structure must be stored
in bbt_md inside the nand_chip structure. If the bbt_md
member is set to NULL then only the main table is used
@@ -632,7 +632,7 @@ static void board_select_chip (struct mt
holds the bad block table. Store a pointer to the pattern
in the pattern field. Further the length of the pattern has to be
stored in len and the offset in the spare area must be given
- in the offs member of the nand_bbt_descr stucture. For mirrored
+ in the offs member of the nand_bbt_descr structure. For mirrored
bad block tables different patterns are mandatory.</para></listitem>
<listitem><para>Table creation</para>
<para>Set the option NAND_BBT_CREATE to enable the table creation
@@ -774,7 +774,7 @@ struct nand_oobinfo {
</para>
<para>
If the spare area buffer is NULL then only the ECC placement is
- done according to the default builtin scheme.
+ done according to the default built-in scheme.
</para>
</sect2>
<sect2>
@@ -1027,19 +1027,19 @@ in this page</entry>
<row>
<entry>0x37</entry>
<entry>ECC byte 15</entry>
-<entry>Error correction code byte 0 of the sixt 256 Bytes of data
+<entry>Error correction code byte 0 of the sixth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x38</entry>
<entry>ECC byte 16</entry>
-<entry>Error correction code byte 1 of the sixt 256 Bytes of data
+<entry>Error correction code byte 1 of the sixth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x39</entry>
<entry>ECC byte 17</entry>
-<entry>Error correction code byte 2 of the sixt 256 Bytes of data
+<entry>Error correction code byte 2 of the sixth 256 Bytes of data
in this page</entry>
</row>
<row>
@@ -1063,19 +1063,19 @@ data in this page</entry>
<row>
<entry>0x3D</entry>
<entry>ECC byte 21</entry>
-<entry>Error correction code byte 0 of the eigth 256 Bytes of data
+<entry>Error correction code byte 0 of the eighth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x3E</entry>
<entry>ECC byte 22</entry>
-<entry>Error correction code byte 1 of the eigth 256 Bytes of data
+<entry>Error correction code byte 1 of the eighth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x3F</entry>
<entry>ECC byte 23</entry>
-<entry>Error correction code byte 2 of the eigth 256 Bytes of data
+<entry>Error correction code byte 2 of the eighth 256 Bytes of data
in this page</entry>
</row>
</tbody></tgroup></informaltable>
@@ -1086,11 +1086,11 @@ in this page</entry>
<chapter id="filesystems">
<title>Filesystem support</title>
<para>
- The NAND driver provides all neccecary functions for a
+ The NAND driver provides all necessary functions for a
filesystem via the MTD interface.
</para>
<para>
- Filesystems must be aware of the NAND pecularities and
+ Filesystems must be aware of the NAND peculiarities and
restrictions. One major restrictions of NAND Flash is, that you cannot
write as often as you want to a page. The consecutive writes to a page,
before erasing it again, are restricted to 1-3 writes, depending on the
@@ -1134,7 +1134,7 @@ in this page</entry>
<sect2>
<title>Constants for chip id table</title>
<para>
- These constants are defined in nand.h. They are ored together to describe
+ These constants are defined in nand.h. They are ORed together to describe
the chip functionality.
<programlisting>
/* Chip can not auto increment pages */
@@ -1159,7 +1159,7 @@ in this page</entry>
<sect2>
<title>Constants for runtime options</title>
<para>
- These constants are defined in nand.h. They are ored together to describe
+ These constants are defined in nand.h. They are ORed together to describe
the functionality.
<programlisting>
/* Use a flash based bad block table. This option is parsed by the
@@ -1245,13 +1245,13 @@ in this page</entry>
#define NAND_BBT_PERCHIP 0x00000080
/* bbt has a version counter at offset veroffs */
#define NAND_BBT_VERSION 0x00000100
-/* Create a bbt if none axists */
+/* Create a bbt if none exists */
#define NAND_BBT_CREATE 0x00000200
/* Search good / bad pattern through all pages of a block */
#define NAND_BBT_SCANALLPAGES 0x00000400
/* Scan block empty during good / bad block scan */
#define NAND_BBT_SCANEMPTY 0x00000800
-/* Write bbt if neccecary */
+/* Write bbt if necessary */
#define NAND_BBT_WRITE 0x00001000
/* Read and write back block contents when writing bbt */
#define NAND_BBT_SAVECONTENT 0x00002000
diff -Nurp linux-2.6.18/Documentation/DocBook/usb.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/usb.tmpl
--- linux-2.6.18/Documentation/DocBook/usb.tmpl 2006-09-20 05:42:06.000000000
+0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/usb.tmpl 2006-09-21
22:38:21.000000000 +0200
@@ -105,7 +105,7 @@
<para>Within the kernel,
host-side drivers for USB devices talk to the "usbcore" APIs.
- There are two types of public "usbcore" APIs, targetted at two different
+ There are two types of public "usbcore" APIs, targeted at two different
layers of USB driver. Those are
<emphasis>general purpose</emphasis> drivers, exposed through
driver frameworks such as block, character, or network devices;
@@ -163,7 +163,7 @@
<listitem><para>The Linux USB API supports synchronous calls for
control and bulk messaging.
- It also supports asynchnous calls for all kinds of data transfer,
+ It also supports asynchronous calls for all kinds of data transfer,
using request structures called "URBs" (USB Request Blocks).
</para></listitem>
@@ -383,7 +383,7 @@
<para>The significance of that is that by default, all user mode
device drivers need super-user privileges.
You can change modes or ownership in a driver setup
- when the device hotplugs, or maye just start the
+ when the device hotplugs, or maybe just start the
driver right then, as a privileged server (or some activity
within one).
That's the most secure approach for multi-user systems,
@@ -690,7 +690,7 @@ usbdev_ioctl (int fd, int ifno, unsigned
</para><para>
This request lets kernel drivers talk to user mode code
through filesystem operations even when they don't create
- a charactor or block special device.
+ a character or block special device.
It's also been used to do things like ask devices what
device special file should be used.
Two pre-defined ioctls are used
@@ -765,7 +765,7 @@ usbdev_ioctl (int fd, int ifno, unsigned
masked with USB_DIR_IN when referring to an endpoint which
sends data to the host from the device.
The length of the data buffer is identified by "len";
- Recent kernels support requests up to about 128KBytes.
+ Recent kernels support requests up to about 128 KBytes.
<emphasis>FIXME say how read length is returned,
and how short reads are handled.</emphasis>.
</para></listitem></varlistentry>
diff -Nurp linux-2.6.18/Documentation/DocBook/videobook.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/videobook.tmpl
--- linux-2.6.18/Documentation/DocBook/videobook.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/videobook.tmpl
2006-09-21 22:43:14.000000000 +0200
@@ -116,7 +116,7 @@ static struct video_device my_radio
<para>
The only defined value relevant for a radio card is VID_TYPE_TUNER
which
indicates that the device can be tuned. Clearly our radio is going to
have some
- way to change channel so it is tuneable.
+ way to change channel so it is tunable.
</para>
<para>
The VID_HARDWARE_ types are unique to each device. Numbers are
assigned by
@@ -186,7 +186,7 @@ int __init myradio_init(struct video_ini
Radio devices are assigned in this block. As with all of these
selections the actual number assignment is done by the video layer
- accordijng to what is free.</entry>
+ according to what is free.</entry>
</row><row>
<entry>VFL_TYPE_GRABBER</entry><entry>/dev/video{n}</entry><entry>
Video capture devices and also -- counter-intuitively for the name --
@@ -460,7 +460,7 @@ static int radio_ioctl(struct video_devi
strength of 0xFFFF (maximum) and no stereo detected.
</para>
<para>
- To finish off we set the range that can be tuned to be 87-108Mhz, the
normal
+ To finish off we set the range that can be tuned to be 87-108 MHz,
the normal
FM broadcast radio range. It is important to find out what the card
is
actually capable of tuning. It is easy enough to simply use the FM
broadcast
range. Unfortunately if you do this you will discover the FM
broadcast
diff -Nurp linux-2.6.18/Documentation/DocBook/writing_usb_driver.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/writing_usb_driver.tmpl
--- linux-2.6.18/Documentation/DocBook/writing_usb_driver.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/writing_usb_driver.tmpl
2006-09-21 22:45:30.000000000 +0200
@@ -210,7 +210,7 @@ static int skel_probe(struct usb_interfa
<para>
The driver now needs to verify that this device is actually one that it
can accept. If so, it returns 0.
- If not, or if any error occurs during initialization, an errorcode
+ If not, or if any error occurs during initialization, an error code
(such as <literal>-ENOMEM</literal> or <literal>-ENODEV</literal>)
is returned from the probe function.
</para>
diff -Nurp linux-2.6.18/Documentation/DocBook/z8530book.tmpl
linux-2.6.18-aspell-docbook/Documentation/DocBook/z8530book.tmpl
--- linux-2.6.18/Documentation/DocBook/z8530book.tmpl 2006-09-20
05:42:06.000000000 +0200
+++ linux-2.6.18-aspell-docbook/Documentation/DocBook/z8530book.tmpl
2006-09-21 22:47:59.000000000 +0200
@@ -90,13 +90,13 @@
host machine but not to the DMA subsystem. When running PIO the
Z8530 has extremely tight timing requirements. Doing high speeds,
even with a Z85230 will be tricky. Typically you should expect to
- achieve at best 9600 baud with a Z8C530 and 64Kbits with a Z85230.
+ achieve at best 9600 baud with a Z8C530 and 64 Kbits with a Z85230.
</para>
<para>
The DMA mode supports the chip when it is configured to use dual DMA
channels on an ISA bus. The better cards tend to support this mode
of operation for a single channel. With DMA running the Z85230 tops
- out when it starts to hit ISA DMA constraints at about 512Kbits. It
+ out when it starts to hit ISA DMA constraints at about 512 Kbits. It
is worth noting here that many PC machines hang or crash when the
chip is driven fast enough to hold the ISA bus solid.
</para>
@@ -132,7 +132,7 @@
The structure holds two channel structures.
Initialise chanA.ctrlio and chanA.dataio with the address of the
control and data ports. You can or this with Z8530_PORT_SLEEP to
- indicate your interface needs the 5uS delay for chip settling done
+ indicate your interface needs the 5 uS delay for chip settling done
in software. The PORT_SLEEP option is architecture specific. Other
flags may become available on future platforms, eg for MMIO.
Initialise the chanA.irqs to &z8530_nop to start the chip up
--
Michael Opdenacker, Free Electrons
Free Embedded Linux Training Materials
on http://free-electrons.com/training
(More than 1000 pages!)
-
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]