kernel-dev: Edits in the Branch section.

simple edits.

(From yocto-docs rev: 3f73e53c9bdbe71f04400aedc042f19a48ea62bb)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 50 insertions, 55 deletions

diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml b/documentation/kernel-dev/kernel-dev-advanced.xml
index d02654f13a..0c9808c35e 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -1377,54 +1377,39 @@ the KTYPE has changed, now set to "tiny".
     <title>Working with Branches</title>
 
     <para>
-        We need a top-level section here that introduces branches in general.
-        There is information that can be pulled from the embedded machine
-        and feature sections to introduce this stuff.
-        The two subsections should deal with each type of specific branch
-        that can be used.
+        Many linux-yocto-custom derived recipes will be using Linux kernel
+        sources with only a single branch: "master".
+        However, when you are working with multiple boards and architectures,
+        you are likely to run into the situation where a series of patches
+        are needed for one board to boot.
+        Sometimes, these patches are works-in-progress or fundamentally wrong,
+        yet still necessary for specific boards.
+        In these situations, you most likely do not want to include these
+        patches in every kernel you build.
+        You have a couple of options.
     </para>
 
-    <section id='machine-branches'>
-        <title>Machine Branches</title>
-
-        <para>
-            The "<link linkend='using-kernel-metadata-in-a-recipe'>Using Kernel Metadata in a Recipe</link>"
-            section introduced the <filename>KBRANCH</filename> variable, which
-            defines the source branch to use from the Linux kernel Git repository
-            you are using.
-            Many linux-yocto-custom derived recipes will be using Linux kernel
-            sources with only a single branch: "master".
-            However, when you are working with multiple boards and architectures,
-            you are likely to run into the situation where a series of patches
-            are needed for one board to boot.
-            Sometimes, these patches are works-in-progress or fundamentally wrong,
-            yet still necessary for specific boards.
-            In these situations, you most likely do not want to include these
-            patches in every kernel you build.
-            You have a couple of options.
-        </para>
-
-        <para>
-            First, you could encapsulate these patches in a feature description
-            and only include them in the BSP description for the board(s) that
-            require them.
-            For more information, see the
-            "<link linkend='patches'>Patches</link>" and
-            "<link linkend='bsp-descriptions'>BSP Descriptions</link>" sections.
-        </para>
+    <para>
+        First, you could encapsulate these patches in a feature description
+        and only include them in the BSP description for the board(s) that
+        require them.
+        For more information, see the
+        "<link linkend='patches'>Patches</link>" and
+        "<link linkend='bsp-descriptions'>BSP Descriptions</link>" sections.
+    </para>
 
-        <para>
-            Alternatively, you can create a branch in your Linux kernel sources
-            and apply the patches there.
-            You can then specify this new branch as the
-            <filename>KBRANCH</filename> to use for this board.
-            You can do this in the recipe with the
-            <filename>KBRANCH</filename> variable:
-           <literallayout class='monospaced'>
+    <para>
+        Alternatively, you can create a branch in your Linux kernel sources
+        and apply the patches there.
+        You can then specify this new branch as the
+        <filename>KBRANCH</filename> to use for this board.
+        You can do this in the recipe with the
+        <filename>KBRANCH</filename> variable:
+        <literallayout class='monospaced'>
      KBRANCH = "mynewbranch"
-            </literallayout>
-            or in the BSP description using the "branch" command:
-            <literallayout class='monospaced'>
+        </literallayout>
+        or in the BSP description using the "branch" command:
+        <literallayout class='monospaced'>
      mybsp.scc:
         define KMACHINE mybsp
         define KTYPE standard
@@ -1434,19 +1419,29 @@ the KTYPE has changed, now set to "tiny".
         branch mynewbranch
 
         include mybsp-hw.scc
-            </literallayout>
-        </para>
+        </literallayout>
+    </para>
+
+    <para>
+        The approach you take, feature or branch, is entirely up to you
+        and depends on what works best for your development model.
+        If you are actively working on board support, you may find that
+        working within a branch is more practical than trying to continually
+        reintegrate your patches into a feature.
+        On the other hand, if you are simply reusing some patches from an
+        external tree and are not working on them, you may find the
+        encapsulated feature to be appropriate as it does not require the
+        additional complexity of branching in your Linux kernel sources.
+    </para>
+
+    <section id='machine-branches'>
+        <title>Machine Branches</title>
 
         <para>
-            The approach you take, feature or branch, is entirely up to you
-            and depends on what works best for your development model.
-            If you are actively working on board support, you may find that
-            working within a branch is more practical than trying to continually
-            reintegrate your patches into a feature.
-            On the other hand, if you are simply reusing some patches from an
-            external tree and are not working on them, you may find the
-            encapsulated feature to be appropriate as it does not require the
-            additional complexity of branching in your Linux kernel sources.
+            The "<link linkend='using-kernel-metadata-in-a-recipe'>Using Kernel Metadata in a Recipe</link>"
+            section introduced the <filename>KBRANCH</filename> variable, which
+            defines the source branch to use from the Linux kernel Git repository
+            you are using.
         </para>
 
         <para>