fix typos "wich" -> "which"

Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

2 files changed, 8 insertions, 8 deletions

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 944cf10..99902ae6 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -121,7 +121,7 @@ Table 1-1: Process specific entries in /proc
 ..............................................................................
  File    Content                                        
  cmdline Command line arguments                         
- cpu	 Current and last cpu in wich it was executed		(2.4)(smp)
+ cpu	 Current and last cpu in which it was executed		(2.4)(smp)
  cwd	 Link to the current working directory
  environ Values of environment variables      
  exe	 Link to the executable of this process
@@ -309,13 +309,13 @@ is the same by default:
   > cat /proc/irq/0/smp_affinity 
   ffffffff
 
-It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can
+It's a bitmask, in which you can specify which CPUs can handle the IRQ, you can
 set it by doing:
 
   > echo 1 > /proc/irq/prof_cpu_mask
 
 This means that only the first CPU will handle the IRQ, but you can also echo 5
-wich means that only the first and fourth CPU can handle the IRQ.
+which means that only the first and fourth CPU can handle the IRQ.
 
 The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
 between all the CPUs which are allowed to handle it. As usual the kernel has
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 8d4cf78..4fc8e98 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -40,7 +40,7 @@ network interface card supports some sort of interrupt load mitigation or
 + How to use CONFIG_PACKET_MMAP
 --------------------------------------------------------------------------------
 
-From the user standpoint, you should use the higher level libpcap library, wich
+From the user standpoint, you should use the higher level libpcap library, which
 is a de facto standard, portable across nearly all operating systems
 including Win32. 
 
@@ -217,8 +217,8 @@ called pg_vec, its size limits the number of blocks that can be allocated.
 
 kmalloc allocates any number of bytes of phisically contiguous memory from 
 a pool of pre-determined sizes. This pool of memory is mantained by the slab 
-allocator wich is at the end the responsible for doing the allocation and 
-hence wich imposes the maximum memory that kmalloc can allocate. 
+allocator which is at the end the responsible for doing the allocation and 
+hence which imposes the maximum memory that kmalloc can allocate. 
 
 In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The 
 predetermined sizes that kmalloc uses can be checked in the "size-<bytes>" 
@@ -254,7 +254,7 @@ and, the number of frames be
 
 	<block number> * <block size> / <frame size>
 
-Suposse the following parameters, wich apply for 2.6 kernel and an
+Suposse the following parameters, which apply for 2.6 kernel and an
 i386 architecture:
 
 	<size-max> = 131072 bytes
@@ -360,7 +360,7 @@ TP_STATUS_LOSING      : indicates there were packet drops from last time
                         statistics where checked with getsockopt() and
                         the PACKET_STATISTICS option.
 
-TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets wich 
+TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which 
                         it's checksum will be done in hardware. So while 
                         reading the packet we should not try to check the 
                         checksum.