Merge tag 'efi-2026-01-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2026-01-rc1-2

CI:

* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28024

Documentation:

* develop: virtio: Fix qemu example (true/false -> on/off)
* separate read and write command documentation
* usage: Add general rule for `$?`
* askenv: Reword and remove return value
* seama: Reword return value section
* usage: Use glob for all commands
* Fix typos and formatting

UEFI:

* console: support editable input fields

5 files changed, 7 insertions, 7 deletions

diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index c25b98683f8..634114af59a 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -288,7 +288,7 @@ The full devicetree is available to U-Boot proper, but normally only a subset
 Using several DTBs in the SPL (SPL_MULTI_DTB_FIT Kconfig option)
 ----------------------------------------------------------------
 In some rare cases it is desirable to let SPL be able to select one DTB among
-many. This usually not very useful as the DTB for the SPL is small and usually
+many. This is usually not very useful as the DTB for the SPL is small and usually
 fits several platforms. However the DTB sometimes include information that do
 work on several platforms (like IO tuning parameters).
 In this case it is possible to use SPL_MULTI_DTB_FIT Kconfig option. This option
diff --git a/doc/develop/driver-model/fdt-fixup.rst b/doc/develop/driver-model/fdt-fixup.rst
index 974c09031ed..b547daf79ff 100644
--- a/doc/develop/driver-model/fdt-fixup.rst
+++ b/doc/develop/driver-model/fdt-fixup.rst
@@ -45,7 +45,7 @@ An additional problem with the device tree in U-Boot is that it is read-only,
 and the current mechanisms don't allow easy manipulation of the device tree
 after the driver model has been initialized. While migrating to a live device
 tree (at least after the relocation) would greatly simplify the solution of
-this problem, it is a non-negligible task to implement it, an a interim
+this problem, it is a non-negligible task to implement it, an ad interim
 solution is needed to address the problem at least in the medium-term.
 
 Hence, we propose a solution to this problem by offering a board-specific
diff --git a/doc/develop/driver-model/virtio.rst b/doc/develop/driver-model/virtio.rst
index 31b94d04675..9a5e3240c3c 100644
--- a/doc/develop/driver-model/virtio.rst
+++ b/doc/develop/driver-model/virtio.rst
@@ -118,9 +118,9 @@ By default QEMU creates VirtIO legacy devices by default. To create non-legacy
 
   $ qemu-system-i386 -nographic -bios u-boot.rom \
     -netdev tap,ifname=tap0,id=net0 \
-    -device virtio-net-pci,netdev=net0,disable-legacy=true,disable-modern=false \
+    -device virtio-net-pci,netdev=net0,disable-legacy=on,disable-modern=off \
     -drive if=none,file=test.img,format=raw,id=hd0 \
-    -device virtio-blk-pci,drive=hd0,disable-legacy=true,disable-modern=false
+    -device virtio-blk-pci,drive=hd0,disable-legacy=on,disable-modern=off
 
 A 'virtio' command is provided in U-Boot shell.
 
diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst
index aa7786c99fd..3a2b496fa00 100644
--- a/doc/develop/testing.rst
+++ b/doc/develop/testing.rst
@@ -28,7 +28,7 @@ run. Type this::
 
     make tcheck
 
-You can also run a selection tests in parallel with::
+You can also run a selection of tests in parallel with::
 
     make pcheck
 
@@ -39,7 +39,7 @@ are run. See :doc:`pytest/usage` for more information.
 Sandbox
 -------
 U-Boot can be built as a user-space application (e.g. for Linux). This
-allows test to be executed without needing target hardware. The 'sandbox'
+allows tests to be executed without needing target hardware. The 'sandbox'
 target provides this feature and it is widely used in tests.
 
 See :doc:`tests_sandbox` for more information.
diff --git a/doc/develop/trace.rst b/doc/develop/trace.rst
index d3c8628d124..16635d6d238 100644
--- a/doc/develop/trace.rst
+++ b/doc/develop/trace.rst
@@ -354,7 +354,7 @@ Writing Out Trace Data
 ----------------------
 
 Once the trace data is in an output buffer in memory there are various ways
-to transmit it to the host. Notably you can use tftput to send the data
+to transmit it to the host. Notably you can use tftpput to send the data
 over a network link::
 
     fakegocmd=trace pause; usb start; set autoload n; bootp;