Merge tag v2023.07-rc4 into next

Signed-off-by: Tom Rini <trini@konsulko.com>

5 files changed, 19 insertions, 19 deletions

diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst
index 5dfa6cfce51..7a2a69fdfce 100644
--- a/doc/develop/bootstd.rst
+++ b/doc/develop/bootstd.rst
@@ -154,7 +154,7 @@ bootmeths
 This environment variable can be used to control the list of bootmeths used and
 their ordering for example::
 
-   setenv bootmeths "syslinux efi"
+   setenv bootmeths "extlinux efi"
 
 Entries may be removed or re-ordered in this list to affect the order the
 bootmeths are tried on each bootdev. If the variable is empty, the default
@@ -389,8 +389,8 @@ Configuration
 -------------
 
 Standard boot is enabled with `CONFIG_BOOTSTD`. Each bootmeth has its own CONFIG
-option also. For example, `CONFIG_BOOTMETH_DISTRO` enables support for distro
-boot from a disk.
+option also. For example, `CONFIG_BOOTMETH_EXTLINUX` enables support for
+booting from a disk using an `extlinux.conf` file.
 
 To enable all feature sof standard boot, use `CONFIG_BOOTSTD_FULL`. This
 includes the full set of commands, more error messages when things go wrong and
@@ -406,8 +406,8 @@ Available bootmeth drivers
 
 Bootmeth drivers are provided for:
 
-   - distro boot from a disk (syslinux)
-   - distro boot from a network (PXE)
+   - extlinux / syslinux boot from a disk
+   - extlinux boot from a network (PXE)
    - U-Boot scripts from disk, network or SPI flash
    - EFI boot using bootefi from disk
    - VBE
@@ -683,8 +683,8 @@ This feature can be added as needed. Note that sandbox is a special case, since
 in that case the host filesystem can be accessed even though the block device
 is NULL.
 
-If we take the example of the `bootmeth_distro` driver, this call ends up at
-`distro_read_bootflow()`. It has the filesystem ready, so tries various
+If we take the example of the `bootmeth_extlinux` driver, this call ends up at
+`extlinux_read_bootflow()`. It has the filesystem ready, so tries various
 filenames to try to find the `extlinux.conf` file, reading it if possible. If
 all goes well the bootflow ends up in the `BOOTFLOWST_READY` state.
 
@@ -697,12 +697,12 @@ the  `BOOTFLOWST_READY` state.
 
 That is the basic operation of scanning for bootflows. The process of booting a
 bootflow is handled by the bootmeth driver for that bootflow. In the case of
-distro boot, this parses and processes the `extlinux.conf` file that was read.
-See `distro_boot()` for how that works. The processing may involve reading
+extlinux boot, this parses and processes the `extlinux.conf` file that was read.
+See `extlinux_boot()` for how that works. The processing may involve reading
 additional files, which is handled by the `read_file()` method, which is
-`distro_read_file()` in this case. All bootmethds should support reading files,
-since the bootflow is typically only the basic instructions and does not include
-the operating system itself, ramdisk, device tree, etc.
+`extlinux_read_file()` in this case. All bootmethds should support reading
+files, since the bootflow is typically only the basic instructions and does not
+include the operating system itself, ramdisk, device tree, etc.
 
 The vast majority of the bootstd code is concerned with iterating through
 partitions on bootdevs and using bootmethds to find bootflows.
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index 0b3b32be1bb..cbb65c9b177 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -100,7 +100,7 @@ and development only and is not recommended for production devices.
 
 If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
 a u-boot.dtb file alongside u-boot-nodtb.bin with the combined result placed
-in u-boot.bin so you can still just flash u-boot,bin onto your board. If you are
+in u-boot.bin so you can still just flash u-boot.bin onto your board. If you are
 using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
 tree binary.
 
diff --git a/doc/develop/driver-model/livetree.rst b/doc/develop/driver-model/livetree.rst
index 579eef5ca9f..20055d559a6 100644
--- a/doc/develop/driver-model/livetree.rst
+++ b/doc/develop/driver-model/livetree.rst
@@ -103,7 +103,7 @@ The new code is:
 
     struct udevice *bus;
 
-    i2c_bus->regs = (struct i2c_ctlr *)dev_read_addr(dev);
+    i2c_bus->regs = dev_read_addr_ptr(dev);
     plat->frequency = dev_read_u32_default(bus, "spi-max-frequency", 500000);
 
 The dev_read\_...() interface is more convenient and works with both the
diff --git a/doc/develop/event.rst b/doc/develop/event.rst
index e60cbf65691..1c1c9ef7f1b 100644
--- a/doc/develop/event.rst
+++ b/doc/develop/event.rst
@@ -11,7 +11,7 @@ block device is probed.
 Rather than using weak functions and direct calls across subsystemss, it is
 often easier to use an event.
 
-An event consists of a type (e.g. EVT_DM_POST_INIT) and some optional data,
+An event consists of a type (e.g. EVT_DM_POST_INIT_F) and some optional data,
 in `union event_data`. An event spy can be created to watch for events of a
 particular type. When the event is created, it is sent to each spy in turn.
 
@@ -26,9 +26,9 @@ To declare a spy, use something like this::
         /* do something */
         return 0;
     }
-    EVENT_SPY(EVT_DM_POST_INIT, snow_setup_cpus);
+    EVENT_SPY(EVT_DM_POST_INIT_F, snow_setup_cpus);
 
-Your function is called when EVT_DM_POST_INIT is emitted, i.e. after driver
+Your function is called when EVT_DM_POST_INIT_F is emitted, i.e. after driver
 model is inited (in SPL, or in U-Boot proper before and after relocation).
 
 
diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
index 41d8edecb88..2c82783a89e 100644
--- a/doc/develop/release_cycle.rst
+++ b/doc/develop/release_cycle.rst
@@ -68,9 +68,9 @@ For the next scheduled release, release candidates were made on::
 
 * U-Boot v2023.07-rc2 was released on Mon 08 May 2023.
 
-.. * U-Boot v2023.07-rc3 was released on Mon 22 May 2023.
+* U-Boot v2023.07-rc3 was released on Mon 29 May 2023.
 
-.. * U-Boot v2023.07-rc4 was released on Mon 05 June 2023.
+* U-Boot v2023.07-rc4 was released on Mon 12 June 2023.
 
 .. * U-Boot v2023.07-rc5 was released on Mon 19 June 2023.