Commit a33f32244d8550da8b4a26e277ce07d5c6d158b5
Committed by
Jiri Kosina
1 parent
6c9468e9eb
Exists in
master
and in
4 other branches
Documentation/: it's -> its where appropriate
Fix obvious cases of "it's" being used when "its" was meant. Signed-off-by: Francis Galiegue <fgaliegue@gmail.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Showing 56 changed files with 81 additions and 81 deletions Side-by-side Diff
- Documentation/ABI/testing/sysfs-devices-memory
- Documentation/DMA-API-HOWTO.txt
- Documentation/DocBook/libata.tmpl
- Documentation/PCI/pci-error-recovery.txt
- Documentation/Smack.txt
- Documentation/arm/SA1100/ADSBitsy
- Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen
- Documentation/atomic_ops.txt
- Documentation/blackfin/bfin-gpio-notes.txt
- Documentation/cachetlb.txt
- Documentation/cgroups/memcg_test.txt
- Documentation/cgroups/memory.txt
- Documentation/connector/connector.txt
- Documentation/dvb/ci.txt
- Documentation/dvb/contributors.txt
- Documentation/filesystems/autofs4-mount-control.txt
- Documentation/filesystems/ceph.txt
- Documentation/filesystems/dlmfs.txt
- Documentation/filesystems/fiemap.txt
- Documentation/filesystems/fuse.txt
- Documentation/filesystems/hpfs.txt
- Documentation/filesystems/nfs/rpc-cache.txt
- Documentation/filesystems/proc.txt
- Documentation/filesystems/smbfs.txt
- Documentation/filesystems/vfs.txt
- Documentation/hwmon/lm85
- Documentation/input/joystick.txt
- Documentation/intel_txt.txt
- Documentation/kbuild/kconfig-language.txt
- Documentation/kernel-docs.txt
- Documentation/kprobes.txt
- Documentation/laptops/laptop-mode.txt
- Documentation/lguest/lguest.c
- Documentation/md.txt
- Documentation/netlabel/lsm_interface.txt
- Documentation/networking/ifenslave.c
- Documentation/networking/packet_mmap.txt
- Documentation/power/regulator/consumer.txt
- Documentation/power/regulator/machine.txt
- Documentation/power/regulator/overview.txt
- Documentation/powerpc/booting-without-of.txt
- Documentation/powerpc/phyp-assisted-dump.txt
- Documentation/rt-mutex-design.txt
- Documentation/scsi/ChangeLog.lpfc
- Documentation/scsi/FlashPoint.txt
- Documentation/scsi/dtc3x80.txt
- Documentation/scsi/ncr53c8xx.txt
- Documentation/scsi/osst.txt
- Documentation/scsi/scsi_fc_transport.txt
- Documentation/scsi/sym53c8xx_2.txt
- Documentation/sound/alsa/soc/dapm.txt
- Documentation/sound/alsa/soc/machine.txt
- Documentation/sound/alsa/soc/overview.txt
- Documentation/usb/WUSB-Design-overview.txt
- Documentation/vm/numa_memory_policy.txt
- Documentation/w1/w1.generic
Documentation/ABI/testing/sysfs-devices-memory
... | ... | @@ -43,7 +43,7 @@ |
43 | 43 | Contact: Badari Pulavarty <pbadari@us.ibm.com> |
44 | 44 | Description: |
45 | 45 | The file /sys/devices/system/memory/memoryX/state |
46 | - is read-write. When read, it's contents show the | |
46 | + is read-write. When read, its contents show the | |
47 | 47 | online/offline state of the memory section. When written, |
48 | 48 | root can toggle the the online/offline state of a removable |
49 | 49 | memory section (see removable file description above) |
Documentation/DMA-API-HOWTO.txt
... | ... | @@ -742,7 +742,7 @@ |
742 | 742 | |
743 | 743 | Closing |
744 | 744 | |
745 | -This document, and the API itself, would not be in it's current | |
745 | +This document, and the API itself, would not be in its current | |
746 | 746 | form without the feedback and suggestions from numerous individuals. |
747 | 747 | We would like to specifically mention, in no particular order, the |
748 | 748 | following people: |
Documentation/DocBook/libata.tmpl
... | ... | @@ -490,7 +490,7 @@ |
490 | 490 | allocates space for a legacy IDE PRD table and returns. |
491 | 491 | </para> |
492 | 492 | <para> |
493 | - ->port_stop() is called after ->host_stop(). It's sole function | |
493 | + ->port_stop() is called after ->host_stop(). Its sole function | |
494 | 494 | is to release DMA/memory resources, now that they are no longer |
495 | 495 | actively being used. Many drivers also free driver-private |
496 | 496 | data from port at this time. |
Documentation/PCI/pci-error-recovery.txt
... | ... | @@ -216,7 +216,7 @@ |
216 | 216 | |
217 | 217 | - PCI_ERS_RESULT_NEED_RESET |
218 | 218 | Driver returns this if it thinks the device is not |
219 | - recoverable in it's current state and it needs a slot | |
219 | + recoverable in its current state and it needs a slot | |
220 | 220 | reset to proceed. |
221 | 221 | |
222 | 222 | - PCI_ERS_RESULT_DISCONNECT |
... | ... | @@ -241,7 +241,7 @@ |
241 | 241 | |
242 | 242 | The driver is not supposed to restart normal driver I/O operations |
243 | 243 | at this point. It should limit itself to "probing" the device to |
244 | -check it's recoverability status. If all is right, then the platform | |
244 | +check its recoverability status. If all is right, then the platform | |
245 | 245 | will call resume() once all drivers have ack'd link_reset(). |
246 | 246 | |
247 | 247 | Result codes: |
Documentation/Smack.txt
... | ... | @@ -73,7 +73,7 @@ |
73 | 73 | If you don't do anything special all users will get the floor ("_") |
74 | 74 | label when they log in. If you do want to log in via the hacked ssh |
75 | 75 | at other labels use the attr command to set the smack value on the |
76 | -home directory and it's contents. | |
76 | +home directory and its contents. | |
77 | 77 | |
78 | 78 | You can add access rules in /etc/smack/accesses. They take the form: |
79 | 79 |
Documentation/arm/SA1100/ADSBitsy
... | ... | @@ -32,7 +32,7 @@ |
32 | 32 | |
33 | 33 | - The flash on board is divided into 3 partitions. |
34 | 34 | You should be careful to use flash on board. |
35 | - It's partition is different from GraphicsClient Plus and GraphicsMaster | |
35 | + Its partition is different from GraphicsClient Plus and GraphicsMaster | |
36 | 36 | |
37 | 37 | - 16bpp mode requires a different cable than what ships with the board. |
38 | 38 | Contact ADS or look through the manual to wire your own. Currently, |
Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen
... | ... | @@ -7,7 +7,7 @@ |
7 | 7 | |
8 | 8 | The touchscreen driver is maintenance free except for the pen-down or |
9 | 9 | touch threshold. Some resistive displays and board combinations may |
10 | -require tuning of this threshold. The driver exposes some of it's | |
10 | +require tuning of this threshold. The driver exposes some of its | |
11 | 11 | internal state in the sys filesystem. If the kernel is configured |
12 | 12 | with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a |
13 | 13 | directory |
Documentation/atomic_ops.txt
... | ... | @@ -320,7 +320,7 @@ |
320 | 320 | obj->active update does. |
321 | 321 | |
322 | 322 | As a historical note, 32-bit Sparc used to only allow usage of |
323 | -24-bits of it's atomic_t type. This was because it used 8 bits | |
323 | +24-bits of its atomic_t type. This was because it used 8 bits | |
324 | 324 | as a spinlock for SMP safety. Sparc32 lacked a "compare and swap" |
325 | 325 | type instruction. However, 32-bit Sparc has since been moved over |
326 | 326 | to a "hash table of spinlocks" scheme, that allows the full 32-bit |
Documentation/blackfin/bfin-gpio-notes.txt
... | ... | @@ -43,7 +43,7 @@ |
43 | 43 | void bfin_gpio_irq_free(unsigned gpio); |
44 | 44 | |
45 | 45 | The request functions will record the function state for a certain pin, |
46 | - the free functions will clear it's function state. | |
46 | + the free functions will clear its function state. | |
47 | 47 | Once a pin is requested, it can't be requested again before it is freed by |
48 | 48 | previous caller, otherwise kernel will dump stacks, and the request |
49 | 49 | function fail. |
Documentation/cachetlb.txt
... | ... | @@ -5,7 +5,7 @@ |
5 | 5 | |
6 | 6 | This document describes the cache/tlb flushing interfaces called |
7 | 7 | by the Linux VM subsystem. It enumerates over each interface, |
8 | -describes it's intended purpose, and what side effect is expected | |
8 | +describes its intended purpose, and what side effect is expected | |
9 | 9 | after the interface is invoked. |
10 | 10 | |
11 | 11 | The side effects described below are stated for a uniprocessor |
... | ... | @@ -231,7 +231,7 @@ |
231 | 231 | The biggest problem is that of virtual aliasing in the data cache |
232 | 232 | of a processor. |
233 | 233 | |
234 | -Is your port susceptible to virtual aliasing in it's D-cache? | |
234 | +Is your port susceptible to virtual aliasing in its D-cache? | |
235 | 235 | Well, if your D-cache is virtually indexed, is larger in size than |
236 | 236 | PAGE_SIZE, and does not prevent multiple cache lines for the same |
237 | 237 | physical address from existing at once, you have this problem. |
... | ... | @@ -249,7 +249,7 @@ |
249 | 249 | Next, you have to solve the D-cache aliasing issue for all |
250 | 250 | other cases. Please keep in mind that fact that, for a given page |
251 | 251 | mapped into some user address space, there is always at least one more |
252 | -mapping, that of the kernel in it's linear mapping starting at | |
252 | +mapping, that of the kernel in its linear mapping starting at | |
253 | 253 | PAGE_OFFSET. So immediately, once the first user maps a given |
254 | 254 | physical page into its address space, by implication the D-cache |
255 | 255 | aliasing problem has the potential to exist since the kernel already |
Documentation/cgroups/memcg_test.txt
... | ... | @@ -244,7 +244,7 @@ |
244 | 244 | we have to check if OLDPAGE/NEWPAGE is a valid page after commit(). |
245 | 245 | |
246 | 246 | 8. LRU |
247 | - Each memcg has its own private LRU. Now, it's handling is under global | |
247 | + Each memcg has its own private LRU. Now, its handling is under global | |
248 | 248 | VM's control (means that it's handled under global zone->lru_lock). |
249 | 249 | Almost all routines around memcg's LRU is called by global LRU's |
250 | 250 | list management functions under zone->lru_lock(). |
Documentation/cgroups/memory.txt
... | ... | @@ -263,7 +263,7 @@ |
263 | 263 | |
264 | 264 | 4.2 Task migration |
265 | 265 | |
266 | -When a task migrates from one cgroup to another, it's charge is not | |
266 | +When a task migrates from one cgroup to another, its charge is not | |
267 | 267 | carried forward by default. The pages allocated from the original cgroup still |
268 | 268 | remain charged to it, the charge is dropped when the page is freed or |
269 | 269 | reclaimed. |
Documentation/connector/connector.txt
... | ... | @@ -88,7 +88,7 @@ |
88 | 88 | int gfp_mask - GFP mask. |
89 | 89 | |
90 | 90 | Note: When registering new callback user, connector core assigns |
91 | - netlink group to the user which is equal to it's id.idx. | |
91 | + netlink group to the user which is equal to its id.idx. | |
92 | 92 | |
93 | 93 | /*****************************************/ |
94 | 94 | Protocol description. |
Documentation/dvb/ci.txt
... | ... | @@ -41,7 +41,7 @@ |
41 | 41 | |
42 | 42 | * Cards that fall in this category |
43 | 43 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
44 | -At present the cards that fall in this category are the Twinhan and it's | |
44 | +At present the cards that fall in this category are the Twinhan and its | |
45 | 45 | clones, these cards are available as VVMER, Tomato, Hercules, Orange and |
46 | 46 | so on. |
47 | 47 |
Documentation/dvb/contributors.txt
1 | 1 | Thanks go to the following people for patches and contributions: |
2 | 2 | |
3 | 3 | Michael Hunold <m.hunold@gmx.de> |
4 | - for the initial saa7146 driver and it's recent overhaul | |
4 | + for the initial saa7146 driver and its recent overhaul | |
5 | 5 | |
6 | 6 | Christian Theiss |
7 | 7 | for his work on the initial Linux DVB driver |
Documentation/filesystems/autofs4-mount-control.txt
... | ... | @@ -146,7 +146,7 @@ |
146 | 146 | used for this as raw Netlink would lead to a significant increase in |
147 | 147 | complexity. There's no question that the Generic Netlink system is an |
148 | 148 | elegant solution for common case ioctl functions but it's not a complete |
149 | -replacement probably because it's primary purpose in life is to be a | |
149 | +replacement probably because its primary purpose in life is to be a | |
150 | 150 | message bus implementation rather than specifically an ioctl replacement. |
151 | 151 | While it would be possible to work around this there is one concern |
152 | 152 | that lead to the decision to not use it. This is that the autofs |
Documentation/filesystems/ceph.txt
... | ... | @@ -90,7 +90,7 @@ |
90 | 90 | Specify the IP and/or port the client should bind to locally. |
91 | 91 | There is normally not much reason to do this. If the IP is not |
92 | 92 | specified, the client's IP address is determined by looking at the |
93 | - address it's connection to the monitor originates from. | |
93 | + address its connection to the monitor originates from. | |
94 | 94 | |
95 | 95 | wsize=X |
96 | 96 | Specify the maximum write size in bytes. By default there is no |
Documentation/filesystems/dlmfs.txt
... | ... | @@ -47,7 +47,7 @@ |
47 | 47 | your lockspace can access. The easiest way to do this is via |
48 | 48 | ocfs2_hb_ctl (distributed with ocfs2-tools). Right now it requires |
49 | 49 | that an OCFS2 file system be in place so that it can automatically |
50 | -find it's heartbeat area, though it will eventually support heartbeat | |
50 | +find its heartbeat area, though it will eventually support heartbeat | |
51 | 51 | against raw disks. |
52 | 52 | |
53 | 53 | Please see the ocfs2_hb_ctl and mkfs.ocfs2 manual pages distributed |
Documentation/filesystems/fiemap.txt
... | ... | @@ -38,7 +38,7 @@ |
38 | 38 | the set of flags which caused the error. If the kernel is compatible |
39 | 39 | with all flags passed, the contents of fm_flags will be unmodified. |
40 | 40 | It is up to userspace to determine whether rejection of a particular |
41 | -flag is fatal to it's operation. This scheme is intended to allow the | |
41 | +flag is fatal to its operation. This scheme is intended to allow the | |
42 | 42 | fiemap interface to grow in the future but without losing |
43 | 43 | compatibility with old software. |
44 | 44 | |
... | ... | @@ -56,7 +56,7 @@ |
56 | 56 | |
57 | 57 | * FIEMAP_FLAG_XATTR |
58 | 58 | If this flag is set, the extents returned will describe the inodes |
59 | -extended attribute lookup tree, instead of it's data tree. | |
59 | +extended attribute lookup tree, instead of its data tree. | |
60 | 60 | |
61 | 61 | |
62 | 62 | Extent Mapping |
... | ... | @@ -89,7 +89,7 @@ |
89 | 89 | }; |
90 | 90 | |
91 | 91 | All offsets and lengths are in bytes and mirror those on disk. It is valid |
92 | -for an extents logical offset to start before the request or it's logical | |
92 | +for an extents logical offset to start before the request or its logical | |
93 | 93 | length to extend past the request. Unless FIEMAP_EXTENT_NOT_ALIGNED is |
94 | 94 | returned, fe_logical, fe_physical, and fe_length will be aligned to the |
95 | 95 | block size of the file system. With the exception of extents flagged as |
... | ... | @@ -125,7 +125,7 @@ |
125 | 125 | |
126 | 126 | * FIEMAP_EXTENT_DELALLOC |
127 | 127 | - This will also set FIEMAP_EXTENT_UNKNOWN. |
128 | -Delayed allocation - while there is data for this extent, it's | |
128 | +Delayed allocation - while there is data for this extent, its | |
129 | 129 | physical location has not been allocated yet. |
130 | 130 | |
131 | 131 | * FIEMAP_EXTENT_ENCODED |
... | ... | @@ -159,7 +159,7 @@ |
159 | 159 | Data is packed into a block with data from other files. |
160 | 160 | |
161 | 161 | * FIEMAP_EXTENT_UNWRITTEN |
162 | -Unwritten extent - the extent is allocated but it's data has not been | |
162 | +Unwritten extent - the extent is allocated but its data has not been | |
163 | 163 | initialized. This indicates the extent's data will be all zero if read |
164 | 164 | through the filesystem but the contents are undefined if read directly from |
165 | 165 | the device. |
... | ... | @@ -176,7 +176,7 @@ |
176 | 176 | |
177 | 177 | File systems wishing to support fiemap must implement a ->fiemap callback on |
178 | 178 | their inode_operations structure. The fs ->fiemap call is responsible for |
179 | -defining it's set of supported fiemap flags, and calling a helper function on | |
179 | +defining its set of supported fiemap flags, and calling a helper function on | |
180 | 180 | each discovered extent: |
181 | 181 | |
182 | 182 | struct inode_operations { |
Documentation/filesystems/fuse.txt
... | ... | @@ -91,7 +91,7 @@ |
91 | 91 | 'default_permissions' |
92 | 92 | |
93 | 93 | By default FUSE doesn't check file access permissions, the |
94 | - filesystem is free to implement it's access policy or leave it to | |
94 | + filesystem is free to implement its access policy or leave it to | |
95 | 95 | the underlying file access mechanism (e.g. in case of network |
96 | 96 | filesystems). This option enables permission checking, restricting |
97 | 97 | access based on file mode. It is usually useful together with the |
... | ... | @@ -171,7 +171,7 @@ |
171 | 171 | the error set to EINTR. |
172 | 172 | |
173 | 173 | It is also possible that there's a race between processing the |
174 | -original request and it's INTERRUPT request. There are two possibilities: | |
174 | +original request and its INTERRUPT request. There are two possibilities: | |
175 | 175 | |
176 | 176 | 1) The INTERRUPT request is processed before the original request is |
177 | 177 | processed |
Documentation/filesystems/hpfs.txt
... | ... | @@ -103,7 +103,7 @@ |
103 | 103 | Codepages |
104 | 104 | |
105 | 105 | HPFS can contain several uppercasing tables for several codepages and each |
106 | -file has a pointer to codepage it's name is in. However OS/2 was created in | |
106 | +file has a pointer to codepage its name is in. However OS/2 was created in | |
107 | 107 | America where people don't care much about codepages and so multiple codepages |
108 | 108 | support is quite buggy. I have Czech OS/2 working in codepage 852 on my disk. |
109 | 109 | Once I booted English OS/2 working in cp 850 and I created a file on my 852 |
Documentation/filesystems/nfs/rpc-cache.txt
... | ... | @@ -185,7 +185,7 @@ |
185 | 185 | request/response format |
186 | 186 | ----------------------- |
187 | 187 | |
188 | -While each cache is free to use it's own format for requests | |
188 | +While each cache is free to use its own format for requests | |
189 | 189 | and responses over channel, the following is recommended as |
190 | 190 | appropriate and support routines are available to help: |
191 | 191 | Each request or response record should be printable ASCII |
Documentation/filesystems/proc.txt
... | ... | @@ -965,7 +965,7 @@ |
965 | 965 | ...] 1375103 17405 0 0 0 0 0 0 |
966 | 966 | ...] 1703981 5535 0 0 0 3 0 0 |
967 | 967 | |
968 | -In addition, each Channel Bond interface has it's own directory. For | |
968 | +In addition, each Channel Bond interface has its own directory. For | |
969 | 969 | example, the bond0 device will have a directory called /proc/net/bond0/. |
970 | 970 | It will contain information that is specific to that bond, such as the |
971 | 971 | current slaves of the bond, the link status of the slaves, and how |
... | ... | @@ -1362,7 +1362,7 @@ |
1362 | 1362 | In other words: The number of bytes which this process caused to not happen, |
1363 | 1363 | by truncating pagecache. A task can cause "negative" IO too. If this task |
1364 | 1364 | truncates some dirty pagecache, some IO which another task has been accounted |
1365 | -for (in it's write_bytes) will not be happening. We _could_ just subtract that | |
1365 | +for (in its write_bytes) will not be happening. We _could_ just subtract that | |
1366 | 1366 | from the truncating task's write_bytes, but there is information loss in doing |
1367 | 1367 | that. |
1368 | 1368 |
Documentation/filesystems/smbfs.txt
... | ... | @@ -3,7 +3,7 @@ |
3 | 3 | Smbfs was inspired by Samba, the program written by Andrew Tridgell |
4 | 4 | that turns any Unix host into a file server for DOS or Windows clients. |
5 | 5 | |
6 | -Smbfs is a SMB client, but uses parts of samba for it's operation. For | |
6 | +Smbfs is a SMB client, but uses parts of samba for its operation. For | |
7 | 7 | more info on samba, including documentation, please go to |
8 | 8 | http://www.samba.org/ and then on to your nearest mirror. |
Documentation/filesystems/vfs.txt
... | ... | @@ -72,7 +72,7 @@ |
72 | 72 | descriptors). The freshly allocated file structure is initialized with |
73 | 73 | a pointer to the dentry and a set of file operation member functions. |
74 | 74 | These are taken from the inode data. The open() file method is then |
75 | -called so the specific filesystem implementation can do it's work. You | |
75 | +called so the specific filesystem implementation can do its work. You | |
76 | 76 | can see that this is another switch performed by the VFS. The file |
77 | 77 | structure is placed into the file descriptor table for the process. |
78 | 78 |
Documentation/hwmon/lm85
... | ... | @@ -157,7 +157,7 @@ |
157 | 157 | |
158 | 158 | There are three PWM outputs. The LM85 datasheet suggests that the |
159 | 159 | pwm3 output control both fan3 and fan4. Each PWM can be individually |
160 | -configured and assigned to a zone for it's control value. Each PWM can be | |
160 | +configured and assigned to a zone for its control value. Each PWM can be | |
161 | 161 | configured individually according to the following options. |
162 | 162 | |
163 | 163 | * pwm#_auto_pwm_min - this specifies the PWM value for temp#_auto_temp_off |
Documentation/input/joystick.txt
... | ... | @@ -402,7 +402,7 @@ |
402 | 402 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
403 | 403 | The Live! has a special PCI gameport, which, although it doesn't provide |
404 | 404 | any "Enhanced" stuff like 4DWave and friends, is quite a bit faster than |
405 | -it's ISA counterparts. It also requires special support, hence the | |
405 | +its ISA counterparts. It also requires special support, hence the | |
406 | 406 | emu10k1-gp.c module for it instead of the normal ns558.c one. |
407 | 407 | |
408 | 408 | 3.15 SoundBlaster 64 and 128 - ES1370 and ES1371, ESS Solo1 and S3 SonicVibes |
Documentation/intel_txt.txt
... | ... | @@ -126,7 +126,7 @@ |
126 | 126 | o Tboot adjusts the e820 table provided by the bootloader to reserve |
127 | 127 | its own location in memory as well as to reserve certain other |
128 | 128 | TXT-related regions. |
129 | -o As part of it's launch, tboot DMA protects all of RAM (using the | |
129 | +o As part of its launch, tboot DMA protects all of RAM (using the | |
130 | 130 | VT-d PMRs). Thus, the kernel must be booted with 'intel_iommu=on' |
131 | 131 | in order to remove this blanket protection and use VT-d's |
132 | 132 | page-level protection. |
Documentation/kbuild/kconfig-language.txt
... | ... | @@ -181,7 +181,7 @@ |
181 | 181 | (7) Returns the result of max(/expr/, /expr/). |
182 | 182 | |
183 | 183 | An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2 |
184 | -respectively for calculations). A menu entry becomes visible when it's | |
184 | +respectively for calculations). A menu entry becomes visible when its | |
185 | 185 | expression evaluates to 'm' or 'y'. |
186 | 186 | |
187 | 187 | There are two types of symbols: constant and non-constant symbols. |
Documentation/kernel-docs.txt
... | ... | @@ -116,7 +116,7 @@ |
116 | 116 | Author: Ingo Molnar, Gadi Oxman and Miguel de Icaza. |
117 | 117 | URL: http://www.linuxjournal.com/article.php?sid=2391 |
118 | 118 | Keywords: RAID, MD driver. |
119 | - Description: Linux Journal Kernel Korner article. Here is it's | |
119 | + Description: Linux Journal Kernel Korner article. Here is its | |
120 | 120 | abstract: "A description of the implementation of the RAID-1, |
121 | 121 | RAID-4 and RAID-5 personalities of the MD device driver in the |
122 | 122 | Linux kernel, providing users with high performance and reliable, |
... | ... | @@ -127,7 +127,7 @@ |
127 | 127 | URL: http://www.linuxjournal.com/article.php?sid=1219 |
128 | 128 | Keywords: device driver, module, loading/unloading modules, |
129 | 129 | allocating resources. |
130 | - Description: Linux Journal Kernel Korner article. Here is it's | |
130 | + Description: Linux Journal Kernel Korner article. Here is its | |
131 | 131 | abstract: "This is the first of a series of four articles |
132 | 132 | co-authored by Alessandro Rubini and Georg Zezchwitz which present |
133 | 133 | a practical approach to writing Linux device drivers as kernel |
... | ... | @@ -141,7 +141,7 @@ |
141 | 141 | Keywords: character driver, init_module, clean_up module, |
142 | 142 | autodetection, mayor number, minor number, file operations, |
143 | 143 | open(), close(). |
144 | - Description: Linux Journal Kernel Korner article. Here is it's | |
144 | + Description: Linux Journal Kernel Korner article. Here is its | |
145 | 145 | abstract: "This article, the second of four, introduces part of |
146 | 146 | the actual code to create custom module implementing a character |
147 | 147 | device driver. It describes the code for module initialization and |
... | ... | @@ -152,7 +152,7 @@ |
152 | 152 | URL: http://www.linuxjournal.com/article.php?sid=1221 |
153 | 153 | Keywords: read(), write(), select(), ioctl(), blocking/non |
154 | 154 | blocking mode, interrupt handler. |
155 | - Description: Linux Journal Kernel Korner article. Here is it's | |
155 | + Description: Linux Journal Kernel Korner article. Here is its | |
156 | 156 | abstract: "This article, the third of four on writing character |
157 | 157 | device drivers, introduces concepts of reading, writing, and using |
158 | 158 | ioctl-calls". |
... | ... | @@ -161,7 +161,7 @@ |
161 | 161 | Author: Alessandro Rubini and Georg v. Zezschwitz. |
162 | 162 | URL: http://www.linuxjournal.com/article.php?sid=1222 |
163 | 163 | Keywords: interrupts, irqs, DMA, bottom halves, task queues. |
164 | - Description: Linux Journal Kernel Korner article. Here is it's | |
164 | + Description: Linux Journal Kernel Korner article. Here is its | |
165 | 165 | abstract: "This is the fourth in a series of articles about |
166 | 166 | writing character device drivers as loadable kernel modules. This |
167 | 167 | month, we further investigate the field of interrupt handling. |
Documentation/kprobes.txt
... | ... | @@ -332,7 +332,7 @@ |
332 | 332 | or during single-stepping of the probed instruction, Kprobes calls |
333 | 333 | kp->fault_handler. Any or all handlers can be NULL. If kp->flags |
334 | 334 | is set KPROBE_FLAG_DISABLED, that kp will be registered but disabled, |
335 | -so, it's handlers aren't hit until calling enable_kprobe(kp). | |
335 | +so, its handlers aren't hit until calling enable_kprobe(kp). | |
336 | 336 | |
337 | 337 | NOTE: |
338 | 338 | 1. With the introduction of the "symbol_name" field to struct kprobe, |
Documentation/laptops/laptop-mode.txt
... | ... | @@ -207,7 +207,7 @@ |
207 | 207 | * Drew Scott Daniels observed: "I don't know why, but when I decrease the number |
208 | 208 | of colours that my display uses it consumes less battery power. I've seen |
209 | 209 | this on powerbooks too. I hope that this is a piece of information that |
210 | - might be useful to the Laptop Mode patch or it's users." | |
210 | + might be useful to the Laptop Mode patch or its users." | |
211 | 211 | |
212 | 212 | * In syslog.conf, you can prefix entries with a dash ``-'' to omit syncing the |
213 | 213 | file after every logging. When you're using laptop-mode and your disk doesn't |
Documentation/lguest/lguest.c
... | ... | @@ -263,7 +263,7 @@ |
263 | 263 | * Launcher virtual with an offset. |
264 | 264 | * |
265 | 265 | * This can be tough to get your head around, but usually it just means that we |
266 | - * use these trivial conversion functions when the Guest gives us it's | |
266 | + * use these trivial conversion functions when the Guest gives us its | |
267 | 267 | * "physical" addresses: |
268 | 268 | */ |
269 | 269 | static void *from_guest_phys(unsigned long addr) |
Documentation/md.txt
... | ... | @@ -136,7 +136,7 @@ |
136 | 136 | |
137 | 137 | Then uninitialized devices can be added with ADD_NEW_DISK. The |
138 | 138 | structure passed to ADD_NEW_DISK must specify the state of the device |
139 | -and it's role in the array. | |
139 | +and its role in the array. | |
140 | 140 | |
141 | 141 | Once started with RUN_ARRAY, uninitialized spares can be added with |
142 | 142 | HOT_ADD_DISK. |
Documentation/netlabel/lsm_interface.txt
... | ... | @@ -38,7 +38,7 @@ |
38 | 38 | label and the internal LSM security identifier can be time consuming. The |
39 | 39 | NetLabel label mapping cache is a caching mechanism which can be used to |
40 | 40 | sidestep much of this overhead once a mapping has been established. Once the |
41 | -LSM has received a packet, used NetLabel to decode it's security attributes, | |
41 | +LSM has received a packet, used NetLabel to decode its security attributes, | |
42 | 42 | and translated the security attributes into a LSM internal identifier the LSM |
43 | 43 | can use the NetLabel caching functions to associate the LSM internal |
44 | 44 | identifier with the network packet's label. This means that in the future |
Documentation/networking/ifenslave.c
Documentation/networking/packet_mmap.txt
... | ... | @@ -100,7 +100,7 @@ |
100 | 100 | The destruction of the socket and all associated resources |
101 | 101 | is done by a simple call to close(fd). |
102 | 102 | |
103 | -Next I will describe PACKET_MMAP settings and it's constraints, | |
103 | +Next I will describe PACKET_MMAP settings and its constraints, | |
104 | 104 | also the mapping of the circular buffer in the user process and |
105 | 105 | the use of this buffer. |
106 | 106 | |
... | ... | @@ -432,7 +432,7 @@ |
432 | 432 | the PACKET_STATISTICS option. |
433 | 433 | |
434 | 434 | TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which |
435 | - it's checksum will be done in hardware. So while | |
435 | + its checksum will be done in hardware. So while | |
436 | 436 | reading the packet we should not try to check the |
437 | 437 | checksum. |
438 | 438 |
Documentation/power/regulator/consumer.txt
... | ... | @@ -8,11 +8,11 @@ |
8 | 8 | 1. Consumer Regulator Access (static & dynamic drivers) |
9 | 9 | ======================================================= |
10 | 10 | |
11 | -A consumer driver can get access to it's supply regulator by calling :- | |
11 | +A consumer driver can get access to its supply regulator by calling :- | |
12 | 12 | |
13 | 13 | regulator = regulator_get(dev, "Vcc"); |
14 | 14 | |
15 | -The consumer passes in it's struct device pointer and power supply ID. The core | |
15 | +The consumer passes in its struct device pointer and power supply ID. The core | |
16 | 16 | then finds the correct regulator by consulting a machine specific lookup table. |
17 | 17 | If the lookup is successful then this call will return a pointer to the struct |
18 | 18 | regulator that supplies this consumer. |
... | ... | @@ -34,7 +34,7 @@ |
34 | 34 | 2. Regulator Output Enable & Disable (static & dynamic drivers) |
35 | 35 | ==================================================================== |
36 | 36 | |
37 | -A consumer can enable it's power supply by calling:- | |
37 | +A consumer can enable its power supply by calling:- | |
38 | 38 | |
39 | 39 | int regulator_enable(regulator); |
40 | 40 | |
... | ... | @@ -49,7 +49,7 @@ |
49 | 49 | This will return > zero when the regulator is enabled. |
50 | 50 | |
51 | 51 | |
52 | -A consumer can disable it's supply when no longer needed by calling :- | |
52 | +A consumer can disable its supply when no longer needed by calling :- | |
53 | 53 | |
54 | 54 | int regulator_disable(regulator); |
55 | 55 | |
... | ... | @@ -140,7 +140,7 @@ |
140 | 140 | int regulator_set_optimum_mode(struct regulator *regulator, int load_uA); |
141 | 141 | |
142 | 142 | This will cause the core to recalculate the total load on the regulator (based |
143 | -on all it's consumers) and change operating mode (if necessary and permitted) | |
143 | +on all its consumers) and change operating mode (if necessary and permitted) | |
144 | 144 | to best match the current operating load. |
145 | 145 | |
146 | 146 | The load_uA value can be determined from the consumers datasheet. e.g.most |
Documentation/power/regulator/machine.txt
... | ... | @@ -52,7 +52,7 @@ |
52 | 52 | }; |
53 | 53 | |
54 | 54 | Regulator-1 supplies power to Regulator-2. This relationship must be registered |
55 | -with the core so that Regulator-1 is also enabled when Consumer A enables it's | |
55 | +with the core so that Regulator-1 is also enabled when Consumer A enables its | |
56 | 56 | supply (Regulator-2). The supply regulator is set by the supply_regulator_dev |
57 | 57 | field below:- |
58 | 58 |
Documentation/power/regulator/overview.txt
... | ... | @@ -35,16 +35,16 @@ |
35 | 35 | o Consumer - Electronic device that is supplied power by a regulator. |
36 | 36 | Consumers can be classified into two types:- |
37 | 37 | |
38 | - Static: consumer does not change it's supply voltage or | |
38 | + Static: consumer does not change its supply voltage or | |
39 | 39 | current limit. It only needs to enable or disable it's |
40 | - power supply. It's supply voltage is set by the hardware, | |
40 | + power supply. Its supply voltage is set by the hardware, | |
41 | 41 | bootloader, firmware or kernel board initialisation code. |
42 | 42 | |
43 | 43 | Dynamic: consumer needs to change it's supply voltage or |
44 | 44 | current limit to meet operation demands. |
45 | 45 | |
46 | 46 | |
47 | - o Power Domain - Electronic circuit that is supplied it's input power by the | |
47 | + o Power Domain - Electronic circuit that is supplied its input power by the | |
48 | 48 | output power of a regulator, switch or by another power |
49 | 49 | domain. |
50 | 50 |
Documentation/powerpc/booting-without-of.txt
... | ... | @@ -1289,7 +1289,7 @@ |
1289 | 1289 | the interrupt tree. The value of interrupt-parent is the |
1290 | 1290 | phandle of the parent node. |
1291 | 1291 | |
1292 | -If the interrupt-parent property is not defined for a node, it's | |
1292 | +If the interrupt-parent property is not defined for a node, its | |
1293 | 1293 | interrupt parent is assumed to be an ancestor in the node's |
1294 | 1294 | _device tree_ hierarchy. |
1295 | 1295 |
Documentation/powerpc/phyp-assisted-dump.txt
... | ... | @@ -19,7 +19,7 @@ |
19 | 19 | immediately available to the system for normal use. |
20 | 20 | -- After the dump is completed, no further reboots are |
21 | 21 | required; the system will be fully usable, and running |
22 | - in it's normal, production mode on it normal kernel. | |
22 | + in its normal, production mode on its normal kernel. | |
23 | 23 | |
24 | 24 | The above can only be accomplished by coordination with, |
25 | 25 | and assistance from the hypervisor. The procedure is |
Documentation/rt-mutex-design.txt
... | ... | @@ -657,7 +657,7 @@ |
657 | 657 | |
658 | 658 | The waiter structure has a "task" field that points to the task that is blocked |
659 | 659 | on the mutex. This field can be NULL the first time it goes through the loop |
660 | -or if the task is a pending owner and had it's mutex stolen. If the "task" | |
660 | +or if the task is a pending owner and had its mutex stolen. If the "task" | |
661 | 661 | field is NULL then we need to set up the accounting for it. |
662 | 662 | |
663 | 663 | Task blocks on mutex |
Documentation/scsi/ChangeLog.lpfc
... | ... | @@ -707,7 +707,7 @@ |
707 | 707 | * Integrate patches from Christoph Hellwig: two new helpers common |
708 | 708 | to lpfc_sli_resume_iocb and lpfc_sli_issue_iocb - singificant |
709 | 709 | cleanup of those two functions - the unused SLI_IOCB_USE_TXQ is |
710 | - gone - lpfc_sli_issue_iocb_wait loses it's flags argument | |
710 | + gone - lpfc_sli_issue_iocb_wait loses its flags argument | |
711 | 711 | totally. |
712 | 712 | * Fix in lpfc_sli.c: we can not store a 5 bit value in a 4-bit |
713 | 713 | field. |
... | ... | @@ -1028,7 +1028,7 @@ |
1028 | 1028 | * Remove the need for buf_tmo. |
1029 | 1029 | * Changed ULP_BDE64 to struct ulp_bde64. |
1030 | 1030 | * Changed ULP_BDE to struct ulp_bde. |
1031 | - * Cleanup lpfc_os_return_scsi_cmd() and it's call path. | |
1031 | + * Cleanup lpfc_os_return_scsi_cmd() and its call path. | |
1032 | 1032 | * Removed lpfc_no_device_delay. |
1033 | 1033 | * Consolidating lpfc_hba_put_event() into lpfc_put_event(). |
1034 | 1034 | * Removed following attributes and their functionality: |
Documentation/scsi/FlashPoint.txt
... | ... | @@ -71,7 +71,7 @@ |
71 | 71 | |
72 | 72 | Ever since its introduction last October, the BusLogic FlashPoint LT has |
73 | 73 | been problematic for members of the Linux community, in that no Linux |
74 | -drivers have been available for this new Ultra SCSI product. Despite it's | |
74 | +drivers have been available for this new Ultra SCSI product. Despite its | |
75 | 75 | officially being positioned as a desktop workstation product, and not being |
76 | 76 | particularly well suited for a high performance multitasking operating |
77 | 77 | system like Linux, the FlashPoint LT has been touted by computer system |
Documentation/scsi/dtc3x80.txt
... | ... | @@ -12,7 +12,7 @@ |
12 | 12 | The DTC3x80 does not support DMA but it does have Pseudo-DMA which is |
13 | 13 | supported by the driver. |
14 | 14 | |
15 | -It's DTC406 scsi chip is supposedly compatible with the NCR 53C400. | |
15 | +Its DTC406 scsi chip is supposedly compatible with the NCR 53C400. | |
16 | 16 | It is memory mapped, uses an IRQ, but no dma or io-port. There is |
17 | 17 | internal DMA, between SCSI bus and an on-chip 128-byte buffer. Double |
18 | 18 | buffering is done automagically by the chip. Data is transferred |
Documentation/scsi/ncr53c8xx.txt
... | ... | @@ -1479,7 +1479,7 @@ |
1479 | 1479 | Enabling serial NVRAM support enables detection of the serial NVRAM included |
1480 | 1480 | on Symbios and some Symbios compatible host adaptors, and Tekram boards. The |
1481 | 1481 | serial NVRAM is used by Symbios and Tekram to hold set up parameters for the |
1482 | -host adaptor and it's attached drives. | |
1482 | +host adaptor and its attached drives. | |
1483 | 1483 | |
1484 | 1484 | The Symbios NVRAM also holds data on the boot order of host adaptors in a |
1485 | 1485 | system with more than one host adaptor. This enables the order of scanning |
Documentation/scsi/osst.txt
... | ... | @@ -40,7 +40,7 @@ |
40 | 40 | |
41 | 41 | History |
42 | 42 | ------- |
43 | -In the first place, osst shared it's identity very much with st. That meant | |
43 | +In the first place, osst shared its identity very much with st. That meant | |
44 | 44 | that it used the same kernel structures and the same device node as st. |
45 | 45 | So you could only have either of them being present in the kernel. This has |
46 | 46 | been fixed by registering an own device, now. |
Documentation/scsi/scsi_fc_transport.txt
... | ... | @@ -70,7 +70,7 @@ |
70 | 70 | up to an administrative entity controlling the vport. For example, |
71 | 71 | if vports are to be associated with virtual machines, a XEN mgmt |
72 | 72 | utility would be responsible for creating wwpn/wwnn's for the vport, |
73 | - using it's own naming authority and OUI. (Note: it already does this | |
73 | + using its own naming authority and OUI. (Note: it already does this | |
74 | 74 | for virtual MAC addresses). |
75 | 75 | |
76 | 76 | |
... | ... | @@ -81,7 +81,7 @@ |
81 | 81 | with rports and scsi target objects underneath it. Currently the FC |
82 | 82 | transport creates the vport object and places it under the scsi_host |
83 | 83 | object corresponding to the physical adapter. The LLDD will allocate |
84 | - a new scsi_host for the vport and link it's object under the vport. | |
84 | + a new scsi_host for the vport and link its object under the vport. | |
85 | 85 | The remainder of the tree under the vports scsi_host is the same |
86 | 86 | as the non-NPIV case. The transport is written currently to easily |
87 | 87 | allow the parent of the vport to be something other than the scsi_host. |
Documentation/scsi/sym53c8xx_2.txt
... | ... | @@ -687,7 +687,7 @@ |
687 | 687 | Enabling serial NVRAM support enables detection of the serial NVRAM included |
688 | 688 | on Symbios and some Symbios compatible host adaptors, and Tekram boards. The |
689 | 689 | serial NVRAM is used by Symbios and Tekram to hold set up parameters for the |
690 | -host adaptor and it's attached drives. | |
690 | +host adaptor and its attached drives. | |
691 | 691 | |
692 | 692 | The Symbios NVRAM also holds data on the boot order of host adaptors in a |
693 | 693 | system with more than one host adaptor. This information is no longer used |
Documentation/sound/alsa/soc/dapm.txt
... | ... | @@ -188,8 +188,8 @@ |
188 | 188 | 3. Mic Sidetone Input |
189 | 189 | |
190 | 190 | Each input in this example has a kcontrol associated with it (defined in example |
191 | -above) and is connected to the output mixer via it's kcontrol name. We can now | |
192 | -connect the destination widget (wrt audio signal) with it's source widgets. | |
191 | +above) and is connected to the output mixer via its kcontrol name. We can now | |
192 | +connect the destination widget (wrt audio signal) with its source widgets. | |
193 | 193 | |
194 | 194 | /* output mixer */ |
195 | 195 | {"Output Mixer", "Line Bypass Switch", "Line Input"}, |
Documentation/sound/alsa/soc/machine.txt
... | ... | @@ -67,7 +67,7 @@ |
67 | 67 | .ops = &corgi_ops, |
68 | 68 | }; |
69 | 69 | |
70 | -struct snd_soc_card then sets up the machine with it's DAIs. e.g. | |
70 | +struct snd_soc_card then sets up the machine with its DAIs. e.g. | |
71 | 71 | |
72 | 72 | /* corgi audio machine driver */ |
73 | 73 | static struct snd_soc_card snd_soc_corgi = { |
Documentation/sound/alsa/soc/overview.txt
... | ... | @@ -33,7 +33,7 @@ |
33 | 33 | and machines. |
34 | 34 | |
35 | 35 | * Easy I2S/PCM audio interface setup between codec and SoC. Each SoC |
36 | - interface and codec registers it's audio interface capabilities with the | |
36 | + interface and codec registers its audio interface capabilities with the | |
37 | 37 | core and are subsequently matched and configured when the application |
38 | 38 | hardware parameters are known. |
39 | 39 |
Documentation/usb/WUSB-Design-overview.txt
... | ... | @@ -381,7 +381,7 @@ |
381 | 381 | we issue another URB to read into the destination buffer the chunk of |
382 | 382 | data coming out of the remote endpoint. Done, wait for the next guy. The |
383 | 383 | callbacks for the URBs issued from here are the ones that will declare |
384 | -the xfer complete at some point and call it's callback. | |
384 | +the xfer complete at some point and call its callback. | |
385 | 385 | |
386 | 386 | Seems simple, but the implementation is not trivial. |
387 | 387 |
Documentation/vm/numa_memory_policy.txt
... | ... | @@ -45,7 +45,7 @@ |
45 | 45 | to establish the task policy for a child task exec()'d from an |
46 | 46 | executable image that has no awareness of memory policy. See the |
47 | 47 | MEMORY POLICY APIS section, below, for an overview of the system call |
48 | - that a task may use to set/change it's task/process policy. | |
48 | + that a task may use to set/change its task/process policy. | |
49 | 49 | |
50 | 50 | In a multi-threaded task, task policies apply only to the thread |
51 | 51 | [Linux kernel task] that installs the policy and any threads |
... | ... | @@ -301,7 +301,7 @@ |
301 | 301 | the structure back to the mempolicy kmem cache when the reference count |
302 | 302 | goes to zero. |
303 | 303 | |
304 | -When a new memory policy is allocated, it's reference count is initialized | |
304 | +When a new memory policy is allocated, its reference count is initialized | |
305 | 305 | to '1', representing the reference held by the task that is installing the |
306 | 306 | new policy. When a pointer to a memory policy structure is stored in another |
307 | 307 | structure, another reference is added, as the task's reference will be dropped |
Documentation/w1/w1.generic
... | ... | @@ -25,7 +25,7 @@ |
25 | 25 | - sysfs entries for that w1 master are created |
26 | 26 | - the w1 bus is periodically searched for new slave devices |
27 | 27 | |
28 | -When a device is found on the bus, w1 core checks if driver for it's family is | |
28 | +When a device is found on the bus, w1 core checks if driver for its family is | |
29 | 29 | loaded. If so, the family driver is attached to the slave. |
30 | 30 | If there is no driver for the family, default one is assigned, which allows to perform |
31 | 31 | almost any kind of operations. Each logical operation is a transaction |