1 files changed, 7 insertions, 7 deletions
diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index 224c34741d32..f9da827a0c18 100644
--- a/REPORTING-BUGS
+++ b/REPORTING-BUGS
@@ -9,7 +9,7 @@ screen please read "Documentation/oops-tracing.txt" before posting your
 bug report. This explains what you should do with the "Oops" information
 to make it useful to the recipient.
-      Send the output the maintainer of the kernel area that seems to
+      Send the output to the maintainer of the kernel area that seems to
 be involved with the problem. Don't worry too much about getting the
 wrong person. If you are unsure send it to the person responsible for the
 code relevant to what you were doing. If it occurs repeatably try and
@@ -18,15 +18,15 @@ The list of maintainers is in the MAINTAINERS file in this directory.
      If it is a security bug, please copy the Security Contact listed
 in the MAINTAINERS file.  They can help coordinate bugfix and disclosure.
-See Documentation/SecurityBugs for more infomation.
+See Documentation/SecurityBugs for more information.
      If you are totally stumped as to whom to send the report, send it to
 linux-kernel@vger.kernel.org. (For more information on the linux-kernel
 mailing list see http://www.tux.org/lkml/).
-This is a suggested format for a bug report sent to the Linux kernel mailing 
+This is a suggested format for a bug report sent to the Linux kernel mailing
-list. Having a standardized bug report form makes it easier  for you not to 
+list. Having a standardized bug report form makes it easier for you not to
-overlook things, and easier for the developers to find the pieces of 
+overlook things, and easier for the developers to find the pieces of
 information they're really interested in. Don't feel you have to follow it.
      First run the ver_linux script included as scripts/ver_linux, which
@@ -35,9 +35,9 @@ the command "sh scripts/ver_linux".
 Use that information to fill in all fields of the bug report form, and
 post it to the mailing list with a subject of "PROBLEM: <one line
-summary from [1.]>" for easy identification by the developers    
+summary from [1.]>" for easy identification by the developers.
-[1.] One line summary of the problem:    
+[1.] One line summary of the problem:
 [2.] Full description of the problem/report:
 [3.] Keywords (i.e., modules, networking, kernel):
 [4.] Kernel version (from /proc/version):

diff --git a/REPORTING-BUGS b/REPORTING-BUGS index 224c34741d32..f9da827a0c18 100644 --- a/REPORTING-BUGS +++ b/REPORTING-BUGS
@@ -9,7 +9,7 @@ screen please read "Documentation/oops-tracing.txt" before posting your
9	bug report. This explains what you should do with the "Oops" information	9	bug report. This explains what you should do with the "Oops" information
10	to make it useful to the recipient.	10	to make it useful to the recipient.
11		11
12	Send the output the maintainer of the kernel area that seems to	12	Send the output to the maintainer of the kernel area that seems to
13	be involved with the problem. Don't worry too much about getting the	13	be involved with the problem. Don't worry too much about getting the
14	wrong person. If you are unsure send it to the person responsible for the	14	wrong person. If you are unsure send it to the person responsible for the
15	code relevant to what you were doing. If it occurs repeatably try and	15	code relevant to what you were doing. If it occurs repeatably try and
@@ -18,15 +18,15 @@ The list of maintainers is in the MAINTAINERS file in this directory.
18		18
19	If it is a security bug, please copy the Security Contact listed	19	If it is a security bug, please copy the Security Contact listed
20	in the MAINTAINERS file. They can help coordinate bugfix and disclosure.	20	in the MAINTAINERS file. They can help coordinate bugfix and disclosure.
21	See Documentation/SecurityBugs for more infomation.	21	See Documentation/SecurityBugs for more information.
22		22
23	If you are totally stumped as to whom to send the report, send it to	23	If you are totally stumped as to whom to send the report, send it to
24	linux-kernel@vger.kernel.org. (For more information on the linux-kernel	24	linux-kernel@vger.kernel.org. (For more information on the linux-kernel
25	mailing list see http://www.tux.org/lkml/).	25	mailing list see http://www.tux.org/lkml/).
26		26
27	This is a suggested format for a bug report sent to the Linux kernel mailing	27	This is a suggested format for a bug report sent to the Linux kernel mailing
28	list. Having a standardized bug report form makes it easier for you not to	28	list. Having a standardized bug report form makes it easier for you not to
29	overlook things, and easier for the developers to find the pieces of	29	overlook things, and easier for the developers to find the pieces of
30	information they're really interested in. Don't feel you have to follow it.	30	information they're really interested in. Don't feel you have to follow it.
31		31
32	First run the ver_linux script included as scripts/ver_linux, which	32	First run the ver_linux script included as scripts/ver_linux, which
@@ -35,9 +35,9 @@ the command "sh scripts/ver_linux".
35		35
36	Use that information to fill in all fields of the bug report form, and	36	Use that information to fill in all fields of the bug report form, and
37	post it to the mailing list with a subject of "PROBLEM: <one line	37	post it to the mailing list with a subject of "PROBLEM: <one line
38	summary from [1.]>" for easy identification by the developers	38	summary from [1.]>" for easy identification by the developers.
39		39
40	[1.] One line summary of the problem:	40	[1.] One line summary of the problem:
41	[2.] Full description of the problem/report:	41	[2.] Full description of the problem/report:
42	[3.] Keywords (i.e., modules, networking, kernel):	42	[3.] Keywords (i.e., modules, networking, kernel):
43	[4.] Kernel version (from /proc/version):	43	[4.] Kernel version (from /proc/version):