Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 8 May 2023 21:13:05 +0700
From:   Bagas Sanjaya <bagasdotme@gmail.com>
To:     Randy Dunlap <rdunlap@infradead.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc:     Grant Likely <grant.likely@linaro.org>, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Linux Doc Mailing List <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v2] docs: dt: Make references and mention kernel
 abstractions
Message-ID: <ZFkDce5ISNEu6nsp@debian.me>
References: <20230505-dt-docs-refresh-v2-1-56bf359c53b4@linaro.org>
 <4b0249cd-7538-6df4-777b-d25a72f06668@infradead.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="xOniEH0+SQaTVZrU"
Content-Disposition: inline
In-Reply-To: <4b0249cd-7538-6df4-777b-d25a72f06668@infradead.org>
Precedence: bulk


--xOniEH0+SQaTVZrU
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, May 06, 2023 at 03:09:11PM -0700, Randy Dunlap wrote:
> For @linux-doc: Is there something in ReST that does auto section numberi=
ng
> so that this renumbering does not have to be repeated in the future?
>=20

There is sectnum:: directive which does the job. In the kernel docs,
however, it is customarily used together with contents:: directive to
generate toctree for current doc. In order for this to work as expected,
you need also to rearrange section heading levels, like:

---- >8 ----
diff --git a/Documentation/devicetree/usage-model.rst b/Documentation/devic=
etree/usage-model.rst
index 87f522d5feba81..890dde293540f9 100644
--- a/Documentation/devicetree/usage-model.rst
+++ b/Documentation/devicetree/usage-model.rst
@@ -1,5 +1,8 @@
 .. SPDX-License-Identifier: GPL-2.0
=20
+.. contents::
+.. sectnum::
+
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Linux and the Devicetree
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
@@ -76,7 +79,7 @@ If you haven't already read the Device Tree Usage\ [1]_ p=
age,
 then go read it now.  It's okay, I'll wait....
=20
 2.1 Linux Kernel Firmware Abstractions
---------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=20
 The Linux kernel supports several different hardware description
 frameworks and DT is just one of them. The closest sibling is the
@@ -112,7 +115,8 @@ resources to other devices in the DT, will need to impl=
ement calls into
 the DT abstractions.
=20
 2.2 High Level View
--------------------
+~~~~~~~~~~~~~~~~~~~
+
 The most important thing to understand is that the DT is simply a data
 structure that describes the hardware.  There is nothing magical about
 it, and it doesn't magically make all hardware configuration problems
@@ -134,7 +138,8 @@ Linux uses DT data for three major purposes:
 3) device population.
=20
 2.3 Platform Identification
----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 First and foremost, the kernel will use data in the DT to identify the
 specific machine.  In a perfect world, the specific platform shouldn't
 matter to the kernel because all platform details would be described
@@ -217,7 +222,8 @@ compatible list, and probably should be avoided for new=
 architecture
 support.
=20
 2.4 Runtime configuration
--------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
 In most cases, a DT will be the sole method of communicating data from
 firmware to the kernel, so also gets used to pass in runtime and
 configuration data like the kernel parameters string and the location
@@ -254,7 +260,8 @@ scanning of the device tree after selecting the correct=
 machine_desc
 that supports the board.
=20
 2.5 Device population
----------------------
+~~~~~~~~~~~~~~~~~~~~~
+
 After the board has been identified, and after the early configuration data
 has been parsed, then kernel initialization can proceed in the normal
 way.  At some point in this process, unflatten_device_tree() is called

The caveat is the title heading also get numbered, making it top-level
section. Hence, it is more appropriate if the directory toctree:: also
have :numbered: option to do the job instead:

---- >8 ----
diff --git a/Documentation/devicetree/index.rst b/Documentation/devicetree/=
index.rst
index 1a2fc80149966e..b5297dd511ef31 100644
--- a/Documentation/devicetree/index.rst
+++ b/Documentation/devicetree/index.rst
@@ -8,6 +8,7 @@ Kernel Devicetree Usage
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 .. toctree::
    :maxdepth: 1
+   :numbered:
=20
    usage-model
    of_unittest

Anyway, if you use auto section numbering, you need to also remove the manu=
al
numbers:

---- >8 ----
diff --git a/Documentation/devicetree/usage-model.rst b/Documentation/devic=
etree/usage-model.rst
index 0ff62cdb3cc51c..e2dfbcc38c2f03 100644
--- a/Documentation/devicetree/usage-model.rst
+++ b/Documentation/devicetree/usage-model.rst
@@ -42,8 +42,8 @@ incompatible, bindings for i2c busses that came about bec=
ause the new
 binding was created without first investigating how i2c devices were
 already being enumerated in existing systems.
=20
-1. History
-----------
+History
+-------
 The DT was originally created by Open Firmware as part of the
 communication method for passing data from Open Firmware to a client
 program (like to an operating system).  An operating system used the
@@ -72,13 +72,13 @@ all architectures.  At the time of this writing, 6 main=
lined
 architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1
 out of mainline (nios) have some level of DT support.
=20
-2. Data Model
--------------
+Data Model
+----------
 If you haven't already read the Device Tree Usage\ [1]_ page,
 then go read it now.  It's okay, I'll wait....
=20
-2.1 Linux Kernel Firmware Abstractions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Linux Kernel Firmware Abstractions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=20
 The Linux kernel supports several different hardware description
 frameworks and DT is just one of them. The closest sibling is the
@@ -113,8 +113,8 @@ detected devices using the device tree, or that want to=
 provide
 resources to other devices in the DT, will need to implement calls into
 the DT abstractions.
=20
-2.2 High Level View
-~~~~~~~~~~~~~~~~~~~
+High Level View
+~~~~~~~~~~~~~~~
=20
 The most important thing to understand is that the DT is simply a data
 structure that describes the hardware.  There is nothing magical about
@@ -136,8 +136,8 @@ Linux uses DT data for three major purposes:
 2) runtime configuration, and
 3) device population.
=20
-2.3 Platform Identification
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Platform Identification
+~~~~~~~~~~~~~~~~~~~~~~~
=20
 First and foremost, the kernel will use data in the DT to identify the
 specific machine.  In a perfect world, the specific platform shouldn't
@@ -220,8 +220,8 @@ However, this approach does not take into account the p=
riority of the
 compatible list, and probably should be avoided for new architecture
 support.
=20
-2.4 Runtime configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~
+Runtime configuration
+~~~~~~~~~~~~~~~~~~~~~
=20
 In most cases, a DT will be the sole method of communicating data from
 firmware to the kernel, so also gets used to pass in runtime and
@@ -258,8 +258,8 @@ On ARM, the function setup_machine_fdt() is responsible=
 for early
 scanning of the device tree after selecting the correct machine_desc
 that supports the board.
=20
-2.5 Device population
-~~~~~~~~~~~~~~~~~~~~~
+Device population
+~~~~~~~~~~~~~~~~~
=20
 After the board has been identified, and after the early configuration data
 has been parsed, then kernel initialization can proceed in the normal

Thanks.

--=20
An old man doll... just what I always wanted! - Clara

--xOniEH0+SQaTVZrU
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCZFkDagAKCRD2uYlJVVFO
oysPAQDxWkP3fxh7R+TWnA4ynuNz9UlgQ7SMY9jzck+htYXc2QEA2U4yeZYXribV
zay6/Xfm83+oep4xtcG9V6g3cXkfgAo=
=KKzX
-----END PGP SIGNATURE-----

--xOniEH0+SQaTVZrU--