Merge tag 'doc-202510-rc6' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request doc-202510-rc6

CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/27807

* Update coding style to recommend b4 for patch submission
* pytest: Fix inline code and other formatting
* develop: fix grammar and syntax

Author: trini

doc/develop/codingstyle.rst

@@ -23,13 +23,55 @@ The following rules apply:
   <https://peps.python.org/pep-0008/>`_. Use `pylint
   <https://github.com/pylint-dev/pylint>`_ for checking the code.
 
-* Use patman to send your patches (``tools/patman/patman -H`` for full
-  instructions). With a few tags in your commits this will check your patches
-  and take care of emailing them.
+* Use the `b4 <https://git.kernel.org/pub/scm/utils/b4/b4.git/>`_ tool to prepare and
+  send your patches. b4 has become the preferred tool to sending patches for many
+  Linux kernel contributors, and U-Boot ships with a ready-to-use ``.b4-config`` that
+  targets ``[email protected]`` and integrates with ``scripts/get_maintainer.pl`` for
+  recipient discovery.
 
-* If you don't use patman, make sure to run ``scripts/checkpatch.pl``. For
-  more information, read :doc:`checkpatch`. Note that this should be done
-  *before* posting on the mailing list!
+  Start a topical series with ``b4 prep`` and keep the commits organised with
+  ``git rebase -i``. ``b4 prep --edit-cover`` opens an editor for the cover
+  letter, while ``b4 prep --auto-to-cc`` collects reviewers and maintainers from
+  both the configuration file and ``scripts/get_maintainer.pl``.
+
+  .. code-block:: bash
+
+     b4 prep -n mmc-fixes
+     git rebase -i origin/master
+     b4 prep --edit-cover
+     b4 prep --auto-to-cc
+
+  Run the style checks before sending. ``b4 prep --check`` wraps the existing
+  tooling so you see the output from ``scripts/checkpatch.pl`` alongside b4's
+  own validation. You can always invoke ``scripts/checkpatch.pl`` directly for
+  additional runs.
+
+  .. code-block:: bash
+
+     b4 prep --check
+
+  When the series is ready, use ``b4 send``. Begin with ``--dry-run`` to review
+  the generated emails and ``--reflect`` to copy yourself for records before
+  dispatching to ``[email protected]``.
+
+  .. code-block:: bash
+
+     b4 send --dry-run
+     b4 send --reflect
+     b4 send
+
+  After reviews arrive, collect Acked-by/Tested-by tags with ``b4 trailers -u``
+  and fold them into your commits before resending the updated series.
+
+  .. code-block:: bash
+
+     b4 trailers -u
+     git rebase -i origin/master
+     b4 send
+
+* Run ``scripts/checkpatch.pl`` directly or via ``b4 prep --check`` so that all
+  issues are resolved *before* posting on the mailing list. For more information,
+  read :doc:`checkpatch`.
 
 * Source files originating from different projects (for example the MTD
   subsystem or the hush shell code from the BusyBox project) may, after

doc/develop/devicetree/control.rst

@@ -79,7 +79,7 @@ regularly synced with the Linux kernel and hence no need for manual devicetree
 sync. You may find that the `dts/upstream/` already has a suitable devicetree
 file for your board. Look in `dts/upstream/src/<arch>/<vendor>`.
 
-If not you might find other boards with suitable files that you can
+If not, you might find other boards with suitable files that you can
 modify to your needs. Look in the board directories for files with a
 .dts extension.
 
@@ -98,7 +98,7 @@ Linux kernel release. To sync the `dts/upstream/` subtree, run::
 
     ./tools/update-subtree.sh pull dts <devicetree-rebasing-release-tag>
 
-If required it is also possible to cherry-pick fixes from the
+If required, it is also possible to cherry-pick fixes from the
 devicetree-rebasing repository prior to next sync, usage::
 
     ./tools/update-subtree.sh pick dts <devicetree-rebasing-commit-id>
@@ -192,7 +192,7 @@ With `dts/upstream` Git subtree, it is ensured that devicetree files in U-Boot
 are an exact copy of those in Linux kernel available under
 `dts/upstream/src/<arch>/<vendor>`.
 
-U-Boot is of course a very different project from Linux, e.g. it operates under
+U-Boot is, of course, a very different project from Linux, e.g. it operates under
 much more restrictive memory and code-size constraints. Where Linux may use a
 full clock driver with Common Clock Format (CCF) to find the input clock to the
 UART, U-Boot typically wants to output a banner as early as possible before too
@@ -212,7 +212,7 @@ order::
    <CONFIG_SYS_VENDOR>-u-boot.dtsi
    u-boot.dtsi
 
-Only one of these is selected but of course you can #include another one within
+Only one of these is selected, but, of course, you can #include another one within
 that file, to create a hierarchy of shared files.
 
 
@@ -309,8 +309,8 @@ Limitations
 Devicetrees can help reduce the complexity of supporting variants of boards
 which use the same SOC / CPU.
 
-However U-Boot is designed to build for a single architecture type and CPU
-type. So for example it is not possible to build a single ARM binary
+However, U-Boot is designed to build for a single architecture type and CPU
+type. So, for example, it is not possible to build a single ARM binary
 which runs on your AT91 and OMAP boards, relying on an fdt to configure
 the various features. This is because you must select one of
 the CPU families within arch/arm/cpu/arm926ejs (omap or at91) at build
@@ -328,7 +328,7 @@ files are pulled in, and the fdt controls *how* those files work.
 History
 -------
 
-U-Boot configuration was previous done using CONFIG options in the board
+U-Boot configuration was previously done using CONFIG options in the board
 config file. This eventually got out of hand with nearly 10,000 options.
 
 U-Boot adopted devicetrees around the same time as Linux and early boards