7 files changed, 103 insertions, 42 deletions
diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
index fa3cd6aec82..bc18b2ebb7b 100644
--- a/doc/develop/codingstyle.rst
+++ b/doc/develop/codingstyle.rst
@@ -154,6 +154,73 @@ See `here
 <https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation>`_
 for style.
 
+Conditional Compilation
+-----------------------
+
+Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c
+files; doing so makes code harder to read and logic harder to follow.  Instead,
+use such conditionals in a header file defining functions for use in those .c
+files, providing no-op stub versions in the #else case, and then call those
+functions unconditionally from .c files.  The compiler will avoid generating
+any code for the stub calls, producing identical results, but the logic will
+remain easy to follow.
+
+Prefer to compile out entire functions, rather than portions of functions or
+portions of expressions.  Rather than putting an ifdef in an expression, factor
+out part or all of the expression into a separate helper function and apply the
+conditional to that function.
+
+If you have a function or variable which may potentially go unused in a
+particular configuration, and the compiler would warn about its definition
+going unused, mark the definition as __maybe_unused rather than wrapping it in
+a preprocessor conditional.  (However, if a function or variable *always* goes
+unused, delete it.)
+
+Within code, where possible, use the IS_ENABLED macro to convert a Kconfig
+symbol into a C boolean expression, and use it in a normal C conditional:
+
+.. code-block:: c
+
+	if (IS_ENABLED(CONFIG_SOMETHING)) {
+		...
+	}
+
+The compiler will constant-fold the conditional away, and include or exclude
+the block of code just as with an #ifdef, so this will not add any runtime
+overhead.  However, this approach still allows the C compiler to see the code
+inside the block, and check it for correctness (syntax, types, symbol
+references, etc).  Thus, you still have to use an #ifdef if the code inside the
+block references symbols that will not exist if the condition is not met.
+
+When working with xPL (see :doc:`spl` for more information) we need to take
+further care to use the right macro. In the case where a symbol may be
+referenced with an xPL-specific Kconfig symbol, use the CONFIG_IS_ENABLED macro
+instead, in a similar manner:
+
+.. code-block:: c
+
+	if (CONIG_IS_ENABLED(SOMETHING)) {
+		...
+	}
+
+When dealing with a Kconfig symbol that has both a normal name and one or more
+xPL-prefixed names, the Makefile needs special consideration as well. The
+PHASE\_ macro helps us in this situation thusly:
+
+.. code-block:: make
+
+        obj-$(CONFIG_$(PHASE_)SOMETHING) += something.o
+
+At the end of any non-trivial #if or #ifdef block (more than a few lines),
+place a comment after the #endif on the same line, noting the conditional
+expression used.  For instance:
+
+.. code-block:: c
+
+	#ifdef CONFIG_SOMETHING
+	...
+	#endif /* CONFIG_SOMETHING */
+
 Driver model
 ------------
 
diff --git a/doc/develop/devicetree/dt_qemu.rst b/doc/develop/devicetree/dt_qemu.rst
index 8ba2b225590..b452e2a997a 100644
--- a/doc/develop/devicetree/dt_qemu.rst
+++ b/doc/develop/devicetree/dt_qemu.rst
@@ -16,15 +16,22 @@ Obtaining the QEMU devicetree
 Where QEMU generates its own devicetree to pass to U-Boot you can use
 `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version.
 
-To obtain the devicetree that qemu generates, add `-machine dumpdtb=qemu.dtb`,
-e.g.::
-
-    qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb
-
-    qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
-
-    qemu-system-riscv64 -machine virt -machine dumpdtb=qemu.dtb
-
+To obtain the devicetree that QEMU generates, add `dumpdtb=qemu.dtb` to the
+`-machine` argument, e.g.
+
+.. code-block:: bash
+
+    qemu-system-aarch64 \
+      -machine virt,gic-version=3,dumpdtb=qemu.dtb \
+      -cpu cortex-a57 \
+      -smp 4 \
+      -memory 8G \
+      -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \
+      -tpmdev emulator,id=tpm0,chardev=chrtpm \
+      -device tpm-tis-device,tpmdev=tpm0
+
+Except for the dumpdtb=qemu.dtb sub-parameter use the same qemu-system-<arch>
+invocation that you would use to start U-Boot to to get a complete device-tree.
 
 Merging in U-Boot nodes/properties
 ----------------------------------
diff --git a/doc/develop/driver-model/design.rst b/doc/develop/driver-model/design.rst
index 30093737200..633545944d1 100644
--- a/doc/develop/driver-model/design.rst
+++ b/doc/develop/driver-model/design.rst
@@ -312,7 +312,7 @@ drivers/demo/demo-shape.c):
 		.name	= "demo_shape_drv",
 		.id	= UCLASS_DEMO,
 		.ops	= &shape_ops,
-		.priv_data_size = sizeof(struct shape_data),
+		.priv_auto = sizeof(struct shape_data),
 	};
 
 
diff --git a/doc/develop/py_testing.rst b/doc/develop/py_testing.rst
index 502053f09fc..217ae447035 100644
--- a/doc/develop/py_testing.rst
+++ b/doc/develop/py_testing.rst
@@ -69,19 +69,19 @@ To create disk images we have helper functions located in
 `test/py/tests/fs_helper.py` which shall be used in any tests that require
 creating disk images.
 
-Using `virtualenv` to provide requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Using a Python sandbox to provide requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The recommended way to run the test suite, in order to ensure reproducibility
-is to use `virtualenv` to set up the necessary environment.  This can be done
-via the following commands:
+is to use a Python sandbox such as `python -m venv` to set up the necessary
+environment.  This can be done via the following commands:
 
 
 .. code-block:: console
 
     $ cd /path/to/u-boot
-    $ sudo apt-get install python3 python3-virtualenv
-    $ virtualenv -p /usr/bin/python3 venv
+    $ sudo apt-get install python3 python3-venv
+    $ python3 -m venv venv
     $ . ./venv/bin/activate
     $ pip install -r test/py/requirements.txt
 
diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
index cbbc2bad0eb..73b354db94e 100644
--- a/doc/develop/release_cycle.rst
+++ b/doc/develop/release_cycle.rst
@@ -1,3 +1,5 @@
+.. |next_ver| replace:: v2025.07
+
 Release Cycle
 =============
 
@@ -53,13 +55,13 @@ Current Status
 
 * U-Boot v2025.04 was released on Monday, 07 April 2025.
 
-* The Merge Window for the next release (v2025.07) is **open** until the -rc1
+* The Merge Window for the next release (|next_ver|) was **closed** with the -rc1
   release on Monday, 28 April 2025.
 
 * The next branch is now **closed** until the -rc2 release on Monday, 12 May
   2025.
 
-* Release "v2025.07" is scheduled for Monday, 07 July 2025.
+* Release "|next_ver|" is scheduled for Monday, 07 July 2025.
 
 Future Releases
 ---------------
@@ -67,17 +69,17 @@ Future Releases
 .. The following commented out dates are for when release candidates are
    planned to be tagged.
 
-.. For the next scheduled release, release candidates were made on::
+For the next scheduled release, release candidates were made on::
 
-.. * U-Boot v2025.07-rc1 was released on Mon 21 April 2025.
+* U-Boot |next_ver|-rc1 was released on Mon 28 April 2025.
 
-.. * U-Boot v2025.07-rc2 was released on Mon 12 May 2025.
+.. * U-Boot |next_ver|-rc2 was released on Mon 12 May 2025.
 
-.. * U-Boot v2025.07-rc3 was released on Mon 26 May 2025.
+.. * U-Boot |next_ver|-rc3 was released on Mon 26 May 2025.
 
-.. * U-Boot v2025.07-rc4 was released on Mon 09 June 2025.
+.. * U-Boot |next_ver|-rc4 was released on Mon 09 June 2025.
 
-.. * U-Boot v2025.07-rc5 was released on Mon 23 June 2025.
+.. * U-Boot |next_ver|-rc5 was released on Mon 23 June 2025.
 
 Please note that the following dates are planned only and may be deviated from
 as needed.
diff --git a/doc/develop/tests_writing.rst b/doc/develop/tests_writing.rst
index 7ea17081def..f6f852c297d 100644
--- a/doc/develop/tests_writing.rst
+++ b/doc/develop/tests_writing.rst
@@ -309,15 +309,15 @@ an #ifdef since the suite will automatically be compiled out in that case.
 Finally, add the test to the build by adding to the Makefile in the same
 directory::
 
-  obj-$(CONFIG_$(XPL_)CMDLINE) += wibble.o
+  obj-$(CONFIG_$(PHASE_)CMDLINE) += wibble.o
 
 Note that CMDLINE is never enabled in SPL, so this test will only be present in
 U-Boot proper. See below for how to do SPL tests.
 
 You can add an extra Kconfig check if needed::
 
-  ifneq ($(CONFIG_$(XPL_)WIBBLE),)
-  obj-$(CONFIG_$(XPL_)CMDLINE) += wibble.o
+  ifneq ($(CONFIG_$(PHASE_)WIBBLE),)
+  obj-$(CONFIG_$(PHASE_)CMDLINE) += wibble.o
   endif
 
 Each suite can have an optional init and uninit function. These are run before
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 48d6110b2ad..3ca22b572a9 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -597,21 +597,6 @@ and used by the steps highlighted below.
       [--fit | --raw | --guid <guid-string] \
       <image_blob> <capsule_file_name>
 
-4. Insert the signature list into a device tree in the following format::
-
-    {
-            signature {
-                    capsule-key = [ <binary of signature list> ];
-            }
-            ...
-    }
-
-You can perform step-4 through the Kconfig symbol
-CONFIG_EFI_CAPSULE_CRT_FILE. This symbol points to the signing key
-generated in step-2. As part of U-Boot build, the ESL certificate file will
-be generated from the signing key and automatically get embedded into the
-platform's dtb.
-
 Anti-rollback Protection
 ************************