Commit c9f3f2d8b3247b7e16b3cd66698e690ab4697301

Authored by Masanari Iida
Committed by Jiri Kosina
1 parent 30abda170b

doc: Fix typo in doucmentations

Correct typo (double words) in documentations.

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Showing 17 changed files with 19 additions and 19 deletions Side-by-side Diff

Documentation/arm/OMAP/omap_pm
... ... @@ -78,7 +78,7 @@
78 78 The most common usage of these functions will probably be to specify
79 79 the maximum time from when an interrupt occurs, to when the device
80 80 becomes accessible. To accomplish this, driver writers should use the
81   -set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup
  81 +set_max_mpu_wakeup_lat() function to constrain the MPU wakeup
82 82 latency, and the set_max_dev_wakeup_lat() function to constrain the
83 83 device wakeup latency (from clk_enable() to accessibility). For
84 84 example,
Documentation/block/cfq-iosched.txt
... ... @@ -69,7 +69,7 @@
69 69 group_idle
70 70 -----------
71 71 This parameter forces idling at the CFQ group level instead of CFQ
72   -queue level. This was introduced after after a bottleneck was observed
  72 +queue level. This was introduced after a bottleneck was observed
73 73 in higher end storage due to idle on sequential queue and allow dispatch
74 74 from a single queue. The idea with this parameter is that it can be run with
75 75 slice_idle=0 and group_idle=8, so that idling does not happen on individual
Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
... ... @@ -32,8 +32,8 @@
32 32 The node describing a config device must refer to the sysreg node via
33 33 "arm,vexpress,config-bridge" phandle (can be also defined in the node's
34 34 parent) and relies on the board topology properties - see main vexpress
35   -node documentation for more details. It must must also define the
36   -following property:
  35 +node documentation for more details. It must also define the following
  36 +property:
37 37 - arm,vexpress-sysreg,func : must contain two cells:
38 38 - first cell defines function number (eg. 1 for clock generator,
39 39 2 for voltage regulators etc.)
Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
... ... @@ -37,7 +37,7 @@
37 37 0xffffffff 0x7fff3ccf /* pioB */
38 38 0xffffffff 0x007fffff /* pioC */
39 39  
40   -For each peripheral/bank we will descibe in a u32 if a pin can can be
  40 +For each peripheral/bank we will descibe in a u32 if a pin can be
41 41 configured in it by putting 1 to the pin bit (1 << pin)
42 42  
43 43 Let's take the pioA on peripheral B
Documentation/dma-buf-sharing.txt
... ... @@ -321,7 +321,7 @@
321 321  
322 322 When the importer is done accessing the range specified in begin_cpu_access,
323 323 it needs to announce this to the exporter (to facilitate cache flushing and
324   - unpinning of any pinned resources). The result of of any dma_buf kmap calls
  324 + unpinning of any pinned resources). The result of any dma_buf kmap calls
325 325 after end_cpu_access is undefined.
326 326  
327 327 Interface:
Documentation/fb/fbcon.txt
... ... @@ -150,7 +150,7 @@
150 150  
151 151 C. Attaching, Detaching and Unloading
152 152  
153   -Before going on on how to attach, detach and unload the framebuffer console, an
  153 +Before going on how to attach, detach and unload the framebuffer console, an
154 154 illustration of the dependencies may help.
155 155  
156 156 The console layer, as with most subsystems, needs a driver that interfaces with
Documentation/fb/viafb.txt
... ... @@ -32,7 +32,7 @@
32 32 Start viafb with default settings:
33 33 #modprobe viafb
34 34  
35   - Start viafb with with user options:
  35 + Start viafb with user options:
36 36 #modprobe viafb viafb_mode=800x600 viafb_bpp=16 viafb_refresh=60
37 37 viafb_active_dev=CRT+DVI viafb_dvi_port=DVP1
38 38 viafb_mode1=1024x768 viafb_bpp=16 viafb_refresh1=60
Documentation/filesystems/ext4.txt
... ... @@ -2,7 +2,7 @@
2 2 Ext4 Filesystem
3 3 ===============
4 4  
5   -Ext4 is an an advanced level of the ext3 filesystem which incorporates
  5 +Ext4 is an advanced level of the ext3 filesystem which incorporates
6 6 scalability and reliability enhancements for supporting large filesystems
7 7 (64 bit) in keeping with increasing disk capacities and state-of-the-art
8 8 feature requirements.
Documentation/filesystems/nfs/pnfs.txt
... ... @@ -12,7 +12,7 @@
12 12 ----------------------
13 13 The on-the-wire command LAYOUTGET corresponds to struct
14 14 pnfs_layout_segment, usually referred to by the variable name lseg.
15   -Each nfs_inode may hold a pointer to a cache of of these layout
  15 +Each nfs_inode may hold a pointer to a cache of these layout
16 16 segments in nfsi->layout, of type struct pnfs_layout_hdr.
17 17  
18 18 We reference the header for the inode pointing to it, across each
Documentation/filesystems/relay.txt
... ... @@ -31,7 +31,7 @@
31 31  
32 32 Each relay channel has one buffer per CPU, each buffer has one or more
33 33 sub-buffers. Messages are written to the first sub-buffer until it is
34   -too full to contain a new message, in which case it it is written to
  34 +too full to contain a new message, in which case it is written to
35 35 the next (if available). Messages are never split across sub-buffers.
36 36 At this point, userspace can be notified so it empties the first
37 37 sub-buffer, while the kernel continues writing to the next.
Documentation/filesystems/sysfs-tagging.txt
... ... @@ -24,7 +24,7 @@
24 24 point to the namespace to which it belongs.
25 25  
26 26 Each sysfs superblock's sysfs_super_info contains an array void
27   -*ns[KOBJ_NS_TYPES]. When a a task in a tagging namespace
  27 +*ns[KOBJ_NS_TYPES]. When a task in a tagging namespace
28 28 kobj_nstype first mounts sysfs, a new superblock is created. It
29 29 will be differentiated from other sysfs mounts by having its
30 30 s_fs_info->ns[kobj_nstype] set to the new namespace. Note that
Documentation/i2c/upgrading-clients
... ... @@ -196,8 +196,8 @@
196 196  
197 197 Update the detach method, by changing the name to _remove and
198 198 to delete the i2c_detach_client call. It is possible that you
199   -can also remove the ret variable as it is not not needed for
200   -any of the core functions.
  199 +can also remove the ret variable as it is not needed for any
  200 +of the core functions.
201 201  
202 202 - static int example_detach(struct i2c_client *client)
203 203 + static int example_remove(struct i2c_client *client)
Documentation/rapidio/rapidio.txt
... ... @@ -300,7 +300,7 @@
300 300 -------------------------------------------
301 301  
302 302 RapidIO subsystem code organization allows addition of new enumeration/discovery
303   -methods as new configuration options without significant impact to to the core
  303 +methods as new configuration options without significant impact to the core
304 304 RapidIO code.
305 305  
306 306 A new enumeration/discovery method has to be attached to one or more mport
Documentation/sound/alsa/compress_offload.txt
... ... @@ -73,7 +73,7 @@
73 73  
74 74 Design
75 75  
76   -The new API shares a number of concepts with with the PCM API for flow
  76 +The new API shares a number of concepts with the PCM API for flow
77 77 control. Start, pause, resume, drain and stop commands have the same
78 78 semantics no matter what the content is.
79 79  
Documentation/sysfs-rules.txt
... ... @@ -47,7 +47,7 @@
47 47 at device creation and removal
48 48 - the unique key to the device at that point in time
49 49 - the kernel's path to the device directory without the leading
50   - /sys, and always starting with with a slash
  50 + /sys, and always starting with a slash
51 51 - all elements of a devpath must be real directories. Symlinks
52 52 pointing to /sys/devices must always be resolved to their real
53 53 target and the target path must be used to access the device.
Documentation/virtual/kvm/api.txt
... ... @@ -53,7 +53,7 @@
53 53 facility that allows backward-compatible extensions to the API to be
54 54 queried and used.
55 55  
56   -The extension mechanism is not based on on the Linux version number.
  56 +The extension mechanism is not based on the Linux version number.
57 57 Instead, kvm defines extension identifiers and a facility to query
58 58 whether a particular extension identifier is available. If it is, a
59 59 set of ioctls is available for application use.
Documentation/x86/boot.txt
... ... @@ -58,7 +58,7 @@
58 58 protocol entry point.
59 59  
60 60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields
61   - to struct boot_params for for loading bzImage and ramdisk
  61 + to struct boot_params for loading bzImage and ramdisk
62 62 above 4G in 64bit.
63 63  
64 64 **** MEMORY LAYOUT