Documentation cleanup

index badb6e4..16c86cc 100644
@@ -100,7 +100,7 @@ most important ones allow to:
    toolchain should have largefile support (i.e support for files
    larger than 2 GB on 32 bits systems), IPv6 support, RPC support
    (used mainly for NFS), wide-char support, locale support (for
-   internationalization), C++ support, thread support. Depending on
+   internationalization), C++ support or thread support. Depending on
    which options you choose, the number of userspace applications and
    libraries visible in Buildroot menus will change: many applications
    and libraries require certain toolchain options to be enabled. Most

index 16c86cc..869066a 100644
@@ -165,7 +165,7 @@ Then, you have three solutions to use an external toolchain:
   prefix+ and +External toolchain C library+ options. Then, you have
   to tell Buildroot what your external toolchain supports. If your
   external toolchain uses the 'glibc' library, you only have to tell
-  whether your toolchain supports C\+\+ or not and whether it has
+  whether your toolchain supports C++ or not and whether it has
   built-in RPC support. If your external toolchain uses the 'uClibc'
   library, then you have to tell Buildroot if it supports largefile,
   IPv6, RPC, wide-char, locale, program invocation, threads and

index faf59f2..81edae3 100644
@@ -32,7 +32,7 @@ The result of the search shows the help message of the matching items.
 Not all targets are always available,
 some settings in the +.config+ file may hide some targets:
 
-* +busybox-menuconfig+ and +busybox-savedefconfig+ ony work when
+* +busybox-menuconfig+ and +busybox-savedefconfig+ only work when
   +busybox+ is enabled;
 * +linux-menuconfig+ and +linux-savedefconfig+ only work when
   +linux+ is enabled;

index 52d4d04..028dd90 100644
@@ -97,7 +97,7 @@ To indicate approval of a patch, there are three formal tags that keep
 track of this approval. To add your tag to a patch, reply to it with the
 approval tag below the original author's Signed-off-by line. These tags
 will be picked up automatically by patchwork (see
-ref:apply-patches-patchwork[]) and will be part of the commit log when
+xref:apply-patches-patchwork[]) and will be part of the commit log when
 the patch is accepted.
 
 Tested-by:: Indicates that the patch has been tested successfully.

index 028dd90..47494cb 100644
@@ -307,7 +307,7 @@ Here is a short list of details to provide in such case:
 * any information you think that may be relevant
 
 Additionally, you should add the +.config+ file (or if you know how, a
-+defconfig+).
++defconfig+; see xref:customize-store-buildroot-config[]).
 
 If some of these details are too large, do not hesitate to use a
 pastebin service. Note that not all available pastebin services will

index f79a578..c21012d 100644
@@ -99,7 +99,7 @@ Buildroot, with the name used in the manifest files:
   GNU Library General Public License, version 2];
 * `LGPLv2+`:
   http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html[
-  GNU Library General Public License, version 2.1]
+  GNU Library General Public License, version 2]
   or (at your option) any later version;
 * `LGPLv2.1`:
   http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html[

index 47494cb..b641ff2 100644
@@ -270,7 +270,9 @@ Changes v1 -> v2:
 
 Any patch revision should include the version number. The version number
 is simply composed of the letter +v+ followed by an +integer+ greater or
-equal to two (i.e. "PATCH v2", "PATCH v3" ...).
+equal to two (i.e. "PATCH v2", "PATCH v3" ...). Note that when your patch
+series is introduced by a cover letter, an overall patch version may be
+added to the cover letter in addition/instead to the individual commits.
 
 This can be easily handled with +git format-patch+ by using the option
 +--subject-prefix+:

index e125498..faee3e9 100644
@@ -150,7 +150,7 @@ On line 31..33, we define a device-node file used by this package
 On line 35..37, we define the permissions to set to specific files
 installed by this package (+LIBFOO_PERMISSIONS+).
 
-On lines 39..41, we define a user that is used by this package (eg.
+On lines 39..41, we define a user that is used by this package (e.g.
 to run a daemon as non-root) (+LIBFOO_USERS+).
 
 Finally, on line 43, we call the +generic-package+ function, which

@@ -335,7 +335,7 @@ information is (assuming the package name is +libfoo+) :
   This variable is optional.
 
 * +LIBFOO_USERS+ lists the users to create for this package, if it installs
-  a program you want to run as a specific user (eg. as a daemon, or as a
+  a program you want to run as a specific user (e.g. as a daemon, or as a
   cron-job). The syntax is similar in spirit to the makedevs one, and is
   described in the xref:makeuser-syntax[]. This variable is optional.
 

index ca1bffe..d9de598 100644
@@ -116,7 +116,7 @@ Dealing efficiently with filesystem images
 
 Filesystem images can get pretty big, depending on the filesystem you choose,
 the number of packages, whether you provisioned free space... Yet, some
-locations in the filesystems images may just be _empty_ (eg. a long run of
+locations in the filesystems images may just be _empty_ (e.g. a long run of
 'zeroes'); such a file is called a _sparse_ file.
 
 Most tools can handle sparse files efficiently, and will only store or write

@@ -139,12 +139,12 @@ For example:
 Other tools may have similar options. Please consult their respective man
 pages.
 
-You can use sparse files if you need to store the filesystem images (eg.
-to transfer from one machine to another), or if you need to send them (eg.
+You can use sparse files if you need to store the filesystem images (e.g.
+to transfer from one machine to another), or if you need to send them (e.g.
 to the Q&A team).
 
 Note however that flashing a filesystem image to a device while using the
-sparse mode of +dd+ may result in a broken filesystem (eg. the block bitmap
+sparse mode of +dd+ may result in a broken filesystem (e.g. the block bitmap
 of an ext2 filesystem may be corrupted; or, if you have sparse files in
 your filesystem, those parts may not be all-zeroes when read back). You
 should only use sparse files when handling files on the build machine, not

index d0c92ff..cc668b5 100644
@@ -119,7 +119,7 @@ cases, typical packages will therefore only use a few of them.
   +make+ command. By default, empty.
 
 * +LIBFOO_AUTORECONF+, tells whether the package should
-  be autoreconfigured or not (i.e, if the configure script and
+  be autoreconfigured or not (i.e. if the configure script and
   Makefile.in files should be re-generated by re-running autoconf,
   automake, libtool, etc.). Valid values are +YES+ and
   +NO+. By default, the value is +NO+

index 869066a..306a12d 100644
@@ -82,7 +82,7 @@ most important ones allow to:
    built. This library provides the interface between userspace
    applications and the Linux kernel. In order to know how to "talk"
    to the Linux kernel, the C library needs to have access to the
-   _Linux kernel headers_ (i.e, the +.h+ files from the kernel), which
+   _Linux kernel headers_ (i.e. the +.h+ files from the kernel), which
    define the interface between userspace and the kernel (system
    calls, data structures, etc.). Since this interface is backward
    compatible, the version of the Linux kernel headers used to build

@@ -97,7 +97,7 @@ most important ones allow to:
  * Change the version of the GCC compiler, binutils and the C library.
 
  * Select a number of toolchain options (uClibc only): whether the
-   toolchain should have largefile support (i.e support for files
+   toolchain should have largefile support (i.e. support for files
    larger than 2 GB on 32 bits systems), IPv6 support, RPC support
    (used mainly for NFS), wide-char support, locale support (for
    internationalization), C++ support or thread support. Depending on

@@ -180,17 +180,17 @@ Buildroot itself. In general, all toolchains that support the
 developers.
 
 We do not support toolchains or SDK generated by OpenEmbedded or
-Yocto, because these toolchains are not pure toolchains (i.e just the
+Yocto, because these toolchains are not pure toolchains (i.e. just the
 compiler, binutils, the C and C++ libraries). Instead these toolchains
 come with a very large set of pre-compiled libraries and
 programs. Therefore, Buildroot cannot import the 'sysroot' of the
 toolchain, as it would contain hundreds of megabytes of pre-compiled
 libraries that are normally built by Buildroot.
 
-We also do not support using the distribution toolchain (i.e the
+We also do not support using the distribution toolchain (i.e. the
 gcc/binutils/C library installed by your distribution) as the
 toolchain to build software for the target. This is because your
-distribution toolchain is not a "pure" toolchain (i.e only with the
+distribution toolchain is not a "pure" toolchain (i.e. only with the
 C/C++ library), so we cannot import it properly into the Buildroot
 build environment. So even if you are building a system for a x86 or
 x86_64 target, you have to generate a cross-compilation toolchain with

@@ -235,7 +235,7 @@ different solutions to handle the +/dev+ directory :
  * The first solution is *Static using device table*. This is the old
    classical way of handling device files in Linux. With this method,
    the device files are persistently stored in the root filesystem
-   (i.e they persist accross reboots), and there is nothing that will
+   (i.e. they persist accross reboots), and there is nothing that will
    automatically create and remove those device files when hardware
    devices are added or removed from the system. Buildroot therefore
    creates a standard set of device files using a _device table_, the

index 7498940..6ee55a3 100644
@@ -78,7 +78,7 @@ Or disable the usage of external definitions:
    directories called +board/<boardname>/+ under +BR2_EXTERNAL+. This
    matches the directory structure used within Buildroot.
 
- * One can store package recipes (i.e +Config.in+ and
+ * One can store package recipes (i.e. +Config.in+ and
    +<packagename>.mk+), or even custom configuration options and make
    logic. Buildroot automatically includes +BR2_EXTERNAL/Config.in+ to
    make it appear in the top-level configuration menu, and includes

index a5079e3..473b0e2 100644
@@ -138,7 +138,7 @@ is much more complicated than that:
 
  * When a package is unselected from the configuration, it is not
    sufficient to remove just the files it installed. One must also
-   remove all its reverse dependencies (i.e packages relying on it)
+   remove all its reverse dependencies (i.e. packages relying on it)
    and rebuild all those packages. For example, package A depends
    optionally on the OpenSSL library. Both are selected, and Buildroot
    is built. Package A is built with crypto support using OpenSSL.