[PATCH 01/22] docs: dt: convert booting-without-of.txt to ReST format

[PATCH 01/22] docs: dt: convert booting-without-of.txt to ReST format

[Mauro Carvalho Chehab]

- Add a SPDX header;
- Use copyright symbol;
- Adjust document title;
- Adjust document and section titles;
- Some whitespace fixes and new line breaks;
- Mark literal blocks as such;
- Add table markups;
- Add it to devicetree/index.rst.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/arm/booting.rst                 |   2 +-
 ...-without-of.txt => booting-without-of.rst} | 299 ++++++++++--------
 Documentation/devicetree/index.rst            |   1 +
 Documentation/translations/zh_CN/arm/Booting  |   2 +-
 4 files changed, 169 insertions(+), 135 deletions(-)
 rename Documentation/devicetree/{booting-without-of.txt => booting-without-of.rst} (90%)

diff --git a/Documentation/arm/booting.rst b/Documentation/arm/booting.rst
index 4babb6c6ae1e..a2263451dc2c 100644
--- a/Documentation/arm/booting.rst
+++ b/Documentation/arm/booting.rst
@@ -128,7 +128,7 @@ it.  The recommended placement is in the first 16KiB of RAM.
 
 The boot loader must load a device tree image (dtb) into system ram
 at a 64bit aligned address and initialize it with the boot data.  The
-dtb format is documented in Documentation/devicetree/booting-without-of.txt.
+dtb format is documented in Documentation/devicetree/booting-without-of.rst.
 The kernel will look for the dtb magic value of 0xd00dfeed at the dtb
 physical address to determine if a dtb has been passed instead of a
 tagged list.
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.rst
similarity index 90%
rename from Documentation/devicetree/booting-without-of.txt
rename to Documentation/devicetree/booting-without-of.rst
index 4660ccee35a3..56e54e95efa7 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.rst
@@ -1,15 +1,20 @@
-           Booting the Linux/ppc kernel without Open Firmware
-           --------------------------------------------------
-
-(c) 2005 Benjamin Herrenschmidt <benh at kernel.crashing.org>,
-    IBM Corp.
-(c) 2005 Becky Bruce <becky.bruce at freescale.com>,
-    Freescale Semiconductor, FSL SOC and 32-bit additions
-(c) 2006 MontaVista Software, Inc.
-    Flash chip node definition
-
-Table of Contents
-=================
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+==================================================
+Booting the Linux/ppc kernel without Open Firmware
+==================================================
+
+Copyright |copy| 2005 Benjamin Herrenschmidt <benh at kernel.crashing.org>,
+IBM Corp.
+
+Copyright |copy| 2005 Becky Bruce <becky.bruce at freescale.com>,
+Freescale Semiconductor, FSL SOC and 32-bit additions
+
+Copyright |copy| 2006 MontaVista Software, Inc.
+Flash chip node definition
+
+.. Table of Contents
 
   I - Introduction
     1) Entry point for arch/arm
@@ -61,15 +66,18 @@ Table of Contents
 Revision Information
 ====================
 
-   May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
+   May 18, 2005: Rev 0.1
+			 - Initial draft, no chapter III yet.
 
-   May 19, 2005: Rev 0.2 - Add chapter III and bits & pieces here or
+   May 19, 2005: Rev 0.2
+			 - Add chapter III and bits & pieces here or
                            clarifies the fact that a lot of things are
                            optional, the kernel only requires a very
                            small device tree, though it is encouraged
                            to provide an as complete one as possible.
 
-   May 24, 2005: Rev 0.3 - Precise that DT block has to be in RAM
+   May 24, 2005: Rev 0.3
+			 - Precise that DT block has to be in RAM
 			 - Misc fixes
 			 - Define version 3 and new format version 16
 			   for the DT block (version 16 needs kernel
@@ -82,7 +90,8 @@ Revision Information
 			   "name" property is now automatically
 			   deduced from the unit name
 
-   June 1, 2005: Rev 0.4 - Correct confusion between OF_DT_END and
+   June 1, 2005: Rev 0.4
+			 - Correct confusion between OF_DT_END and
                            OF_DT_END_NODE in structure definition.
                          - Change version 16 format to always align
                            property data to 4 bytes. Since tokens are
@@ -115,7 +124,7 @@ Revision Information
 	- Compare FSL SOC use of PCI to standard and make sure no new
 	  node definition required.
 	- Add more information about node definitions for SOC devices
-  	  that currently have no standard, like the FSL CPM.
+	  that currently have no standard, like the FSL CPM.
 
 
 I - Introduction
@@ -260,7 +269,7 @@ it with special cases.
 
         b) create your main platform file as
         "arch/powerpc/platforms/myplatform/myboard_setup.c" and add it
-        to the Makefile under the condition of your CONFIG_
+        to the Makefile under the condition of your ``CONFIG_``
         option. This file will define a structure of type "ppc_md"
         containing the various callbacks that the generic code will
         use to get to your platform specific code
@@ -271,7 +280,7 @@ it with special cases.
   with classic Powerpc architectures.
 
 3) Entry point for arch/x86
--------------------------------
+---------------------------
 
   There is one single 32bit entry point to the kernel at code32_start,
   the decompressor (the real mode entry point goes to the same  32bit
@@ -280,9 +289,9 @@ it with special cases.
   Documentation/x86/boot.rst
   The physical pointer to the device-tree block (defined in chapter II)
   is passed via setup_data which requires at least boot protocol 2.09.
-  The type filed is defined as
+  The type filed is defined as::
 
-  #define SETUP_DTB                      2
+    #define SETUP_DTB                      2
 
   This device-tree is used as an extension to the "boot page". As such it
   does not parse / consider data which is already covered by the boot
@@ -354,9 +363,9 @@ the block to RAM before passing it to the kernel.
 
    The kernel is passed the physical address pointing to an area of memory
    that is roughly described in include/linux/of_fdt.h by the structure
-   boot_param_header:
+   boot_param_header:::
 
-struct boot_param_header {
+      struct boot_param_header {
         u32     magic;                  /* magic word OF_DT_HEADER */
         u32     totalsize;              /* total size of DT block */
         u32     off_dt_struct;          /* offset to structure */
@@ -374,19 +383,19 @@ struct boot_param_header {
 
         /* version 17 fields below */
         u32	size_dt_struct;		/* size of the DT structure block */
-};
+      };
 
-   Along with the constants:
+   Along with the constants::
 
-/* Definitions used by the flattened device tree */
-#define OF_DT_HEADER            0xd00dfeed      /* 4: version,
-						   4: total size */
-#define OF_DT_BEGIN_NODE        0x1             /* Start node: full name
-						   */
-#define OF_DT_END_NODE          0x2             /* End node */
-#define OF_DT_PROP              0x3             /* Property: name off,
-                                                   size, content */
-#define OF_DT_END               0x9
+    /* Definitions used by the flattened device tree */
+    #define OF_DT_HEADER            0xd00dfeed      /* 4: version,
+						    4: total size */
+    #define OF_DT_BEGIN_NODE        0x1             /* Start node: full name
+						    */
+    #define OF_DT_END_NODE          0x2             /* End node */
+    #define OF_DT_PROP              0x3             /* Property: name off,
+						    size, content */
+    #define OF_DT_END               0x9
 
    All values in this header are in big endian format, the various
    fields in this header are defined more precisely below. All
@@ -430,7 +439,7 @@ struct boot_param_header {
      way to avoid overriding critical things like, on Open Firmware
      capable machines, the RTAS instance, or on some pSeries, the TCE
      tables used for the iommu. Typically, the reserve map should
-     contain _at least_ this DT block itself (header,total_size). If
+     contain **at least** this DT block itself (header,total_size). If
      you are passing an initrd to the kernel, you should reserve it as
      well. You do not need to reserve the kernel image itself. The map
      should be 64-bit aligned.
@@ -485,7 +494,7 @@ struct boot_param_header {
 
    So the typical layout of a DT block (though the various parts don't
    need to be in that order) looks like this (addresses go from top to
-   bottom):
+   bottom)::
 
 
              ------------------------------
@@ -511,9 +520,9 @@ struct boot_param_header {
       |
       --- (base + totalsize)
 
-  (*) The alignment gaps are not necessarily present; their presence
-      and size are dependent on the various alignment requirements of
-      the individual data blocks.
+     (*) The alignment gaps are not necessarily present; their presence
+         and size are dependent on the various alignment requirements of
+         the individual data blocks.
 
 
 2) Device tree generalities
@@ -600,7 +609,7 @@ discussed in a later chapter. At this point, it is only meant to give
 you a idea of what a device-tree looks like. I have purposefully kept
 the "name" and "linux,phandle" properties which aren't necessary in
 order to give you a better idea of what the tree looks like in
-practice.
+practice::
 
   / o device-tree
       |- name = "device-tree"
@@ -650,6 +659,7 @@ properties and their content.
 
 
 3) Device tree "structure" block
+--------------------------------
 
 The structure of the device tree is a linearized tree structure. The
 "OF_DT_BEGIN_NODE" token starts a new node, and the "OF_DT_END_NODE"
@@ -666,12 +676,14 @@ Here's the basic structure of a single node:
        root node)
      * [align gap to next 4 bytes boundary]
      * for each property:
+
         * token OF_DT_PROP (that is 0x00000003)
         * 32-bit value of property value size in bytes (or 0 if no
           value)
         * 32-bit value of offset in string block of property name
         * property value data if any
         * [align gap to next 4 bytes boundary]
+
      * [child nodes if any]
      * token OF_DT_END_NODE (that is 0x00000002)
 
@@ -688,6 +700,7 @@ manipulating a flattened tree must take care to preserve this
 constraint.
 
 4) Device tree "strings" block
+------------------------------
 
 In order to save space, property names, which are generally redundant,
 are stored separately in the "strings" block. This block is simply the
@@ -700,15 +713,17 @@ strings block.
 III - Required content of the device tree
 =========================================
 
-WARNING: All "linux,*" properties defined in this document apply only
-to a flattened device-tree. If your platform uses a real
-implementation of Open Firmware or an implementation compatible with
-the Open Firmware client interface, those properties will be created
-by the trampoline code in the kernel's prom_init() file. For example,
-that's where you'll have to add code to detect your board model and
-set the platform number. However, when using the flattened device-tree
-entry point, there is no prom_init() pass, and thus you have to
-provide those properties yourself.
+.. Warning::
+
+   All ``linux,*`` properties defined in this document apply only
+   to a flattened device-tree. If your platform uses a real
+   implementation of Open Firmware or an implementation compatible with
+   the Open Firmware client interface, those properties will be created
+   by the trampoline code in the kernel's prom_init() file. For example,
+   that's where you'll have to add code to detect your board model and
+   set the platform number. However, when using the flattened device-tree
+   entry point, there is no prom_init() pass, and thus you have to
+   provide those properties yourself.
 
 
 1) Note about cells and address representation
@@ -769,7 +784,7 @@ addresses), all buses must contain a "ranges" property. If the
 "ranges" property is missing at a given level, it's assumed that
 translation isn't possible, i.e., the registers are not visible on the
 parent bus.  The format of the "ranges" property for a bus is a list
-of:
+of::
 
 	bus address, parent bus address, size
 
@@ -877,7 +892,7 @@ address which can extend beyond that limit.
 
   This node is the parent of all individual CPU nodes. It doesn't
   have any specific requirements, though it's generally good practice
-  to have at least:
+  to have at least::
 
                #address-cells = <00000001>
                #size-cells    = <00000000>
@@ -887,7 +902,7 @@ address which can extend beyond that limit.
   that format when reading the "reg" properties of a CPU node, see
   below
 
-  c) The /cpus/* nodes
+  c) The ``/cpus/*`` nodes
 
   So under /cpus, you are supposed to create a node for every CPU on
   the machine. There is no specific restriction on the name of the
@@ -903,21 +918,23 @@ address which can extend beyond that limit.
     - reg : This is the physical CPU number, it's a single 32-bit cell
       and is also used as-is as the unit number for constructing the
       unit name in the full path. For example, with 2 CPUs, you would
-      have the full path:
+      have the full path::
+
         /cpus/PowerPC,970FX@0
         /cpus/PowerPC,970FX@1
+
       (unit addresses do not require leading zeroes)
-    - d-cache-block-size : one cell, L1 data cache block size in bytes (*)
+    - d-cache-block-size : one cell, L1 data cache block size in bytes [#]_
     - i-cache-block-size : one cell, L1 instruction cache block size in
       bytes
     - d-cache-size : one cell, size of L1 data cache in bytes
     - i-cache-size : one cell, size of L1 instruction cache in bytes
 
-(*) The cache "block" size is the size on which the cache management
-instructions operate. Historically, this document used the cache
-"line" size here which is incorrect. The kernel will prefer the cache
-block size and will fallback to cache line size for backward
-compatibility.
+    .. [#] The cache "block" size is the size on which the cache management
+	   instructions operate. Historically, this document used the cache
+	   "line" size here which is incorrect. The kernel will prefer the cache
+	   block size and will fallback to cache line size for backward
+	   compatibility.
 
   Recommended properties:
 
@@ -963,10 +980,10 @@ compatibility.
       #address-cells and #size-cells of the root node. For example,
       with both of these properties being 2 like in the example given
       earlier, a 970 based machine with 6Gb of RAM could typically
-      have a "reg" property here that looks like:
+      have a "reg" property here that looks like::
 
-      00000000 00000000 00000000 80000000
-      00000001 00000000 00000001 00000000
+        00000000 00000000 00000000 80000000
+        00000001 00000000 00000001 00000000
 
       That is a range starting at 0 of 0x80000000 bytes and a range
       starting at 0x100000000 and of 0x100000000 bytes. You can see
@@ -1047,18 +1064,18 @@ compatibility.
       See 1) above for more details on defining #address-cells.
     - #size-cells : Size representation for "soc" devices
     - #interrupt-cells : Defines the width of cells used to represent
-       interrupts.  Typically this value is <2>, which includes a
-       32-bit number that represents the interrupt number, and a
-       32-bit number that represents the interrupt sense and level.
-       This field is only needed if the SOC contains an interrupt
-       controller.
+      interrupts.  Typically this value is <2>, which includes a
+      32-bit number that represents the interrupt number, and a
+      32-bit number that represents the interrupt sense and level.
+      This field is only needed if the SOC contains an interrupt
+      controller.
 
   The SOC node may contain child nodes for each SOC device that the
   platform uses.  Nodes should not be created for devices which exist
   on the SOC but are not used by a particular platform. See chapter VI
   for more information on how to specify devices that are part of a SOC.
 
-  Example SOC node for the MPC8540:
+  Example SOC node for the MPC8540::
 
 	soc8540@e0000000 {
 		#address-cells = <1>;
@@ -1079,31 +1096,33 @@ IV - "dtc", the device tree compiler
 dtc source code can be found at
 <http://git.jdl.com/gitweb/?p=dtc.git>
 
-WARNING: This version is still in early development stage; the
-resulting device-tree "blobs" have not yet been validated with the
-kernel. The current generated block lacks a useful reserve map (it will
-be fixed to generate an empty one, it's up to the bootloader to fill
-it up) among others. The error handling needs work, bugs are lurking,
-etc...
+.. Warning::
+
+   This version is still in early development stage; the
+   resulting device-tree "blobs" have not yet been validated with the
+   kernel. The current generated block lacks a useful reserve map (it will
+   be fixed to generate an empty one, it's up to the bootloader to fill
+   it up) among others. The error handling needs work, bugs are lurking,
+   etc...
 
 dtc basically takes a device-tree in a given format and outputs a
 device-tree in another format. The currently supported formats are:
 
-  Input formats:
-  -------------
+Input formats
+-------------
 
      - "dtb": "blob" format, that is a flattened device-tree block
        with
-        header all in a binary blob.
+       header all in a binary blob.
      - "dts": "source" format. This is a text file containing a
        "source" for a device-tree. The format is defined later in this
-        chapter.
+       chapter.
      - "fs" format. This is a representation equivalent to the
-        output of /proc/device-tree, that is nodes are directories and
-	properties are files
+       output of /proc/device-tree, that is nodes are directories and
+       properties are files
 
- Output formats:
- ---------------
+Output formats
+--------------
 
      - "dtb": "blob" format
      - "dts": "source" format
@@ -1113,7 +1132,7 @@ device-tree in another format. The currently supported formats are:
        assembly file exports some symbols that can be used.
 
 
-The syntax of the dtc tool is
+The syntax of the dtc tool is::
 
     dtc [-I <input-format>] [-O <output-format>]
         [-o output-filename] [-V output_version] input_filename
@@ -1127,43 +1146,45 @@ Additionally, dtc performs various sanity checks on the tree, like the
 uniqueness of linux, phandle properties, validity of strings, etc...
 
 The format of the .dts "source" file is "C" like, supports C and C++
-style comments.
+style comments::
 
-/ {
-}
+    / {
+    }
 
 The above is the "device-tree" definition. It's the only statement
 supported currently at the toplevel.
 
-/ {
-  property1 = "string_value";	/* define a property containing a 0
-                                 * terminated string
-				 */
+::
 
-  property2 = <0x1234abcd>;	/* define a property containing a
-                                 * numerical 32-bit value (hexadecimal)
-				 */
+  / {
+    property1 = "string_value";	   /* define a property containing a 0
+				    * terminated string
+				    */
 
-  property3 = <0x12345678 0x12345678 0xdeadbeef>;
-                                /* define a property containing 3
-                                 * numerical 32-bit values (cells) in
-                                 * hexadecimal
-				 */
-  property4 = [0x0a 0x0b 0x0c 0x0d 0xde 0xea 0xad 0xbe 0xef];
-                                /* define a property whose content is
-                                 * an arbitrary array of bytes
-                                 */
+    property2 = <0x1234abcd>;	   /* define a property containing a
+				    * numerical 32-bit value (hexadecimal)
+				    */
 
-  childnode@address {	/* define a child node named "childnode"
-                                 * whose unit name is "childnode at
-				 * address"
-                                 */
+    property3 = <0x12345678 0x12345678 0xdeadbeef>;
+				   /* define a property containing 3
+				    * numerical 32-bit values (cells) in
+				    * hexadecimal
+				    */
+    property4 = [0x0a 0x0b 0x0c 0x0d 0xde 0xea 0xad 0xbe 0xef];
+				   /* define a property whose content is
+				    * an arbitrary array of bytes
+				    */
 
-    childprop = "hello\n";      /* define a property "childprop" of
-                                 * childnode (in this case, a string)
-                                 */
-  };
-};
+    childnode@address {		   /* define a child node named "childnode"
+				    * whose unit name is "childnode at
+				    * address"
+				    */
+
+	childprop = "hello\n";	       /* define a property "childprop" of
+					* childnode (in this case, a string)
+					*/
+	};
+    };
 
 Nodes can contain other nodes etc... thus defining the hierarchical
 structure of the tree.
@@ -1322,7 +1343,7 @@ phandle of the parent node.
 
 If the interrupt-parent property is not defined for a node, its
 interrupt parent is assumed to be an ancestor in the node's
-_device tree_ hierarchy.
+*device tree* hierarchy.
 
 3) OpenPIC Interrupt Controllers
 --------------------------------
@@ -1334,10 +1355,12 @@ information.
 
 Sense and level information should be encoded as follows:
 
-	0 = low to high edge sensitive type enabled
-	1 = active low level sensitive type enabled
-	2 = active high level sensitive type enabled
-	3 = high to low edge sensitive type enabled
+	==  ========================================
+	0   low to high edge sensitive type enabled
+	1   active low level sensitive type enabled
+	2   active high level sensitive type enabled
+	3   high to low edge sensitive type enabled
+	==  ========================================
 
 4) ISA Interrupt Controllers
 ----------------------------
@@ -1350,13 +1373,15 @@ information.
 ISA PIC interrupt controllers should adhere to the ISA PIC
 encodings listed below:
 
-	0 =  active low level sensitive type enabled
-	1 =  active high level sensitive type enabled
-	2 =  high to low edge sensitive type enabled
-	3 =  low to high edge sensitive type enabled
+	==  ========================================
+	0   active low level sensitive type enabled
+	1   active high level sensitive type enabled
+	2   high to low edge sensitive type enabled
+	3   low to high edge sensitive type enabled
+	==  ========================================
 
 VIII - Specifying Device Power Management Information (sleep property)
-===================================================================
+======================================================================
 
 Devices on SOCs often have mechanisms for placing devices into low-power
 states that are decoupled from the devices' own register blocks.  Sometimes,
@@ -1387,6 +1412,7 @@ reasonably grouped in this manner, then create a virtual sleep controller
 sleep-map should wait until its necessity is demonstrated).
 
 IX - Specifying dma bus information
+===================================
 
 Some devices may have DMA memory range shifted relatively to the beginning of
 RAM, or even placed outside of kernel RAM. For example, the Keystone 2 SoC
@@ -1404,25 +1430,30 @@ coherent DMA operations. The "dma-coherent" property is intended to be used
 for identifying devices supported coherent DMA operations in DT.
 
 * DMA Bus master
+
 Optional property:
+
 - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
-	(child-bus-address, parent-bus-address, length). Each triplet specified
-	describes a contiguous DMA address range.
-	The dma-ranges property is used to describe the direct memory access (DMA)
-	structure of a memory-mapped bus whose device tree parent can be accessed
-	from DMA operations originating from the bus. It provides a means of
-	defining a mapping or translation between the physical address space of
-	the bus and the physical address space of the parent of the bus.
-	(for more information see the Devicetree Specification)
+  (child-bus-address, parent-bus-address, length). Each triplet specified
+  describes a contiguous DMA address range.
+  The dma-ranges property is used to describe the direct memory access (DMA)
+  structure of a memory-mapped bus whose device tree parent can be accessed
+  from DMA operations originating from the bus. It provides a means of
+  defining a mapping or translation between the physical address space of
+  the bus and the physical address space of the parent of the bus.
+  (for more information see the Devicetree Specification)
 
 * DMA Bus child
+
 Optional property:
+
 - dma-ranges: <empty> value. if present - It means that DMA addresses
-	translation has to be enabled for this device.
+  translation has to be enabled for this device.
 - dma-coherent: Present if dma operations are coherent
 
-Example:
-soc {
+Example::
+
+	soc {
 		compatible = "ti,keystone","simple-bus";
 		ranges = <0x0 0x0 0x0 0xc0000000>;
 		dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
@@ -1435,11 +1466,13 @@ soc {
 			[...]
 			dma-coherent;
 		};
-};
+	};
 
 Appendix A - Sample SOC node for MPC8540
 ========================================
 
+::
+
 	soc@e0000000 {
 		#address-cells = <1>;
 		#size-cells = <1>;
diff --git a/Documentation/devicetree/index.rst b/Documentation/devicetree/index.rst
index 54026763916d..d2a96e1af23e 100644
--- a/Documentation/devicetree/index.rst
+++ b/Documentation/devicetree/index.rst
@@ -15,3 +15,4 @@ Open Firmware and Device Tree
    overlay-notes
 
    bindings/index
+   booting-without-of
diff --git a/Documentation/translations/zh_CN/arm/Booting b/Documentation/translations/zh_CN/arm/Booting
index 562e9a2957e6..c3d26ce5f6de 100644
--- a/Documentation/translations/zh_CN/arm/Booting
+++ b/Documentation/translations/zh_CN/arm/Booting
@@ -124,7 +124,7 @@ bootloader 必须传递一个系统内存的位置和最小值，以及根文件
 
 bootloader 必须以 64bit 地址对齐的形式加载一个设备树映像(dtb)到系统
 RAM 中，并用启动数据初始化它。dtb 格式在文档
-Documentation/devicetree/booting-without-of.txt 中。内核将会在
+Documentation/devicetree/booting-without-of.rst 中。内核将会在
 dtb 物理地址处查找 dtb 魔数值（0xd00dfeed），以确定 dtb 是否已经代替
 标签列表被传递进来。
 
-- 
2.26.2

Re: [PATCH 01/22] docs: dt: convert booting-without-of.txt to ReST format

[Jonathan Corbet]

On Mon, 15 Jun 2020 08:50:06 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> +Copyright |copy| 2005 Benjamin Herrenschmidt <benh at kernel.crashing.org>,
> +IBM Corp.
> +
> +Copyright |copy| 2005 Becky Bruce <becky.bruce at freescale.com>,
> +Freescale Semiconductor, FSL SOC and 32-bit additions
> +
> +Copyright |copy| 2006 MontaVista Software, Inc.
> +Flash chip node definition

So use of |copy| like this has caused complaints in the past; I think it's
probably better to leave these as they are.

Thanks,

jon

[PATCH 02/22] docs: thermal: convert cpu-idle-cooling.rst to ReST

[Mauro Carvalho Chehab]

Despite being named with .rst extension, this file doesn't
match the ReST standard. It actually causes a crash at
Sphinx:

	Sphinx parallel build error:
	docutils.utils.SystemMessage: /devel/v4l/docs/Documentation/driver-api/thermal/cpu-idle-cooling.rst:69: (SEVERE/4) Unexpected section title.

Add needed markups for it to be properly parsed.

While here, add it to the thermal index.rst.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../driver-api/thermal/cpu-idle-cooling.rst        | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Documentation/driver-api/thermal/cpu-idle-cooling.rst b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
index b9f34ceb2a38..c2a7ca676853 100644
--- a/Documentation/driver-api/thermal/cpu-idle-cooling.rst
+++ b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
 ================
 CPU Idle Cooling
 ================
@@ -48,7 +50,7 @@ idle state target residency, we lead to dropping the static and the
 dynamic leakage for this period (modulo the energy needed to enter
 this state). So the sustainable power with idle cycles has a linear
 relation with the OPP’s sustainable power and can be computed with a
-coefficient similar to:
+coefficient similar to::
 
 	    Power(IdleCycle) = Coef x Power(OPP)
 
@@ -139,7 +141,7 @@ Power considerations
 --------------------
 
 When we reach the thermal trip point, we have to sustain a specified
-power for a specific temperature but at this time we consume:
+power for a specific temperature but at this time we consume::
 
  Power = Capacitance x Voltage^2 x Frequency x Utilisation
 
@@ -148,7 +150,7 @@ wrong in the system setup). The ‘Capacitance’ and ‘Utilisation’ are a
 fixed value, ‘Voltage’ and the ‘Frequency’ are fixed artificially
 because we don’t want to change the OPP. We can group the
 ‘Capacitance’ and the ‘Utilisation’ into a single term which is the
-‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have:
+‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have::
 
  Pdyn = Cdyn x Voltage^2 x Frequency
 
@@ -157,7 +159,7 @@ in order to target the sustainable power defined in the device
 tree. So with the idle injection mechanism, we want an average power
 (Ptarget) resulting in an amount of time running at full power on a
 specific OPP and idle another amount of time. That could be put in a
-equation:
+equation::
 
  P(opp)target = ((Trunning x (P(opp)running) + (Tidle x P(opp)idle)) /
 			(Trunning + Tidle)
@@ -168,7 +170,7 @@ equation:
 
 At this point if we know the running period for the CPU, that gives us
 the idle injection we need. Alternatively if we have the idle
-injection duration, we can compute the running duration with:
+injection duration, we can compute the running duration with::
 
  Trunning = Tidle / ((P(opp)running / P(opp)target) - 1)
 
@@ -191,7 +193,7 @@ However, in this demonstration we ignore three aspects:
    target residency, otherwise we end up consuming more energy and
    potentially invert the mitigation effect
 
-So the final equation is:
+So the final equation is::
 
  Trunning = (Tidle - Twakeup ) x
 		(((P(opp)dyn + P(opp)static ) - P(opp)target) / P(opp)target )
-- 
2.26.2

Re: [PATCH 02/22] docs: thermal: convert cpu-idle-cooling.rst to ReST

[Jonathan Corbet]

On Mon, 15 Jun 2020 08:50:07 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> Despite being named with .rst extension, this file doesn't
> match the ReST standard. It actually causes a crash at
> Sphinx:
> 
> 	Sphinx parallel build error:
> 	docutils.utils.SystemMessage: /devel/v4l/docs/Documentation/driver-api/thermal/cpu-idle-cooling.rst:69: (SEVERE/4) Unexpected section title.
> 
> Add needed markups for it to be properly parsed.
> 
> While here, add it to the thermal index.rst.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---

Applied (though I took out the line about adding it to index.rst since
this patch doesn't do that...)

Thanks,

jon

[PATCH 03/22] docs: crypto: convert asymmetric-keys.txt to ReST

[Mauro Carvalho Chehab]

This file is almost compatible with ReST. Just minor changes
were needed:

- Adjust document and titles markups;
- Adjust numbered list markups;
- Add a comments markup for the Contents section;
- Add markups for literal blocks.

Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 ...symmetric-keys.txt => asymmetric-keys.rst} | 91 +++++++++----------
 Documentation/crypto/index.rst                |  1 +
 Documentation/security/keys/core.rst          |  2 +-
 MAINTAINERS                                   |  2 +-
 crypto/asymmetric_keys/asymmetric_type.c      |  2 +-
 crypto/asymmetric_keys/public_key.c           |  2 +-
 crypto/asymmetric_keys/signature.c            |  2 +-
 include/crypto/public_key.h                   |  2 +-
 include/keys/asymmetric-parser.h              |  2 +-
 include/keys/asymmetric-subtype.h             |  2 +-
 include/keys/asymmetric-type.h                |  2 +-
 11 files changed, 53 insertions(+), 57 deletions(-)
 rename Documentation/crypto/{asymmetric-keys.txt => asymmetric-keys.rst} (91%)

diff --git a/Documentation/crypto/asymmetric-keys.txt b/Documentation/crypto/asymmetric-keys.rst
similarity index 91%
rename from Documentation/crypto/asymmetric-keys.txt
rename to Documentation/crypto/asymmetric-keys.rst
index 8763866b11cf..349f44a29392 100644
--- a/Documentation/crypto/asymmetric-keys.txt
+++ b/Documentation/crypto/asymmetric-keys.rst
@@ -1,8 +1,10 @@
-		=============================================
-		ASYMMETRIC / PUBLIC-KEY CRYPTOGRAPHY KEY TYPE
-		=============================================
+.. SPDX-License-Identifier: GPL-2.0
 
-Contents:
+=============================================
+Asymmetric / Public-key Cryptography Key Type
+=============================================
+
+.. Contents:
 
   - Overview.
   - Key identification.
@@ -13,8 +15,7 @@ Contents:
   - Keyring link restrictions.
 
 
-========
-OVERVIEW
+Overview
 ========
 
 The "asymmetric" key type is designed to be a container for the keys used in
@@ -42,8 +43,7 @@ key, or it may interpret it as a reference to a key held somewhere else in the
 system (for example, a TPM).
 
 
-==================
-KEY IDENTIFICATION
+Key Identification
 ==================
 
 If a key is added with an empty name, the instantiation data parsers are given
@@ -57,49 +57,48 @@ The asymmetric key type's match function can then perform a wider range of
 comparisons than just the straightforward comparison of the description with
 the criterion string:
 
- (1) If the criterion string is of the form "id:<hexdigits>" then the match
+  1) If the criterion string is of the form "id:<hexdigits>" then the match
      function will examine a key's fingerprint to see if the hex digits given
-     after the "id:" match the tail.  For instance:
+     after the "id:" match the tail.  For instance::
 
 	keyctl search @s asymmetric id:5acc2142
 
-     will match a key with fingerprint:
+     will match a key with fingerprint::
 
 	1A00 2040 7601 7889 DE11  882C 3823 04AD 5ACC 2142
 
- (2) If the criterion string is of the form "<subtype>:<hexdigits>" then the
+  2) If the criterion string is of the form "<subtype>:<hexdigits>" then the
      match will match the ID as in (1), but with the added restriction that
      only keys of the specified subtype (e.g. tpm) will be matched.  For
-     instance:
+     instance::
 
 	keyctl search @s asymmetric tpm:5acc2142
 
 Looking in /proc/keys, the last 8 hex digits of the key fingerprint are
-displayed, along with the subtype:
+displayed, along with the subtype::
 
 	1a39e171 I-----     1 perm 3f010000     0     0 asymmetric modsign.0: DSA 5acc2142 []
 
 
-=========================
-ACCESSING ASYMMETRIC KEYS
+Accessing Asymmetric Keys
 =========================
 
 For general access to asymmetric keys from within the kernel, the following
-inclusion is required:
+inclusion is required::
 
 	#include <crypto/public_key.h>
 
 This gives access to functions for dealing with asymmetric / public keys.
 Three enums are defined there for representing public-key cryptography
-algorithms:
+algorithms::
 
 	enum pkey_algo
 
-digest algorithms used by those:
+digest algorithms used by those::
 
 	enum pkey_hash_algo
 
-and key identifier representations:
+and key identifier representations::
 
 	enum pkey_id_type
 
@@ -110,25 +109,25 @@ PGP-specific metadata, whereas X.509 has arbitrary certificate identifiers.
 
 The operations defined upon a key are:
 
- (1) Signature verification.
+  1) Signature verification.
 
 Other operations are possible (such as encryption) with the same key data
 required for verification, but not currently supported, and others
 (eg. decryption and signature generation) require extra key data.
 
 
-SIGNATURE VERIFICATION
+Signature Verification
 ----------------------
 
 An operation is provided to perform cryptographic signature verification, using
-an asymmetric key to provide or to provide access to the public key.
+an asymmetric key to provide or to provide access to the public key::
 
 	int verify_signature(const struct key *key,
 			     const struct public_key_signature *sig);
 
 The caller must have already obtained the key from some source and can then use
 it to check the signature.  The caller must have parsed the signature and
-transferred the relevant bits to the structure pointed to by sig.
+transferred the relevant bits to the structure pointed to by sig::
 
 	struct public_key_signature {
 		u8 *digest;
@@ -159,8 +158,7 @@ data; or -ENOMEM if an allocation can't be performed.  -EINVAL can be returned
 if the key argument is the wrong type or is incompletely set up.
 
 
-=======================
-ASYMMETRIC KEY SUBTYPES
+Asymmetric Key Subtypes
 =======================
 
 Asymmetric keys have a subtype that defines the set of operations that can be
@@ -171,11 +169,11 @@ The subtype is selected by the key data parser and the parser must initialise
 the data required for it.  The asymmetric key retains a reference on the
 subtype module.
 
-The subtype definition structure can be found in:
+The subtype definition structure can be found in::
 
 	#include <keys/asymmetric-subtype.h>
 
-and looks like the following:
+and looks like the following::
 
 	struct asymmetric_key_subtype {
 		struct module		*owner;
@@ -198,39 +196,37 @@ the subtype.  Currently, the name is only used for print statements.
 
 There are a number of operations defined by the subtype:
 
- (1) describe().
+  1) describe().
 
      Mandatory.  This allows the subtype to display something in /proc/keys
      against the key.  For instance the name of the public key algorithm type
      could be displayed.  The key type will display the tail of the key
      identity string after this.
 
- (2) destroy().
+  2) destroy().
 
      Mandatory.  This should free the memory associated with the key.  The
      asymmetric key will look after freeing the fingerprint and releasing the
      reference on the subtype module.
 
- (3) query().
+  3) query().
 
      Mandatory.  This is a function for querying the capabilities of a key.
 
- (4) eds_op().
+  4) eds_op().
 
      Optional.  This is the entry point for the encryption, decryption and
      signature creation operations (which are distinguished by the operation ID
      in the parameter struct).  The subtype may do anything it likes to
      implement an operation, including offloading to hardware.
 
- (5) verify_signature().
+  5) verify_signature().
 
      Optional.  This is the entry point for signature verification.  The
      subtype may do anything it likes to implement an operation, including
      offloading to hardware.
 
-
-==========================
-INSTANTIATION DATA PARSERS
+Instantiation Data Parsers
 ==========================
 
 The asymmetric key type doesn't generally want to store or to deal with a raw
@@ -254,11 +250,11 @@ Examples of blob formats for which parsers could be implemented include:
 During key instantiation each parser in the list is tried until one doesn't
 return -EBADMSG.
 
-The parser definition structure can be found in:
+The parser definition structure can be found in::
 
 	#include <keys/asymmetric-parser.h>
 
-and looks like the following:
+and looks like the following::
 
 	struct asymmetric_key_parser {
 		struct module	*owner;
@@ -273,7 +269,7 @@ the parser.
 There is currently only a single operation defined by the parser, and it is
 mandatory:
 
- (1) parse().
+  1) parse().
 
      This is called to preparse the key from the key creation and update paths.
      In particular, it is called during the key creation _before_ a key is
@@ -282,7 +278,7 @@ mandatory:
 
      The caller passes a pointer to the following struct with all of the fields
      cleared, except for data, datalen and quotalen [see
-     Documentation/security/keys/core.rst].
+     Documentation/security/keys/core.rst]::
 
 	struct key_preparsed_payload {
 		char		*description;
@@ -321,7 +317,7 @@ mandatory:
      public-key algorithm such as RSA and DSA this will likely be a printable
      hex version of the key's fingerprint.
 
-Functions are provided to register and unregister parsers:
+Functions are provided to register and unregister parsers::
 
 	int register_asymmetric_key_parser(struct asymmetric_key_parser *parser);
 	void unregister_asymmetric_key_parser(struct asymmetric_key_parser *subtype);
@@ -330,8 +326,7 @@ Parsers may not have the same name.  The names are otherwise only used for
 displaying in debugging messages.
 
 
-=========================
-KEYRING LINK RESTRICTIONS
+Keyring Link Restrictions
 =========================
 
 Keyrings created from userspace using add_key can be configured to check the
@@ -340,7 +335,7 @@ allowed to link.
 
 Several restriction methods are available:
 
- (1) Restrict using the kernel builtin trusted keyring
+  1) Restrict using the kernel builtin trusted keyring
 
      - Option string used with KEYCTL_RESTRICT_KEYRING:
        - "builtin_trusted"
@@ -350,7 +345,7 @@ Several restriction methods are available:
      rejected.  The ca_keys kernel parameter also affects which keys are used
      for signature verification.
 
- (2) Restrict using the kernel builtin and secondary trusted keyrings
+  2) Restrict using the kernel builtin and secondary trusted keyrings
 
      - Option string used with KEYCTL_RESTRICT_KEYRING:
        - "builtin_and_secondary_trusted"
@@ -361,7 +356,7 @@ Several restriction methods are available:
      kernel parameter also affects which keys are used for signature
      verification.
 
- (3) Restrict using a separate key or keyring
+  3) Restrict using a separate key or keyring
 
      - Option string used with KEYCTL_RESTRICT_KEYRING:
        - "key_or_keyring:<key or keyring serial number>[:chain]"
@@ -378,7 +373,7 @@ Several restriction methods are available:
      certificate in order (starting closest to the root) to a keyring.  For
      instance, one keyring can be populated with links to a set of root
      certificates, with a separate, restricted keyring set up for each
-     certificate chain to be validated:
+     certificate chain to be validated::
 
 	# Create and populate a keyring for root certificates
 	root_id=`keyctl add keyring root-certs "" @s`
@@ -400,7 +395,7 @@ Several restriction methods are available:
      one of the root certificates.
 
      A single keyring can be used to verify a chain of signatures by
-     restricting the keyring after linking the root certificate:
+     restricting the keyring after linking the root certificate::
 
 	# Create a keyring for the certificate chain and add the root
 	chain2_id=`keyctl add keyring chain2 "" @s`
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index c4ff5d791233..2bcaf422731e 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -18,6 +18,7 @@ for cryptographic use cases, as well as programming examples.
 
    intro
    architecture
+   asymmetric-keys
    devel-algos
    userspace-if
    crypto_engine
diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index e0f1211ca843..e6522dd05037 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -912,7 +912,7 @@ The keyctl syscall functions are:
 
      One application of restricted keyrings is to verify X.509 certificate
      chains or individual certificate signatures using the asymmetric key type.
-     See Documentation/crypto/asymmetric-keys.txt for specific restrictions
+     See Documentation/crypto/asymmetric-keys.rst for specific restrictions
      applicable to the asymmetric key type.
 
 
diff --git a/MAINTAINERS b/MAINTAINERS
index 452904d75228..84eabb5f0a5d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2827,7 +2827,7 @@ ASYMMETRIC KEYS
 M:	David Howells <dhowells@redhat.com>
 L:	keyrings@vger.kernel.org
 S:	Maintained
-F:	Documentation/crypto/asymmetric-keys.txt
+F:	Documentation/crypto/asymmetric-keys.rst
 F:	crypto/asymmetric_keys/
 F:	include/crypto/pkcs7.h
 F:	include/crypto/public_key.h
diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c
index 6e5fc8e31f01..33e77d846caa 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /* Asymmetric public-key cryptography key type
  *
- * See Documentation/crypto/asymmetric-keys.txt
+ * See Documentation/crypto/asymmetric-keys.rst
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
index d7f43d4ea925..da4d0b82d018 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /* In-software asymmetric public-key crypto subtype
  *
- * See Documentation/crypto/asymmetric-keys.txt
+ * See Documentation/crypto/asymmetric-keys.rst
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
diff --git a/crypto/asymmetric_keys/signature.c b/crypto/asymmetric_keys/signature.c
index e24a031db1e4..4aff3eebec17 100644
--- a/crypto/asymmetric_keys/signature.c
+++ b/crypto/asymmetric_keys/signature.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /* Signature verification with an asymmetric key
  *
- * See Documentation/crypto/asymmetric-keys.txt
+ * See Documentation/crypto/asymmetric-keys.rst
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 0588ef3bc6ff..11f535cfb810 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 /* Asymmetric public-key algorithm definitions
  *
- * See Documentation/crypto/asymmetric-keys.txt
+ * See Documentation/crypto/asymmetric-keys.rst
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
diff --git a/include/keys/asymmetric-parser.h b/include/keys/asymmetric-parser.h
index 8a21d6a613ab..c47dc5405f79 100644
--- a/include/keys/asymmetric-parser.h
+++ b/include/keys/asymmetric-parser.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 /* Asymmetric public-key cryptography data parser
  *
- * See Documentation/crypto/asymmetric-keys.txt
+ * See Documentation/crypto/asymmetric-keys.rst
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
diff --git a/include/keys/asymmetric-subtype.h b/include/keys/asymmetric-subtype.h
index 21407815d9c3..d55171f640a0 100644
--- a/include/keys/asymmetric-subtype.h
+++ b/include/keys/asymmetric-subtype.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 /* Asymmetric public-key cryptography key subtype
  *
- * See Documentation/crypto/asymmetric-keys.txt
+ * See Documentation/crypto/asymmetric-keys.rst
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
diff --git a/include/keys/asymmetric-type.h b/include/keys/asymmetric-type.h
index 91cfd9bd9385..a29d3ff2e7e8 100644
--- a/include/keys/asymmetric-type.h
+++ b/include/keys/asymmetric-type.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 /* Asymmetric Public-key cryptography key type interface
  *
- * See Documentation/crypto/asymmetric-keys.txt
+ * See Documentation/crypto/asymmetric-keys.rst
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
-- 
2.26.2

Re: [PATCH 03/22] docs: crypto: convert asymmetric-keys.txt to ReST

[Jonathan Corbet]

On Mon, 15 Jun 2020 08:50:08 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> This file is almost compatible with ReST. Just minor changes
> were needed:
> 
> - Adjust document and titles markups;
> - Adjust numbered list markups;
> - Add a comments markup for the Contents section;
> - Add markups for literal blocks.
> 
> Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Applied, thanks.

jon

[PATCH 04/22] docs: crypto: convert api-intro.txt to ReST format

[Mauro Carvalho Chehab]

- Change title markups;
- Mark literal blocks;
- Use list markups at authors/credits;
- Add blank lines when needed;
- Remove trailing whitespaces.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../crypto/{api-intro.txt => api-intro.rst}   | 186 ++++++++++--------
 Documentation/crypto/index.rst                |   1 +
 2 files changed, 100 insertions(+), 87 deletions(-)
 rename Documentation/crypto/{api-intro.txt => api-intro.rst} (70%)

diff --git a/Documentation/crypto/api-intro.txt b/Documentation/crypto/api-intro.rst
similarity index 70%
rename from Documentation/crypto/api-intro.txt
rename to Documentation/crypto/api-intro.rst
index 45d943fcae5b..bcff47d42189 100644
--- a/Documentation/crypto/api-intro.txt
+++ b/Documentation/crypto/api-intro.rst
@@ -1,7 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
 
-                    Scatterlist Cryptographic API
-                   
-INTRODUCTION
+=============================
+Scatterlist Cryptographic API
+=============================
+
+Introduction
+============
 
 The Scatterlist Crypto API takes page vectors (scatterlists) as
 arguments, and works directly on pages.  In some cases (e.g. ECB
@@ -13,22 +17,23 @@ so that processing can be applied to paged skb's without the need
 for linearization.
 
 
-DETAILS
+Details
+=======
 
 At the lowest level are algorithms, which register dynamically with the
 API.
 
 'Transforms' are user-instantiated objects, which maintain state, handle all
-of the implementation logic (e.g. manipulating page vectors) and provide an 
-abstraction to the underlying algorithms.  However, at the user 
+of the implementation logic (e.g. manipulating page vectors) and provide an
+abstraction to the underlying algorithms.  However, at the user
 level they are very simple.
 
-Conceptually, the API layering looks like this:
+Conceptually, the API layering looks like this::
 
   [transform api]  (user interface)
   [transform ops]  (per-type logic glue e.g. cipher.c, compress.c)
   [algorithm api]  (for registering algorithms)
-  
+
 The idea is to make the user interface and algorithm registration API
 very simple, while hiding the core logic from both.  Many good ideas
 from existing APIs such as Cryptoapi and Nettle have been adapted for this.
@@ -44,21 +49,21 @@ one block while the former can operate on an arbitrary amount of data,
 subject to block size requirements (i.e., non-stream ciphers can only
 process multiples of blocks).
 
-Here's an example of how to use the API:
+Here's an example of how to use the API::
 
 	#include <crypto/hash.h>
 	#include <linux/err.h>
 	#include <linux/scatterlist.h>
-	
+
 	struct scatterlist sg[2];
 	char result[128];
 	struct crypto_ahash *tfm;
 	struct ahash_request *req;
-	
+
 	tfm = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
 	if (IS_ERR(tfm))
 		fail();
-		
+
 	/* ... set up the scatterlists ... */
 
 	req = ahash_request_alloc(tfm, GFP_ATOMIC);
@@ -67,18 +72,19 @@ Here's an example of how to use the API:
 
 	ahash_request_set_callback(req, 0, NULL, NULL);
 	ahash_request_set_crypt(req, sg, result, 2);
-	
+
 	if (crypto_ahash_digest(req))
 		fail();
 
 	ahash_request_free(req);
 	crypto_free_ahash(tfm);
 
-    
+
 Many real examples are available in the regression test module (tcrypt.c).
 
 
-DEVELOPER NOTES
+Developer Notes
+===============
 
 Transforms may only be allocated in user context, and cryptographic
 methods may only be called from softirq and user contexts.  For
@@ -91,7 +97,8 @@ size (typically 8 bytes).  This prevents having to do any copying
 across non-aligned page fragment boundaries.
 
 
-ADDING NEW ALGORITHMS
+Adding New Algorithms
+=====================
 
 When submitting a new algorithm for inclusion, a mandatory requirement
 is that at least a few test vectors from known sources (preferably
@@ -119,132 +126,137 @@ Also check the TODO list at the web site listed below to see what people
 might already be working on.
 
 
-BUGS
+Bugs
+====
 
 Send bug reports to:
-linux-crypto@vger.kernel.org
-Cc: Herbert Xu <herbert@gondor.apana.org.au>,
+    linux-crypto@vger.kernel.org
+
+Cc:
+    Herbert Xu <herbert@gondor.apana.org.au>,
     David S. Miller <davem@redhat.com>
 
 
-FURTHER INFORMATION
+Further Information
+===================
 
 For further patches and various updates, including the current TODO
 list, see:
 http://gondor.apana.org.au/~herbert/crypto/
 
 
-AUTHORS
+Authors
+=======
 
-James Morris
-David S. Miller
-Herbert Xu
+- James Morris
+- David S. Miller
+- Herbert Xu
 
 
-CREDITS
+Credits
+=======
 
 The following people provided invaluable feedback during the development
 of the API:
 
-  Alexey Kuznetzov
-  Rusty Russell
-  Herbert Valerio Riedel
-  Jeff Garzik
-  Michael Richardson
-  Andrew Morton
-  Ingo Oeser
-  Christoph Hellwig
+  - Alexey Kuznetzov
+  - Rusty Russell
+  - Herbert Valerio Riedel
+  - Jeff Garzik
+  - Michael Richardson
+  - Andrew Morton
+  - Ingo Oeser
+  - Christoph Hellwig
 
 Portions of this API were derived from the following projects:
-  
+
   Kerneli Cryptoapi (http://www.kerneli.org/)
-    Alexander Kjeldaas
-    Herbert Valerio Riedel
-    Kyle McMartin
-    Jean-Luc Cooke
-    David Bryson
-    Clemens Fruhwirth
-    Tobias Ringstrom
-    Harald Welte
+   - Alexander Kjeldaas
+   - Herbert Valerio Riedel
+   - Kyle McMartin
+   - Jean-Luc Cooke
+   - David Bryson
+   - Clemens Fruhwirth
+   - Tobias Ringstrom
+   - Harald Welte
 
 and;
-  
+
   Nettle (http://www.lysator.liu.se/~nisse/nettle/)
-    Niels Möller
+   - Niels Möller
 
 Original developers of the crypto algorithms:
 
-  Dana L. How (DES)
-  Andrew Tridgell and Steve French (MD4)
-  Colin Plumb (MD5)
-  Steve Reid (SHA1)
-  Jean-Luc Cooke (SHA256, SHA384, SHA512)
-  Kazunori Miyazawa / USAGI (HMAC)
-  Matthew Skala (Twofish)
-  Dag Arne Osvik (Serpent)
-  Brian Gladman (AES)
-  Kartikey Mahendra Bhatt (CAST6)
-  Jon Oberheide (ARC4)
-  Jouni Malinen (Michael MIC)
-  NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
+  - Dana L. How (DES)
+  - Andrew Tridgell and Steve French (MD4)
+  - Colin Plumb (MD5)
+  - Steve Reid (SHA1)
+  - Jean-Luc Cooke (SHA256, SHA384, SHA512)
+  - Kazunori Miyazawa / USAGI (HMAC)
+  - Matthew Skala (Twofish)
+  - Dag Arne Osvik (Serpent)
+  - Brian Gladman (AES)
+  - Kartikey Mahendra Bhatt (CAST6)
+  - Jon Oberheide (ARC4)
+  - Jouni Malinen (Michael MIC)
+  - NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
 
 SHA1 algorithm contributors:
-  Jean-Francois Dive
-  
+  - Jean-Francois Dive
+
 DES algorithm contributors:
-  Raimar Falke
-  Gisle Sælensminde
-  Niels Möller
+  - Raimar Falke
+  - Gisle Sælensminde
+  - Niels Möller
 
 Blowfish algorithm contributors:
-  Herbert Valerio Riedel
-  Kyle McMartin
+  - Herbert Valerio Riedel
+  - Kyle McMartin
 
 Twofish algorithm contributors:
-  Werner Koch
-  Marc Mutz
+  - Werner Koch
+  - Marc Mutz
 
 SHA256/384/512 algorithm contributors:
-  Andrew McDonald
-  Kyle McMartin
-  Herbert Valerio Riedel
-  
+  - Andrew McDonald
+  - Kyle McMartin
+  - Herbert Valerio Riedel
+
 AES algorithm contributors:
-  Alexander Kjeldaas
-  Herbert Valerio Riedel
-  Kyle McMartin
-  Adam J. Richter
-  Fruhwirth Clemens (i586)
-  Linus Torvalds (i586)
+  - Alexander Kjeldaas
+  - Herbert Valerio Riedel
+  - Kyle McMartin
+  - Adam J. Richter
+  - Fruhwirth Clemens (i586)
+  - Linus Torvalds (i586)
 
 CAST5 algorithm contributors:
-  Kartikey Mahendra Bhatt (original developers unknown, FSF copyright).
+  - Kartikey Mahendra Bhatt (original developers unknown, FSF copyright).
 
 TEA/XTEA algorithm contributors:
-  Aaron Grothe
-  Michael Ringe
+  - Aaron Grothe
+  - Michael Ringe
 
 Khazad algorithm contributors:
-  Aaron Grothe
+  - Aaron Grothe
 
 Whirlpool algorithm contributors:
-  Aaron Grothe
-  Jean-Luc Cooke
+  - Aaron Grothe
+  - Jean-Luc Cooke
 
 Anubis algorithm contributors:
-  Aaron Grothe
+  - Aaron Grothe
 
 Tiger algorithm contributors:
-  Aaron Grothe
+  - Aaron Grothe
 
 VIA PadLock contributors:
-  Michal Ludvig
+  - Michal Ludvig
 
 Camellia algorithm contributors:
-  NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
+  - NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
 
 Generic scatterwalk code by Adam J. Richter <adam@yggdrasil.com>
 
 Please send any credits updates or corrections to:
 Herbert Xu <herbert@gondor.apana.org.au>
-
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index 2bcaf422731e..b2eeab3c8631 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -17,6 +17,7 @@ for cryptographic use cases, as well as programming examples.
    :maxdepth: 2
 
    intro
+   api-intro
    architecture
    asymmetric-keys
    devel-algos
-- 
2.26.2

[PATCH 05/22] docs: crypto: convert async-tx-api.txt to ReST format

[Mauro Carvalho Chehab]

- Place the txt index inside a comment;
- Use title and chapter markups;
- Adjust markups for numbered list;
- Mark literal blocks as such;
- Use tables markup.
- Adjust indentation when needed.

Acked-By: Vinod Koul <vkoul@kernel.org> # dmaengine
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../{async-tx-api.txt => async-tx-api.rst}    | 253 +++++++++++-------
 Documentation/crypto/index.rst                |   2 +
 Documentation/driver-api/dmaengine/client.rst |   2 +-
 .../driver-api/dmaengine/provider.rst         |   2 +-
 MAINTAINERS                                   |   2 +-
 5 files changed, 154 insertions(+), 107 deletions(-)
 rename Documentation/crypto/{async-tx-api.txt => async-tx-api.rst} (55%)

diff --git a/Documentation/crypto/async-tx-api.txt b/Documentation/crypto/async-tx-api.rst
similarity index 55%
rename from Documentation/crypto/async-tx-api.txt
rename to Documentation/crypto/async-tx-api.rst
index 7bf1be20d93a..bfc773991bdc 100644
--- a/Documentation/crypto/async-tx-api.txt
+++ b/Documentation/crypto/async-tx-api.rst
@@ -1,27 +1,32 @@
-		 Asynchronous Transfers/Transforms API
+.. SPDX-License-Identifier: GPL-2.0
 
-1 INTRODUCTION
+=====================================
+Asynchronous Transfers/Transforms API
+=====================================
 
-2 GENEALOGY
+.. Contents
 
-3 USAGE
-3.1 General format of the API
-3.2 Supported operations
-3.3 Descriptor management
-3.4 When does the operation execute?
-3.5 When does the operation complete?
-3.6 Constraints
-3.7 Example
+  1. INTRODUCTION
 
-4 DMAENGINE DRIVER DEVELOPER NOTES
-4.1 Conformance points
-4.2 "My application needs exclusive control of hardware channels"
+  2 GENEALOGY
 
-5 SOURCE
+  3 USAGE
+  3.1 General format of the API
+  3.2 Supported operations
+  3.3 Descriptor management
+  3.4 When does the operation execute?
+  3.5 When does the operation complete?
+  3.6 Constraints
+  3.7 Example
 
----
+  4 DMAENGINE DRIVER DEVELOPER NOTES
+  4.1 Conformance points
+  4.2 "My application needs exclusive control of hardware channels"
 
-1 INTRODUCTION
+  5 SOURCE
+
+1. Introduction
+===============
 
 The async_tx API provides methods for describing a chain of asynchronous
 bulk memory transfers/transforms with support for inter-transactional
@@ -31,7 +36,8 @@ that is written to the API can optimize for asynchronous operation and
 the API will fit the chain of operations to the available offload
 resources.
 
-2 GENEALOGY
+2.Genealogy
+===========
 
 The API was initially designed to offload the memory copy and
 xor-parity-calculations of the md-raid5 driver using the offload engines
@@ -39,40 +45,52 @@ present in the Intel(R) Xscale series of I/O processors.  It also built
 on the 'dmaengine' layer developed for offloading memory copies in the
 network stack using Intel(R) I/OAT engines.  The following design
 features surfaced as a result:
-1/ implicit synchronous path: users of the API do not need to know if
+
+1. implicit synchronous path: users of the API do not need to know if
    the platform they are running on has offload capabilities.  The
    operation will be offloaded when an engine is available and carried out
    in software otherwise.
-2/ cross channel dependency chains: the API allows a chain of dependent
+2. cross channel dependency chains: the API allows a chain of dependent
    operations to be submitted, like xor->copy->xor in the raid5 case.  The
    API automatically handles cases where the transition from one operation
    to another implies a hardware channel switch.
-3/ dmaengine extensions to support multiple clients and operation types
+3. dmaengine extensions to support multiple clients and operation types
    beyond 'memcpy'
 
-3 USAGE
+3. Usage
+========
 
-3.1 General format of the API:
-struct dma_async_tx_descriptor *
-async_<operation>(<op specific parameters>, struct async_submit ctl *submit)
+3.1 General format of the API
+-----------------------------
 
-3.2 Supported operations:
-memcpy  - memory copy between a source and a destination buffer
-memset  - fill a destination buffer with a byte value
-xor     - xor a series of source buffers and write the result to a
+::
+
+  struct dma_async_tx_descriptor *
+  async_<operation>(<op specific parameters>, struct async_submit ctl *submit)
+
+3.2 Supported operations
+------------------------
+
+========  ====================================================================
+memcpy    memory copy between a source and a destination buffer
+memset    fill a destination buffer with a byte value
+xor       xor a series of source buffers and write the result to a
 	  destination buffer
-xor_val - xor a series of source buffers and set a flag if the
+xor_val   xor a series of source buffers and set a flag if the
 	  result is zero.  The implementation attempts to prevent
 	  writes to memory
-pq	- generate the p+q (raid6 syndrome) from a series of source buffers
-pq_val  - validate that a p and or q buffer are in sync with a given series of
+pq	  generate the p+q (raid6 syndrome) from a series of source buffers
+pq_val    validate that a p and or q buffer are in sync with a given series of
 	  sources
-datap	- (raid6_datap_recov) recover a raid6 data block and the p block
+datap	  (raid6_datap_recov) recover a raid6 data block and the p block
 	  from the given sources
-2data	- (raid6_2data_recov) recover 2 raid6 data blocks from the given
+2data	  (raid6_2data_recov) recover 2 raid6 data blocks from the given
 	  sources
+========  ====================================================================
+
+3.3 Descriptor management
+-------------------------
 
-3.3 Descriptor management:
 The return value is non-NULL and points to a 'descriptor' when the operation
 has been queued to execute asynchronously.  Descriptors are recycled
 resources, under control of the offload engine driver, to be reused as
@@ -82,12 +100,15 @@ before the dependency is submitted.  This requires that all descriptors be
 acknowledged by the application before the offload engine driver is allowed to
 recycle (or free) the descriptor.  A descriptor can be acked by one of the
 following methods:
-1/ setting the ASYNC_TX_ACK flag if no child operations are to be submitted
-2/ submitting an unacknowledged descriptor as a dependency to another
+
+1. setting the ASYNC_TX_ACK flag if no child operations are to be submitted
+2. submitting an unacknowledged descriptor as a dependency to another
    async_tx call will implicitly set the acknowledged state.
-3/ calling async_tx_ack() on the descriptor.
+3. calling async_tx_ack() on the descriptor.
 
 3.4 When does the operation execute?
+------------------------------------
+
 Operations do not immediately issue after return from the
 async_<operation> call.  Offload engine drivers batch operations to
 improve performance by reducing the number of mmio cycles needed to
@@ -98,12 +119,15 @@ channels since the application has no knowledge of channel to operation
 mapping.
 
 3.5 When does the operation complete?
+-------------------------------------
+
 There are two methods for an application to learn about the completion
 of an operation.
-1/ Call dma_wait_for_async_tx().  This call causes the CPU to spin while
+
+1. Call dma_wait_for_async_tx().  This call causes the CPU to spin while
    it polls for the completion of the operation.  It handles dependency
    chains and issuing pending operations.
-2/ Specify a completion callback.  The callback routine runs in tasklet
+2. Specify a completion callback.  The callback routine runs in tasklet
    context if the offload engine driver supports interrupts, or it is
    called in application context if the operation is carried out
    synchronously in software.  The callback can be set in the call to
@@ -111,83 +135,95 @@ of an operation.
    unknown length it can use the async_trigger_callback() routine to set a
    completion interrupt/callback at the end of the chain.
 
-3.6 Constraints:
-1/ Calls to async_<operation> are not permitted in IRQ context.  Other
+3.6 Constraints
+---------------
+
+1. Calls to async_<operation> are not permitted in IRQ context.  Other
    contexts are permitted provided constraint #2 is not violated.
-2/ Completion callback routines cannot submit new operations.  This
+2. Completion callback routines cannot submit new operations.  This
    results in recursion in the synchronous case and spin_locks being
    acquired twice in the asynchronous case.
 
-3.7 Example:
+3.7 Example
+-----------
+
 Perform a xor->copy->xor operation where each operation depends on the
-result from the previous operation:
-
-void callback(void *param)
-{
-	struct completion *cmp = param;
-
-	complete(cmp);
-}
-
-void run_xor_copy_xor(struct page **xor_srcs,
-		      int xor_src_cnt,
-		      struct page *xor_dest,
-		      size_t xor_len,
-		      struct page *copy_src,
-		      struct page *copy_dest,
-		      size_t copy_len)
-{
-	struct dma_async_tx_descriptor *tx;
-	addr_conv_t addr_conv[xor_src_cnt];
-	struct async_submit_ctl submit;
-	addr_conv_t addr_conv[NDISKS];
-	struct completion cmp;
-
-	init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL,
-			  addr_conv);
-	tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit)
-
-	submit->depend_tx = tx;
-	tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit);
-
-	init_completion(&cmp);
-	init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx,
-			  callback, &cmp, addr_conv);
-	tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit);
-
-	async_tx_issue_pending_all();
-
-	wait_for_completion(&cmp);
-}
+result from the previous operation::
+
+    void callback(void *param)
+    {
+	    struct completion *cmp = param;
+
+	    complete(cmp);
+    }
+
+    void run_xor_copy_xor(struct page **xor_srcs,
+			int xor_src_cnt,
+			struct page *xor_dest,
+			size_t xor_len,
+			struct page *copy_src,
+			struct page *copy_dest,
+			size_t copy_len)
+    {
+	    struct dma_async_tx_descriptor *tx;
+	    addr_conv_t addr_conv[xor_src_cnt];
+	    struct async_submit_ctl submit;
+	    addr_conv_t addr_conv[NDISKS];
+	    struct completion cmp;
+
+	    init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL,
+			    addr_conv);
+	    tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit)
+
+	    submit->depend_tx = tx;
+	    tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit);
+
+	    init_completion(&cmp);
+	    init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx,
+			    callback, &cmp, addr_conv);
+	    tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit);
+
+	    async_tx_issue_pending_all();
+
+	    wait_for_completion(&cmp);
+    }
 
 See include/linux/async_tx.h for more information on the flags.  See the
 ops_run_* and ops_complete_* routines in drivers/md/raid5.c for more
 implementation examples.
 
-4 DRIVER DEVELOPMENT NOTES
+4. Driver Development Notes
+===========================
+
+4.1 Conformance points
+----------------------
 
-4.1 Conformance points:
 There are a few conformance points required in dmaengine drivers to
 accommodate assumptions made by applications using the async_tx API:
-1/ Completion callbacks are expected to happen in tasklet context
-2/ dma_async_tx_descriptor fields are never manipulated in IRQ context
-3/ Use async_tx_run_dependencies() in the descriptor clean up path to
+
+1. Completion callbacks are expected to happen in tasklet context
+2. dma_async_tx_descriptor fields are never manipulated in IRQ context
+3. Use async_tx_run_dependencies() in the descriptor clean up path to
    handle submission of dependent operations
 
 4.2 "My application needs exclusive control of hardware channels"
+-----------------------------------------------------------------
+
 Primarily this requirement arises from cases where a DMA engine driver
 is being used to support device-to-memory operations.  A channel that is
 performing these operations cannot, for many platform specific reasons,
 be shared.  For these cases the dma_request_channel() interface is
 provided.
 
-The interface is:
-struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
-				     dma_filter_fn filter_fn,
-				     void *filter_param);
+The interface is::
 
-Where dma_filter_fn is defined as:
-typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param);
+  struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
+				       dma_filter_fn filter_fn,
+				       void *filter_param);
+
+Where dma_filter_fn is defined as::
+
+  typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param);
 
 When the optional 'filter_fn' parameter is set to NULL
 dma_request_channel simply returns the first channel that satisfies the
@@ -207,19 +243,28 @@ private.  Alternatively, it is set when dma_request_channel() finds an
 unused "public" channel.
 
 A couple caveats to note when implementing a driver and consumer:
-1/ Once a channel has been privately allocated it will no longer be
+
+1. Once a channel has been privately allocated it will no longer be
    considered by the general-purpose allocator even after a call to
    dma_release_channel().
-2/ Since capabilities are specified at the device level a dma_device
+2. Since capabilities are specified at the device level a dma_device
    with multiple channels will either have all channels public, or all
    channels private.
 
-5 SOURCE
+5. Source
+---------
 
-include/linux/dmaengine.h: core header file for DMA drivers and api users
-drivers/dma/dmaengine.c: offload engine channel management routines
-drivers/dma/: location for offload engine drivers
-include/linux/async_tx.h: core header file for the async_tx api
-crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code
-crypto/async_tx/async_memcpy.c: copy offload
-crypto/async_tx/async_xor.c: xor and xor zero sum offload
+include/linux/dmaengine.h:
+    core header file for DMA drivers and api users
+drivers/dma/dmaengine.c:
+    offload engine channel management routines
+drivers/dma/:
+    location for offload engine drivers
+include/linux/async_tx.h:
+    core header file for the async_tx api
+crypto/async_tx/async_tx.c:
+    async_tx interface to dmaengine and common code
+crypto/async_tx/async_memcpy.c:
+    copy offload
+crypto/async_tx/async_xor.c:
+    xor and xor zero sum offload
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index b2eeab3c8631..22a6870bf356 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -19,6 +19,8 @@ for cryptographic use cases, as well as programming examples.
    intro
    api-intro
    architecture
+
+   async-tx-api
    asymmetric-keys
    devel-algos
    userspace-if
diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst
index 2104830a99ae..b0f32cfc38c2 100644
--- a/Documentation/driver-api/dmaengine/client.rst
+++ b/Documentation/driver-api/dmaengine/client.rst
@@ -5,7 +5,7 @@ DMA Engine API Guide
 Vinod Koul <vinod dot koul at intel.com>
 
 .. note:: For DMA Engine usage in async_tx please see:
-          ``Documentation/crypto/async-tx-api.txt``
+          ``Documentation/crypto/async-tx-api.rst``
 
 
 Below is a guide to device driver writers on how to use the Slave-DMA API of the
diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst
index 56e5833e8a07..954422c2b704 100644
--- a/Documentation/driver-api/dmaengine/provider.rst
+++ b/Documentation/driver-api/dmaengine/provider.rst
@@ -95,7 +95,7 @@ accommodates that API in some cases, and made some design choices to
 ensure that it stayed compatible.
 
 For more information on the Async TX API, please look the relevant
-documentation file in Documentation/crypto/async-tx-api.txt.
+documentation file in Documentation/crypto/async-tx-api.rst.
 
 DMAEngine APIs
 ==============
diff --git a/MAINTAINERS b/MAINTAINERS
index 84eabb5f0a5d..805309399939 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2837,7 +2837,7 @@ ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API
 R:	Dan Williams <dan.j.williams@intel.com>
 S:	Odd fixes
 W:	http://sourceforge.net/projects/xscaleiop
-F:	Documentation/crypto/async-tx-api.txt
+F:	Documentation/crypto/async-tx-api.rst
 F:	crypto/async_tx/
 F:	drivers/dma/
 F:	include/linux/async_tx.h
-- 
2.26.2

[PATCH 06/22] docs: crypto: descore-readme.txt: convert to ReST format

[Mauro Carvalho Chehab]

Convert this readme file to ReST file format, preserving its
contents as-is as much as possible. The only changes are:

- Added chapter and title markups;
- Added blank lines where needed;
- Added list markups where needed;
- Use a table markup;
- replace markups like `foo' to ``foo``;
- add one extra literal markup to avoid warnings.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 ...{descore-readme.txt => descore-readme.rst} | 152 ++++++++++++------
 Documentation/crypto/index.rst                |   1 +
 2 files changed, 108 insertions(+), 45 deletions(-)
 rename Documentation/crypto/{descore-readme.txt => descore-readme.rst} (81%)

diff --git a/Documentation/crypto/descore-readme.txt b/Documentation/crypto/descore-readme.rst
similarity index 81%
rename from Documentation/crypto/descore-readme.txt
rename to Documentation/crypto/descore-readme.rst
index 16e9e6350755..45bd9c8babf4 100644
--- a/Documentation/crypto/descore-readme.txt
+++ b/Documentation/crypto/descore-readme.rst
@@ -1,8 +1,20 @@
-Below is the original README file from the descore.shar package.
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+===========================================
+Fast & Portable DES encryption & decryption
+===========================================
+
+.. note::
+
+   Below is the original README file from the descore.shar package,
+   converted to ReST format.
+
 ------------------------------------------------------------------------------
 
 des - fast & portable DES encryption & decryption.
-Copyright (C) 1992  Dana L. How
+
+Copyright |copy| 1992  Dana L. How
 
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU Library General Public License as published by
@@ -20,13 +32,12 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 
 Author's address: how@isl.stanford.edu
 
-$Id: README,v 1.15 1992/05/20 00:25:32 how E $
-
-
-==>> To compile after untarring/unsharring, just `make' <<==
+.. README,v 1.15 1992/05/20 00:25:32 how E
 
+==>> To compile after untarring/unsharring, just ``make`` <<==
 
 This package was designed with the following goals:
+
 1.	Highest possible encryption/decryption PERFORMANCE.
 2.	PORTABILITY to any byte-addressable host with a 32bit unsigned C type
 3.	Plug-compatible replacement for KERBEROS's low-level routines.
@@ -36,7 +47,7 @@ register-starved machines.  My discussions with Richard Outerbridge,
 71755.204@compuserve.com, sparked a number of these enhancements.
 
 To more rapidly understand the code in this package, inspect desSmallFips.i
-(created by typing `make') BEFORE you tackle desCode.h.  The latter is set
+(created by typing ``make``) BEFORE you tackle desCode.h.  The latter is set
 up in a parameterized fashion so it can easily be modified by speed-daemon
 hackers in pursuit of that last microsecond.  You will find it more
 illuminating to inspect one specific implementation,
@@ -47,11 +58,13 @@ performance comparison to other available des code which i could
 compile on a SPARCStation 1 (cc -O4, gcc -O2):
 
 this code (byte-order independent):
-   30us per encryption (options: 64k tables, no IP/FP)
-   33us per encryption (options: 64k tables, FIPS standard bit ordering)
-   45us per encryption (options:  2k tables, no IP/FP)
-   48us per encryption (options:  2k tables, FIPS standard bit ordering)
-  275us to set a new key (uses 1k of key tables)
+
+  - 30us per encryption (options: 64k tables, no IP/FP)
+  - 33us per encryption (options: 64k tables, FIPS standard bit ordering)
+  - 45us per encryption (options:  2k tables, no IP/FP)
+  - 48us per encryption (options:  2k tables, FIPS standard bit ordering)
+  - 275us to set a new key (uses 1k of key tables)
+
 	this has the quickest encryption/decryption routines i've seen.
 	since i was interested in fast des filters rather than crypt(3)
 	and password cracking, i haven't really bothered yet to speed up
@@ -63,15 +76,20 @@ this code (byte-order independent):
 	are highly variable because of cache effects).
 
 kerberos des replacement from australia (version 1.95):
-   53us per encryption (uses 2k of tables)
-   96us to set a new key (uses 2.25k of key tables)
+
+  - 53us per encryption (uses 2k of tables)
+  - 96us to set a new key (uses 2.25k of key tables)
+
 	so despite the author's inclusion of some of the performance
 	improvements i had suggested to him, this package's
 	encryption/decryption is still slower on the sparc and 68000.
 	more specifically, 19-40% slower on the 68020 and 11-35% slower
 	on the sparc,  depending on the compiler;
 	in full gory detail (ALT_ECB is a libdes variant):
+
+	===============	==============	===============	=================
 	compiler   	machine		desCore	libdes	ALT_ECB	slower by
+	===============	==============	===============	=================
 	gcc 2.1 -O2	Sun 3/110	304  uS	369.5uS	461.8uS	 22%
 	cc      -O1	Sun 3/110	336  uS	436.6uS	399.3uS	 19%
 	cc      -O2	Sun 3/110	360  uS	532.4uS	505.1uS	 40%
@@ -79,10 +97,15 @@ kerberos des replacement from australia (version 1.95):
 	gcc 2.1 -O2	Sun 4/50	 48  uS	 53.4uS	 57.5uS	 11%
 	cc      -O2	Sun 4/50	 48  uS	 64.6uS	 64.7uS	 35%
 	cc      -O4	Sun 4/50	 48  uS	 64.7uS	 64.9uS	 35%
+	===============	==============	===============	=================
+
 	(my time measurements are not as accurate as his).
+
    the comments in my first release of desCore on version 1.92:
-   68us per encryption (uses 2k of tables)
-   96us to set a new key (uses 2.25k of key tables)
+
+   - 68us per encryption (uses 2k of tables)
+   - 96us to set a new key (uses 2.25k of key tables)
+
 	this is a very nice package which implements the most important
 	of the optimizations which i did in my encryption routines.
 	it's a bit weak on common low-level optimizations which is why
@@ -91,48 +114,60 @@ kerberos des replacement from australia (version 1.95):
 	speed up the key-setting routines with impressive results.
 	(at some point i may do the same in my package).  he also implements
 	the rest of the mit des library.
+
 	(code from eay@psych.psy.uq.oz.au via comp.sources.misc)
 
 fast crypt(3) package from denmark:
+
 	the des routine here is buried inside a loop to do the
 	crypt function and i didn't feel like ripping it out and measuring
 	performance. his code takes 26 sparc instructions to compute one
 	des iteration; above, Quick (64k) takes 21 and Small (2k) takes 37.
 	he claims to use 280k of tables but the iteration calculation seems
 	to use only 128k.  his tables and code are machine independent.
+
 	(code from glad@daimi.aau.dk via alt.sources or comp.sources.misc)
 
 swedish reimplementation of Kerberos des library
-  108us per encryption (uses 34k worth of tables)
-  134us to set a new key (uses 32k of key tables to get this speed!)
+
+  - 108us per encryption (uses 34k worth of tables)
+  - 134us to set a new key (uses 32k of key tables to get this speed!)
+
 	the tables used seem to be machine-independent;
 	he seems to have included a lot of special case code
-	so that, e.g., `long' loads can be used instead of 4 `char' loads
+	so that, e.g., ``long`` loads can be used instead of 4 ``char`` loads
 	when the machine's architecture allows it.
+
 	(code obtained from chalmers.se:pub/des)
 
 crack 3.3c package from england:
+
 	as in crypt above, the des routine is buried in a loop. it's
 	also very modified for crypt.  his iteration code uses 16k
 	of tables and appears to be slow.
+
 	(code obtained from aem@aber.ac.uk via alt.sources or comp.sources.misc)
 
-``highly optimized'' and tweaked Kerberos/Athena code (byte-order dependent):
-  165us per encryption (uses 6k worth of tables)
-  478us to set a new key (uses <1k of key tables)
+``highly optimized`` and tweaked Kerberos/Athena code (byte-order dependent):
+
+  - 165us per encryption (uses 6k worth of tables)
+  - 478us to set a new key (uses <1k of key tables)
+
 	so despite the comments in this code, it was possible to get
 	faster code AND smaller tables, as well as making the tables
 	machine-independent.
 	(code obtained from prep.ai.mit.edu)
 
 UC Berkeley code (depends on machine-endedness):
-  226us per encryption
-10848us to set a new key
+  -  226us per encryption
+  - 10848us to set a new key
+
 	table sizes are unclear, but they don't look very small
 	(code obtained from wuarchive.wustl.edu)
 
 
 motivation and history
+======================
 
 a while ago i wanted some des routines and the routines documented on sun's
 man pages either didn't exist or dumped core.  i had heard of kerberos,
@@ -142,10 +177,10 @@ it was too convoluted, the code had been written without taking
 advantage of the regular structure of operations such as IP, E, and FP
 (i.e. the author didn't sit down and think before coding),
 it was excessively slow,  the author had attempted to clarify the code
-by adding MORE statements to make the data movement more `consistent'
+by adding MORE statements to make the data movement more ``consistent``
 instead of simplifying his implementation and cutting down on all data
 movement (in particular, his use of L1, R1, L2, R2), and it was full of
-idiotic `tweaks' for particular machines which failed to deliver significant
+idiotic ``tweaks`` for particular machines which failed to deliver significant
 speedups but which did obfuscate everything.  so i took the test data
 from his verification program and rewrote everything else.
 
@@ -167,12 +202,13 @@ than versions hand-written in assembly for the sparc!
 
 
 porting notes
+=============
 
 one thing i did not want to do was write an enormous mess
 which depended on endedness and other machine quirks,
 and which necessarily produced different code and different lookup tables
 for different machines.  see the kerberos code for an example
-of what i didn't want to do; all their endedness-specific `optimizations'
+of what i didn't want to do; all their endedness-specific ``optimizations``
 obfuscate the code and in the end were slower than a simpler machine
 independent approach.  however, there are always some portability
 considerations of some kind, and i have included some options
@@ -184,8 +220,8 @@ perhaps some will still regard the result as a mess!
    i assume word pointers can be freely cast to and from char pointers.
    note that 99% of C programs make these assumptions.
    i always use unsigned char's if the high bit could be set.
-2) the typedef `word' means a 32 bit unsigned integral type.
-   if `unsigned long' is not 32 bits, change the typedef in desCore.h.
+2) the typedef ``word`` means a 32 bit unsigned integral type.
+   if ``unsigned long`` is not 32 bits, change the typedef in desCore.h.
    i assume sizeof(word) == 4 EVERYWHERE.
 
 the (worst-case) cost of my NOT doing endedness-specific optimizations
@@ -195,40 +231,46 @@ the input and output work areas do not need to be word-aligned.
 
 
 OPTIONAL performance optimizations
+==================================
 
-1) you should define one of `i386,' `vax,' `mc68000,' or `sparc,'
+1) you should define one of ``i386,`` ``vax,`` ``mc68000,`` or ``sparc,``
    whichever one is closest to the capabilities of your machine.
    see the start of desCode.h to see exactly what this selection implies.
    note that if you select the wrong one, the des code will still work;
    these are just performance tweaks.
-2) for those with functional `asm' keywords: you should change the
+2) for those with functional ``asm`` keywords: you should change the
    ROR and ROL macros to use machine rotate instructions if you have them.
    this will save 2 instructions and a temporary per use,
    or about 32 to 40 instructions per en/decryption.
+
    note that gcc is smart enough to translate the ROL/R macros into
    machine rotates!
 
 these optimizations are all rather persnickety, yet with them you should
 be able to get performance equal to assembly-coding, except that:
+
 1) with the lack of a bit rotate operator in C, rotates have to be synthesized
-   from shifts.  so access to `asm' will speed things up if your machine
+   from shifts.  so access to ``asm`` will speed things up if your machine
    has rotates, as explained above in (3) (not necessary if you use gcc).
 2) if your machine has less than 12 32-bit registers i doubt your compiler will
    generate good code.
-   `i386' tries to configure the code for a 386 by only declaring 3 registers
+
+   ``i386`` tries to configure the code for a 386 by only declaring 3 registers
    (it appears that gcc can use ebx, esi and edi to hold register variables).
    however, if you like assembly coding, the 386 does have 7 32-bit registers,
-   and if you use ALL of them, use `scaled by 8' address modes with displacement
+   and if you use ALL of them, use ``scaled by 8`` address modes with displacement
    and other tricks, you can get reasonable routines for DesQuickCore... with
    about 250 instructions apiece.  For DesSmall... it will help to rearrange
    des_keymap, i.e., now the sbox # is the high part of the index and
    the 6 bits of data is the low part; it helps to exchange these.
+
    since i have no way to conveniently test it i have not provided my
    shoehorned 386 version.  note that with this release of desCore, gcc is able
    to put everything in registers(!), and generate about 370 instructions apiece
    for the DesQuickCore... routines!
 
 coding notes
+============
 
 the en/decryption routines each use 6 necessary register variables,
 with 4 being actively used at once during the inner iterations.
@@ -236,15 +278,18 @@ if you don't have 4 register variables get a new machine.
 up to 8 more registers are used to hold constants in some configurations.
 
 i assume that the use of a constant is more expensive than using a register:
+
 a) additionally, i have tried to put the larger constants in registers.
    registering priority was by the following:
-	anything more than 12 bits (bad for RISC and CISC)
-	greater than 127 in value (can't use movq or byte immediate on CISC)
-	9-127 (may not be able to use CISC shift immediate or add/sub quick),
-	1-8 were never registered, being the cheapest constants.
+
+	- anything more than 12 bits (bad for RISC and CISC)
+	- greater than 127 in value (can't use movq or byte immediate on CISC)
+	- 9-127 (may not be able to use CISC shift immediate or add/sub quick),
+	- 1-8 were never registered, being the cheapest constants.
+
 b) the compiler may be too stupid to realize table and table+256 should
    be assigned to different constant registers and instead repetitively
-   do the arithmetic, so i assign these to explicit `m' register variables
+   do the arithmetic, so i assign these to explicit ``m`` register variables
    when possible and helpful.
 
 i assume that indexing is cheaper or equivalent to auto increment/decrement,
@@ -253,25 +298,31 @@ this assumption is reversed for 68k and vax.
 
 i assume that addresses can be cheaply formed from two registers,
 or from a register and a small constant.
-for the 68000, the `two registers and small offset' form is used sparingly.
+for the 68000, the ``two registers and small offset`` form is used sparingly.
 all index scaling is done explicitly - no hidden shifts by log2(sizeof).
 
 the code is written so that even a dumb compiler
 should never need more than one hidden temporary,
 increasing the chance that everything will fit in the registers.
 KEEP THIS MORE SUBTLE POINT IN MIND IF YOU REWRITE ANYTHING.
+
 (actually, there are some code fragments now which do require two temps,
 but fixing it would either break the structure of the macros or
 require declaring another temporary).
 
 
 special efficient data format
+==============================
+
+bits are manipulated in this arrangement most of the time (S7 S5 S3 S1)::
 
-bits are manipulated in this arrangement most of the time (S7 S5 S3 S1):
 	003130292827xxxx242322212019xxxx161514131211xxxx080706050403xxxx
+
 (the x bits are still there, i'm just emphasizing where the S boxes are).
-bits are rotated left 4 when computing S6 S4 S2 S0:
+bits are rotated left 4 when computing S6 S4 S2 S0::
+
 	282726252423xxxx201918171615xxxx121110090807xxxx040302010031xxxx
+
 the rightmost two bits are usually cleared so the lower byte can be used
 as an index into an sbox mapping table. the next two x'd bits are set
 to various values to access different parts of the tables.
@@ -288,7 +339,7 @@ datatypes:
 	must be long-aligned.
 
 DesQuickInit()
-	call this before using any other routine with `Quick' in its name.
+	call this before using any other routine with ``Quick`` in its name.
 	it generates the special 64k table these routines need.
 DesQuickDone()
 	frees this table
@@ -298,6 +349,7 @@ DesMethod(m, k)
 	which must have odd parity (or -1 is returned) and which must
 	not be a (semi-)weak key (or -2 is returned).
 	normally DesMethod() returns 0.
+
 	m is filled in from k so that when one of the routines below
 	is called with m, the routine will act like standard des
 	en/decryption with the key k. if you use DesMethod,
@@ -308,19 +360,26 @@ DesMethod(m, k)
 	will be set to magic constants which speed up the encryption/decryption
 	on some machines.  and yes, each byte controls
 	a specific sbox during a specific iteration.
+
 	you really shouldn't use the 768bit format directly;  i should
 	provide a routine that converts 128 6-bit bytes (specified in
 	S-box mapping order or something) into the right format for you.
 	this would entail some byte concatenation and rotation.
 
 Des{Small|Quick}{Fips|Core}{Encrypt|Decrypt}(d, m, s)
-	performs des on the 8 bytes at s into the 8 bytes at d. (d,s: char *).
+	performs des on the 8 bytes at s into the 8 bytes at
+	``d. (d,s: char *)``.
+
 	uses m as a 768bit key as explained above.
+
 	the Encrypt|Decrypt choice is obvious.
+
 	Fips|Core determines whether a completely standard FIPS initial
 	and final permutation is done; if not, then the data is loaded
 	and stored in a nonstandard bit order (FIPS w/o IP/FP).
+
 	Fips slows down Quick by 10%, Small by 9%.
+
 	Small|Quick determines whether you use the normal routine
 	or the crazy quick one which gobbles up 64k more of memory.
 	Small is 50% slower then Quick, but Quick needs 32 times as much
@@ -329,15 +388,17 @@ Des{Small|Quick}{Fips|Core}{Encrypt|Decrypt}(d, m, s)
 
 
 Getting it to compile on your machine
+=====================================
 
 there are no machine-dependencies in the code (see porting),
-except perhaps the `now()' macro in desTest.c.
+except perhaps the ``now()`` macro in desTest.c.
 ALL generated tables are machine independent.
 you should edit the Makefile with the appropriate optimization flags
 for your compiler (MAX optimization).
 
 
 Speeding up kerberos (and/or its des library)
+=============================================
 
 note that i have included a kerberos-compatible interface in desUtil.c
 through the functions des_key_sched() and des_ecb_encrypt().
@@ -347,6 +408,7 @@ you should not need to #include desCore.h;  just include the header
 file provided with the kerberos library.
 
 Other uses
+==========
 
 the macros in desCode.h would be very useful for putting inline des
 functions in more complicated encryption routines.
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index 22a6870bf356..21338fa92642 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -27,3 +27,4 @@ for cryptographic use cases, as well as programming examples.
    crypto_engine
    api
    api-samples
+   descore-readme
-- 
2.26.2

[PATCH 07/22] docs: misc-devices/spear-pcie-gadget.txt: convert to ReST

[Mauro Carvalho Chehab]

- Use title/chapter markups;
- Use table markups;
- Mark literal blocks as such;
- Adjust indentation.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/misc-devices/index.rst          |   1 +
 .../misc-devices/spear-pcie-gadget.rst        | 170 ++++++++++++++++++
 .../misc-devices/spear-pcie-gadget.txt        | 130 --------------
 3 files changed, 171 insertions(+), 130 deletions(-)
 create mode 100644 Documentation/misc-devices/spear-pcie-gadget.rst
 delete mode 100644 Documentation/misc-devices/spear-pcie-gadget.txt

diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index 1ecc05fbe6f4..56fc1e03488a 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -21,5 +21,6 @@ fit into other categories.
    lis3lv02d
    max6875
    mic/index
+   spear-pcie-gadget
    uacce
    xilinx_sdfec
diff --git a/Documentation/misc-devices/spear-pcie-gadget.rst b/Documentation/misc-devices/spear-pcie-gadget.rst
new file mode 100644
index 000000000000..09b9d6c7ac15
--- /dev/null
+++ b/Documentation/misc-devices/spear-pcie-gadget.rst
@@ -0,0 +1,170 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+Spear PCIe Gadget Driver
+========================
+
+Author
+======
+Pratyush Anand (pratyush.anand@gmail.com)
+
+Location
+========
+driver/misc/spear13xx_pcie_gadget.c
+
+Supported Chip:
+===============
+SPEAr1300
+SPEAr1310
+
+Menuconfig option:
+==================
+Device Drivers
+	Misc devices
+		PCIe gadget support for SPEAr13XX platform
+
+purpose
+=======
+This driver has several nodes which can be read/written by configfs interface.
+Its main purpose is to configure selected dual mode PCIe controller as device
+and then program its various registers to configure it as a particular device
+type. This driver can be used to show spear's PCIe device capability.
+
+Description of different nodes:
+===============================
+
+read behavior of nodes:
+-----------------------
+
+=============== ==============================================================
+link 		gives ltssm status.
+int_type 	type of supported interrupt
+no_of_msi 	zero if MSI is not enabled by host. A positive value is the
+		number of MSI vector granted.
+vendor_id	returns programmed vendor id (hex)
+device_id	returns programmed device id(hex)
+bar0_size:	returns size of bar0 in hex.
+bar0_address	returns address of bar0 mapped area in hex.
+bar0_rw_offset	returns offset of bar0 for which bar0_data will return value.
+bar0_data	returns data at bar0_rw_offset.
+=============== ==============================================================
+
+write behavior of nodes:
+------------------------
+
+=============== ================================================================
+link 		write UP to enable ltsmm DOWN to disable
+int_type	write interrupt type to be configured and (int_type could be
+		INTA, MSI or NO_INT). Select MSI only when you have programmed
+		no_of_msi node.
+no_of_msi	number of MSI vector needed.
+inta		write 1 to assert INTA and 0 to de-assert.
+send_msi	write MSI vector to be sent.
+vendor_id	write vendor id(hex) to be programmed.
+device_id	write device id(hex) to be programmed.
+bar0_size	write size of bar0 in hex. default bar0 size is 1000 (hex)
+		bytes.
+bar0_address	write	address of bar0 mapped area in hex. (default mapping of
+		bar0 is SYSRAM1(E0800000). Always program bar size before bar
+		address. Kernel might modify bar size and address for alignment,
+		so read back bar size and address after writing to cross check.
+bar0_rw_offset	write offset of bar0 for which	bar0_data will write value.
+bar0_data	write data to be written at bar0_rw_offset.
+=============== ================================================================
+
+Node programming example
+========================
+
+Program all PCIe registers in such a way that when this device is connected
+to the PCIe host, then host sees this device as 1MB RAM.
+
+::
+
+    #mount -t configfs none /Config
+
+For nth PCIe Device Controller::
+
+    # cd /config/pcie_gadget.n/
+
+Now you have all the nodes in this directory.
+program vendor id as 0x104a::
+
+    # echo 104A >> vendor_id
+
+program device id as 0xCD80::
+
+    # echo CD80 >> device_id
+
+program BAR0 size as 1MB::
+
+    # echo 100000 >> bar0_size
+
+check for programmed bar0 size::
+
+    # cat bar0_size
+
+Program BAR0 Address as DDR (0x2100000). This is the physical address of
+memory, which is to be made visible to PCIe host. Similarly any other peripheral
+can also be made visible to PCIe host. E.g., if you program base address of UART
+as BAR0 address then when this device will be connected to a host, it will be
+visible as UART.
+
+::
+
+    # echo 2100000 >> bar0_address
+
+program interrupt type : INTA::
+
+    # echo INTA >> int_type
+
+go for link up now::
+
+    # echo UP >> link
+
+It will have to be insured that, once link up is done on gadget, then only host
+is initialized and start to search PCIe devices on its port.
+
+::
+
+    /*wait till link is up*/
+    # cat link
+
+Wait till it returns UP.
+
+To assert INTA::
+
+    # echo 1 >> inta
+
+To de-assert INTA::
+
+    # echo 0 >> inta
+
+if MSI is to be used as interrupt, program no of msi vector needed (say4)::
+
+    # echo 4 >> no_of_msi
+
+select MSI as interrupt type::
+
+    # echo MSI >> int_type
+
+go for link up now::
+
+    # echo UP >> link
+
+wait till link is up::
+
+    # cat link
+
+An application can repetitively read this node till link is found UP. It can
+sleep between two read.
+
+wait till msi is enabled::
+
+    # cat no_of_msi
+
+Should return 4 (number of requested MSI vector)
+
+to send msi vector 2::
+
+    # echo 2 >> send_msi
+    # cd -
diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt
deleted file mode 100644
index 89b88dee4143..000000000000
--- a/Documentation/misc-devices/spear-pcie-gadget.txt
+++ /dev/null
@@ -1,130 +0,0 @@
-Spear PCIe Gadget Driver:
-
-Author
-=============
-Pratyush Anand (pratyush.anand@gmail.com)
-
-Location
-============
-driver/misc/spear13xx_pcie_gadget.c
-
-Supported Chip:
-===================
-SPEAr1300
-SPEAr1310
-
-Menuconfig option:
-==========================
-Device Drivers
-	Misc devices
-		PCIe gadget support for SPEAr13XX platform
-purpose
-===========
-This driver has several nodes which can be read/written by configfs interface.
-Its main purpose is to configure selected dual mode PCIe controller as device
-and then program its various registers to configure it as a particular device
-type. This driver can be used to show spear's PCIe device capability.
-
-Description of different nodes:
-=================================
-
-read behavior of nodes:
-------------------------------
-link 		:gives ltssm status.
-int_type 	:type of supported interrupt
-no_of_msi 	:zero if MSI is not enabled by host. A positive value is the
-		number of MSI vector granted.
-vendor_id	:returns programmed vendor id (hex)
-device_id	:returns programmed device id(hex)
-bar0_size:	:returns size of bar0 in hex.
-bar0_address	:returns address of bar0 mapped area in hex.
-bar0_rw_offset	:returns offset of bar0 for which bar0_data will return value.
-bar0_data	:returns data at bar0_rw_offset.
-
-write behavior of nodes:
-------------------------------
-link 		:write UP to enable ltsmm DOWN to disable
-int_type	:write interrupt type to be configured and (int_type could be
-		INTA, MSI or NO_INT). Select MSI only when you have programmed
-		no_of_msi node.
-no_of_msi	:number of MSI vector needed.
-inta		:write 1 to assert INTA and 0 to de-assert.
-send_msi	:write MSI vector to be sent.
-vendor_id	:write vendor id(hex) to be programmed.
-device_id	:write device id(hex) to be programmed.
-bar0_size	:write size of bar0 in hex. default bar0 size is 1000 (hex)
-		bytes.
-bar0_address	:write	address of bar0 mapped area in hex. (default mapping of
-		bar0 is SYSRAM1(E0800000). Always program bar size before bar
-		address. Kernel might modify bar size and address for alignment, so
-		read back bar size and address after writing to cross check.
-bar0_rw_offset	:write offset of bar0 for which	bar0_data will write value.
-bar0_data	:write data to be written at bar0_rw_offset.
-
-Node programming example
-===========================
-Program all PCIe registers in such a way that when this device is connected
-to the PCIe host, then host sees this device as 1MB RAM.
-#mount -t configfs none /Config
-For nth PCIe Device Controller
-# cd /config/pcie_gadget.n/
-Now you have all the nodes in this directory.
-program vendor id as 0x104a
-# echo 104A >> vendor_id
-
-program device id as 0xCD80
-# echo CD80 >> device_id
-
-program BAR0 size as 1MB
-# echo 100000 >> bar0_size
-
-check for programmed bar0 size
-# cat bar0_size
-
-Program BAR0 Address as DDR (0x2100000). This is the physical address of
-memory, which is to be made visible to PCIe host. Similarly any other peripheral
-can also be made visible to PCIe host. E.g., if you program base address of UART
-as BAR0 address then when this device will be connected to a host, it will be
-visible as UART.
-# echo 2100000 >> bar0_address
-
-program interrupt type : INTA
-# echo INTA >> int_type
-
-go for link up now.
-# echo UP >> link
-
-It will have to be insured that, once link up is done on gadget, then only host
-is initialized and start to search PCIe devices on its port.
-
-/*wait till link is up*/
-# cat link
-wait till it returns UP.
-
-To assert INTA
-# echo 1 >> inta
-
-To de-assert INTA
-# echo 0 >> inta
-
-if MSI is to be used as interrupt, program no of msi vector needed (say4)
-# echo 4 >> no_of_msi
-
-select MSI as interrupt type
-# echo MSI >> int_type
-
-go for link up now
-# echo UP >> link
-
-wait till link is up
-# cat link
-An application can repetitively read this node till link is found UP. It can
-sleep between two read.
-
-wait till msi is enabled
-# cat no_of_msi
-Should return 4 (number of requested MSI vector)
-
-to send msi vector 2
-# echo 2 >> send_msi
-#cd -
-- 
2.26.2

[PATCH 08/22] docs: misc-devices/pci-endpoint-test.txt: convert to ReST

[Mauro Carvalho Chehab]

- use title markups;
- mark literal blocks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../{ad525x_dpot.txt => ad525x_dpot.rst}      | 24 +++++++++----------
 Documentation/misc-devices/index.rst          |  1 +
 drivers/misc/Kconfig                          |  2 +-
 drivers/misc/ad525x_dpot.c                    |  2 +-
 4 files changed, 15 insertions(+), 14 deletions(-)
 rename Documentation/misc-devices/{ad525x_dpot.txt => ad525x_dpot.rst} (85%)

diff --git a/Documentation/misc-devices/ad525x_dpot.txt b/Documentation/misc-devices/ad525x_dpot.rst
similarity index 85%
rename from Documentation/misc-devices/ad525x_dpot.txt
rename to Documentation/misc-devices/ad525x_dpot.rst
index 0c9413b1cbf3..6483ec254520 100644
--- a/Documentation/misc-devices/ad525x_dpot.txt
+++ b/Documentation/misc-devices/ad525x_dpot.rst
@@ -1,6 +1,8 @@
----------------------------------
-  AD525x Digital Potentiometers
----------------------------------
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================
+AD525x Digital Potentiometers
+=============================
 
 The ad525x_dpot driver exports a simple sysfs interface.  This allows you to
 work with the immediate resistance settings as well as update the saved startup
@@ -8,9 +10,8 @@ settings.  Access to the factory programmed tolerance is also provided, but
 interpretation of this settings is required by the end application according to
 the specific part in use.
 
----------
-  Files
----------
+Files
+=====
 
 Each dpot device will have a set of eeprom, rdac, and tolerance files.  How
 many depends on the actual part you have, as will the range of allowed values.
@@ -24,23 +25,22 @@ and may vary greatly on a part-by-part basis.  For exact interpretation of
 this field, please consult the datasheet for your part.  This is presented
 as a hex file for easier parsing.
 
------------
-  Example
------------
+Example
+=======
 
 Locate the device in your sysfs tree.  This is probably easiest by going into
-the common i2c directory and locating the device by the i2c slave address.
+the common i2c directory and locating the device by the i2c slave address::
 
 	# ls /sys/bus/i2c/devices/
 	0-0022  0-0027  0-002f
 
 So assuming the device in question is on the first i2c bus and has the slave
-address of 0x2f, we descend (unrelated sysfs entries have been trimmed).
+address of 0x2f, we descend (unrelated sysfs entries have been trimmed)::
 
 	# ls /sys/bus/i2c/devices/0-002f/
 	eeprom0 rdac0 tolerance0
 
-You can use simple reads/writes to access these files:
+You can use simple reads/writes to access these files::
 
 	# cd /sys/bus/i2c/devices/0-002f/
 
diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index 56fc1e03488a..d05626dd0fbb 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -14,6 +14,7 @@ fit into other categories.
 .. toctree::
    :maxdepth: 2
 
+   ad525x_dpot
    eeprom
    ibmvmc
    ics932s401
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e1b1ba5e2b92..3ca4325cc191 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -24,7 +24,7 @@ config AD525X_DPOT
 	  AD5271, AD5272, AD5274
 	  digital potentiometer chips.
 
-	  See Documentation/misc-devices/ad525x_dpot.txt for the
+	  See Documentation/misc-devices/ad525x_dpot.rst for the
 	  userspace interface.
 
 	  This driver can also be built as a module.  If so, the module
diff --git a/drivers/misc/ad525x_dpot.c b/drivers/misc/ad525x_dpot.c
index ccce3226a571..6f164522b028 100644
--- a/drivers/misc/ad525x_dpot.c
+++ b/drivers/misc/ad525x_dpot.c
@@ -58,7 +58,7 @@
  * AD5272		1		1024		20, 50, 100 (50-TP)
  * AD5274		1		256		20, 50, 100 (50-TP)
  *
- * See Documentation/misc-devices/ad525x_dpot.txt for more info.
+ * See Documentation/misc-devices/ad525x_dpot.rst for more info.
  *
  * derived from ad5258.c
  * Copyright (c) 2009 Cyber Switching, Inc.
-- 
2.26.2

[PATCH 09/22] docs: misc-devices/pci-endpoint-test.txt: convert to ReST

[Mauro Carvalho Chehab]

- Use titles markups;
- Adjust identation;
- use literal markup;
- Use the proper notation for footnotes.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/misc-devices/index.rst          |  1 +
 .../misc-devices/pci-endpoint-test.rst        | 56 +++++++++++++++++++
 .../misc-devices/pci-endpoint-test.txt        | 41 --------------
 3 files changed, 57 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/misc-devices/pci-endpoint-test.rst
 delete mode 100644 Documentation/misc-devices/pci-endpoint-test.txt

diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index d05626dd0fbb..d2e87f791821 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -22,6 +22,7 @@ fit into other categories.
    lis3lv02d
    max6875
    mic/index
+   pci-endpoint-test
    spear-pcie-gadget
    uacce
    xilinx_sdfec
diff --git a/Documentation/misc-devices/pci-endpoint-test.rst b/Documentation/misc-devices/pci-endpoint-test.rst
new file mode 100644
index 000000000000..26e5d9ba146b
--- /dev/null
+++ b/Documentation/misc-devices/pci-endpoint-test.rst
@@ -0,0 +1,56 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Driver for PCI Endpoint Test Function
+=====================================
+
+This driver should be used as a host side driver if the root complex is
+connected to a configurable PCI endpoint running ``pci_epf_test`` function
+driver configured according to [1]_.
+
+The "pci_endpoint_test" driver can be used to perform the following tests.
+
+The PCI driver for the test device performs the following tests:
+
+	#) verifying addresses programmed in BAR
+	#) raise legacy IRQ
+	#) raise MSI IRQ
+	#) raise MSI-X IRQ
+	#) read data
+	#) write data
+	#) copy data
+
+This misc driver creates /dev/pci-endpoint-test.<num> for every
+``pci_epf_test`` function connected to the root complex and "ioctls"
+should be used to perform the above tests.
+
+ioctl
+-----
+
+ PCITEST_BAR:
+	      Tests the BAR. The number of the BAR to be tested
+	      should be passed as argument.
+ PCITEST_LEGACY_IRQ:
+	      Tests legacy IRQ
+ PCITEST_MSI:
+	      Tests message signalled interrupts. The MSI number
+	      to be tested should be passed as argument.
+ PCITEST_MSIX:
+	      Tests message signalled interrupts. The MSI-X number
+	      to be tested should be passed as argument.
+ PCITEST_SET_IRQTYPE:
+	      Changes driver IRQ type configuration. The IRQ type
+	      should be passed as argument (0: Legacy, 1:MSI, 2:MSI-X).
+ PCITEST_GET_IRQTYPE:
+	      Gets driver IRQ type configuration.
+ PCITEST_WRITE:
+	      Perform write tests. The size of the buffer should be passed
+	      as argument.
+ PCITEST_READ:
+	      Perform read tests. The size of the buffer should be passed
+	      as argument.
+ PCITEST_COPY:
+	      Perform read tests. The size of the buffer should be passed
+	      as argument.
+
+.. [1] Documentation/PCI/endpoint/function/binding/pci-test.txt
diff --git a/Documentation/misc-devices/pci-endpoint-test.txt b/Documentation/misc-devices/pci-endpoint-test.txt
deleted file mode 100644
index 58ccca4416b1..000000000000
--- a/Documentation/misc-devices/pci-endpoint-test.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Driver for PCI Endpoint Test Function
-
-This driver should be used as a host side driver if the root complex is
-connected to a configurable PCI endpoint running *pci_epf_test* function
-driver configured according to [1].
-
-The "pci_endpoint_test" driver can be used to perform the following tests.
-
-The PCI driver for the test device performs the following tests
-	*) verifying addresses programmed in BAR
-	*) raise legacy IRQ
-	*) raise MSI IRQ
-	*) raise MSI-X IRQ
-	*) read data
-	*) write data
-	*) copy data
-
-This misc driver creates /dev/pci-endpoint-test.<num> for every
-*pci_epf_test* function connected to the root complex and "ioctls"
-should be used to perform the above tests.
-
-ioctl
------
- PCITEST_BAR: Tests the BAR. The number of the BAR to be tested
-	      should be passed as argument.
- PCITEST_LEGACY_IRQ: Tests legacy IRQ
- PCITEST_MSI: Tests message signalled interrupts. The MSI number
-	      to be tested should be passed as argument.
- PCITEST_MSIX: Tests message signalled interrupts. The MSI-X number
-	      to be tested should be passed as argument.
- PCITEST_SET_IRQTYPE: Changes driver IRQ type configuration. The IRQ type
-	      should be passed as argument (0: Legacy, 1:MSI, 2:MSI-X).
- PCITEST_GET_IRQTYPE: Gets driver IRQ type configuration.
- PCITEST_WRITE: Perform write tests. The size of the buffer should be passed
-		as argument.
- PCITEST_READ: Perform read tests. The size of the buffer should be passed
-	       as argument.
- PCITEST_COPY: Perform read tests. The size of the buffer should be passed
-	       as argument.
-
-[1] -> Documentation/PCI/endpoint/function/binding/pci-test.txt
-- 
2.26.2

[PATCH 10/22] docs: misc-devices/c2port.txt: convert to ReST format

[Mauro Carvalho Chehab]

- Use copyright symbol;
- use title markups;
- adjust indentation;
- mark literal blocks as such.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../misc-devices/{c2port.txt => c2port.rst}   | 58 ++++++++++---------
 Documentation/misc-devices/index.rst          |  1 +
 2 files changed, 32 insertions(+), 27 deletions(-)
 rename Documentation/misc-devices/{c2port.txt => c2port.rst} (59%)

diff --git a/Documentation/misc-devices/c2port.txt b/Documentation/misc-devices/c2port.rst
similarity index 59%
rename from Documentation/misc-devices/c2port.txt
rename to Documentation/misc-devices/c2port.rst
index 31351b1a5a1f..3cf3c571bead 100644
--- a/Documentation/misc-devices/c2port.txt
+++ b/Documentation/misc-devices/c2port.rst
@@ -1,7 +1,11 @@
-			C2 port support
-			---------------
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
 
-(C) Copyright 2007 Rodolfo Giometti <giometti@enneenne.com>
+===============
+C2 port support
+===============
+
+|copy| Copyright 2007 Rodolfo Giometti <giometti@enneenne.com>
 
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
@@ -32,10 +36,10 @@ The C2 Interface main references are at (https://www.silabs.com)
 Silicon Laboratories site], see:
 
 - AN127: FLASH Programming via the C2 Interface at
-https://www.silabs.com/Support Documents/TechnicalDocs/an127.pdf 
+  https://www.silabs.com/Support Documents/TechnicalDocs/an127.pdf
 
 - C2 Specification at
-https://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/an127.pdf&src=SearchResults
+  https://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/an127.pdf&src=SearchResults
 
 however it implements a two wire serial communication protocol (bit
 banging) designed to enable in-system programming, debugging, and
@@ -47,44 +51,44 @@ Using the driver
 ----------------
 
 Once the driver is loaded you can use sysfs support to get C2port's
-info or read/write in-system flash.
+info or read/write in-system flash::
 
-# ls /sys/class/c2port/c2port0/
-access            flash_block_size  flash_erase       rev_id
-dev_id            flash_blocks_num  flash_size        subsystem/
-flash_access      flash_data        reset             uevent
+  # ls /sys/class/c2port/c2port0/
+  access            flash_block_size  flash_erase       rev_id
+  dev_id            flash_blocks_num  flash_size        subsystem/
+  flash_access      flash_data        reset             uevent
 
 Initially the C2port access is disabled since you hardware may have
 such lines multiplexed with other devices so, to get access to the
-C2port, you need the command:
+C2port, you need the command::
 
-# echo 1 > /sys/class/c2port/c2port0/access
+  # echo 1 > /sys/class/c2port/c2port0/access
 
 after that you should read the device ID and revision ID of the
-connected micro controller:
+connected micro controller::
 
-# cat /sys/class/c2port/c2port0/dev_id
-8
-# cat /sys/class/c2port/c2port0/rev_id
-1
+  # cat /sys/class/c2port/c2port0/dev_id
+  8
+  # cat /sys/class/c2port/c2port0/rev_id
+  1
 
 However, for security reasons, the in-system flash access in not
-enabled yet, to do so you need the command:
+enabled yet, to do so you need the command::
 
-# echo 1 > /sys/class/c2port/c2port0/flash_access
+  # echo 1 > /sys/class/c2port/c2port0/flash_access
 
-After that you can read the whole flash:
+After that you can read the whole flash::
 
-# cat /sys/class/c2port/c2port0/flash_data > image
+  # cat /sys/class/c2port/c2port0/flash_data > image
 
-erase it:
+erase it::
 
-# echo 1 > /sys/class/c2port/c2port0/flash_erase
+  # echo 1 > /sys/class/c2port/c2port0/flash_erase
 
-and write it:
+and write it::
 
-# cat image > /sys/class/c2port/c2port0/flash_data
+  # cat image > /sys/class/c2port/c2port0/flash_data
 
-after writing you have to reset the device to execute the new code:
+after writing you have to reset the device to execute the new code::
 
-# echo 1 > /sys/class/c2port/c2port0/reset
+  # echo 1 > /sys/class/c2port/c2port0/reset
diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index d2e87f791821..27e268805067 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -16,6 +16,7 @@ fit into other categories.
 
    ad525x_dpot
    eeprom
+   c2port
    ibmvmc
    ics932s401
    isl29003
-- 
2.26.2

[PATCH 11/22] docs: misc-devices/bh1770glc.txt: convert to ReST

[Mauro Carvalho Chehab]

- Adjust document title markup;
- use list markups;
- Adjust identations to display properly at ReST output.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../{bh1770glc.txt => bh1770glc.rst}          | 45 +++++++++++++------
 Documentation/misc-devices/index.rst          |  1 +
 2 files changed, 33 insertions(+), 13 deletions(-)
 rename Documentation/misc-devices/{bh1770glc.txt => bh1770glc.rst} (83%)

diff --git a/Documentation/misc-devices/bh1770glc.txt b/Documentation/misc-devices/bh1770glc.rst
similarity index 83%
rename from Documentation/misc-devices/bh1770glc.txt
rename to Documentation/misc-devices/bh1770glc.rst
index 7d64c014dc70..ea5ca58bb958 100644
--- a/Documentation/misc-devices/bh1770glc.txt
+++ b/Documentation/misc-devices/bh1770glc.rst
@@ -1,9 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
 Kernel driver bh1770glc
 =======================
 
 Supported chips:
-ROHM BH1770GLC
-OSRAM SFH7770
+
+- ROHM BH1770GLC
+- OSRAM SFH7770
 
 Data sheet:
 Not freely available
@@ -48,12 +52,16 @@ chip_id
 	RO - shows detected chip type and version
 
 power_state
-	RW - enable / disable chip. Uses counting logic
-	     1 enables the chip
-	     0 disables the chip
+	RW - enable / disable chip
+
+	Uses counting logic
+
+	     - 1 enables the chip
+	     - 0 disables the chip
 
 lux0_input
 	RO - measured lux value
+
 	     sysfs_notify called when threshold interrupt occurs
 
 lux0_sensor_range
@@ -66,16 +74,22 @@ lux0_rate_avail
 	RO - supported measurement rates
 
 lux0_thresh_above_value
-	RW - HI level threshold value. All results above the value
+	RW - HI level threshold value
+
+	     All results above the value
 	     trigs an interrupt. 65535 (i.e. sensor_range) disables the above
 	     interrupt.
 
 lux0_thresh_below_value
-	RW - LO level threshold value. All results below the value
+	RW - LO level threshold value
+
+	     All results below the value
 	     trigs an interrupt. 0 disables the below interrupt.
 
 lux0_calibscale
-	RW - calibration value. Set to neutral value by default.
+	RW - calibration value
+
+	     Set to neutral value by default.
 	     Output results are multiplied with calibscale / calibscale_default
 	     value.
 
@@ -84,32 +98,37 @@ lux0_calibscale_default
 
 prox0_raw
 	RO - measured proximity value
+
 	     sysfs_notify called when threshold interrupt occurs
 
 prox0_sensor_range
 	RO - prox0_raw max value
 
 prox0_raw_en
-	RW - enable / disable proximity - uses counting logic
-	     1 enables the proximity
-	     0 disables the proximity
+	RW - enable / disable proximity
+
+	     Uses counting logic
+
+	     - 1 enables the proximity
+	     - 0 disables the proximity
 
 prox0_thresh_above_count
 	RW - number of proximity interrupts needed before triggering the event
 
 prox0_rate_above
 	RW - Measurement rate (in Hz) when the level is above threshold
-	     i.e. when proximity on has been reported.
+	i.e. when proximity on has been reported.
 
 prox0_rate_below
 	RW - Measurement rate (in Hz) when the level is below threshold
-	     i.e. when proximity off has been reported.
+	i.e. when proximity off has been reported.
 
 prox0_rate_avail
 	RO - Supported proximity measurement rates in Hz
 
 prox0_thresh_above0_value
 	RW - threshold level which trigs proximity events.
+
 	     Filtered by persistence filter (prox0_thresh_above_count)
 
 prox0_thresh_above1_value
diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index 27e268805067..edf66b59f2d4 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -15,6 +15,7 @@ fit into other categories.
    :maxdepth: 2
 
    ad525x_dpot
+   bh1770glc
    eeprom
    c2port
    ibmvmc
-- 
2.26.2

[PATCH 12/22] docs: misc-devices/apds990x.txt: convert to ReST format

[Mauro Carvalho Chehab]

- Adjust title markup;
- Adjust identation.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../{apds990x.txt => apds990x.rst}            | 31 ++++++++++++++-----
 Documentation/misc-devices/index.rst          |  1 +
 2 files changed, 25 insertions(+), 7 deletions(-)
 rename Documentation/misc-devices/{apds990x.txt => apds990x.rst} (86%)

diff --git a/Documentation/misc-devices/apds990x.txt b/Documentation/misc-devices/apds990x.rst
similarity index 86%
rename from Documentation/misc-devices/apds990x.txt
rename to Documentation/misc-devices/apds990x.rst
index 454d95d623b3..e2f75577f731 100644
--- a/Documentation/misc-devices/apds990x.txt
+++ b/Documentation/misc-devices/apds990x.rst
@@ -1,3 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
 Kernel driver apds990x
 ======================
 
@@ -50,14 +53,18 @@ chip_id
 
 power_state
 	RW - enable / disable chip. Uses counting logic
+
 	     1 enables the chip
 	     0 disables the chip
 lux0_input
 	RO - measured lux value
+
 	     sysfs_notify called when threshold interrupt occurs
 
 lux0_sensor_range
-	RO - lux0_input max value. Actually never reaches since sensor tends
+	RO - lux0_input max value.
+
+	     Actually never reaches since sensor tends
 	     to saturate much before that. Real max value varies depending
 	     on the light spectrum etc.
 
@@ -68,7 +75,9 @@ lux0_rate_avail
 	RO - supported measurement rates
 
 lux0_calibscale
-	RW - calibration value. Set to neutral value by default.
+	RW - calibration value.
+
+	     Set to neutral value by default.
 	     Output results are multiplied with calibscale / calibscale_default
 	     value.
 
@@ -76,16 +85,21 @@ lux0_calibscale_default
 	RO - neutral calibration value
 
 lux0_thresh_above_value
-	RW - HI level threshold value. All results above the value
+	RW - HI level threshold value.
+
+	     All results above the value
 	     trigs an interrupt. 65535 (i.e. sensor_range) disables the above
 	     interrupt.
 
 lux0_thresh_below_value
-	RW - LO level threshold value. All results below the value
+	RW - LO level threshold value.
+
+	     All results below the value
 	     trigs an interrupt. 0 disables the below interrupt.
 
 prox0_raw
 	RO - measured proximity value
+
 	     sysfs_notify called when threshold interrupt occurs
 
 prox0_sensor_range
@@ -93,11 +107,14 @@ prox0_sensor_range
 
 prox0_raw_en
 	RW - enable / disable proximity - uses counting logic
-	     1 enables the proximity
-	     0 disables the proximity
+
+	     - 1 enables the proximity
+	     - 0 disables the proximity
 
 prox0_reporting_mode
-	RW - trigger / periodic. In "trigger" mode the driver tells two possible
+	RW - trigger / periodic.
+
+	     In "trigger" mode the driver tells two possible
 	     values: 0 or prox0_sensor_range value. 0 means no proximity,
 	     1023 means proximity. This causes minimal number of interrupts.
 	     In "periodic" mode the driver reports all values above
diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index edf66b59f2d4..46072ce3d7ef 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -15,6 +15,7 @@ fit into other categories.
    :maxdepth: 2
 
    ad525x_dpot
+   apds990x
    bh1770glc
    eeprom
    c2port
-- 
2.26.2

[PATCH 13/22] docs: pci: endpoint/function/binding/pci-test.txt convert to ReST

[Mauro Carvalho Chehab]

Convert this file to ReST by adding a proper title to it and
use the right markups for a table.

While here, add a SPDX header.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../endpoint/function/binding/pci-test.rst    | 26 +++++++++++++++++++
 .../endpoint/function/binding/pci-test.txt    | 19 --------------
 Documentation/PCI/endpoint/index.rst          |  2 ++
 .../misc-devices/pci-endpoint-test.rst        |  2 +-
 4 files changed, 29 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.rst
 delete mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.txt

diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.rst b/Documentation/PCI/endpoint/function/binding/pci-test.rst
new file mode 100644
index 000000000000..57ee866fb165
--- /dev/null
+++ b/Documentation/PCI/endpoint/function/binding/pci-test.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================
+PCI Test Endpoint Function
+==========================
+
+name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
+
+Configurable Fields:
+
+================   ===========================================================
+vendorid	   should be 0x104c
+deviceid	   should be 0xb500 for DRA74x and 0xb501 for DRA72x
+revid		   don't care
+progif_code	   don't care
+subclass_code	   don't care
+baseclass_code	   should be 0xff
+cache_line_size	   don't care
+subsys_vendor_id   don't care
+subsys_id	   don't care
+interrupt_pin	   Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
+msi_interrupts	   Should be 1 to 32 depending on the number of MSI interrupts
+		   to test
+msix_interrupts	   Should be 1 to 2048 depending on the number of MSI-X
+		   interrupts to test
+================   ===========================================================
diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt b/Documentation/PCI/endpoint/function/binding/pci-test.txt
deleted file mode 100644
index cd76ba47394b..000000000000
--- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-PCI TEST ENDPOINT FUNCTION
-
-name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
-
-Configurable Fields:
-vendorid	 : should be 0x104c
-deviceid	 : should be 0xb500 for DRA74x and 0xb501 for DRA72x
-revid		 : don't care
-progif_code	 : don't care
-subclass_code	 : don't care
-baseclass_code	 : should be 0xff
-cache_line_size	 : don't care
-subsys_vendor_id : don't care
-subsys_id	 : don't care
-interrupt_pin	 : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
-msi_interrupts	 : Should be 1 to 32 depending on the number of MSI interrupts
-		   to test
-msix_interrupts	 : Should be 1 to 2048 depending on the number of MSI-X
-		   interrupts to test
diff --git a/Documentation/PCI/endpoint/index.rst b/Documentation/PCI/endpoint/index.rst
index d114ea74b444..4ca7439fbfc9 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -11,3 +11,5 @@ PCI Endpoint Framework
    pci-endpoint-cfs
    pci-test-function
    pci-test-howto
+
+   function/binding/pci-test
diff --git a/Documentation/misc-devices/pci-endpoint-test.rst b/Documentation/misc-devices/pci-endpoint-test.rst
index 26e5d9ba146b..4cf3f4433be7 100644
--- a/Documentation/misc-devices/pci-endpoint-test.rst
+++ b/Documentation/misc-devices/pci-endpoint-test.rst
@@ -53,4 +53,4 @@ ioctl
 	      Perform read tests. The size of the buffer should be passed
 	      as argument.
 
-.. [1] Documentation/PCI/endpoint/function/binding/pci-test.txt
+.. [1] Documentation/PCI/endpoint/function/binding/pci-test.rst
-- 
2.26.2

[PATCH 14/22] docs: arm64: convert perf.txt to ReST format

[Mauro Carvalho Chehab]

This file is almost in ReST. All it needs is a rename and
adding a :field: for the two fields at the beginning
(author and date).

While here, add a proper SPDX header, and use the standard
markup for document titles, just for consistency.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/arm64/index.rst              | 1 +
 Documentation/arm64/{perf.txt => perf.rst} | 7 +++++--
 2 files changed, 6 insertions(+), 2 deletions(-)
 rename Documentation/arm64/{perf.txt => perf.rst} (95%)

diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst
index 09cbb4ed2237..d9665d83c53a 100644
--- a/Documentation/arm64/index.rst
+++ b/Documentation/arm64/index.rst
@@ -14,6 +14,7 @@ ARM64 Architecture
     hugetlbpage
     legacy_instructions
     memory
+    perf
     pointer-authentication
     silicon-errata
     sve
diff --git a/Documentation/arm64/perf.txt b/Documentation/arm64/perf.rst
similarity index 95%
rename from Documentation/arm64/perf.txt
rename to Documentation/arm64/perf.rst
index 0d6a7d87d49e..9c76a97baf28 100644
--- a/Documentation/arm64/perf.txt
+++ b/Documentation/arm64/perf.rst
@@ -1,8 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
 Perf Event Attributes
 =====================
 
-Author: Andrew Murray <andrew.murray@arm.com>
-Date: 2019-03-06
+:Author: Andrew Murray <andrew.murray@arm.com>
+:Date: 2019-03-06
 
 exclude_user
 ------------
-- 
2.26.2

[PATCH 15/22] docs: powerpc: convert vcpudispatch_stats.txt to ReST

[Mauro Carvalho Chehab]

- Add a SPDX header;
- Use standard markup for document title;
- Adjust identation on lists and add blank lines where
  needed;
- Add it to the powerpc index.rst file.

Acked-by: Michael Ellerman <mpe@ellerman.id.au> # powerpc
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/powerpc/index.rst                 |  1 +
 ...ispatch_stats.txt => vcpudispatch_stats.rst} | 17 ++++++++++++-----
 2 files changed, 13 insertions(+), 5 deletions(-)
 rename Documentation/powerpc/{vcpudispatch_stats.txt => vcpudispatch_stats.rst} (94%)

diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst
index afe2d5e54db6..748bf483b1c2 100644
--- a/Documentation/powerpc/index.rst
+++ b/Documentation/powerpc/index.rst
@@ -31,6 +31,7 @@ powerpc
     transactional_memory
     ultravisor
     vas-api
+    vcpudispatch_stats
 
 .. only::  subproject and html
 
diff --git a/Documentation/powerpc/vcpudispatch_stats.txt b/Documentation/powerpc/vcpudispatch_stats.rst
similarity index 94%
rename from Documentation/powerpc/vcpudispatch_stats.txt
rename to Documentation/powerpc/vcpudispatch_stats.rst
index e21476bfd78c..5704657a5987 100644
--- a/Documentation/powerpc/vcpudispatch_stats.txt
+++ b/Documentation/powerpc/vcpudispatch_stats.rst
@@ -1,5 +1,8 @@
-VCPU Dispatch Statistics:
-=========================
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+VCPU Dispatch Statistics
+========================
 
 For Shared Processor LPARs, the POWER Hypervisor maintains a relatively
 static mapping of the LPAR processors (vcpus) to physical processor
@@ -20,25 +23,29 @@ The statistics themselves are available by reading the procfs file
 a vcpu as represented by the first field, followed by 8 numbers.
 
 The first number corresponds to:
+
 1. total vcpu dispatches since the beginning of statistics collection
 
 The next 4 numbers represent vcpu dispatch dispersions:
+
 2. number of times this vcpu was dispatched on the same processor as last
    time
 3. number of times this vcpu was dispatched on a different processor core
    as last time, but within the same chip
 4. number of times this vcpu was dispatched on a different chip
 5. number of times this vcpu was dispatches on a different socket/drawer
-(next numa boundary)
+   (next numa boundary)
 
 The final 3 numbers represent statistics in relation to the home node of
 the vcpu:
+
 6. number of times this vcpu was dispatched in its home node (chip)
 7. number of times this vcpu was dispatched in a different node
 8. number of times this vcpu was dispatched in a node further away (numa
-distance)
+   distance)
+
+An example output::
 
-An example output:
     $ sudo cat /proc/powerpc/vcpudispatch_stats
     cpu0 6839 4126 2683 30 0 6821 18 0
     cpu1 2515 1274 1229 12 0 2509 6 0
-- 
2.26.2

[PATCH 16/22] docs: sh: convert new-machine.txt to ReST

[Mauro Carvalho Chehab]

- Add a SPDX header;
- Adjust document title to follow ReST style;
- Mark literal blocks as such;
- Mark a table as such;
- Add it to sh/index.rst.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/sh/index.rst                    |   5 +
 .../sh/{new-machine.txt => new-machine.rst}   | 195 +++++++++---------
 2 files changed, 106 insertions(+), 94 deletions(-)
 rename Documentation/sh/{new-machine.txt => new-machine.rst} (73%)

diff --git a/Documentation/sh/index.rst b/Documentation/sh/index.rst
index bc8db7ba894a..56c08790265d 100644
--- a/Documentation/sh/index.rst
+++ b/Documentation/sh/index.rst
@@ -4,6 +4,11 @@ SuperH Interfaces Guide
 
 :Author: Paul Mundt
 
+.. toctree::
+    :maxdepth: 1
+
+    new-machine
+
 Memory Management
 =================
 
diff --git a/Documentation/sh/new-machine.txt b/Documentation/sh/new-machine.rst
similarity index 73%
rename from Documentation/sh/new-machine.txt
rename to Documentation/sh/new-machine.rst
index e0961a66130b..e501c52b3b30 100644
--- a/Documentation/sh/new-machine.txt
+++ b/Documentation/sh/new-machine.rst
@@ -1,6 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
 
-                Adding a new board to LinuxSH
-               ================================
+=============================
+Adding a new board to LinuxSH
+=============================
 
                Paul Mundt <lethal@linux-sh.org>
 
@@ -19,65 +21,67 @@ include/asm-sh/. For the new kernel, things are broken out by board type,
 companion chip type, and CPU type. Looking at a tree view of this directory
 hierarchy looks like the following:
 
-Board-specific code:
+Board-specific code::
 
-.
-|-- arch
-|   `-- sh
-|       `-- boards
-|           |-- adx
-|           |   `-- board-specific files
-|           |-- bigsur
-|           |   `-- board-specific files
-|           |
-|           ... more boards here ...
-|
-`-- include
-    `-- asm-sh
-        |-- adx
-        |   `-- board-specific headers
-        |-- bigsur
-        |   `-- board-specific headers
-        |
-	.. more boards here ...
+    .
+    |-- arch
+    |   `-- sh
+    |       `-- boards
+    |           |-- adx
+    |           |   `-- board-specific files
+    |           |-- bigsur
+    |           |   `-- board-specific files
+    |           |
+    |           ... more boards here ...
+    |
+    `-- include
+	`-- asm-sh
+	    |-- adx
+	    |   `-- board-specific headers
+	    |-- bigsur
+	    |   `-- board-specific headers
+	    |
+	    .. more boards here ...
 
-Next, for companion chips:
-.
-`-- arch
-    `-- sh
-        `-- cchips
-            `-- hd6446x
-                `-- hd64461
-                    `-- cchip-specific files
+Next, for companion chips::
+
+    .
+    `-- arch
+	`-- sh
+	    `-- cchips
+		`-- hd6446x
+		    `-- hd64461
+			`-- cchip-specific files
 
 ... and so on. Headers for the companion chips are treated the same way as
 board-specific headers. Thus, include/asm-sh/hd64461 is home to all of the
 hd64461-specific headers.
 
-Finally, CPU family support is also abstracted:
-.
-|-- arch
-|   `-- sh
-|       |-- kernel
-|       |   `-- cpu
-|       |       |-- sh2
-|       |       |   `-- SH-2 generic files
-|       |       |-- sh3
-|       |       |   `-- SH-3 generic files
-|       |       `-- sh4
-|       |           `-- SH-4 generic files
-|       `-- mm
-|           `-- This is also broken out per CPU family, so each family can
-|               have their own set of cache/tlb functions.
-|
-`-- include
-    `-- asm-sh
-        |-- cpu-sh2
-        |   `-- SH-2 specific headers
-        |-- cpu-sh3
-        |   `-- SH-3 specific headers
-        `-- cpu-sh4
-            `-- SH-4 specific headers
+Finally, CPU family support is also abstracted::
+
+    .
+    |-- arch
+    |   `-- sh
+    |       |-- kernel
+    |       |   `-- cpu
+    |       |       |-- sh2
+    |       |       |   `-- SH-2 generic files
+    |       |       |-- sh3
+    |       |       |   `-- SH-3 generic files
+    |       |       `-- sh4
+    |       |           `-- SH-4 generic files
+    |       `-- mm
+    |           `-- This is also broken out per CPU family, so each family can
+    |               have their own set of cache/tlb functions.
+    |
+    `-- include
+	`-- asm-sh
+	    |-- cpu-sh2
+	    |   `-- SH-2 specific headers
+	    |-- cpu-sh3
+	    |   `-- SH-3 specific headers
+	    `-- cpu-sh4
+		`-- SH-4 specific headers
 
 It should be noted that CPU subtypes are _not_ abstracted. Thus, these still
 need to be dealt with by the CPU family specific code.
@@ -110,33 +114,33 @@ arch/sh/boards and the include/asm-sh/ hierarchy. In order to better
 explain this, we use some examples for adding an imaginary board. For
 setup code, we're required at the very least to provide definitions for
 get_system_type() and platform_setup(). For our imaginary board, this
-might look something like:
+might look something like::
 
-/*
- * arch/sh/boards/vapor/setup.c - Setup code for imaginary board
- */
-#include <linux/init.h>
+    /*
+    * arch/sh/boards/vapor/setup.c - Setup code for imaginary board
+    */
+    #include <linux/init.h>
 
-const char *get_system_type(void)
-{
-	return "FooTech Vaporboard";
-}
+    const char *get_system_type(void)
+    {
+	    return "FooTech Vaporboard";
+    }
 
-int __init platform_setup(void)
-{
-  	/*
-	 * If our hardware actually existed, we would do real
-	 * setup here. Though it's also sane to leave this empty
-	 * if there's no real init work that has to be done for
-	 * this board.
-	 */
+    int __init platform_setup(void)
+    {
+	    /*
+	    * If our hardware actually existed, we would do real
+	    * setup here. Though it's also sane to leave this empty
+	    * if there's no real init work that has to be done for
+	    * this board.
+	    */
 
-	/* Start-up imaginary PCI ... */
+	    /* Start-up imaginary PCI ... */
 
-	/* And whatever else ... */
+	    /* And whatever else ... */
 
-	return 0;
-}
+	    return 0;
+    }
 
 Our new imaginary board will also have to tie into the machvec in order for it
 to be of any use.
@@ -172,16 +176,16 @@ sufficient.
    vector.
 
    Note that these prototypes are generated automatically by setting
-   __IO_PREFIX to something sensible. A typical example would be:
+   __IO_PREFIX to something sensible. A typical example would be::
 
 	#define __IO_PREFIX vapor
-   	#include <asm/io_generic.h>
+	#include <asm/io_generic.h>
 
    somewhere in the board-specific header. Any boards being ported that still
    have a legacy io.h should remove it entirely and switch to the new model.
 
  - Add machine vector definitions to the board's setup.c. At a bare minimum,
-   this must be defined as something like:
+   this must be defined as something like::
 
 	struct sh_machine_vector mv_vapor __initmv = {
 		.mv_name = "vapor",
@@ -202,20 +206,20 @@ Large portions of the build system are now entirely dynamic, and merely
 require the proper entry here and there in order to get things done.
 
 The first thing to do is to add an entry to arch/sh/Kconfig, under the
-"System type" menu:
+"System type" menu::
 
-config SH_VAPOR
-	bool "Vapor"
-	help
-	  select Vapor if configuring for a FooTech Vaporboard.
+    config SH_VAPOR
+	    bool "Vapor"
+	    help
+	    select Vapor if configuring for a FooTech Vaporboard.
 
 next, this has to be added into arch/sh/Makefile. All boards require a
 machdir-y entry in order to be built. This entry needs to be the name of
 the board directory as it appears in arch/sh/boards, even if it is in a
 sub-directory (in which case, all parent directories below arch/sh/boards/
-need to be listed). For our new board, this entry can look like:
+need to be listed). For our new board, this entry can look like::
 
-machdir-$(CONFIG_SH_VAPOR)	+= vapor
+    machdir-$(CONFIG_SH_VAPOR)	+= vapor
 
 provided that we've placed everything in the arch/sh/boards/vapor/ directory.
 
@@ -230,7 +234,7 @@ This is done by adding an entry to the end of the arch/sh/tools/mach-types
 list. The method for doing this is self explanatory, and so we won't waste
 space restating it here. After this is done, you will be able to use
 implicit checks for your board if you need this somewhere throughout the
-common code, such as:
+common code, such as::
 
 	/* Make sure we're on the FooTech Vaporboard */
 	if (!mach_is_vapor())
@@ -253,16 +257,19 @@ build target, and it will be implicitly listed as such in the help text.
 Looking at the 'make help' output, you should now see something like:
 
 Architecture specific targets (sh):
-  zImage                  - Compressed kernel image (arch/sh/boot/zImage)
-  adx_defconfig           - Build for adx
-  cqreek_defconfig        - Build for cqreek
-  dreamcast_defconfig     - Build for dreamcast
-...
-  vapor_defconfig         - Build for vapor
 
-which then allows you to do:
+  =======================   =============================================
+  zImage                    Compressed kernel image (arch/sh/boot/zImage)
+  adx_defconfig             Build for adx
+  cqreek_defconfig          Build for cqreek
+  dreamcast_defconfig       Build for dreamcast
+  ...
+  vapor_defconfig           Build for vapor
+  =======================   =============================================
 
-$ make ARCH=sh CROSS_COMPILE=sh4-linux- vapor_defconfig vmlinux
+which then allows you to do::
+
+    $ make ARCH=sh CROSS_COMPILE=sh4-linux- vapor_defconfig vmlinux
 
 which will in turn copy the defconfig for this board, run it through
 oldconfig (prompting you for any new options since the time of creation),
-- 
2.26.2

[PATCH 17/22] docs: sh: convert register-banks.txt to ReST

[Mauro Carvalho Chehab]

- Add a SPDX header;
- Adjust document title to follow ReST style;
- Add blank lines to make ReST markup happy
- Add it to sh/index.rst.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/sh/index.rst                          |  1 +
 .../sh/{register-banks.txt => register-banks.rst}   | 13 ++++++++++---
 arch/sh/Kconfig.cpu                                 |  2 +-
 3 files changed, 12 insertions(+), 4 deletions(-)
 rename Documentation/sh/{register-banks.txt => register-banks.rst} (88%)

diff --git a/Documentation/sh/index.rst b/Documentation/sh/index.rst
index 56c08790265d..580f3b17e841 100644
--- a/Documentation/sh/index.rst
+++ b/Documentation/sh/index.rst
@@ -8,6 +8,7 @@ SuperH Interfaces Guide
     :maxdepth: 1
 
     new-machine
+    register-banks
 
 Memory Management
 =================
diff --git a/Documentation/sh/register-banks.txt b/Documentation/sh/register-banks.rst
similarity index 88%
rename from Documentation/sh/register-banks.txt
rename to Documentation/sh/register-banks.rst
index a6719f2f6594..2bef5c8fcbbc 100644
--- a/Documentation/sh/register-banks.txt
+++ b/Documentation/sh/register-banks.rst
@@ -1,5 +1,8 @@
-	Notes on register bank usage in the kernel
-	==========================================
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================================
+Notes on register bank usage in the kernel
+==========================================
 
 Introduction
 ------------
@@ -23,11 +26,15 @@ Presently the kernel uses several of these registers.
 
 	- r0_bank, r1_bank (referenced as k0 and k1, used for scratch
 	  registers when doing exception handling).
+
 	- r2_bank (used to track the EXPEVT/INTEVT code)
+
 		- Used by do_IRQ() and friends for doing irq mapping based off
 		  of the interrupt exception vector jump table offset
+
 	- r6_bank (global interrupt mask)
+
 		- The SR.IMASK interrupt handler makes use of this to set the
 		  interrupt priority level (used by local_irq_enable())
+
 	- r7_bank (current)
-
diff --git a/arch/sh/Kconfig.cpu b/arch/sh/Kconfig.cpu
index 97ca35f2cd37..fff419f3d757 100644
--- a/arch/sh/Kconfig.cpu
+++ b/arch/sh/Kconfig.cpu
@@ -85,7 +85,7 @@ config CPU_HAS_SR_RB
 	  that are lacking this bit must have another method in place for
 	  accomplishing what is taken care of by the banked registers.
 
-	  See <file:Documentation/sh/register-banks.txt> for further
+	  See <file:Documentation/sh/register-banks.rst> for further
 	  information on SR.RB and register banking in the kernel in general.
 
 config CPU_HAS_PTEAEX
-- 
2.26.2

[PATCH 18/22] docs: trace: ring-buffer-design.txt: convert to ReST format

[Mauro Carvalho Chehab]

- Just like some media documents, this file is dual licensed
  with GPL and GFDL. As right now the GFDL SPDX definition is
  bogus (as it doesn't tell anything about invariant parts),
  let's not use SPDX here. Let's use, instead, the same test
  as we have on media.
- Convert title to ReST format;
- use :field:  markup;
- Proper mark literal blocks as such;
- Add it to trace/index.rst file.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/trace/index.rst                 |   1 +
 ...ffer-design.txt => ring-buffer-design.rst} | 802 ++++++++++--------
 2 files changed, 428 insertions(+), 375 deletions(-)
 rename Documentation/trace/{ring-buffer-design.txt => ring-buffer-design.rst} (55%)

diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
index fa9e1c730f6a..7d83156c9ac1 100644
--- a/Documentation/trace/index.rst
+++ b/Documentation/trace/index.rst
@@ -22,6 +22,7 @@ Linux Tracing Technologies
    boottime-trace
    hwlat_detector
    intel_th
+   ring-buffer-design
    stm
    sys-t
    coresight/index
diff --git a/Documentation/trace/ring-buffer-design.txt b/Documentation/trace/ring-buffer-design.rst
similarity index 55%
rename from Documentation/trace/ring-buffer-design.txt
rename to Documentation/trace/ring-buffer-design.rst
index 2d53c6f25b91..6e2746d297af 100644
--- a/Documentation/trace/ring-buffer-design.txt
+++ b/Documentation/trace/ring-buffer-design.rst
@@ -1,11 +1,39 @@
-		Lockless Ring Buffer Design
-		===========================
+.. This file is dual-licensed: you can use it either under the terms
+.. of the GPL 2.0 or the GFDL 1.2+ license, at your option. Note that this
+.. dual licensing only applies to this file, and not this project as a
+.. whole.
+..
+.. a) This file is free software; you can redistribute it and/or
+..    modify it under the terms of the GNU General Public License as
+..    published by the Free Software Foundation version 2 of
+..    the License.
+..
+..    This file is distributed in the hope that it will be useful,
+..    but WITHOUT ANY WARRANTY; without even the implied warranty of
+..    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+..    GNU General Public License for more details.
+..
+.. Or, alternatively,
+..
+.. b) Permission is granted to copy, distribute and/or modify this
+..    document under the terms of the GNU Free Documentation License,
+..    Version 1.1 or any later version published by the Free Software
+..    Foundation, with no Invariant Sections, no Front-Cover Texts
+..    and no Back-Cover Texts. A copy of the license is available at
+..    https://www.gnu.org/licenses/old-licenses/fdl-1.2.html
+..
+.. TODO: replace it to GPL-2.0 OR GFDL-1.2-or-later WITH no-invariant-sections
+
+===========================
+Lockless Ring Buffer Design
+===========================
 
 Copyright 2009 Red Hat Inc.
-   Author:   Steven Rostedt <srostedt@redhat.com>
-  License:   The GNU Free Documentation License, Version 1.2
-               (dual licensed under the GPL v2)
-Reviewers:   Mathieu Desnoyers, Huang Ying, Hidetoshi Seto,
+
+:Author:   Steven Rostedt <srostedt@redhat.com>
+:License:  The GNU Free Documentation License, Version 1.2
+           (dual licensed under the GPL v2)
+:Reviewers:  Mathieu Desnoyers, Huang Ying, Hidetoshi Seto,
 	     and Frederic Weisbecker.
 
 
@@ -14,37 +42,50 @@ Written for: 2.6.31
 Terminology used in this Document
 ---------------------------------
 
-tail - where new writes happen in the ring buffer.
+tail
+	- where new writes happen in the ring buffer.
 
-head - where new reads happen in the ring buffer.
+head
+	- where new reads happen in the ring buffer.
 
-producer - the task that writes into the ring buffer (same as writer)
+producer
+	- the task that writes into the ring buffer (same as writer)
 
-writer - same as producer
+writer
+	- same as producer
 
-consumer - the task that reads from the buffer (same as reader)
+consumer
+	- the task that reads from the buffer (same as reader)
 
-reader - same as consumer.
+reader
+	- same as consumer.
 
-reader_page - A page outside the ring buffer used solely (for the most part)
-    by the reader.
+reader_page
+	- A page outside the ring buffer used solely (for the most part)
+	  by the reader.
 
-head_page - a pointer to the page that the reader will use next
+head_page
+	- a pointer to the page that the reader will use next
 
-tail_page - a pointer to the page that will be written to next
+tail_page
+	- a pointer to the page that will be written to next
 
-commit_page - a pointer to the page with the last finished non-nested write.
+commit_page
+	- a pointer to the page with the last finished non-nested write.
 
-cmpxchg - hardware-assisted atomic transaction that performs the following:
+cmpxchg
+	- hardware-assisted atomic transaction that performs the following::
 
-   A = B if previous A == C
+	    A = B if previous A == C
 
-   R = cmpxchg(A, C, B) is saying that we replace A with B if and only if
-      current A is equal to C, and we put the old (current) A into R
+	    R = cmpxchg(A, C, B) is saying that we replace A with B if and only
+		if current A is equal to C, and we put the old (current)
+		A into R
 
-   R gets the previous A regardless if A is updated with B or not.
+	    R gets the previous A regardless if A is updated with B or not.
 
-   To see if the update was successful a compare of R == C may be used.
+	  To see if the update was successful a compare of ``R == C``
+	  may be used.
 
 The Generic Ring Buffer
 -----------------------
@@ -64,7 +105,7 @@ No two writers can write at the same time (on the same per-cpu buffer),
 but a writer may interrupt another writer, but it must finish writing
 before the previous writer may continue. This is very important to the
 algorithm. The writers act like a "stack". The way interrupts works
-enforces this behavior.
+enforces this behavior::
 
 
   writer1 start
@@ -115,6 +156,8 @@ A sample of how the reader page is swapped: Note this does not
 show the head page in the buffer, it is for demonstrating a swap
 only.
 
+::
+
   +------+
   |reader|          RING BUFFER
   |page  |
@@ -172,21 +215,22 @@ only.
 It is possible that the page swapped is the commit page and the tail page,
 if what is in the ring buffer is less than what is held in a buffer page.
 
+::
 
-          reader page    commit page   tail page
-              |              |             |
-              v              |             |
-             +---+           |             |
-             |   |<----------+             |
-             |   |<------------------------+
-             |   |------+
-             +---+      |
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+            reader page    commit page   tail page
+                |              |             |
+                v              |             |
+               +---+           |             |
+               |   |<----------+             |
+               |   |<------------------------+
+               |   |------+
+               +---+      |
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 This case is still valid for this algorithm.
 When the writer leaves the page, it simply goes into the ring buffer
@@ -196,15 +240,19 @@ buffer.
 
 The main pointers:
 
-  reader page - The page used solely by the reader and is not part
-                of the ring buffer (may be swapped in)
+  reader page
+	    - The page used solely by the reader and is not part
+              of the ring buffer (may be swapped in)
 
-  head page - the next page in the ring buffer that will be swapped
+  head page
+	    - the next page in the ring buffer that will be swapped
               with the reader page.
 
-  tail page - the page where the next write will take place.
+  tail page
+	    - the page where the next write will take place.
 
-  commit page - the page that last finished a write.
+  commit page
+	    - the page that last finished a write.
 
 The commit page only is updated by the outermost writer in the
 writer stack. A writer that preempts another writer will not move the
@@ -219,7 +267,7 @@ transaction. If another write happens it must finish before continuing
 with the previous write.
 
 
-   Write reserve:
+   Write reserve::
 
        Buffer page
       +---------+
@@ -230,7 +278,7 @@ with the previous write.
       | empty   |
       +---------+
 
-   Write commit:
+   Write commit::
 
        Buffer page
       +---------+
@@ -242,7 +290,7 @@ with the previous write.
       +---------+
 
 
- If a write happens after the first reserve:
+ If a write happens after the first reserve::
 
        Buffer page
       +---------+
@@ -253,7 +301,7 @@ with the previous write.
       |reserved |
       +---------+ <--- tail pointer
 
-  After second writer commits:
+  After second writer commits::
 
 
        Buffer page
@@ -266,7 +314,7 @@ with the previous write.
       |commit   |
       +---------+ <--- tail pointer
 
-  When the first writer commits:
+  When the first writer commits::
 
        Buffer page
       +---------+
@@ -292,21 +340,22 @@ be several pages ahead. If the tail page catches up to the commit
 page then no more writes may take place (regardless of the mode
 of the ring buffer: overwrite and produce/consumer).
 
-The order of pages is:
+The order of pages is::
 
  head page
  commit page
  tail page
 
-Possible scenario:
-                             tail page
-  head page         commit page  |
-      |                 |        |
-      v                 v        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+Possible scenario::
+
+                               tail page
+    head page         commit page  |
+        |                 |        |
+        v                 v        v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 There is a special case that the head page is after either the commit page
 and possibly the tail page. That is when the commit (and tail) page has been
@@ -315,24 +364,25 @@ part of the ring buffer, but the reader page is not. Whenever there
 has been less than a full page that has been committed inside the ring buffer,
 and a reader swaps out a page, it will be swapping out the commit page.
 
+::
 
-          reader page    commit page   tail page
-              |              |             |
-              v              |             |
-             +---+           |             |
-             |   |<----------+             |
-             |   |<------------------------+
-             |   |------+
-             +---+      |
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
-                        ^
-                        |
-                    head page
+            reader page    commit page   tail page
+                |              |             |
+                v              |             |
+               +---+           |             |
+               |   |<----------+             |
+               |   |<------------------------+
+               |   |------+
+               +---+      |
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
+                          ^
+                          |
+                      head page
 
 
 In this case, the head page will not move when the tail and commit
@@ -347,42 +397,42 @@ When the tail meets the head page, if the buffer is in overwrite mode,
 the head page will be pushed ahead one. If the buffer is in producer/consumer
 mode, the write will fail.
 
-Overwrite mode:
+Overwrite mode::
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
-                        ^
-                        |
-                    head page
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
+                          ^
+                          |
+                      head page
 
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
-                                 ^
-                                 |
-                             head page
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
+                                   ^
+                                   |
+                               head page
 
 
-                    tail page
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
-                                 ^
-                                 |
-                             head page
+                      tail page
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
+                                   ^
+                                   |
+                               head page
 
 Note, the reader page will still point to the previous head page.
 But when a swap takes place, it will use the most recent head page.
@@ -397,7 +447,7 @@ State flags are placed inside the pointer to the page. To do this,
 each page must be aligned in memory by 4 bytes. This will allow the 2
 least significant bits of the address to be used as flags, since
 they will always be zero for the address. To get the address,
-simply mask out the flags.
+simply mask out the flags::
 
   MASK = ~3
 
@@ -405,24 +455,27 @@ simply mask out the flags.
 
 Two flags will be kept by these two bits:
 
-   HEADER - the page being pointed to is a head page
+   HEADER
+	- the page being pointed to is a head page
 
-   UPDATE - the page being pointed to is being updated by a writer
+   UPDATE
+	- the page being pointed to is being updated by a writer
           and was or is about to be a head page.
 
+::
 
-          reader page
-              |
-              v
-             +---+
-             |   |------+
-             +---+      |
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-H->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+	      reader page
+		  |
+		  v
+		+---+
+		|   |------+
+		+---+      |
+			    |
+			    v
+	+---+    +---+    +---+    +---+
+    <---|   |--->|   |-H->|   |--->|   |--->
+    --->|   |<---|   |<---|   |<---|   |<---
+	+---+    +---+    +---+    +---+
 
 
 The above pointer "-H->" would have the HEADER flag set. That is
@@ -430,24 +483,24 @@ the next page is the next page to be swapped out by the reader.
 This pointer means the next page is the head page.
 
 When the tail page meets the head pointer, it will use cmpxchg to
-change the pointer to the UPDATE state:
+change the pointer to the UPDATE state::
 
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-H->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-H->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 "-U->" represents a pointer in the UPDATE state.
 
@@ -462,7 +515,7 @@ head page does not have the HEADER flag set, the compare will fail
 and the reader will need to look for the new head page and try again.
 Note, the flags UPDATE and HEADER are never set at the same time.
 
-The reader swaps the reader page as follows:
+The reader swaps the reader page as follows::
 
   +------+
   |reader|          RING BUFFER
@@ -477,7 +530,7 @@ The reader swaps the reader page as follows:
                    +-----H-------------+
 
 The reader sets the reader page next pointer as HEADER to the page after
-the head page.
+the head page::
 
 
   +------+
@@ -495,7 +548,7 @@ the head page.
 
 It does a cmpxchg with the pointer to the previous head page to make it
 point to the reader page. Note that the new pointer does not have the HEADER
-flag set.  This action atomically moves the head page forward.
+flag set.  This action atomically moves the head page forward::
 
   +------+
   |reader|          RING BUFFER
@@ -511,7 +564,7 @@ flag set.  This action atomically moves the head page forward.
     +------------------------------------+
 
 After the new head page is set, the previous pointer of the head page is
-updated to the reader page.
+updated to the reader page::
 
   +------+
   |reader|          RING BUFFER
@@ -548,7 +601,7 @@ prev pointers may not.
 
 Note, the way to determine a reader page is simply by examining the previous
 pointer of the page. If the next pointer of the previous page does not
-point back to the original page, then the original page is a reader page:
+point back to the original page, then the original page is a reader page::
 
 
              +--------+
@@ -572,54 +625,54 @@ not be able to swap the head page from the buffer, nor will it be able to
 move the head page, until the writer is finished with the move.
 
 This eliminates any races that the reader can have on the writer. The reader
-must spin, and this is why the reader cannot preempt the writer.
+must spin, and this is why the reader cannot preempt the writer::
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-H->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-H->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
-The following page will be made into the new head page.
+The following page will be made into the new head page::
 
-           tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-H->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+             tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-H->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 After the new head page has been set, we can set the old head page
-pointer back to NORMAL.
+pointer back to NORMAL::
 
-           tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |-H->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+             tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |-H->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
-After the head page has been moved, the tail page may now move forward.
+After the head page has been moved, the tail page may now move forward::
 
-                    tail page
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |-H->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                      tail page
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |-H->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 
 The above are the trivial updates. Now for the more complex scenarios.
@@ -630,26 +683,26 @@ tail page may make it all the way around the buffer and meet the commit
 page. At this time, we must start dropping writes (usually with some kind
 of warning to the user). But what happens if the commit was still on the
 reader page? The commit page is not part of the ring buffer. The tail page
-must account for this.
+must account for this::
 
 
-          reader page    commit page
-              |              |
-              v              |
-             +---+           |
-             |   |<----------+
-             |   |
-             |   |------+
-             +---+      |
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-H->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
-               ^
-               |
-           tail page
+            reader page    commit page
+                |              |
+                v              |
+               +---+           |
+               |   |<----------+
+               |   |
+               |   |------+
+               +---+      |
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-H->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
+                 ^
+                 |
+             tail page
 
 If the tail page were to simply push the head page forward, the commit when
 leaving the reader page would not be pointing to the correct page.
@@ -676,7 +729,7 @@ the head page if the head page is the next page. If the head page
 is not the next page, the tail page is simply updated with a cmpxchg.
 
 Only writers move the tail page. This must be done atomically to protect
-against nested writers.
+against nested writers::
 
   temp_page = tail_page
   next_page = temp_page->next
@@ -684,54 +737,54 @@ against nested writers.
 
 The above will update the tail page if it is still pointing to the expected
 page. If this fails, a nested write pushed it forward, the current write
-does not need to push it.
+does not need to push it::
 
 
-           temp page
-               |
-               v
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+             temp page
+                 |
+                 v
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
-Nested write comes in and moves the tail page forward:
+Nested write comes in and moves the tail page forward::
 
-                    tail page (moved by nested writer)
-            temp page   |
-               |        |
-               v        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                      tail page (moved by nested writer)
+              temp page   |
+                 |        |
+                 v        v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 The above would fail the cmpxchg, but since the tail page has already
 been moved forward, the writer will just try again to reserve storage
 on the new tail page.
 
-But the moving of the head page is a bit more complex.
+But the moving of the head page is a bit more complex::
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-H->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-H->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
-The write converts the head page pointer to UPDATE.
+The write converts the head page pointer to UPDATE::
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 But if a nested writer preempts here, it will see that the next
 page is a head page, but it is also nested. It will detect that
@@ -739,217 +792,216 @@ it is nested and will save that information. The detection is the
 fact that it sees the UPDATE flag instead of a HEADER or NORMAL
 pointer.
 
-The nested writer will set the new head page pointer.
+The nested writer will set the new head page pointer::
 
-           tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-H->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+             tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-H->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 But it will not reset the update back to normal. Only the writer
 that converted a pointer from HEAD to UPDATE will convert it back
-to NORMAL.
+to NORMAL::
 
-                    tail page
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-H->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                      tail page
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-H->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 After the nested writer finishes, the outermost writer will convert
-the UPDATE pointer to NORMAL.
+the UPDATE pointer to NORMAL::
 
 
-                    tail page
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |-H->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                      tail page
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |-H->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 
 It can be even more complex if several nested writes came in and moved
-the tail page ahead several pages:
+the tail page ahead several pages::
 
 
-(first writer)
+  (first writer)
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-H->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-H->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
-The write converts the head page pointer to UPDATE.
+The write converts the head page pointer to UPDATE::
 
-            tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |--->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+              tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |--->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 Next writer comes in, and sees the update and sets up the new
-head page.
+head page::
 
-(second writer)
+  (second writer)
 
-           tail page
-               |
-               v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-H->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+             tail page
+                 |
+                 v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-H->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 The nested writer moves the tail page forward. But does not set the old
-update page to NORMAL because it is not the outermost writer.
+update page to NORMAL because it is not the outermost writer::
 
-                    tail page
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-H->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                      tail page
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-H->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 Another writer preempts and sees the page after the tail page is a head page.
-It changes it from HEAD to UPDATE.
+It changes it from HEAD to UPDATE::
 
-(third writer)
+  (third writer)
 
-                    tail page
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-U->|   |--->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                      tail page
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-U->|   |--->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
-The writer will move the head page forward:
+The writer will move the head page forward::
 
 
-(third writer)
+  (third writer)
 
-                    tail page
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-U->|   |-H->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                      tail page
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-U->|   |-H->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 But now that the third writer did change the HEAD flag to UPDATE it
-will convert it to normal:
+will convert it to normal::
 
 
-(third writer)
+  (third writer)
 
-                    tail page
-                        |
-                        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |--->|   |-H->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                      tail page
+                          |
+                          v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |--->|   |-H->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 
-Then it will move the tail page, and return back to the second writer.
+Then it will move the tail page, and return back to the second writer::
 
 
-(second writer)
+  (second writer)
 
-                             tail page
-                                 |
-                                 v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |--->|   |-H->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                               tail page
+                                   |
+                                   v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |--->|   |-H->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 
 The second writer will fail to move the tail page because it was already
 moved, so it will try again and add its data to the new tail page.
-It will return to the first writer.
+It will return to the first writer::
 
 
-(first writer)
+  (first writer)
 
-                             tail page
-                                 |
-                                 v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |--->|   |-H->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                               tail page
+                                   |
+                                   v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |--->|   |-H->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 The first writer cannot know atomically if the tail page moved
 while it updates the HEAD page. It will then update the head page to
-what it thinks is the new head page.
+what it thinks is the new head page::
 
 
-(first writer)
+  (first writer)
 
-                             tail page
-                                 |
-                                 v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-H->|   |-H->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                               tail page
+                                   |
+                                   v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-H->|   |-H->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 Since the cmpxchg returns the old value of the pointer the first writer
 will see it succeeded in updating the pointer from NORMAL to HEAD.
 But as we can see, this is not good enough. It must also check to see
-if the tail page is either where it use to be or on the next page:
+if the tail page is either where it use to be or on the next page::
 
 
-(first writer)
+  (first writer)
 
-               A        B    tail page
-               |        |        |
-               v        v        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |-H->|   |-H->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                 A        B    tail page
+                 |        |        |
+                 v        v        v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |-H->|   |-H->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 If tail page != A and tail page != B, then it must reset the pointer
 back to NORMAL. The fact that it only needs to worry about nested
-writers means that it only needs to check this after setting the HEAD page.
+writers means that it only needs to check this after setting the HEAD page::
 
 
-(first writer)
+  (first writer)
 
-               A        B    tail page
-               |        |        |
-               v        v        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |-U->|   |--->|   |-H->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+                 A        B    tail page
+                 |        |        |
+                 v        v        v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |-U->|   |--->|   |-H->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
 
 Now the writer can update the head page. This is also why the head page must
 remain in UPDATE and only reset by the outermost writer. This prevents
-the reader from seeing the incorrect head page.
+the reader from seeing the incorrect head page::
 
 
-(first writer)
-
-               A        B    tail page
-               |        |        |
-               v        v        v
-    +---+    +---+    +---+    +---+
-<---|   |--->|   |--->|   |--->|   |-H->
---->|   |<---|   |<---|   |<---|   |<---
-    +---+    +---+    +---+    +---+
+  (first writer)
 
+                 A        B    tail page
+                 |        |        |
+                 v        v        v
+      +---+    +---+    +---+    +---+
+  <---|   |--->|   |--->|   |--->|   |-H->
+  --->|   |<---|   |<---|   |<---|   |<---
+      +---+    +---+    +---+    +---+
-- 
2.26.2

Re: [PATCH 18/22] docs: trace: ring-buffer-design.txt: convert to ReST format

[Joe Perches]

On Mon, 2020-06-15 at 08:50 +0200, Mauro Carvalho Chehab wrote:
> - Just like some media documents, this file is dual licensed
>   with GPL and GFDL. As right now the GFDL SPDX definition is
>   bogus (as it doesn't tell anything about invariant parts),
>   let's not use SPDX here. Let's use, instead, the same test
>   as we have on media.
[]
> diff --git a/Documentation/trace/ring-buffer-design.txt b/Documentation/trace/ring-buffer-design.rst
> []
> +.. Or, alternatively,
> +..
> +.. b) Permission is granted to copy, distribute and/or modify this
> +..    document under the terms of the GNU Free Documentation License,
> +..    Version 1.1 or any later version published by the Free Software
> +..    Foundation, with no Invariant Sections, no Front-Cover Texts
> +..    and no Back-Cover Texts. A copy of the license is available at
> +..    https://www.gnu.org/licenses/old-licenses/fdl-1.2.html

Use of a version 1.1 reference with a 1.2 link.

Perhaps the link should be:
https://www.gnu.org/licenses/old-licenses/fdl-1.1.html

> +..
> +.. TODO: replace it to GPL-2.0 OR GFDL-1.2-or-later WITH no-invariant-sections

Is there some reason a new GFDL entry has not yet been added
to the LICENSES directory?

Re: [PATCH 18/22] docs: trace: ring-buffer-design.txt: convert to ReST format

[Mauro Carvalho Chehab]

Em Mon, 15 Jun 2020 10:48:10 -0700
Joe Perches <joe@perches.com> escreveu:

> On Mon, 2020-06-15 at 08:50 +0200, Mauro Carvalho Chehab wrote:
> > - Just like some media documents, this file is dual licensed
> >   with GPL and GFDL. As right now the GFDL SPDX definition is
> >   bogus (as it doesn't tell anything about invariant parts),
> >   let's not use SPDX here. Let's use, instead, the same test
> >   as we have on media.  
> []
> > diff --git a/Documentation/trace/ring-buffer-design.txt b/Documentation/trace/ring-buffer-design.rst
> > []
> > +.. Or, alternatively,
> > +..
> > +.. b) Permission is granted to copy, distribute and/or modify this
> > +..    document under the terms of the GNU Free Documentation License,
> > +..    Version 1.1 or any later version published by the Free Software
> > +..    Foundation, with no Invariant Sections, no Front-Cover Texts
> > +..    and no Back-Cover Texts. A copy of the license is available at
> > +..    https://www.gnu.org/licenses/old-licenses/fdl-1.2.html  
> 
> Use of a version 1.1 reference with a 1.2 link.

Right. I'll fix it.

> 
> Perhaps the link should be:
> https://www.gnu.org/licenses/old-licenses/fdl-1.1.html
> 
> > +..
> > +.. TODO: replace it to GPL-2.0 OR GFDL-1.2-or-later WITH no-invariant-sections  
> 
> Is there some reason a new GFDL entry has not yet been added
> to the LICENSES directory?

Yes:

	https://github.com/spdx/license-list-XML/issues/686
	https://github.com/spdx/license-list-XML/issues/970

In summary, GFDL can either be a free or non-free license, depending
on having or not "invariant sections", but SPDX spec is incomplete on
that matter.

From the discussions, it *seems* that we'll end having a SPDX header
like: 

	GFDL-1.2-or-later-no-invariant	https://github.com/spdx/license-list-XML/milestone/12


But the discussion is still open, and so far there's no such tag.
So, we'll need to keep track at the above issues, until they finally
create the new ones.

It sounds that this is expected to happen on SPDX version 3.10:

	https://github.com/spdx/license-list-XML/milestone/12

Btw, thanks for asking. I just added some comments there, in order
to indicate what it is needed for the Linux Kernel.

Thanks,
Mauro

Re: [PATCH 18/22] docs: trace: ring-buffer-design.txt: convert to ReST format

[Jonathan Corbet]

On Mon, 15 Jun 2020 08:50:23 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

[CC += Steve]

> - Just like some media documents, this file is dual licensed
>   with GPL and GFDL. As right now the GFDL SPDX definition is
>   bogus (as it doesn't tell anything about invariant parts),
>   let's not use SPDX here. Let's use, instead, the same test
>   as we have on media.

The dual-licensing really can't be expressed with an SPDX tag?  Because...

[...]

> +.. This file is dual-licensed: you can use it either under the terms
> +.. of the GPL 2.0 or the GFDL 1.2+ license, at your option. Note that this
> +.. dual licensing only applies to this file, and not this project as a
> +.. whole.
> +..
> +.. a) This file is free software; you can redistribute it and/or
> +..    modify it under the terms of the GNU General Public License as
> +..    published by the Free Software Foundation version 2 of
> +..    the License.
> +..
> +..    This file is distributed in the hope that it will be useful,
> +..    but WITHOUT ANY WARRANTY; without even the implied warranty of
> +..    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +..    GNU General Public License for more details.
> +..
> +.. Or, alternatively,
> +..
> +.. b) Permission is granted to copy, distribute and/or modify this
> +..    document under the terms of the GNU Free Documentation License,
> +..    Version 1.1 or any later version published by the Free Software
> +..    Foundation, with no Invariant Sections, no Front-Cover Texts
> +..    and no Back-Cover Texts. A copy of the license is available at
> +..    https://www.gnu.org/licenses/old-licenses/fdl-1.2.html
> +..
> +.. TODO: replace it to GPL-2.0 OR GFDL-1.2-or-later WITH no-invariant-sections

...adding all that boilerplate is kind of a bummer.

At a minimum I'd want an ack from Steve (who wasn't copied) before
applying this, but it would be better to add a bit more SPDX
infrastructure to express this if possible.

Thanks,

jon

Re: [PATCH 18/22] docs: trace: ring-buffer-design.txt: convert to ReST format

[Steven Rostedt]

On Fri, 19 Jun 2020 14:13:29 -0600
Jonathan Corbet <corbet@lwn.net> wrote:

> On Mon, 15 Jun 2020 08:50:23 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 
> [CC += Steve]

Thanks.

> 
> > - Just like some media documents, this file is dual licensed
> >   with GPL and GFDL. As right now the GFDL SPDX definition is
> >   bogus (as it doesn't tell anything about invariant parts),
> >   let's not use SPDX here. Let's use, instead, the same test
> >   as we have on media.  
> 
> The dual-licensing really can't be expressed with an SPDX tag?  Because...

A SPDX dual license should be possible, as it's used for GPL and BSD in
several locations.

> 
> [...]
> 
> > +.. This file is dual-licensed: you can use it either under the terms
> > +.. of the GPL 2.0 or the GFDL 1.2+ license, at your option. Note that this

And I never said GFDL 1.2+

 Copyright 2009 Red Hat Inc.                                                                                                                                                                  
-   Author:   Steven Rostedt <srostedt@redhat.com>                                                                                                                                            
-  License:   The GNU Free Documentation License, Version 1.2                                                                                                                                 
-               (dual licensed under the GPL v2)                                                                                                                                              
-Reviewers:   Mathieu Desnoyers, Huang Ying, Hidetoshi Seto,

There is no "+" sign here.


> > +.. dual licensing only applies to this file, and not this project as a
> > +.. whole.
> > +..
> > +.. a) This file is free software; you can redistribute it and/or
> > +..    modify it under the terms of the GNU General Public License as
> > +..    published by the Free Software Foundation version 2 of
> > +..    the License.
> > +..
> > +..    This file is distributed in the hope that it will be useful,
> > +..    but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +..    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +..    GNU General Public License for more details.
> > +..
> > +.. Or, alternatively,
> > +..
> > +.. b) Permission is granted to copy, distribute and/or modify this
> > +..    document under the terms of the GNU Free Documentation License,
> > +..    Version 1.1 or any later version published by the Free Software
> > +..    Foundation, with no Invariant Sections, no Front-Cover Texts
> > +..    and no Back-Cover Texts. A copy of the license is available at
> > +..    https://www.gnu.org/licenses/old-licenses/fdl-1.2.html
> > +..
> > +.. TODO: replace it to GPL-2.0 OR GFDL-1.2-or-later WITH no-invariant-sections  

  "GPL-2.0 OR GFDL-1.2"

-- Steve

> 
> ...adding all that boilerplate is kind of a bummer.
> 
> At a minimum I'd want an ack from Steve (who wasn't copied) before
> applying this, but it would be better to add a bit more SPDX
> infrastructure to express this if possible.
> 
> Thanks,
> 
> jon

Re: [PATCH 18/22] docs: trace: ring-buffer-design.txt: convert to ReST format

[Mauro Carvalho Chehab]

Em Fri, 19 Jun 2020 16:41:14 -0400
Steven Rostedt <rostedt@goodmis.org> escreveu:

> On Fri, 19 Jun 2020 14:13:29 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
> 
> > On Mon, 15 Jun 2020 08:50:23 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > 
> > [CC += Steve]  
> 
> Thanks.
> 
> >   
> > > - Just like some media documents, this file is dual licensed
> > >   with GPL and GFDL. As right now the GFDL SPDX definition is
> > >   bogus (as it doesn't tell anything about invariant parts),
> > >   let's not use SPDX here. Let's use, instead, the same test
> > >   as we have on media.    
> > 
> > The dual-licensing really can't be expressed with an SPDX tag?  Because...  
> 
> A SPDX dual license should be possible, as it's used for GPL and BSD in
> several locations.

Until one week ago, this was not possible, because SPDX headers
were broken for GFDL:

	https://github.com/spdx/license-list-XML/issues/686
	https://github.com/spdx/license-list-XML/issues/970

There are 2 types of GFDL licenses:
	- a Free license where the entire document allows
	  reviewing/changing;
	- a non-free variant, were some parts of the document
	  have a non-free license, where only the author can
	  change (called invariant parts).

Basically, some distro policies don't allow shipping documents
under the non-free version of GFDL.

The SPDX spec (up to version 3.9) doesn't allow differentiating
between them.

-

There's now an upstream patch (at SPDX) to be merged on the upcoming
versin 3.10 that will allow us to finally get rid of those:

	https://github.com/spdx/license-list-XML/pull/1048/commits/f695d2ac65230d0f4161ba58fff2f9d87bb5a053#diff-b948674e5c5cf6341e44e76b2565e80c

The GFDL-1.2 with no invariant sections is defined as:

	<SPDXLicenseCollection xmlns="http://www.spdx.org/license">
	  <license licenseId="GFDL-1.2-only-no-invariants" isOsiApproved="false"
	  name="GNU Free Documentation License v1.2 only - no invariants">
	    <crossRefs>
	      <crossRef>https://www.gnu.org/licenses/old-licenses/fdl-1.2.txt</crossRef>
	    </crossRefs>
	    <standardLicenseHeader>
	      Copyright (c) <alt name="copyright" match=".+">YEAR YOUR NAME</alt>.
	      Permission is granted to copy, distribute and/or modify this
	      document under the terms of the GNU Free Documentation License,
	      Version 1.2; with no Invariant Sections, no Front-Cover Texts,
	      and no Back-Cover Texts. A copy of the license is included
	      in the section entitled "GNU Free Documentation License".
	    </standardLicenseHeader>
	    <notes>
	      This license was released November 2002. The identifier 
	      GFDL-1.2-only-no-invariants should only be used when there are 
	      no Invariant Sections, Front-Cover Texts or Back-Cover Texts. 
	      See GFDL-1.2-only and GFDL-1.2-only-invariants for alternatives.
	    </notes>

> 
> > 
> > [...]
> >   
> > > +.. This file is dual-licensed: you can use it either under the terms
> > > +.. of the GPL 2.0 or the GFDL 1.2+ license, at your option. Note that this  
> 
> And I never said GFDL 1.2+

Ah, right. I'll fix it.

> 
>  Copyright 2009 Red Hat Inc.                                                                                                                                                                  
> -   Author:   Steven Rostedt <srostedt@redhat.com>                                                                                                                                            
> -  License:   The GNU Free Documentation License, Version 1.2                                                                                                                                 
> -               (dual licensed under the GPL v2)                                                                                                                                              
> -Reviewers:   Mathieu Desnoyers, Huang Ying, Hidetoshi Seto,
> 
> There is no "+" sign here.
> 
> 
> > > +.. dual licensing only applies to this file, and not this project as a
> > > +.. whole.
> > > +..
> > > +.. a) This file is free software; you can redistribute it and/or
> > > +..    modify it under the terms of the GNU General Public License as
> > > +..    published by the Free Software Foundation version 2 of
> > > +..    the License.
> > > +..
> > > +..    This file is distributed in the hope that it will be useful,
> > > +..    but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > +..    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > +..    GNU General Public License for more details.
> > > +..
> > > +.. Or, alternatively,
> > > +..
> > > +.. b) Permission is granted to copy, distribute and/or modify this
> > > +..    document under the terms of the GNU Free Documentation License,
> > > +..    Version 1.1 or any later version published by the Free Software
> > > +..    Foundation, with no Invariant Sections, no Front-Cover Texts
> > > +..    and no Back-Cover Texts. A copy of the license is available at
> > > +..    https://www.gnu.org/licenses/old-licenses/fdl-1.2.html
> > > +..
> > > +.. TODO: replace it to GPL-2.0 OR GFDL-1.2-or-later WITH no-invariant-sections    
> 
>   "GPL-2.0 OR GFDL-1.2"

It should actually be:

	"GPL-2.0 OR GFDL-1.2-only-no-invariants"

Thanks,
Mauro

[PATCH 19/22] docs: move other kAPI documents to core-api

[Mauro Carvalho Chehab]

There are a number of random documents that seem to be
describing some aspects of the core-api. Move them to such
directory, adding them at the core-api/index.rst file.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/admin-guide/sysctl/vm.rst                     | 2 +-
 Documentation/core-api/index.rst                            | 6 ++++++
 Documentation/{mailbox.txt => core-api/mailbox.rst}         | 0
 Documentation/{nommu-mmap.txt => core-api/nommu-mmap.rst}   | 0
 .../{this_cpu_ops.txt => core-api/this_cpu_ops.rst}         | 0
 .../{process => core-api}/unaligned-memory-access.rst       | 0
 Documentation/gpu/drm-mm.rst                                | 2 +-
 arch/Kconfig                                                | 2 +-
 init/Kconfig                                                | 2 +-
 mm/Kconfig                                                  | 2 +-
 mm/nommu.c                                                  | 2 +-
 11 files changed, 12 insertions(+), 6 deletions(-)
 rename Documentation/{mailbox.txt => core-api/mailbox.rst} (100%)
 rename Documentation/{nommu-mmap.txt => core-api/nommu-mmap.rst} (100%)
 rename Documentation/{this_cpu_ops.txt => core-api/this_cpu_ops.rst} (100%)
 rename Documentation/{process => core-api}/unaligned-memory-access.rst (100%)

diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index d46d5b7013c6..9f7fa2d37fa7 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -583,7 +583,7 @@ trimming of allocations is initiated.
 
 The default value is 1.
 
-See Documentation/nommu-mmap.txt for more information.
+See Documentation/core-api/nommu-mmap.rst for more information.
 
 
 numa_zonelist_order
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index 721e40a8c65b..2a364dd533de 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -38,11 +38,15 @@ Library functionality that is used throughout the kernel.
    circular-buffers
    rbtree
    generic-radix-tree
+   mailbox
    packing
+   rbtree
+   this_cpu_ops
    timekeeping
    watch_queue
    errseq
 
+
 Concurrency primitives
 ======================
 
@@ -83,11 +87,13 @@ more memory-management documentation in :doc:`/vm/index`.
    :maxdepth: 1
 
    memory-allocation
+   unaligned-memory-access
    dma-api
    dma-api-howto
    dma-attributes
    dma-isa-lpc
    bus-virt-phys-mapping
+   nommu-mmap
    mm-api
    genalloc
    pin_user_pages
diff --git a/Documentation/mailbox.txt b/Documentation/core-api/mailbox.rst
similarity index 100%
rename from Documentation/mailbox.txt
rename to Documentation/core-api/mailbox.rst
diff --git a/Documentation/nommu-mmap.txt b/Documentation/core-api/nommu-mmap.rst
similarity index 100%
rename from Documentation/nommu-mmap.txt
rename to Documentation/core-api/nommu-mmap.rst
diff --git a/Documentation/this_cpu_ops.txt b/Documentation/core-api/this_cpu_ops.rst
similarity index 100%
rename from Documentation/this_cpu_ops.txt
rename to Documentation/core-api/this_cpu_ops.rst
diff --git a/Documentation/process/unaligned-memory-access.rst b/Documentation/core-api/unaligned-memory-access.rst
similarity index 100%
rename from Documentation/process/unaligned-memory-access.rst
rename to Documentation/core-api/unaligned-memory-access.rst
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 1839762044be..e0bbcbb6f512 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -314,7 +314,7 @@ To use drm_gem_cma_get_unmapped_area(), drivers must fill the struct
 a pointer on drm_gem_cma_get_unmapped_area().
 
 More detailed information about get_unmapped_area can be found in
-Documentation/nommu-mmap.txt
+Documentation/core-api/nommu-mmap.rst
 
 Memory Coherency
 ----------------
diff --git a/arch/Kconfig b/arch/Kconfig
index 8cc35dc556c7..2a439fb8069e 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -147,7 +147,7 @@ config HAVE_EFFICIENT_UNALIGNED_ACCESS
 	  problems with received packets if doing so would not help
 	  much.
 
-	  See Documentation/unaligned-memory-access.txt for more
+	  See Documentation/core-api/unaligned-memory-access.rst for more
 	  information on the topic of unaligned memory accesses.
 
 config ARCH_USE_BUILTIN_BSWAP
diff --git a/init/Kconfig b/init/Kconfig
index 3327f0eca1a3..4218a60f5f79 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1957,7 +1957,7 @@ config MMAP_ALLOW_UNINITIALIZED
 	  userspace.  Since that isn't generally a problem on no-MMU systems,
 	  it is normally safe to say Y here.
 
-	  See Documentation/nommu-mmap.txt for more information.
+	  See Documentation/core-api/nommu-mmap.rst for more information.
 
 config SYSTEM_DATA_VERIFICATION
 	def_bool n
diff --git a/mm/Kconfig b/mm/Kconfig
index f2104cc0d35c..6c6189724b75 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -387,7 +387,7 @@ config NOMMU_INITIAL_TRIM_EXCESS
 	  This option specifies the initial value of this option.  The default
 	  of 1 says that all excess pages should be trimmed.
 
-	  See Documentation/nommu-mmap.txt for more information.
+	  See Documentation/core-api/nommu-mmap.rst for more information.
 
 config TRANSPARENT_HUGEPAGE
 	bool "Transparent Hugepage Support"
diff --git a/mm/nommu.c b/mm/nommu.c
index cdcad5d61dd1..8f2e502ad8a3 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -5,7 +5,7 @@
  *  Replacement code for mm functions to support CPU's that don't
  *  have any form of memory management unit (thus no virtual memory).
  *
- *  See Documentation/nommu-mmap.txt
+ *  See Documentation/core-api/nommu-mmap.rst
  *
  *  Copyright (c) 2004-2008 David Howells <dhowells@redhat.com>
  *  Copyright (c) 2000-2003 David McCullough <davidm@snapgear.com>
-- 
2.26.2

[PATCH 20/22] docs: move remaining stuff under Documentation/*.txt to Documentation/staging

[Mauro Carvalho Chehab]

There are several files that I was unable to find a proper place
for them, and 3 ones that are still in plain old text format.

Let's place those stuff behind the carpet, as we'd like to keep the
root directory clean.

We can later discuss and move those into better places.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/index.rst                       | 13 ++++++++
 .../{crc32.txt => staging/crc32.rst}          |  0
 Documentation/staging/index.rst               | 32 +++++++++++++++++++
 .../{kprobes.txt => staging/kprobes.rst}      |  0
 Documentation/{lzo.txt => staging/lzo.rst}    |  0
 .../remoteproc.rst}                           |  2 +-
 .../{rpmsg.txt => staging/rpmsg.rst}          |  0
 .../speculation.rst}                          |  8 +++--
 .../static-keys.rst}                          |  0
 Documentation/{tee.txt => staging/tee.rst}    |  1 +
 Documentation/{xz.txt => staging/xz.rst}      |  0
 Documentation/trace/kprobetrace.rst           |  2 +-
 MAINTAINERS                                   |  8 ++---
 include/linux/jump_label.h                    |  2 +-
 lib/crc32.c                                   |  2 +-
 lib/lzo/lzo1x_decompress_safe.c               |  2 +-
 lib/xz/Kconfig                                |  2 +-
 samples/kprobes/kprobe_example.c              |  2 +-
 samples/kprobes/kretprobe_example.c           |  2 +-
 19 files changed, 63 insertions(+), 15 deletions(-)
 rename Documentation/{crc32.txt => staging/crc32.rst} (100%)
 create mode 100644 Documentation/staging/index.rst
 rename Documentation/{kprobes.txt => staging/kprobes.rst} (100%)
 rename Documentation/{lzo.txt => staging/lzo.rst} (100%)
 rename Documentation/{remoteproc.txt => staging/remoteproc.rst} (99%)
 rename Documentation/{rpmsg.txt => staging/rpmsg.rst} (100%)
 rename Documentation/{speculation.txt => staging/speculation.rst} (97%)
 rename Documentation/{static-keys.txt => staging/static-keys.rst} (100%)
 rename Documentation/{tee.txt => staging/tee.rst} (99%)
 rename Documentation/{xz.txt => staging/xz.rst} (100%)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 71eca3171574..3b491af0122d 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -182,6 +182,19 @@ subprojects.
 
    filesystems/ext4/index
 
+Other documentation
+-------------------
+
+There are several unsorted documents that don't seem to fit on other parts
+of the documentation body, or may require some adjustments and/or conversion
+to ReStructured Text format, or are simply too old.
+
+.. toctree::
+   :maxdepth: 2
+
+   staging/index
+
+
 Translations
 ------------
 
diff --git a/Documentation/crc32.txt b/Documentation/staging/crc32.rst
similarity index 100%
rename from Documentation/crc32.txt
rename to Documentation/staging/crc32.rst
diff --git a/Documentation/staging/index.rst b/Documentation/staging/index.rst
new file mode 100644
index 000000000000..8e98517675ca
--- /dev/null
+++ b/Documentation/staging/index.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Unsorted Documentation
+======================
+
+.. toctree::
+   :maxdepth: 2
+
+   crc32
+   kprobes
+   lzo
+   remoteproc
+   rpmsg
+   speculation
+   static-keys
+   tee
+   xz
+
+Atomic Types
+============
+
+.. literalinclude:: ../atomic_t.txt
+
+Atomic bitops
+=============
+
+.. literalinclude:: ../atomic_bitops.txt
+
+Memory Barriers
+===============
+
+.. literalinclude:: ../memory-barriers.txt
diff --git a/Documentation/kprobes.txt b/Documentation/staging/kprobes.rst
similarity index 100%
rename from Documentation/kprobes.txt
rename to Documentation/staging/kprobes.rst
diff --git a/Documentation/lzo.txt b/Documentation/staging/lzo.rst
similarity index 100%
rename from Documentation/lzo.txt
rename to Documentation/staging/lzo.rst
diff --git a/Documentation/remoteproc.txt b/Documentation/staging/remoteproc.rst
similarity index 99%
rename from Documentation/remoteproc.txt
rename to Documentation/staging/remoteproc.rst
index 2be1147256e0..9cccd3dd6a4b 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/staging/remoteproc.rst
@@ -22,7 +22,7 @@ for remote processors that supports this kind of communication. This way,
 platform-specific remoteproc drivers only need to provide a few low-level
 handlers, and then all rpmsg drivers will then just work
 (for more information about the virtio-based rpmsg bus and its drivers,
-please read Documentation/rpmsg.txt).
+please read Documentation/staging/rpmsg.rst).
 Registration of other types of virtio devices is now also possible. Firmwares
 just need to publish what kind of virtio devices do they support, and then
 remoteproc will add those devices. This makes it possible to reuse the
diff --git a/Documentation/rpmsg.txt b/Documentation/staging/rpmsg.rst
similarity index 100%
rename from Documentation/rpmsg.txt
rename to Documentation/staging/rpmsg.rst
diff --git a/Documentation/speculation.txt b/Documentation/staging/speculation.rst
similarity index 97%
rename from Documentation/speculation.txt
rename to Documentation/staging/speculation.rst
index 50d7ea857cff..8045d99bcf12 100644
--- a/Documentation/speculation.txt
+++ b/Documentation/staging/speculation.rst
@@ -1,9 +1,11 @@
+===========
+Speculation
+===========
+
 This document explains potential effects of speculation, and how undesirable
 effects can be mitigated portably using common APIs.
 
-===========
-Speculation
-===========
+------------------------------------------------------------------------------
 
 To improve performance and minimize average latencies, many contemporary CPUs
 employ speculative execution techniques such as branch prediction, performing
diff --git a/Documentation/static-keys.txt b/Documentation/staging/static-keys.rst
similarity index 100%
rename from Documentation/static-keys.txt
rename to Documentation/staging/static-keys.rst
diff --git a/Documentation/tee.txt b/Documentation/staging/tee.rst
similarity index 99%
rename from Documentation/tee.txt
rename to Documentation/staging/tee.rst
index c8fad81c4563..324604a15d17 100644
--- a/Documentation/tee.txt
+++ b/Documentation/staging/tee.rst
@@ -162,6 +162,7 @@ The AMD-TEE driver packages the command buffer payload for processing in TEE.
 The command buffer format for the different TEE commands can be found in [7].
 
 The TEE commands supported by AMD-TEE Trusted OS are:
+
 * TEE_CMD_ID_LOAD_TA          - loads a Trusted Application (TA) binary into
                                 TEE environment.
 * TEE_CMD_ID_UNLOAD_TA        - unloads TA binary from TEE environment.
diff --git a/Documentation/xz.txt b/Documentation/staging/xz.rst
similarity index 100%
rename from Documentation/xz.txt
rename to Documentation/staging/xz.rst
diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst
index cc4c5fc313df..c1709165c553 100644
--- a/Documentation/trace/kprobetrace.rst
+++ b/Documentation/trace/kprobetrace.rst
@@ -40,7 +40,7 @@ Synopsis of kprobe_events
  MEMADDR	: Address where the probe is inserted.
  MAXACTIVE	: Maximum number of instances of the specified function that
 		  can be probed simultaneously, or 0 for the default value
-		  as defined in Documentation/kprobes.txt section 1.3.1.
+		  as defined in Documentation/staging/kprobes.rst section 1.3.1.
 
  FETCHARGS	: Arguments. Each probe can have up to 128 args.
   %REG		: Fetch register REG
diff --git a/MAINTAINERS b/MAINTAINERS
index 805309399939..4c9814ee2fdb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9597,7 +9597,7 @@ M:	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
 M:	"David S. Miller" <davem@davemloft.net>
 M:	Masami Hiramatsu <mhiramat@kernel.org>
 S:	Maintained
-F:	Documentation/kprobes.txt
+F:	Documentation/staging/kprobes.rst
 F:	include/asm-generic/kprobes.h
 F:	include/linux/kprobes.h
 F:	kernel/kprobes.c
@@ -14500,7 +14500,7 @@ S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git rproc-next
 F:	Documentation/ABI/testing/sysfs-class-remoteproc
 F:	Documentation/devicetree/bindings/remoteproc/
-F:	Documentation/remoteproc.txt
+F:	Documentation/staging/remoteproc.rst
 F:	drivers/remoteproc/
 F:	include/linux/remoteproc.h
 F:	include/linux/remoteproc/
@@ -14512,7 +14512,7 @@ L:	linux-remoteproc@vger.kernel.org
 S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git rpmsg-next
 F:	Documentation/ABI/testing/sysfs-bus-rpmsg
-F:	Documentation/rpmsg.txt
+F:	Documentation/staging/rpmsg.rst
 F:	drivers/rpmsg/
 F:	include/linux/rpmsg.h
 F:	include/linux/rpmsg/
@@ -16761,7 +16761,7 @@ TEE SUBSYSTEM
 M:	Jens Wiklander <jens.wiklander@linaro.org>
 L:	tee-dev@lists.linaro.org
 S:	Maintained
-F:	Documentation/tee.txt
+F:	Documentation/staging/tee.rst
 F:	drivers/tee/
 F:	include/linux/tee_drv.h
 F:	include/uapi/linux/tee.h
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 3526c0aee954..32809624d422 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -68,7 +68,7 @@
  * Lacking toolchain and or architecture support, static keys fall back to a
  * simple conditional branch.
  *
- * Additional babbling in: Documentation/static-keys.txt
+ * Additional babbling in: Documentation/staging/static-keys.rst
  */
 
 #ifndef __ASSEMBLY__
diff --git a/lib/crc32.c b/lib/crc32.c
index 4a20455d1f61..35a03d03f973 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -24,7 +24,7 @@
  * Version 2.  See the file COPYING for more details.
  */
 
-/* see: Documentation/crc32.txt for a description of algorithms */
+/* see: Documentation/staging/crc32.rst for a description of algorithms */
 
 #include <linux/crc32.h>
 #include <linux/crc32poly.h>
diff --git a/lib/lzo/lzo1x_decompress_safe.c b/lib/lzo/lzo1x_decompress_safe.c
index 2717c7963acd..7892a40cf765 100644
--- a/lib/lzo/lzo1x_decompress_safe.c
+++ b/lib/lzo/lzo1x_decompress_safe.c
@@ -32,7 +32,7 @@
  * depending on the base count. Since the base count is taken from a u8
  * and a few bits, it is safe to assume that it will always be lower than
  * or equal to 2*255, thus we can always prevent any overflow by accepting
- * two less 255 steps. See Documentation/lzo.txt for more information.
+ * two less 255 steps. See Documentation/staging/lzo.rst for more information.
  */
 #define MAX_255_COUNT      ((((size_t)~0) / 255) - 2)
 
diff --git a/lib/xz/Kconfig b/lib/xz/Kconfig
index 22528743d4ce..5cb50245a878 100644
--- a/lib/xz/Kconfig
+++ b/lib/xz/Kconfig
@@ -5,7 +5,7 @@ config XZ_DEC
 	help
 	  LZMA2 compression algorithm and BCJ filters are supported using
 	  the .xz file format as the container. For integrity checking,
-	  CRC32 is supported. See Documentation/xz.txt for more information.
+	  CRC32 is supported. See Documentation/staging/xz.rst for more information.
 
 if XZ_DEC
 
diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 501911d1b327..240f2435ce6f 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -5,7 +5,7 @@
  * stack trace and selected registers when _do_fork() is called.
  *
  * For more information on theory of operation of kprobes, see
- * Documentation/kprobes.txt
+ * Documentation/staging/kprobes.rst
  *
  * You will see the trace data in /var/log/messages and on the console
  * whenever _do_fork() is invoked to create a new process.
diff --git a/samples/kprobes/kretprobe_example.c b/samples/kprobes/kretprobe_example.c
index 013e8e6ebae9..78a2da6fb3cd 100644
--- a/samples/kprobes/kretprobe_example.c
+++ b/samples/kprobes/kretprobe_example.c
@@ -11,7 +11,7 @@
  * If no func_name is specified, _do_fork is instrumented
  *
  * For more information on theory of operation of kretprobes, see
- * Documentation/kprobes.txt
+ * Documentation/staging/kprobes.rst
  *
  * Build and insert the kernel module as done in the kprobe example.
  * You will see the trace data in /var/log/messages and on the console
-- 
2.26.2

Re: [PATCH 20/22] docs: move remaining stuff under Documentation/*.txt to Documentation/staging

[Masami Hiramatsu]

Hi Mauro,

If you have any chance to update this series, could you move
kprobes.rst under trace/ directly? I think Naveen's idea is better.

Thank you,

On Mon, 15 Jun 2020 08:50:25 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> There are several files that I was unable to find a proper place
> for them, and 3 ones that are still in plain old text format.
> 
> Let's place those stuff behind the carpet, as we'd like to keep the
> root directory clean.
> 
> We can later discuss and move those into better places.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/index.rst                       | 13 ++++++++
>  .../{crc32.txt => staging/crc32.rst}          |  0
>  Documentation/staging/index.rst               | 32 +++++++++++++++++++
>  .../{kprobes.txt => staging/kprobes.rst}      |  0
>  Documentation/{lzo.txt => staging/lzo.rst}    |  0
>  .../remoteproc.rst}                           |  2 +-
>  .../{rpmsg.txt => staging/rpmsg.rst}          |  0
>  .../speculation.rst}                          |  8 +++--
>  .../static-keys.rst}                          |  0
>  Documentation/{tee.txt => staging/tee.rst}    |  1 +
>  Documentation/{xz.txt => staging/xz.rst}      |  0
>  Documentation/trace/kprobetrace.rst           |  2 +-
>  MAINTAINERS                                   |  8 ++---
>  include/linux/jump_label.h                    |  2 +-
>  lib/crc32.c                                   |  2 +-
>  lib/lzo/lzo1x_decompress_safe.c               |  2 +-
>  lib/xz/Kconfig                                |  2 +-
>  samples/kprobes/kprobe_example.c              |  2 +-
>  samples/kprobes/kretprobe_example.c           |  2 +-
>  19 files changed, 63 insertions(+), 15 deletions(-)
>  rename Documentation/{crc32.txt => staging/crc32.rst} (100%)
>  create mode 100644 Documentation/staging/index.rst
>  rename Documentation/{kprobes.txt => staging/kprobes.rst} (100%)
>  rename Documentation/{lzo.txt => staging/lzo.rst} (100%)
>  rename Documentation/{remoteproc.txt => staging/remoteproc.rst} (99%)
>  rename Documentation/{rpmsg.txt => staging/rpmsg.rst} (100%)
>  rename Documentation/{speculation.txt => staging/speculation.rst} (97%)
>  rename Documentation/{static-keys.txt => staging/static-keys.rst} (100%)
>  rename Documentation/{tee.txt => staging/tee.rst} (99%)
>  rename Documentation/{xz.txt => staging/xz.rst} (100%)
> 
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index 71eca3171574..3b491af0122d 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -182,6 +182,19 @@ subprojects.
>  
>     filesystems/ext4/index
>  
> +Other documentation
> +-------------------
> +
> +There are several unsorted documents that don't seem to fit on other parts
> +of the documentation body, or may require some adjustments and/or conversion
> +to ReStructured Text format, or are simply too old.
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   staging/index
> +
> +
>  Translations
>  ------------
>  
> diff --git a/Documentation/crc32.txt b/Documentation/staging/crc32.rst
> similarity index 100%
> rename from Documentation/crc32.txt
> rename to Documentation/staging/crc32.rst
> diff --git a/Documentation/staging/index.rst b/Documentation/staging/index.rst
> new file mode 100644
> index 000000000000..8e98517675ca
> --- /dev/null
> +++ b/Documentation/staging/index.rst
> @@ -0,0 +1,32 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Unsorted Documentation
> +======================
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   crc32
> +   kprobes
> +   lzo
> +   remoteproc
> +   rpmsg
> +   speculation
> +   static-keys
> +   tee
> +   xz
> +
> +Atomic Types
> +============
> +
> +.. literalinclude:: ../atomic_t.txt
> +
> +Atomic bitops
> +=============
> +
> +.. literalinclude:: ../atomic_bitops.txt
> +
> +Memory Barriers
> +===============
> +
> +.. literalinclude:: ../memory-barriers.txt
> diff --git a/Documentation/kprobes.txt b/Documentation/staging/kprobes.rst
> similarity index 100%
> rename from Documentation/kprobes.txt
> rename to Documentation/staging/kprobes.rst
> diff --git a/Documentation/lzo.txt b/Documentation/staging/lzo.rst
> similarity index 100%
> rename from Documentation/lzo.txt
> rename to Documentation/staging/lzo.rst
> diff --git a/Documentation/remoteproc.txt b/Documentation/staging/remoteproc.rst
> similarity index 99%
> rename from Documentation/remoteproc.txt
> rename to Documentation/staging/remoteproc.rst
> index 2be1147256e0..9cccd3dd6a4b 100644
> --- a/Documentation/remoteproc.txt
> +++ b/Documentation/staging/remoteproc.rst
> @@ -22,7 +22,7 @@ for remote processors that supports this kind of communication. This way,
>  platform-specific remoteproc drivers only need to provide a few low-level
>  handlers, and then all rpmsg drivers will then just work
>  (for more information about the virtio-based rpmsg bus and its drivers,
> -please read Documentation/rpmsg.txt).
> +please read Documentation/staging/rpmsg.rst).
>  Registration of other types of virtio devices is now also possible. Firmwares
>  just need to publish what kind of virtio devices do they support, and then
>  remoteproc will add those devices. This makes it possible to reuse the
> diff --git a/Documentation/rpmsg.txt b/Documentation/staging/rpmsg.rst
> similarity index 100%
> rename from Documentation/rpmsg.txt
> rename to Documentation/staging/rpmsg.rst
> diff --git a/Documentation/speculation.txt b/Documentation/staging/speculation.rst
> similarity index 97%
> rename from Documentation/speculation.txt
> rename to Documentation/staging/speculation.rst
> index 50d7ea857cff..8045d99bcf12 100644
> --- a/Documentation/speculation.txt
> +++ b/Documentation/staging/speculation.rst
> @@ -1,9 +1,11 @@
> +===========
> +Speculation
> +===========
> +
>  This document explains potential effects of speculation, and how undesirable
>  effects can be mitigated portably using common APIs.
>  
> -===========
> -Speculation
> -===========
> +------------------------------------------------------------------------------
>  
>  To improve performance and minimize average latencies, many contemporary CPUs
>  employ speculative execution techniques such as branch prediction, performing
> diff --git a/Documentation/static-keys.txt b/Documentation/staging/static-keys.rst
> similarity index 100%
> rename from Documentation/static-keys.txt
> rename to Documentation/staging/static-keys.rst
> diff --git a/Documentation/tee.txt b/Documentation/staging/tee.rst
> similarity index 99%
> rename from Documentation/tee.txt
> rename to Documentation/staging/tee.rst
> index c8fad81c4563..324604a15d17 100644
> --- a/Documentation/tee.txt
> +++ b/Documentation/staging/tee.rst
> @@ -162,6 +162,7 @@ The AMD-TEE driver packages the command buffer payload for processing in TEE.
>  The command buffer format for the different TEE commands can be found in [7].
>  
>  The TEE commands supported by AMD-TEE Trusted OS are:
> +
>  * TEE_CMD_ID_LOAD_TA          - loads a Trusted Application (TA) binary into
>                                  TEE environment.
>  * TEE_CMD_ID_UNLOAD_TA        - unloads TA binary from TEE environment.
> diff --git a/Documentation/xz.txt b/Documentation/staging/xz.rst
> similarity index 100%
> rename from Documentation/xz.txt
> rename to Documentation/staging/xz.rst
> diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst
> index cc4c5fc313df..c1709165c553 100644
> --- a/Documentation/trace/kprobetrace.rst
> +++ b/Documentation/trace/kprobetrace.rst
> @@ -40,7 +40,7 @@ Synopsis of kprobe_events
>   MEMADDR	: Address where the probe is inserted.
>   MAXACTIVE	: Maximum number of instances of the specified function that
>  		  can be probed simultaneously, or 0 for the default value
> -		  as defined in Documentation/kprobes.txt section 1.3.1.
> +		  as defined in Documentation/staging/kprobes.rst section 1.3.1.
>  
>   FETCHARGS	: Arguments. Each probe can have up to 128 args.
>    %REG		: Fetch register REG
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 805309399939..4c9814ee2fdb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9597,7 +9597,7 @@ M:	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
>  M:	"David S. Miller" <davem@davemloft.net>
>  M:	Masami Hiramatsu <mhiramat@kernel.org>
>  S:	Maintained
> -F:	Documentation/kprobes.txt
> +F:	Documentation/staging/kprobes.rst
>  F:	include/asm-generic/kprobes.h
>  F:	include/linux/kprobes.h
>  F:	kernel/kprobes.c
> @@ -14500,7 +14500,7 @@ S:	Maintained
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git rproc-next
>  F:	Documentation/ABI/testing/sysfs-class-remoteproc
>  F:	Documentation/devicetree/bindings/remoteproc/
> -F:	Documentation/remoteproc.txt
> +F:	Documentation/staging/remoteproc.rst
>  F:	drivers/remoteproc/
>  F:	include/linux/remoteproc.h
>  F:	include/linux/remoteproc/
> @@ -14512,7 +14512,7 @@ L:	linux-remoteproc@vger.kernel.org
>  S:	Maintained
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git rpmsg-next
>  F:	Documentation/ABI/testing/sysfs-bus-rpmsg
> -F:	Documentation/rpmsg.txt
> +F:	Documentation/staging/rpmsg.rst
>  F:	drivers/rpmsg/
>  F:	include/linux/rpmsg.h
>  F:	include/linux/rpmsg/
> @@ -16761,7 +16761,7 @@ TEE SUBSYSTEM
>  M:	Jens Wiklander <jens.wiklander@linaro.org>
>  L:	tee-dev@lists.linaro.org
>  S:	Maintained
> -F:	Documentation/tee.txt
> +F:	Documentation/staging/tee.rst
>  F:	drivers/tee/
>  F:	include/linux/tee_drv.h
>  F:	include/uapi/linux/tee.h
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index 3526c0aee954..32809624d422 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -68,7 +68,7 @@
>   * Lacking toolchain and or architecture support, static keys fall back to a
>   * simple conditional branch.
>   *
> - * Additional babbling in: Documentation/static-keys.txt
> + * Additional babbling in: Documentation/staging/static-keys.rst
>   */
>  
>  #ifndef __ASSEMBLY__
> diff --git a/lib/crc32.c b/lib/crc32.c
> index 4a20455d1f61..35a03d03f973 100644
> --- a/lib/crc32.c
> +++ b/lib/crc32.c
> @@ -24,7 +24,7 @@
>   * Version 2.  See the file COPYING for more details.
>   */
>  
> -/* see: Documentation/crc32.txt for a description of algorithms */
> +/* see: Documentation/staging/crc32.rst for a description of algorithms */
>  
>  #include <linux/crc32.h>
>  #include <linux/crc32poly.h>
> diff --git a/lib/lzo/lzo1x_decompress_safe.c b/lib/lzo/lzo1x_decompress_safe.c
> index 2717c7963acd..7892a40cf765 100644
> --- a/lib/lzo/lzo1x_decompress_safe.c
> +++ b/lib/lzo/lzo1x_decompress_safe.c
> @@ -32,7 +32,7 @@
>   * depending on the base count. Since the base count is taken from a u8
>   * and a few bits, it is safe to assume that it will always be lower than
>   * or equal to 2*255, thus we can always prevent any overflow by accepting
> - * two less 255 steps. See Documentation/lzo.txt for more information.
> + * two less 255 steps. See Documentation/staging/lzo.rst for more information.
>   */
>  #define MAX_255_COUNT      ((((size_t)~0) / 255) - 2)
>  
> diff --git a/lib/xz/Kconfig b/lib/xz/Kconfig
> index 22528743d4ce..5cb50245a878 100644
> --- a/lib/xz/Kconfig
> +++ b/lib/xz/Kconfig
> @@ -5,7 +5,7 @@ config XZ_DEC
>  	help
>  	  LZMA2 compression algorithm and BCJ filters are supported using
>  	  the .xz file format as the container. For integrity checking,
> -	  CRC32 is supported. See Documentation/xz.txt for more information.
> +	  CRC32 is supported. See Documentation/staging/xz.rst for more information.
>  
>  if XZ_DEC
>  
> diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
> index 501911d1b327..240f2435ce6f 100644
> --- a/samples/kprobes/kprobe_example.c
> +++ b/samples/kprobes/kprobe_example.c
> @@ -5,7 +5,7 @@
>   * stack trace and selected registers when _do_fork() is called.
>   *
>   * For more information on theory of operation of kprobes, see
> - * Documentation/kprobes.txt
> + * Documentation/staging/kprobes.rst
>   *
>   * You will see the trace data in /var/log/messages and on the console
>   * whenever _do_fork() is invoked to create a new process.
> diff --git a/samples/kprobes/kretprobe_example.c b/samples/kprobes/kretprobe_example.c
> index 013e8e6ebae9..78a2da6fb3cd 100644
> --- a/samples/kprobes/kretprobe_example.c
> +++ b/samples/kprobes/kretprobe_example.c
> @@ -11,7 +11,7 @@
>   * If no func_name is specified, _do_fork is instrumented
>   *
>   * For more information on theory of operation of kretprobes, see
> - * Documentation/kprobes.txt
> + * Documentation/staging/kprobes.rst
>   *
>   * Build and insert the kernel module as done in the kprobe example.
>   * You will see the trace data in /var/log/messages and on the console
> -- 
> 2.26.2
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH 20/22] docs: move remaining stuff under Documentation/*.txt to Documentation/staging

[Mathieu Poirier]

Hi Mauro,

On Mon, 15 Jun 2020 at 00:51, Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> There are several files that I was unable to find a proper place
> for them, and 3 ones that are still in plain old text format.
>
> Let's place those stuff behind the carpet, as we'd like to keep the
> root directory clean.
>
> We can later discuss and move those into better places.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/index.rst                       | 13 ++++++++
>  .../{crc32.txt => staging/crc32.rst}          |  0
>  Documentation/staging/index.rst               | 32 +++++++++++++++++++
>  .../{kprobes.txt => staging/kprobes.rst}      |  0
>  Documentation/{lzo.txt => staging/lzo.rst}    |  0
>  .../remoteproc.rst}                           |  2 +-
>  .../{rpmsg.txt => staging/rpmsg.rst}          |  0

For remoteproc.rst and rpmsg.rst, I suggest moving them under a new
"remoteproc" directory.

Thanks,
Mathieu

>  .../speculation.rst}                          |  8 +++--
>  .../static-keys.rst}                          |  0
>  Documentation/{tee.txt => staging/tee.rst}    |  1 +
>  Documentation/{xz.txt => staging/xz.rst}      |  0
>  Documentation/trace/kprobetrace.rst           |  2 +-
>  MAINTAINERS                                   |  8 ++---
>  include/linux/jump_label.h                    |  2 +-
>  lib/crc32.c                                   |  2 +-
>  lib/lzo/lzo1x_decompress_safe.c               |  2 +-
>  lib/xz/Kconfig                                |  2 +-
>  samples/kprobes/kprobe_example.c              |  2 +-
>  samples/kprobes/kretprobe_example.c           |  2 +-
>  19 files changed, 63 insertions(+), 15 deletions(-)
>  rename Documentation/{crc32.txt => staging/crc32.rst} (100%)
>  create mode 100644 Documentation/staging/index.rst
>  rename Documentation/{kprobes.txt => staging/kprobes.rst} (100%)
>  rename Documentation/{lzo.txt => staging/lzo.rst} (100%)
>  rename Documentation/{remoteproc.txt => staging/remoteproc.rst} (99%)
>  rename Documentation/{rpmsg.txt => staging/rpmsg.rst} (100%)
>  rename Documentation/{speculation.txt => staging/speculation.rst} (97%)
>  rename Documentation/{static-keys.txt => staging/static-keys.rst} (100%)
>  rename Documentation/{tee.txt => staging/tee.rst} (99%)
>  rename Documentation/{xz.txt => staging/xz.rst} (100%)
>
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index 71eca3171574..3b491af0122d 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -182,6 +182,19 @@ subprojects.
>
>     filesystems/ext4/index
>
> +Other documentation
> +-------------------
> +
> +There are several unsorted documents that don't seem to fit on other parts
> +of the documentation body, or may require some adjustments and/or conversion
> +to ReStructured Text format, or are simply too old.
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   staging/index
> +
> +
>  Translations
>  ------------
>
> diff --git a/Documentation/crc32.txt b/Documentation/staging/crc32.rst
> similarity index 100%
> rename from Documentation/crc32.txt
> rename to Documentation/staging/crc32.rst
> diff --git a/Documentation/staging/index.rst b/Documentation/staging/index.rst
> new file mode 100644
> index 000000000000..8e98517675ca
> --- /dev/null
> +++ b/Documentation/staging/index.rst
> @@ -0,0 +1,32 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Unsorted Documentation
> +======================
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   crc32
> +   kprobes
> +   lzo
> +   remoteproc
> +   rpmsg
> +   speculation
> +   static-keys
> +   tee
> +   xz
> +
> +Atomic Types
> +============
> +
> +.. literalinclude:: ../atomic_t.txt
> +
> +Atomic bitops
> +=============
> +
> +.. literalinclude:: ../atomic_bitops.txt
> +
> +Memory Barriers
> +===============
> +
> +.. literalinclude:: ../memory-barriers.txt
> diff --git a/Documentation/kprobes.txt b/Documentation/staging/kprobes.rst
> similarity index 100%
> rename from Documentation/kprobes.txt
> rename to Documentation/staging/kprobes.rst
> diff --git a/Documentation/lzo.txt b/Documentation/staging/lzo.rst
> similarity index 100%
> rename from Documentation/lzo.txt
> rename to Documentation/staging/lzo.rst
> diff --git a/Documentation/remoteproc.txt b/Documentation/staging/remoteproc.rst
> similarity index 99%
> rename from Documentation/remoteproc.txt
> rename to Documentation/staging/remoteproc.rst
> index 2be1147256e0..9cccd3dd6a4b 100644
> --- a/Documentation/remoteproc.txt
> +++ b/Documentation/staging/remoteproc.rst
> @@ -22,7 +22,7 @@ for remote processors that supports this kind of communication. This way,
>  platform-specific remoteproc drivers only need to provide a few low-level
>  handlers, and then all rpmsg drivers will then just work
>  (for more information about the virtio-based rpmsg bus and its drivers,
> -please read Documentation/rpmsg.txt).
> +please read Documentation/staging/rpmsg.rst).
>  Registration of other types of virtio devices is now also possible. Firmwares
>  just need to publish what kind of virtio devices do they support, and then
>  remoteproc will add those devices. This makes it possible to reuse the
> diff --git a/Documentation/rpmsg.txt b/Documentation/staging/rpmsg.rst
> similarity index 100%
> rename from Documentation/rpmsg.txt
> rename to Documentation/staging/rpmsg.rst
> diff --git a/Documentation/speculation.txt b/Documentation/staging/speculation.rst
> similarity index 97%
> rename from Documentation/speculation.txt
> rename to Documentation/staging/speculation.rst
> index 50d7ea857cff..8045d99bcf12 100644
> --- a/Documentation/speculation.txt
> +++ b/Documentation/staging/speculation.rst
> @@ -1,9 +1,11 @@
> +===========
> +Speculation
> +===========
> +
>  This document explains potential effects of speculation, and how undesirable
>  effects can be mitigated portably using common APIs.
>
> -===========
> -Speculation
> -===========
> +------------------------------------------------------------------------------
>
>  To improve performance and minimize average latencies, many contemporary CPUs
>  employ speculative execution techniques such as branch prediction, performing
> diff --git a/Documentation/static-keys.txt b/Documentation/staging/static-keys.rst
> similarity index 100%
> rename from Documentation/static-keys.txt
> rename to Documentation/staging/static-keys.rst
> diff --git a/Documentation/tee.txt b/Documentation/staging/tee.rst
> similarity index 99%
> rename from Documentation/tee.txt
> rename to Documentation/staging/tee.rst
> index c8fad81c4563..324604a15d17 100644
> --- a/Documentation/tee.txt
> +++ b/Documentation/staging/tee.rst
> @@ -162,6 +162,7 @@ The AMD-TEE driver packages the command buffer payload for processing in TEE.
>  The command buffer format for the different TEE commands can be found in [7].
>
>  The TEE commands supported by AMD-TEE Trusted OS are:
> +
>  * TEE_CMD_ID_LOAD_TA          - loads a Trusted Application (TA) binary into
>                                  TEE environment.
>  * TEE_CMD_ID_UNLOAD_TA        - unloads TA binary from TEE environment.
> diff --git a/Documentation/xz.txt b/Documentation/staging/xz.rst
> similarity index 100%
> rename from Documentation/xz.txt
> rename to Documentation/staging/xz.rst
> diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst
> index cc4c5fc313df..c1709165c553 100644
> --- a/Documentation/trace/kprobetrace.rst
> +++ b/Documentation/trace/kprobetrace.rst
> @@ -40,7 +40,7 @@ Synopsis of kprobe_events
>   MEMADDR       : Address where the probe is inserted.
>   MAXACTIVE     : Maximum number of instances of the specified function that
>                   can be probed simultaneously, or 0 for the default value
> -                 as defined in Documentation/kprobes.txt section 1.3.1.
> +                 as defined in Documentation/staging/kprobes.rst section 1.3.1.
>
>   FETCHARGS     : Arguments. Each probe can have up to 128 args.
>    %REG         : Fetch register REG
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 805309399939..4c9814ee2fdb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9597,7 +9597,7 @@ M:        Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
>  M:     "David S. Miller" <davem@davemloft.net>
>  M:     Masami Hiramatsu <mhiramat@kernel.org>
>  S:     Maintained
> -F:     Documentation/kprobes.txt
> +F:     Documentation/staging/kprobes.rst
>  F:     include/asm-generic/kprobes.h
>  F:     include/linux/kprobes.h
>  F:     kernel/kprobes.c
> @@ -14500,7 +14500,7 @@ S:      Maintained
>  T:     git git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git rproc-next
>  F:     Documentation/ABI/testing/sysfs-class-remoteproc
>  F:     Documentation/devicetree/bindings/remoteproc/
> -F:     Documentation/remoteproc.txt
> +F:     Documentation/staging/remoteproc.rst
>  F:     drivers/remoteproc/
>  F:     include/linux/remoteproc.h
>  F:     include/linux/remoteproc/
> @@ -14512,7 +14512,7 @@ L:      linux-remoteproc@vger.kernel.org
>  S:     Maintained
>  T:     git git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git rpmsg-next
>  F:     Documentation/ABI/testing/sysfs-bus-rpmsg
> -F:     Documentation/rpmsg.txt
> +F:     Documentation/staging/rpmsg.rst
>  F:     drivers/rpmsg/
>  F:     include/linux/rpmsg.h
>  F:     include/linux/rpmsg/
> @@ -16761,7 +16761,7 @@ TEE SUBSYSTEM
>  M:     Jens Wiklander <jens.wiklander@linaro.org>
>  L:     tee-dev@lists.linaro.org
>  S:     Maintained
> -F:     Documentation/tee.txt
> +F:     Documentation/staging/tee.rst
>  F:     drivers/tee/
>  F:     include/linux/tee_drv.h
>  F:     include/uapi/linux/tee.h
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index 3526c0aee954..32809624d422 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -68,7 +68,7 @@
>   * Lacking toolchain and or architecture support, static keys fall back to a
>   * simple conditional branch.
>   *
> - * Additional babbling in: Documentation/static-keys.txt
> + * Additional babbling in: Documentation/staging/static-keys.rst
>   */
>
>  #ifndef __ASSEMBLY__
> diff --git a/lib/crc32.c b/lib/crc32.c
> index 4a20455d1f61..35a03d03f973 100644
> --- a/lib/crc32.c
> +++ b/lib/crc32.c
> @@ -24,7 +24,7 @@
>   * Version 2.  See the file COPYING for more details.
>   */
>
> -/* see: Documentation/crc32.txt for a description of algorithms */
> +/* see: Documentation/staging/crc32.rst for a description of algorithms */
>
>  #include <linux/crc32.h>
>  #include <linux/crc32poly.h>
> diff --git a/lib/lzo/lzo1x_decompress_safe.c b/lib/lzo/lzo1x_decompress_safe.c
> index 2717c7963acd..7892a40cf765 100644
> --- a/lib/lzo/lzo1x_decompress_safe.c
> +++ b/lib/lzo/lzo1x_decompress_safe.c
> @@ -32,7 +32,7 @@
>   * depending on the base count. Since the base count is taken from a u8
>   * and a few bits, it is safe to assume that it will always be lower than
>   * or equal to 2*255, thus we can always prevent any overflow by accepting
> - * two less 255 steps. See Documentation/lzo.txt for more information.
> + * two less 255 steps. See Documentation/staging/lzo.rst for more information.
>   */
>  #define MAX_255_COUNT      ((((size_t)~0) / 255) - 2)
>
> diff --git a/lib/xz/Kconfig b/lib/xz/Kconfig
> index 22528743d4ce..5cb50245a878 100644
> --- a/lib/xz/Kconfig
> +++ b/lib/xz/Kconfig
> @@ -5,7 +5,7 @@ config XZ_DEC
>         help
>           LZMA2 compression algorithm and BCJ filters are supported using
>           the .xz file format as the container. For integrity checking,
> -         CRC32 is supported. See Documentation/xz.txt for more information.
> +         CRC32 is supported. See Documentation/staging/xz.rst for more information.
>
>  if XZ_DEC
>
> diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
> index 501911d1b327..240f2435ce6f 100644
> --- a/samples/kprobes/kprobe_example.c
> +++ b/samples/kprobes/kprobe_example.c
> @@ -5,7 +5,7 @@
>   * stack trace and selected registers when _do_fork() is called.
>   *
>   * For more information on theory of operation of kprobes, see
> - * Documentation/kprobes.txt
> + * Documentation/staging/kprobes.rst
>   *
>   * You will see the trace data in /var/log/messages and on the console
>   * whenever _do_fork() is invoked to create a new process.
> diff --git a/samples/kprobes/kretprobe_example.c b/samples/kprobes/kretprobe_example.c
> index 013e8e6ebae9..78a2da6fb3cd 100644
> --- a/samples/kprobes/kretprobe_example.c
> +++ b/samples/kprobes/kretprobe_example.c
> @@ -11,7 +11,7 @@
>   * If no func_name is specified, _do_fork is instrumented
>   *
>   * For more information on theory of operation of kretprobes, see
> - * Documentation/kprobes.txt
> + * Documentation/staging/kprobes.rst
>   *
>   * Build and insert the kernel module as done in the kprobe example.
>   * You will see the trace data in /var/log/messages and on the console
> --
> 2.26.2
>

[PATCH 21/22] docs: staging: don't use literalinclude

[Mauro Carvalho Chehab]

Such directive cause troubles with PDF output.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/staging/index.rst | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/staging/index.rst b/Documentation/staging/index.rst
index 8e98517675ca..8cc9d94b0a13 100644
--- a/Documentation/staging/index.rst
+++ b/Documentation/staging/index.rst
@@ -19,14 +19,17 @@ Unsorted Documentation
 Atomic Types
 ============
 
-.. literalinclude:: ../atomic_t.txt
+.. include:: ../atomic_t.txt
+   :literal:
 
 Atomic bitops
 =============
 
-.. literalinclude:: ../atomic_bitops.txt
+.. include:: ../atomic_bitops.txt
+   :literal:
 
 Memory Barriers
 ===============
 
-.. literalinclude:: ../memory-barriers.txt
+.. include:: ../memory-barriers.txt
+   :literal:
-- 
2.26.2

[PATCH 22/22] docs: staging: use small font for literal includes

[Mauro Carvalho Chehab]

The normal font is too big to display 80 columns, causing extra
breaks to be added at weird places.

change to the footnotesize, as this would fit a little bit
better.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/staging/index.rst | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/staging/index.rst b/Documentation/staging/index.rst
index 8cc9d94b0a13..184e6aece0a7 100644
--- a/Documentation/staging/index.rst
+++ b/Documentation/staging/index.rst
@@ -19,17 +19,41 @@ Unsorted Documentation
 Atomic Types
 ============
 
+.. raw:: latex
+
+    \footnotesize
+
 .. include:: ../atomic_t.txt
    :literal:
 
+.. raw:: latex
+
+    \normalsize
+
 Atomic bitops
 =============
 
+.. raw:: latex
+
+    \footnotesize
+
 .. include:: ../atomic_bitops.txt
    :literal:
 
+.. raw:: latex
+
+    \normalsize
+
 Memory Barriers
 ===============
 
+.. raw:: latex
+
+    \footnotesize
+
 .. include:: ../memory-barriers.txt
    :literal:
+
+.. raw:: latex
+
+    \normalsize
-- 
2.26.2

Re: [PATCH 22/22] docs: staging: use small font for literal includes

[Jonathan Corbet]

On Mon, 15 Jun 2020 08:50:27 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> The normal font is too big to display 80 columns, causing extra
> breaks to be added at weird places.
> 
> change to the footnotesize, as this would fit a little bit
> better.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/staging/index.rst | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/Documentation/staging/index.rst b/Documentation/staging/index.rst
> index 8cc9d94b0a13..184e6aece0a7 100644
> --- a/Documentation/staging/index.rst
> +++ b/Documentation/staging/index.rst
> @@ -19,17 +19,41 @@ Unsorted Documentation
>  Atomic Types
>  ============
>  
> +.. raw:: latex
> +
> +    \footnotesize

Is there really no way we can avoid this?  Adding latex markup to RST docs
certainly is not a way to make them prettier...

Thanks,

jon