Documentation: remove duplicated words

Remove many duplicated words under Documentation/ and do other small
cleanups.

Examples:
        "and and" --> "and"
        "in in" --> "in"
        "the the" --> "the"
        "the the" --> "to the"
        ...

Signed-off-by: Paolo Ornati <ornati@fastwebnet.it>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

52 files changed, 61 insertions, 62 deletions

diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
index 1d8dccf04e..028614cdd0 100644
--- a/Documentation/DMA-mapping.txt
+++ b/Documentation/DMA-mapping.txt
@@ -107,7 +107,7 @@ The query is performed via a call to pci_set_dma_mask():
 
         int pci_set_dma_mask(struct pci_dev *pdev, u64 device_mask);
 
-The query for consistent allocations is performed via a a call to
+The query for consistent allocations is performed via a call to
 pci_set_consistent_dma_mask():
 
         int pci_set_consistent_dma_mask(struct pci_dev *pdev, u64 device_mask);
diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl
index 065e8dc23e..c684abf0d3 100644
--- a/Documentation/DocBook/libata.tmpl
+++ b/Documentation/DocBook/libata.tmpl
@@ -1400,7 +1400,7 @@ and other resources, etc.
         <listitem>
         <para>
         When it's known that HBA is in ready state but ATA/ATAPI
-        device in in unknown state, reset only device.
+        device is in unknown state, reset only device.
         </para>
         </listitem>
 
diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl
index fbc72d4dbc..143e5ff7de 100644
--- a/Documentation/DocBook/usb.tmpl
+++ b/Documentation/DocBook/usb.tmpl
@@ -740,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
                 <title>Synchronous I/O Support</title>
 
                 <para>Synchronous requests involve the kernel blocking
-                until until the user mode request completes, either by
+                until the user mode request completes, either by
                 finishing successfully or by reporting an error.
                 In most cases this is the simplest way to use usbfs,
                 although as noted above it does prevent performing I/O
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index f8092a891d..820fee2369 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -750,7 +750,7 @@ Or, for those who prefer a side-by-side listing:
 
 Either way, the differences are quite small.  Read-side locking moves
 to rcu_read_lock() and rcu_read_unlock, update-side locking moves from
-from a reader-writer lock to a simple spinlock, and a synchronize_rcu()
+a reader-writer lock to a simple spinlock, and a synchronize_rcu()
 precedes the kfree().
 
 However, there is one potential catch: the read-side and update-side
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index e2f7dc6069..34bf8f60d8 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -135,7 +135,7 @@ Some new queue property settings:
                 Sets two variables that limit the size of the request.
 
                 - The request queue's max_sectors, which is a soft size in
-                in units of 512 byte sectors, and could be dynamically varied
+                units of 512 byte sectors, and could be dynamically varied
                 by the core kernel.
 
                 - The request queue's max_hw_sectors, which is a hard limit
diff --git a/Documentation/driver-model/overview.txt b/Documentation/driver-model/overview.txt
index 2050c9ffc6..07236ed968 100644
--- a/Documentation/driver-model/overview.txt
+++ b/Documentation/driver-model/overview.txt
@@ -57,7 +57,7 @@ the two.
 
 The PCI bus layer freely accesses the fields of struct device. It knows about
 the structure of struct pci_dev, and it should know the structure of struct
-device. Individual PCI device drivers that have been converted the the current
+device. Individual PCI device drivers that have been converted to the current
 driver model generally do not and should not touch the fields of struct device,
 unless there is a strong compelling reason to do so.
 
diff --git a/Documentation/exception.txt b/Documentation/exception.txt
index 3cb39ade29..2d5aded642 100644
--- a/Documentation/exception.txt
+++ b/Documentation/exception.txt
@@ -10,7 +10,7 @@ int verify_area(int type, const void * addr, unsigned long size)
 function (which has since been replaced by access_ok()).
 
 This function verified that the memory area starting at address 
-addr and of size size was accessible for the operation specified 
+'addr' and of size 'size' was accessible for the operation specified
 in type (read or write). To do this, verify_read had to look up the 
 virtual memory area (vma) that contained the address addr. In the 
 normal case (correctly working program), this test was successful. 
diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt
index f373df12ed..99ea58e65e 100644
--- a/Documentation/fb/fbcon.txt
+++ b/Documentation/fb/fbcon.txt
@@ -163,7 +163,7 @@ from the console layer before unloading the driver.  The VGA driver cannot be
 unloaded if it is still bound to the console layer. (See
 Documentation/console/console.txt for more information).
 
-This is more complicated in the case of the the framebuffer console (fbcon),
+This is more complicated in the case of the framebuffer console (fbcon),
 because fbcon is an intermediate layer between the console and the drivers:
 
 console ---> fbcon ---> fbdev drivers ---> hardware
diff --git a/Documentation/filesystems/directory-locking b/Documentation/filesystems/directory-locking
index 34380d4fbc..d7099a9266 100644
--- a/Documentation/filesystems/directory-locking
+++ b/Documentation/filesystems/directory-locking
@@ -82,7 +82,7 @@ own descendent.  Moreover, there is exactly one cross-directory rename
 
         Consider the object blocking the cross-directory rename.  One
 of its descendents is locked by cross-directory rename (otherwise we
-would again have an infinite set of of contended objects).  But that
+would again have an infinite set of contended objects).  But that
 means that cross-directory rename is taking locks out of order.  Due
 to (2) the order hadn't changed since we had acquired filesystem lock.
 But locking rules for cross-directory rename guarantee that we do not