release: Zephyr 3.3.0

This commit sets the Zephyr version to v3.3.0. Signed-off-by: Stephanos Ioannidis <root@stephanos.io> Signed-off-by: Lauren Murphy <lauren.murphy@intel.com>
doc: release-notes: Use the past tense
2023-02-19 11:13:27 +09:00 · 2023-02-19 11:13:27 +09:00 · 2023-02-18 06:55:51 +09:00 · 2023-02-18 06:37:13 +09:00 · 2023-02-18 06:31:35 +09:00 · 2023-02-18 01:09:16 +09:00
345 changed files with 14891 additions and 3449 deletions
--- a/.github/workflows/bluetooth-tests.yaml
+++ b/.github/workflows/bluetooth-tests.yaml
@@ -20,7 +20,7 @@ jobs:
    if: github.repository_owner == 'zephyrproject-rtos'
    runs-on: zephyr-runner-linux-x64-4xlarge
    container:
-      image: ghcr.io/zephyrproject-rtos/ci:v0.24.6
+      image: ghcr.io/zephyrproject-rtos/ci:v0.24.11
      options: '--entrypoint /bin/bash'
      volumes:
        - /repo-cache/zephyrproject:/github/cache/zephyrproject
--- a/.github/workflows/clang.yaml
+++ b/.github/workflows/clang.yaml
@@ -11,7 +11,7 @@ jobs:
    if: github.repository_owner == 'zephyrproject-rtos'
    runs-on: zephyr-runner-linux-x64-4xlarge
    container:
-      image: ghcr.io/zephyrproject-rtos/ci:v0.24.6
+      image: ghcr.io/zephyrproject-rtos/ci:v0.24.11
      options: '--entrypoint /bin/bash'
      volumes:
        - /repo-cache/zephyrproject:/github/cache/zephyrproject
--- a/.github/workflows/codecov.yaml
+++ b/.github/workflows/codecov.yaml
@@ -13,7 +13,7 @@ jobs:
    if: github.repository == 'zephyrproject-rtos/zephyr'
    runs-on: zephyr-runner-linux-x64-4xlarge
    container:
-      image: ghcr.io/zephyrproject-rtos/ci:v0.24.6
+      image: ghcr.io/zephyrproject-rtos/ci:v0.24.11
      options: '--entrypoint /bin/bash'
      volumes:
        - /repo-cache/zephyrproject:/github/cache/zephyrproject
--- a/.github/workflows/errno.yml
+++ b/.github/workflows/errno.yml
@@ -10,7 +10,7 @@ jobs:
  check-errno:
    runs-on: ubuntu-20.04
    container:
-      image: ghcr.io/zephyrproject-rtos/ci:v0.24.6
+      image: ghcr.io/zephyrproject-rtos/ci:v0.24.11
    env:
      ZEPHYR_SDK_INSTALL_DIR: /opt/toolchains/zephyr-sdk-0.15.2

--- a/.github/workflows/footprint-tracking.yml
+++ b/.github/workflows/footprint-tracking.yml
@@ -22,7 +22,7 @@ jobs:
    runs-on: ubuntu-20.04
    if: github.repository == 'zephyrproject-rtos/zephyr'
    container:
-      image: ghcr.io/zephyrproject-rtos/ci:v0.24.6
+      image: ghcr.io/zephyrproject-rtos/ci:v0.24.11
      options: '--entrypoint /bin/bash'
    strategy:
      fail-fast: false
--- a/.github/workflows/footprint.yml
+++ b/.github/workflows/footprint.yml
@@ -11,7 +11,7 @@ jobs:
    runs-on: ubuntu-20.04
    if: github.repository == 'zephyrproject-rtos/zephyr'
    container:
-      image: ghcr.io/zephyrproject-rtos/ci:v0.24.6
+      image: ghcr.io/zephyrproject-rtos/ci:v0.24.11
      options: '--entrypoint /bin/bash'
    strategy:
      fail-fast: false
--- a/.github/workflows/twister.yaml
+++ b/.github/workflows/twister.yaml
@@ -22,7 +22,7 @@ jobs:
    if: github.repository_owner == 'zephyrproject-rtos'
    runs-on: zephyr-runner-linux-x64-4xlarge
    container:
-      image: ghcr.io/zephyrproject-rtos/ci:v0.24.6
+      image: ghcr.io/zephyrproject-rtos/ci:v0.24.11
      options: '--entrypoint /bin/bash'
      volumes:
        - /repo-cache/zephyrproject:/github/cache/zephyrproject
@@ -118,7 +118,7 @@ jobs:
    needs: twister-build-prep
    if: needs.twister-build-prep.outputs.size != 0
    container:
-      image: ghcr.io/zephyrproject-rtos/ci:v0.24.6
+      image: ghcr.io/zephyrproject-rtos/ci:v0.24.11
      options: '--entrypoint /bin/bash'
      volumes:
        - /repo-cache/zephyrproject:/github/cache/zephyrproject
--- a/MAINTAINERS.yml
+++ b/MAINTAINERS.yml
@@ -118,10 +118,12 @@ ARC arch:
  collaborators:
    - abrodkin
    - evgeniy-paltsev
-    - IRISZZW
+    - SiyuanCheng-CN
  files:
    - arch/arc/
    - include/zephyr/arch/arc/
+    - tests/arch/arc/
+    - dts/arc/synopsys/
  labels:
    - "area: ARC"

@@ -142,6 +144,9 @@ ARM arch:
    - include/zephyr/arch/arm/aarch32/
    - include/zephyr/arch/arm/
    - tests/arch/arm/
+    - doc/hardware/arch/arm_cortex_m.rst
+    - boards/arm/qemu_cortex_m3/
+    - boards/arm/qemu_cortex_m0/
  labels:
    - "area: ARM"

@@ -163,6 +168,16 @@ ARM64 arch:
  labels:
    - "area: ARM64"

+MIPS arch:
+  status: odd fixes
+  files:
+    - soc/mips/
+    - arch/mips/
+    - include/zephyr/arch/mips/
+    - boards/mips/
+  labels:
+    - "area: MIPS"
+
 Bluetooth:
  status: maintained
  maintainers:
@@ -175,6 +190,7 @@ Bluetooth:
    - Thalley
    - asbjornsabo
    - sjanc
+    - theob-pro
  files:
    - doc/connectivity/bluetooth/
    - drivers/bluetooth/
@@ -234,6 +250,7 @@ Bluetooth Mesh:
    - subsys/bluetooth/mesh/
    - include/zephyr/bluetooth/mesh/
    - tests/bluetooth/mesh*/
+    - samples/bluetooth/mesh/
  labels:
    - "area: Bluetooth Mesh"
    - "area: Bluetooth"
@@ -329,6 +346,9 @@ DSP subsystem:
  files:
    - subsys/dsp/
    - tests/subsys/dsp/
+    - include/zephyr/dsp/dsp.h
+    - include/zephyr/dsp/types.h
+    - include/zephyr/dsp/
  labels:
    - "area: DSP"

@@ -432,6 +452,7 @@ Devicetree:
    - doc/build/dts/
    - include/zephyr/devicetree/
    - scripts/kconfig/kconfigfunctions.py
+    - include/zephyr/devicetree.h
  labels:
    - "area: Devicetree"

@@ -479,6 +500,7 @@ Display drivers:
 Documentation:
  status: maintained
  maintainers:
+    - kartben
    - carlescufi
  collaborators:
    - nashif
@@ -490,6 +512,12 @@ Documentation:
    - doc/releases/
    - doc/security/
    - README.rst
+    - doc/substitutions.txt
+    - doc/images/Zephyr-Kite-in-tree.png
+    - doc/index-tex.rst
+    - doc/index.rst
+    - doc/kconfig.rst
+    - doc/known-warnings.txt
  labels:
    - "area: Documentation"

@@ -500,6 +528,7 @@ Documentation Infrastructure:
  collaborators:
    - carlescufi
    - nashif
+    - kartben
  files:
    - doc/_*/
    - doc/CMakeLists.txt
@@ -528,6 +557,10 @@ Release Notes:
    - include/zephyr/drivers/adc.h
    - tests/drivers/adc/
    - samples/drivers/adc/
+    - include/zephyr/drivers/adc/
+    - doc/hardware/peripherals/adc.rst
+    - tests/drivers/build_all/adc/
+    - include/zephyr/dt-bindings/adc/
  labels:
    - "area: ADC"

@@ -586,6 +619,8 @@ Release Notes:
    - include/zephyr/drivers/clock_control.h
    - include/zephyr/dt-bindings/clock/
    - tests/drivers/clock_control/
+    - include/zephyr/drivers/clock_control/
+    - doc/hardware/peripherals/clock_control.rst
  labels:
    - "area: Clock control"

@@ -608,6 +643,7 @@ Release Notes:
    - dts/bindings/coredump/
    - include/zephyr/drivers/coredump.h
    - tests/drivers/coredump/
+    - doc/hardware/peripherals/coredump.rst
  labels:
    - "area: Coredump"

@@ -619,6 +655,8 @@ Release Notes:
    - drivers/counter/
    - include/zephyr/drivers/counter.h
    - tests/drivers/counter/
+    - doc/hardware/peripherals/counter.rst
+    - samples/drivers/counter/
  labels:
    - "area: Counter"

@@ -644,6 +682,8 @@ Release Notes:
    - include/zephyr/drivers/dac.h
    - tests/drivers/dac/
    - samples/drivers/dac/
+    - doc/hardware/peripherals/dac.rst
+    - tests/drivers/build_all/dac/
  labels:
    - "area: DAC"

@@ -668,6 +708,10 @@ Release Notes:
  files:
    - drivers/dma/
    - tests/drivers/dma/
+    - include/zephyr/drivers/dma/
+    - doc/hardware/peripherals/dma.rst
+    - include/zephyr/drivers/dma.h
+    - include/zephyr/dt-bindings/dma/
  labels:
    - "area: DMA"

@@ -681,6 +725,7 @@ Release Notes:
    - include/zephyr/drivers/edac.h
    - samples/subsys/edac/
    - tests/subsys/edac/
+    - doc/hardware/peripherals/edac/index.rst
  labels:
    - "area: EDAC"

@@ -722,6 +767,7 @@ Release Notes:
    - samples/drivers/espi/
    - dts/bindings/espi/
    - doc/hardware/peripherals/espi.rst
+    - include/zephyr/drivers/espi_saf.h
  labels:
    - "area: eSPI"

@@ -794,6 +840,7 @@ Release Notes:
    - include/zephyr/drivers/gpio.h
    - include/zephyr/dt-bindings/gpio/
    - tests/drivers/gpio/
+    - tests/drivers/build_all/gpio/
  labels:
    - "area: GPIO"

@@ -806,6 +853,7 @@ Release Notes:
    - dts/bindings/hwinfo/
    - include/zephyr/drivers/hwinfo.h
    - tests/drivers/hwinfo/
+    - doc/hardware/peripherals/hwinfo.rst
  labels:
    - "area: HWINFO"

@@ -820,6 +868,8 @@ Release Notes:
    - include/zephyr/drivers/i2c.h
    - tests/drivers/i2c/
    - doc/hardware/peripherals/i2c.rst
+    - include/zephyr/dt-bindings/i2c/
+    - tests/boards/frdm_k64f/i2c/
  labels:
    - "area: I2C"

@@ -845,6 +895,7 @@ Release Notes:
    - dts/bindings/i3c/
    - include/zephyr/drivers/i3c.h
    - include/zephyr/drivers/i3c/
+    - doc/hardware/peripherals/i3c.rst
  labels:
    - "area: I3C"

@@ -907,13 +958,14 @@ Release Notes:
  status: maintained
  maintainers:
    - Mani-Sadhasivam
-  collaborators:
    - simonguinot
  files:
    - drivers/led/
    - include/zephyr/drivers/led/
    - include/zephyr/drivers/led.h
    - samples/drivers/led_*/
+    - tests/drivers/led/
+    - doc/hardware/peripherals/led.rst
  labels:
    - "area: LED"

@@ -921,6 +973,7 @@ Release Notes:
  status: maintained
  maintainers:
    - mbolivar-nordic
+    - simonguinot
  files:
    - drivers/led_strip/
    - dts/bindings/led_strip/
@@ -942,6 +995,7 @@ Release Notes:
    - include/zephyr/lorawan/
    - subsys/lorawan/
    - samples/subsys/lorawan/
+    - doc/connectivity/lora_lorawan/index.rst
  labels:
    - "area: LoRa"

@@ -975,6 +1029,7 @@ Release Notes:
    - include/zephyr/drivers/regulator.h
    - include/zephyr/dt-bindings/regulator/
    - tests/drivers/regulator/
+    - doc/hardware/peripherals/regulators.rst
  labels:
    - "area: Regulators"

@@ -1002,6 +1057,7 @@ Release Notes:
    - drivers/peci/
    - include/zephyr/drivers/peci.h
    - samples/drivers/peci/
+    - doc/hardware/peripherals/peci.rst
  labels:
    - "area: PECI"

@@ -1016,6 +1072,7 @@ Release Notes:
    - drivers/pinctrl/
    - tests/drivers/pinctrl/
    - dts/bindings/pinctrl/
+    - include/zephyr/dt-bindings/pinctrl/
  labels:
    - "area: Pinctrl"

@@ -1065,6 +1122,9 @@ Release Notes:
    - dts/bindings/pwm/
    - tests/drivers/pwm/
    - include/zephyr/*/pwms.h
+    - doc/hardware/peripherals/pwm.rst
+    - tests/drivers/build_all/pwm/
+    - include/zephyr/drivers/pwm.h
  labels:
    - "area: PWM"

@@ -1079,6 +1139,7 @@ Release Notes:
    - dts/bindings/serial/
    - samples/drivers/uart/
    - tests/drivers/uart/
+    - doc/hardware/peripherals/uart.rst
  labels:
    - "area: UART"

@@ -1096,6 +1157,9 @@ Release Notes:
    - samples/sensor/
    - tests/drivers/sensor/
    - dts/bindings/sensor/
+    - include/zephyr/drivers/sensor/
+    - include/zephyr/dt-bindings/sensor/
+    - doc/hardware/peripherals/sensor.rst
  labels:
    - "area: Sensors"

@@ -1109,6 +1173,7 @@ Release Notes:
    - drivers/spi/
    - include/zephyr/drivers/spi.h
    - tests/drivers/spi/
+    - doc/hardware/peripherals/spi.rst
  labels:
    - "area: SPI"

@@ -1148,6 +1213,7 @@ Release Notes:
    - include/zephyr/drivers/w1.h
    - include/zephyr/drivers/sensor/w1_sensor.h
    - tests/drivers/w1/
+    - samples/drivers/w1/
  labels:
    - "area: W1"

@@ -1286,6 +1352,7 @@ JSON Web Token:
    - subsys/jwt/
    - include/zephyr/data/
    - lib/os/json.c
+    - tests/subsys/jwt/
  labels:
    - "area: JSON"

@@ -1319,6 +1386,7 @@ Kernel:
    - tests/kernel/
    - include/zephyr/sys_clock.h
    - samples/kernel/
+    - include/zephyr/kernel/
  files-exclude:
    - tests/kernel/mem_protect/
  labels:
@@ -1484,6 +1552,8 @@ Native POSIX and POSIX arch:
  files:
    - arch/posix/
    - boards/posix/native_posix/
+    - boards/posix/doc/
+    - boards/posix/*.rst
    - drivers/*/*native_posix*
    - drivers/*/*/*native_posix*
    - dts/posix/
@@ -1619,6 +1689,7 @@ NIOS-2 arch:
    - soc/nios2/
    - include/zephyr/arch/nios2/
    - tests/boards/altera_max10/
+    - boards/nios2/qemu_nios2/
  labels:
    - "area: NIOS2"

@@ -1639,6 +1710,7 @@ POSIX API layer:
    - include/zephyr/posix/
    - lib/posix/
    - tests/posix/
+    - samples/posix/
  labels:
    - "area: POSIX"

@@ -1656,6 +1728,8 @@ Power management:
    - samples/subsys/pm/
    - subsys/pm/
    - tests/subsys/pm/
+    - doc/services/pm/
+    - drivers/power_domain/
  labels:
    - "area: Power Management"

@@ -1676,6 +1750,7 @@ RISCV arch:
    - dts/bindings/riscv/
    - include/zephyr/arch/riscv/
    - soc/riscv/
+    - tests/arch/riscv/
  labels:
    - "area: RISCV"

@@ -1719,6 +1794,7 @@ Shell:
    - samples/subsys/shell/
    - subsys/shell/
    - tests/subsys/shell/
+    - doc/services/shell/
  labels:
    - "area: Shell"

@@ -1732,6 +1808,7 @@ Shields:
  files:
    - boards/shields/
    - doc/hardware/porting/shields.rst
+    - samples/shields/
  labels:
    - "area: Shields"

@@ -1743,6 +1820,8 @@ SPARC arch:
    - arch/sparc/
    - include/zephyr/arch/sparc/
    - soc/sparc/
+    - boards/sparc/
+    - dts/sparc/
  labels:
    - "area: SPARC"

@@ -1833,6 +1912,25 @@ Nuvoton Numicro Platforms:
  labels:
    - "platform: Nuvoton Numicro"

+Raspberry Pi Pico Platforms:
+  status: maintained
+  maintainers:
+    - yonsch
+  collaborators:
+    - soburi
+  files:
+    - boards/arm/rpi_pico/
+    - boards/arm/adafruit_kb2040/
+    - boards/arm/sparkfun_pro_micro_rp2040/
+    - dts/arm/rpi_pico/
+    - dts/bindings/*/raspberrypi,pico*
+    - drivers/*/*rpi_pico
+    - drivers/*/*rpi_pico*/
+    - drivers/*/*rpi_pico*.c
+    - soc/arm/rpi_pico/
+  labels:
+    - "platform: Raspberry Pi Pico"
+
 SiLabs Platforms:
  status: odd fixes
  files:
@@ -1855,7 +1953,9 @@ Intel Platforms (X86):
    - MaureenHelm
  files:
    - boards/x86/
+    - dts/x86/intel/
    - soc/x86/
+    - samples/boards/up_squared/
  labels:
    - "platform: X86"

@@ -1882,6 +1982,7 @@ Intel Platforms (Xtensa):
    - soc/xtensa/intel_*/
    - dts/xtensa/intel/
    - tests/boards/intel_adsp/
+    - dts/bindings/*/intel,*
  labels:
    - "platform: Intel ADSP"

@@ -1925,6 +2026,8 @@ Microchip MEC Platforms:
    - soc/arm/microchip_mec/
    - drivers/*/*mchp*.c
    - tests/boards/mec15xxevb_assy6853/
+    - tests/boards/mec172xevb_assy6906/
+    - dts/bindings/*/microchip,*
  labels:
    - "platform: Microchip MEC"

@@ -1942,6 +2045,7 @@ Microchip SAM Platforms:
    - dts/arm/atmel/
    - soc/arm/atmel_sam*/
    - drivers/*/*sam*.c
+    - dts/bindings/*/atmel,*
  labels:
    - "platform: Microchip SAM"

@@ -1955,6 +2059,7 @@ nRF Platforms:
    - soc/arm/nordic_nrf/
    - samples/boards/nrf/
    - dts/arm/nordic/
+    - dts/bindings/*/nordic,*
  labels:
    - "platform: nRF"

@@ -2023,6 +2128,7 @@ Espressif Platforms:
    - dts/bindings/*/*esp32*
    - samples/boards/esp32*/
    - tests/boards/espressif_esp32/
+    - drivers/wifi/esp32/
  labels:
    - "platform: ESP32"

@@ -2069,6 +2175,7 @@ TI Platforms:
    - dts/*/ti/
    - dts/bindings/*/ti,*
    - soc/arm/ti*/
+    - dts/bindings/*/ti,*
  labels:
    - "platform: TI"

@@ -2105,6 +2212,7 @@ Storage:
    - subsys/storage/
    - include/zephyr/storage/
    - tests/subsys/storage/
+    - doc/services/storage/
  labels:
    - "area: Storage"

@@ -2176,6 +2284,7 @@ USB:
    - subsys/usb/
    - tests/subsys/usb/
    - tests/drivers/udc/
+    - doc/services/usb/
  labels:
    - "area: USB"

@@ -2293,7 +2402,8 @@ West:
  status: maintained
  maintainers:
    - de-nordic
-  files: []
+  files:
+    - modules/fatfs/
  labels:
    - manifest-fatfs

@@ -2360,6 +2470,7 @@ West:
    - talih0
  files:
    - modules/Kconfig.infineon
+    - modules/hal_infineon/
  labels:
    - manifest-hal_infineon

@@ -2613,6 +2724,7 @@ West:
    - pdgendt
  files:
    - modules/nanopb/
+    - samples/modules/nanopb/
  labels:
    - manifest-nanopb

@@ -2671,7 +2783,8 @@ West:
  status: odd fixes
  collaborators:
    - nordic-krch
-  files: []
+  files:
+    - modules/segger/
  labels:
    - manifest-segger

@@ -2700,6 +2813,17 @@ West:
  labels:
    - manifest-tflite-micro

+"West project: thrift":
+  status: maintained
+  maintainers:
+    - cfriedt
+  files:
+    - modules/thrift/
+    - samples/modules/thrift/
+    - tests/lib/thrift/
+  labels:
+    - manifest-thrift
+
 "West project: tinycrypt":
  status: odd fixes
  files:
@@ -2803,6 +2927,8 @@ Xtensa arch:
    - arch/xtensa/
    - include/zephyr/arch/xtensa/
    - dts/xtensa/
+    - boards/xtensa/qemu_xtensa/
+    - boards/xtensa/xt-sim/
  labels:
    - "area: Xtensa"

@@ -2825,6 +2951,7 @@ x86 arch:
    - drivers/interrupt_controller/*intel*
    - drivers/interrupt_controller/*ioapic*
    - drivers/interrupt_controller/*loapic*
+    - doc/hardware/arch/x86.rst
  labels:
    - "area: X86"

@@ -2874,6 +3001,8 @@ Emulation:
    - include/zephyr/drivers/espi_emul.h
    - include/zephyr/drivers/i2c_emul.h
    - include/zephyr/drivers/spi_emul.h
+    - tests/subsys/emul/
+    - doc/hardware/emulator/
  labels:
    - "area: HW Emulation"

--- a/2
+++ b/2
@@ -2,4 +2,4 @@ VERSION_MAJOR = 3
 VERSION_MINOR = 3
 PATCHLEVEL = 0
 VERSION_TWEAK = 0
-EXTRAVERSION = rc2
+EXTRAVERSION =
--- a/boards/arc/nsim/doc/index.rst
+++ b/boards/arc/nsim/doc/index.rst
@@ -1,54 +1,69 @@
 .. _nsim:

-DesignWare(R) ARC(R) Emulation (nsim)
-#####################################
+DesignWare ARC nSIM and HAPS FPGA boards
+########################################

 Overview
 ********

-This board configuration can be used to run ARC EM / ARC HS based images in
-simulation with `Designware ARC nSIM`_ or run same images on FPGA based HW
-platform `HAPS`_. The board includes the following features:
+This platform can be used to run Zephyr RTOS on the widest possible range of ARC processors in
+simulation with `Designware ARC nSIM`_ or run same images on FPGA prototyping platform `HAPS`_. The
+platform includes the following features:

-* ARC EM or ARC HS processor
-* ARC internal timer
-* a virtual console (ns16550 based UART model)
+* ARC processor core, which implements ARCv2 or ARCv3 ISA, please refer to
+  :ref:`here <hardware_arch_arc_support_status>` for a complete list of ARC processor families which
+  currently supported
+* Virtual serial console (a standard ``ns16550`` UART model)

-There are four supported board sub-configurations:
+ARC processors are known for being highly customizable and some but not all of the configurations
+are currently supported in the Zephyr RTOS for ARC, again please refer to
+:ref:`here <hardware_arch_arc_support_status>` for a complete list of supported features.

-* ``nsim_em`` which includes normal ARC EM features and ARC MPUv2
-* ``nsim_em_em7d_v22`` which includes normal ARC EM features and ARC MPUv2, specially with one register bank and fast irq
-* ``nsim_em_em11d`` which includes normal ARC EM features and ARC MPUv2, specially with XY memory and DSP feature.
-* ``nsim_sem`` which includes secure ARC EM features and ARC MPUv3
-* ``nsim_hs`` which includes base ARC HS features, i.e. w/o PMU and MMU
-* ``nsim_hs_smp`` which includes base ARC HS features in multi-core cluster, still w/o PMU and MMU
+There are multiple supported sub-configurations for that platform. Some but not all of currently
+available configurations are listed below:

-For detailed arc features, please refer to
-:zephyr_file:`boards/arc/nsim/support/nsim_em.props`,
-:zephyr_file:`boards/arc/nsim/support/nsim_em7d_v22.props`,
-:zephyr_file:`boards/arc/nsim/support/nsim_em11d.props`,
-:zephyr_file:`boards/arc/nsim/support/nsim_sem.props`,
-:zephyr_file:`boards/arc/nsim/support/nsim_hs.props` and
-:zephyr_file:`boards/arc/nsim/support/mdb_hs_smp.args`
+* ``nsim_em`` - ARC EM core v4.0 with two register banks, FastIRQ's, MPUv2, DSP options and
+  XY-memory
+* ``nsim_em_em7d_v22`` - ARC EM core v3.0 with one register bank and FastIRQ's
+* ``nsim_em_em11d`` - ARC EM core v4.0 with one register bank, no FastIRQ's, MPUv2, DSP options and
+  XY-memory
+* ``nsim_sem`` - ARC EM core v4.0 with secure features (thus "SEM", i.e. Secure EM) and MPUv4
+* ``nsim_hs`` - ARCv2 HS core v2.1 with two register banks, FastIRQ's and MPUv3
+* ``nsim_hs_smp`` - Dual-core ARCv2 HS core v2.1 with two register banks, FastIRQ's and MPUv3
+* ``nsim_hs5x`` - 32-bit ARCv3 HS core with rich set of options
+* ``nsim_hs6x`` - 64-bit ARCv3 HS core with rich set of options

+.. _board_arc_nsim_prop_args_files:

-Hardware
-********
-Supported Features
-==================
+It is recommended to look at precise description of a particular sub-configuration in either
+``.props`` or ``.args`` files in :zephyr_file:`boards/arc/nsim/support/` directory to understand
+which options are configured and so will be used on invocation of the simulator.

-The following hardware features are supported:
+In case of single-core configurations it would be ``.props`` file which contains configuration
+for nSIM simulator and ``.args`` file which contains configuration for MetaWare debugger (MDB).
+Note that these files contain identical HW configuration and meant to be used with the corresponding
+tool: ``.props`` file for nSIM simulator and ``.args`` file for MDB (which internally uses nSIM for
+simulation anyway).

-+-----------+------------+-----+-------+-----+-----------------------+
-| Interface | Controller | EM  | SEM   | HS  | Driver/Component      |
-+===========+============+=====+=======+=====+=======================+
-| INT       | on-chip    | Y   | Y     | Y   | interrupt_controller  |
-+-----------+------------+-----+-------+-----+-----------------------+
-| UART      | ns16550    | Y   | Y     | Y   | serial port           |
-+-----------+------------+-----+-------+-----+-----------------------+
-| TIMER     | on-chip    | Y   | Y     | Y   | system clock          |
-+-----------+------------+-----+-------+-----+-----------------------+
+.. hint::
+   If different behavior is observed during execution or debugging of a particular application
+   (especially after creation of a new board or modification of the existing one) make sure features
+   defined in ``.props`` and ``.args`` are semantically identical (unfortunately options of
+   nSIM & MDB don't exactly match, so care should be taken).

+I.e. for the single-core ``nsim_hs5x`` platform there are
+:zephyr_file:`boards/arc/nsim/support/nsim_hs5x.props` and
+:zephyr_file:`boards/arc/nsim/support/mdb_hs5x.args`.
+
+For the multi-core configurations there is only ``.args`` file as the multi-core configuration
+can only be instantiated with help of MDB.
+
+I.e. for the multi-core ``nsim_hs5x_smp`` platform there is only
+:zephyr_file:`boards/arc/nsim/support/mdb_hs5x_smp.args`.
+
+.. warning::
+   All nSIM/MDB configurations are used for demo and testing purposes. They are not meant to
+   represent any real system and so might be renamed, removed or modified at any point.

 Programming and Debugging
 *************************
@@ -57,16 +72,38 @@ Required Hardware and Software
 ==============================

 To run single-core Zephyr RTOS applications in simulation on this board,
-`Designware ARC nSIM`_ or `Designware ARC nSIM Lite`_ is required.
+either `DesignWare ARC nSIM`_ or `DesignWare ARC Free nSIM`_ is required.

 To run multi-core Zephyr RTOS applications in simulation on this board,
-`Designware ARC nSIM`_ and MetaWare Debugger from `ARC MWDT`_ are required.
+`DesignWare ARC nSIM`_ and MetaWare Debugger from `ARC MWDT`_ are required.

 To run Zephyr RTOS applications on FPGA-based `HAPS`_ platform,
-MetaWare Debugger from `ARC MWDT`_ is required.
+MetaWare Debugger from `ARC MWDT`_ is required as well as the HAPS platform itself.

-Building Sample Applications
-==============================
+Building & Running Sample Applications
+======================================
+
+Most board sub-configurations support building with both GNU and ARC MWDT toolchains, however
+there might be exceptions from that, especially for newly added targets. You can check supported
+toolchains for the sub-configurations in the corresponding ``.yaml`` file.
+
+I.e. for the ``nsim_hs5x`` board we can check :zephyr_file:`boards/arc/nsim/nsim_hs5x.yaml`
+
+The supported toolchains are listed in ``toolchain:`` array in ``.yaml`` file, where we can find:
+
+* **zephyr** - implies ARC GNU toolchain from Zephyr SDK. You can find more information about
+  Zephyr SDK :ref:`here <toolchain_zephyr_sdk>`.
+* **cross-compile** - implies ARC GNU cross toolchain, which is not a part of Zephyr SDK. Note that
+  some (especially new) sub-configurations may declare ``cross-compile`` toolchain support without
+  ``zephyr`` toolchain support because corresponding target CPU support hasn't been added to Zephyr
+  SDK yet. You can find more information about its usage here: :ref:`here <other_x_compilers>`.
+* **arcmwdt** - implies proprietary ARC MWDT toolchain. You can find more information about its
+  usage here: :ref:`here <toolchain_designware_arc_mwdt>`.
+
+.. note::
+   Note that even if both GNU and MWDT toolchain support is declared for the target some tests or
+   samples can be only built with either GNU or MWDT toolchain due to some features limited to a
+   particular toolchain.

 Use this configuration to run basic Zephyr applications and kernel tests in
 nSIM, for example, with the :ref:`synchronization_sample`:
@@ -78,65 +115,222 @@ nSIM, for example, with the :ref:`synchronization_sample`:
   :goals: flash

 This will build an image with the synchronization sample app, boot it using
-nsim, and display the following console output:
+nSIM, and display the following console output:

 .. code-block:: console

-        ***** BOOTING ZEPHYR OS v1.12 - BUILD: July 6 2018 15:17:26 *****
-        threadA: Hello World from arc!
-        threadB: Hello World from arc!
-        threadA: Hello World from arc!
-        threadB: Hello World from arc!
+      *** Booting Zephyr OS build zephyr-v3.2.0-3948-gd351a024dc87 ***
+      thread_a: Hello World from cpu 0 on nsim!
+      thread_b: Hello World from cpu 0 on nsim!
+      thread_a: Hello World from cpu 0 on nsim!
+      thread_b: Hello World from cpu 0 on nsim!
+      thread_a: Hello World from cpu 0 on nsim!


 .. note::
-   To exit the simulator, use Ctrl+], then Ctrl+c
+   To exit the simulator, use :kbd:`Ctrl+]`, then :kbd:`Ctrl+c`

-Use this configuration to run same application on `HAPS`_ platform:
+.. _board_arc_nsim_verbose_build:

-.. zephyr-app-commands::
-   :zephyr-app: samples/synchronization
-   :host-os: unix
-   :board: nsim_em
-   :goals: flash --runner mdb-hw
+.. tip::
+   You can get more details about the building process by running build in verbose mode. It can be
+   done by passing ``-v`` flag to the west: ``west -v build -b nsim_hs samples/synchronization``
+
+You can run applications built for ``nsim`` board not only on nSIM simulation itself, but also on
+FPGA based HW platform `HAPS`_. To run previously built application on HAPS do:
+
+.. code-block:: console
+
+   west flash --runner mdb-hw
+
+.. note::
+   To run on HAPS, in addition to proper build and flash Zephyr image, you need setup HAPS itself
+   as well as flash proper built FPGA image (aka .bit-file). This instruction doesn't cover those
+   steps, so you need to follow HAPS manual.

 Debugging
 =========

+.. _board_arc_nsim_debugging_mwdt:
+
+Debugging with MDB
+------------------
+
 .. note::
-   The normal ``make debug`` command won't work for debugging
-   applications using nsim because both the nsim simulator and the
-   gdb debugger use the console for output. You need to use separate
-   terminal windows for each tool to avoid intermixing their output.
+   We strongly recommend to debug with MetaWare debugger (MDB) because it:

-After building your application, cd to the build folder and open two
-terminal windows. In terminal one, use nsim to start a GDB server
-and wait for a remote connection:
+   * Supports wider range of ARC hardware features
+   * Allows to debug both single-core and multi-core ``nsim`` targets.
+   * Allows to debug on `HAPS`_ platform.
+
+You can use the following command to start GUI debugging when running application on nSIM simulator
+(regardless if single- or multi-core configuration is used):

 .. code-block:: console

-   # for ninja build system:
-   ninja debugserver
-   # for make build system:
-   make debugserver
+   west debug --runner mdb-nsim

-In terminal two, connect to the GDB server using :file:`arc-elf32-gdb`.
-This command loads the symbol table from the elf binary file, for example
-the :file:`./zephyr/zephyr.elf` file:
+You can use the following command to start GUI debugging when running application on `HAPS`_
+platform:

 .. code-block:: console

-   ..../path/to/arc-elf32-gdb zephyr/zephyr.elf
-   (gdb) target remote : 3333
-   (gdb) load
+   west debug --runner mdb-hw

-Now the debug environment has been set up, you can debug the application with gdb commands.
+.. tip::
+   The ``west debug`` (as well as ``west flash``) is just a wrapper script and so it's possible to
+   extract the exact commands which are called in it by running it in verbose mode. For that you
+   need to pass ``-v`` flag to the wrapper. For example, if you run the following command:

+   .. code-block:: console
+
+      west -v debug --runner mdb-nsim
+
+   it will produce the following output (the ``nsim_hs5x_smp`` configuration was used for that
+   example):
+
+   .. code-block:: console
+
+       < *snip* >
+      -- west debug: using runner mdb-nsim
+      runners.mdb-nsim: mdb -pset=1 -psetname=core0 -nooptions -nogoifmain -toggle=include_local_symbols=1 -nsim @/path/zephyr/boards/arc/nsim/support/mdb_hs5x_smp.args /path/zephyr/build/zephyr/zephyr.elf
+      runners.mdb-nsim: mdb -pset=2 -psetname=core1 -prop=download=2 -nooptions -nogoifmain -toggle=include_local_symbols=1 -nsim @/path/zephyr/boards/arc/nsim/support/mdb_hs5x_smp.args /path/zephyr/build/zephyr/zephyr.elf
+      runners.mdb-nsim: mdb -multifiles=core1,core0 -OKN
+
+   From that output it's possible to extract MDB commands used for setting-up the GUI debugging
+   session:
+
+   .. code-block:: console
+
+      mdb -pset=1 -psetname=core0 -nooptions -nogoifmain -toggle=include_local_symbols=1 -nsim @/path/zephyr/boards/arc/nsim/support/mdb_hs5x_smp.args /path/zephyr/build/zephyr/zephyr.elf
+      mdb -pset=2 -psetname=core1 -prop=download=2 -nooptions -nogoifmain -toggle=include_local_symbols=1 -nsim @/path/zephyr/boards/arc/nsim/support/mdb_hs5x_smp.args /path/zephyr/build/zephyr/zephyr.elf
+      mdb -multifiles=core1,core0 -OKN
+
+   Then it's possible to use them directly or in some machinery if required.
+
+   .. warning::
+      It is strongly recommended to not rely on the mdb command line options listed above but
+      extract it yourself for your configuration.
+
+   .. note::
+      In case of execution or debugging with MDB on multi-core configuration on nSIM
+      simulator without ``west flash`` and ``west debug`` wrappers it's necessary to
+      set :envvar:`NSIM_MULTICORE` environment variable to ``1``. If you are using ``west flash`` or
+      ``west debug`` it's done automatically by wrappers.
+
+      Without :envvar:`NSIM_MULTICORE` environment variable set to 1, MDB will simulate 2 separate
+      ARC cores which don't share any memory regions with each other and so SMP-enabled code won't
+      work as expected.
+
+Debugging with GDB
+------------------
+
+.. note::
+   Debugging on nSIM via GDB is only supported on single-core configurations (which use standalone
+   nSIM). However if it's possible to launch application on multi-core nsim target that means you
+   can simply :ref:`debug with MDB debugger <board_arc_nsim_debugging_mwdt>`.
+   It's the nSIM with ARC GDB restriction, real HW multi-core ARC targets can be debugged with ARC
+   GDB.
+
+.. note::
+   Currently debugging with GDB is not supported on `HAPS`_ platform.
+
+.. note::
+   The normal ``west debug`` command won't work for debugging applications using nsim boards
+   because both the nSIM simulator and the debugger (either GDB or MDB) use the same console for
+   input / output.
+   In case of GDB debugger it's possible to use a separate terminal windows for GDB and nSIM to
+   avoid intermixing their output. For the MDB debugger simply use GUI mode.
+
+After building your application, open two terminal windows. In terminal one, use nSIM to start a GDB
+server and wait for a remote connection with following command:
+
+.. code-block:: console
+
+   west debugserver --runner arc-nsim
+
+In terminal two, connect to the GDB server using ARC GDB. You can find it in Zephyr SDK:
+
+* for the ARCv2 targets you should use :file:`arc-zephyr-elf-gdb`
+* for the ARCv3 targets you should use :file:`arc64-zephyr-elf-gdb`
+
+This command loads the symbol table from the elf binary file, for example the
+:file:`build/zephyr/zephyr.elf` file:
+
+.. code-block:: console
+
+   arc-zephyr-elf-gdb  -ex 'target remote localhost:3333' -ex load build/zephyr/zephyr.elf
+
+Now the debug environment has been set up, and it's possible to debug the application with gdb
+commands.
+
+Modifying the configuration
+***************************
+
+If modification of existing nsim configuration is required or even there's a need in creation of a
+new one it's required to maintain alignment between
+
+* Zephyr OS configuration
+* nSIM & MDB configuration
+* GNU & MWDT toolchain compiler options
+
+.. note::
+   The ``.tcf`` configuration files are not supported by Zephyr directly. There are multiple
+   reasons for that. ``.tcf`` perfectly suits building of bare-metal single-thread application -
+   in that case all the compiler options from ``.tcf`` are passed to the compiler, so all the HW
+   features are used by the application and optimal code is being generated.
+   The situation is completely different when multi-thread feature-rich operation system is
+   considered. Of course it is still possible to build all the code with all the
+   options from ``.tcf`` - but that may be far from optimal solution. For example, such approach
+   require so save & restore full register context for all tasks (and sometimes even for
+   interrupts). And for DSP-enabled or for FPU-enabled systems that leads to dozens of extra
+   registers save and restore even if the most of the user and kernel tasks don't actually use
+   DSP or FPU. Instead we prefer to fine-tune the HW features usage which (with all its pros)
+   require us to maintain them separately from ``.tcf`` configuration.
+
+
+Zephyr OS configuration
+=======================
+
+Zephyr OS configuration is defined via Kconfig and Device tree. These are non ARC-specific
+mechanisms which are described in :ref:`board porting guide <board_porting_guide>`.
+
+It is advised to look for ``<board_name>_defconfig``, ``<board_name>.dts`` and
+``<board_name>.yaml`` as an entry point for board configuration.
+
+nSIM configuration
+==================
+
+nSIM configuration is defined in :ref:`props and args files <board_arc_nsim_prop_args_files>`.
+Generally they are identical to the values from corresponding ``.tcf`` configuration with few
+exceptions:
+
+* The UART model is added (to both ``.props`` and ``.args`` files).
+* Options to fine-tuned MDB behavior are added (to ``.args`` files only) to disable MDB profiling
+  and fine-tune MDB behavior on multi-core systems.
+
+GNU & MWDT toolchain compiler options
+=====================================
+
+The hardware-specific compiler options are set in corresponding SoC cmake file. For ``nsim`` board
+it is :zephyr_file:`soc/arc/snps_nsim/CMakeLists.txt`.
+
+For the GNU toolchain the basic configuration is set via ``-mcpu`` which is defined in generic code
+and based on the selected CPU model via Kconfig. It still can be forcefully set to required value
+on SoC level.
+
+For the MWDT toolchain all hardware-specific compiler options are set directly in SoC
+``CMakeLists.txt``.
+
+.. note::
+   The non hardware-specific compiler options like optimizations, library selections, C / C++
+   language options are still set in Zephyr generic code. It could be observed by
+   :ref:`running build in verbose mode <board_arc_nsim_verbose_build>`.

 References
 **********

 .. _Designware ARC nSIM: https://www.synopsys.com/dw/ipdir.php?ds=sim_nsim
-.. _Designware ARC nSIM Lite: https://www.synopsys.com/cgi-bin/dwarcnsim/req1.cgi
+.. _DesignWare ARC Free nSIM: https://www.synopsys.com/cgi-bin/dwarcnsim/req1.cgi
 .. _HAPS: https://www.synopsys.com/verification/prototyping/haps.html
 .. _ARC MWDT: https://www.synopsys.com/dw/ipdir.php?ds=sw_metaware
--- a/boards/arc/nsim/support/mdb_em7d_v22.args
+++ b/boards/arc/nsim/support/mdb_em7d_v22.args
@@ -14,6 +14,11 @@
 	-Xdsp_complex
 	-Xdsp_divsqrt=radix2
 	-Xdsp_accshift=limited
+	-Xfpus_div
+	-Xfpu_mac
+	-Xfpuda
+	-Xfpus_mpy_slow
+	-Xfpus_div_slow
 	-Xtimer0
 	-Xtimer0_level=1
 	-Xtimer1
--- a/boards/arc/nsim/support/mdb_sem.args
+++ b/boards/arc/nsim/support/mdb_sem.args
@@ -14,6 +14,11 @@
 	-Xdsp_complex
 	-Xdsp_divsqrt=radix2
 	-Xdsp_accshift=limited
+	-Xfpus_div
+	-Xfpu_mac
+	-Xfpuda
+	-Xfpus_mpy_slow
+	-Xfpus_div_slow
 	-Xtimer0
 	-Xtimer0_level=1
 	-Xtimer1
--- a/boards/arc/nsim/support/nsim_em7d_v22.props
+++ b/boards/arc/nsim/support/nsim_em7d_v22.props
@@ -19,6 +19,11 @@
 	nsim_isa_dsp_complex_option=1
 	nsim_isa_dsp_divsqrt_option=1
 	nsim_isa_dsp_accshift_option=1
+	nsim_isa_fpuda_option=1
+	nsim_isa_fpus_div_option=1
+	nsim_isa_fpu_mac_option=1
+	nsim_isa_fpu_fast_mpy_option=0
+	nsim_isa_fpu_fast_div_option=0
 	nsim_isa_enable_timer_0=1
 	nsim_isa_timer_0_int_level=1
 	nsim_isa_enable_timer_1=1
--- a/boards/arc/nsim/support/nsim_sem.props
+++ b/boards/arc/nsim/support/nsim_sem.props
@@ -19,6 +19,11 @@
 	nsim_isa_dsp_complex_option=1
 	nsim_isa_dsp_divsqrt_option=1
 	nsim_isa_dsp_accshift_option=1
+	nsim_isa_fpuda_option=1
+	nsim_isa_fpus_div_option=1
+	nsim_isa_fpu_mac_option=1
+	nsim_isa_fpu_fast_mpy_option=0
+	nsim_isa_fpu_fast_div_option=0
 	nsim_isa_enable_timer_0=1
 	nsim_isa_timer_0_int_level=1
 	nsim_isa_enable_timer_1=1
--- a/boards/arc/nsim/support/nsim_sem_mpu_stack_guard.args
+++ b/boards/arc/nsim/support/nsim_sem_mpu_stack_guard.args
@@ -14,6 +14,11 @@
 	-Xdsp_complex
 	-Xdsp_divsqrt=radix2
 	-Xdsp_accshift=limited
+	-Xfpus_div
+	-Xfpu_mac
+	-Xfpuda
+	-Xfpus_mpy_slow
+	-Xfpus_div_slow
 	-Xtimer0
 	-Xtimer0_level=1
 	-Xtimer1
--- a/boards/arc/nsim/support/nsim_sem_mpu_stack_guard.props
+++ b/boards/arc/nsim/support/nsim_sem_mpu_stack_guard.props
@@ -19,6 +19,11 @@
 	nsim_isa_dsp_complex_option=1
 	nsim_isa_dsp_divsqrt_option=1
 	nsim_isa_dsp_accshift_option=1
+	nsim_isa_fpuda_option=1
+	nsim_isa_fpus_div_option=1
+	nsim_isa_fpu_mac_option=1
+	nsim_isa_fpu_fast_mpy_option=0
+	nsim_isa_fpu_fast_div_option=0
 	nsim_isa_enable_timer_0=1
 	nsim_isa_timer_0_int_level=1
 	nsim_isa_enable_timer_1=1
--- a/boards/arm/adafruit_kb2040/adafruit_kb2040.dts
+++ b/boards/arm/adafruit_kb2040/adafruit_kb2040.dts
@@ -16,6 +16,7 @@
 	chosen {
 		zephyr,sram = &sram0;
 		zephyr,flash = &flash0;
+		zephyr,flash-controller = &ssi;
 		zephyr,console = &uart0;
 		zephyr,shell-uart = &uart0;
 		zephyr,code-partition = &code_partition;
--- a/boards/arm/arduino_portenta_h7/doc/index.rst
+++ b/boards/arm/arduino_portenta_h7/doc/index.rst
@@ -108,7 +108,7 @@ Here is an example for the :ref:`hello_world` application.

 Run a serial host program to connect with your board:

-code-block:: console
+.. code-block:: console

   $ minicom -D /dev/ttyACM0

--- a/boards/arm/decawave_dwm1001_dev/board.cmake
+++ b/boards/arm/decawave_dwm1001_dev/board.cmake
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: Apache-2.0

-board_runner_args(jlink "--device=nRF52832_xxAA" "--speed=4000")
+board_runner_args(jlink "--device=nRF52832_xxAA" "--speed=4000" "--reset-after-load")
 board_runner_args(pyocd "--target=nrf52832")
 set(OPENOCD_NRF5_SUBFAMILY "nrf52")
 include(${ZEPHYR_BASE}/boards/common/jlink.board.cmake)
--- a/boards/arm/decawave_dwm1001_dev/decawave_dwm1001_dev-pinctrl.dtsi
+++ b/boards/arm/decawave_dwm1001_dev/decawave_dwm1001_dev-pinctrl.dtsi
@@ -23,6 +23,7 @@
 		group1 {
 			psels = <NRF_PSEL(TWIM_SDA, 0, 29)>,
 				<NRF_PSEL(TWIM_SCL, 0, 28)>;
+			bias-pull-up;
 		};
 	};

--- a/boards/arm/gd32a503v_eval/gd32a503v_eval.yaml
+++ b/boards/arm/gd32a503v_eval/gd32a503v_eval.yaml
--- a/boards/arm/google_dragonclaw/doc/index.rst
+++ b/boards/arm/google_dragonclaw/doc/index.rst
@@ -44,7 +44,7 @@ References
 .. target-notes::

 .. _Dragonclaw Schematics:
-   https://chromium.googlesource.com/chromiumos/platform/ec/+/HEAD/docs/schematics/dragonclaw
+   https://www.chromium.org/chromium-os/dragonclaw/dragonclaw_v0.2.html

 .. _Chromium EC Flashing Documentation:
   https://chromium.googlesource.com/chromiumos/platform/ec#Flashing-via-the-servo-debug-board
--- a/boards/arm/lpcxpresso55s69/lpcxpresso55s69-pinctrl.dtsi
+++ b/boards/arm/lpcxpresso55s69/lpcxpresso55s69-pinctrl.dtsi
@@ -67,7 +67,8 @@
 	pinmux_lpadc0: pinmux_lpadc0 {
 		group0 {
 			pinmux = <ADC0_CH0_PIO0_23>,
-				<ADC0_CH1_PIO0_10>;
+				<ADC0_CH1_PIO0_10>,
+				<ADC0_CH8_PIO0_16>;
 			slew-rate = "standard";
 			nxp,analog-mode;
 		};
--- a/boards/arm/npcx7m6fb_evb/doc/index.rst
+++ b/boards/arm/npcx7m6fb_evb/doc/index.rst
@@ -1,7 +1,7 @@
 .. _npcx7m6fb_evb:

-NPCX7M6FB_EVB
-###################
+Nuvoton NPCX7M6FB_EVB
+#####################

 Overview
 ********
--- a/boards/arm/npcx9m6f_evb/doc/index.rst
+++ b/boards/arm/npcx9m6f_evb/doc/index.rst
@@ -1,7 +1,7 @@
 .. _npcx9m6f_evb:

-NPCX9M6F_EVB
-###################
+Nuvoton NPCX9M6F_EVB
+####################

 Overview
 ********
--- a/boards/arm/nrf52840dongle_nrf52840/Kconfig
+++ b/boards/arm/nrf52840dongle_nrf52840/Kconfig
@@ -1,6 +1,6 @@
 # nRF52840 Dongle NRF52840 board configuration

-# Copyright (c) 2018 Nordic Semiconductor ASA
+# Copyright (c) 2018-2023 Nordic Semiconductor ASA
 # SPDX-License-Identifier: Apache-2.0

 if BOARD_NRF52840DONGLE_NRF52840
@@ -22,4 +22,8 @@ config BOARD_HAS_NRF5_BOOTLOADER
 	  If selected, applications are linked so that they can be loaded by Nordic
 	  nRF5 bootloader.

+config BOARD_SERIAL_BACKEND_CDC_ACM
+	bool "USB CDC"
+	default y
+
 endif # BOARD_NRF52840DONGLE_NRF52840
--- a/boards/arm/nrf52840dongle_nrf52840/Kconfig.defconfig
+++ b/boards/arm/nrf52840dongle_nrf52840/Kconfig.defconfig
@@ -1,6 +1,6 @@
 # nRF52840 Dongle NRF52840 board configuration
 #
-# Copyright (c) 2018 Nordic Semiconductor ASA
+# Copyright (c) 2018-2023 Nordic Semiconductor ASA
 #
 # SPDX-License-Identifier: Apache-2.0

@@ -24,6 +24,44 @@ config FLASH_LOAD_OFFSET
 	default 0x1000
 	depends on BOARD_HAS_NRF5_BOOTLOADER && !USE_DT_CODE_PARTITION

+if BOARD_SERIAL_BACKEND_CDC_ACM
+
+config USB_DEVICE_STACK
+	default y
+
+config USB_CDC_ACM
+	default y
+
+config UART_CONSOLE
+	default CONSOLE
+
+config USB_DEVICE_INITIALIZE_AT_BOOT
+	default y if !MCUBOOT
+
+config SHELL_BACKEND_SERIAL_CHECK_DTR
+	default SHELL
+
+config USB_DEVICE_REMOTE_WAKEUP
+	default n
+
+if LOG
+
+# Logger cannot use itself to log
+choice USB_CDC_ACM_LOG_LEVEL_CHOICE
+	default USB_CDC_ACM_LOG_LEVEL_OFF
+endchoice
+
+# Set USB log level to error only
+choice USB_DEVICE_LOG_LEVEL_CHOICE
+	default USB_DEVICE_LOG_LEVEL_ERR
+endchoice
+
+# Wait 4000ms at startup for logging
+config LOG_PROCESS_THREAD_STARTUP_DELAY_MS
+	default 4000
+
+endif # LOG
+
 if USB_DEVICE_STACK

 # Enable UART driver, needed for CDC ACM
@@ -32,6 +70,8 @@ config SERIAL

 endif # USB_DEVICE_STACK

+endif # BOARD_SERIAL_BACKEND_CDC_ACM
+
 config BT_CTLR
 	default BT

--- a/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840.dts
+++ b/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840.dts
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2018 Nordic Semiconductor ASA
+ * Copyright (c) 2018-2023 Nordic Semiconductor ASA
 * Copyright (c) 2017 Linaro Limited
 *
 * SPDX-License-Identifier: Apache-2.0
@@ -14,11 +14,11 @@
 	compatible = "nordic,nrf52840-dongle-nrf52840";

 	chosen {
-		zephyr,console = &uart0;
-		zephyr,shell-uart = &uart0;
-		zephyr,uart-mcumgr = &uart0;
-		zephyr,bt-mon-uart = &uart0;
-		zephyr,bt-c2h-uart = &uart0;
+		zephyr,console = &cdc_acm_uart;
+		zephyr,shell-uart = &cdc_acm_uart;
+		zephyr,uart-mcumgr = &cdc_acm_uart;
+		zephyr,bt-mon-uart = &cdc_acm_uart;
+		zephyr,bt-c2h-uart = &cdc_acm_uart;
 		zephyr,sram = &sram0;
 		zephyr,flash = &flash0;
 		zephyr,code-partition = &slot0_partition;
@@ -173,4 +173,8 @@
 zephyr_udc0: &usbd {
 	compatible = "nordic,nrf-usbd";
 	status = "okay";
+
+	cdc_acm_uart: cdc_acm_uart {
+		compatible = "zephyr,cdc-acm-uart";
+	};
 };
--- a/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840_defconfig
+++ b/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840_defconfig
@@ -18,3 +18,9 @@ CONFIG_GPIO_AS_PINRESET=y
 CONFIG_NFCT_PINS_AS_GPIOS=y

 CONFIG_PINCTRL=y
+
+# Board Kconfig.defconfig enables USB CDC ACM and should disable USB remote
+# wakeup by default. It needs to be disabled here, because the USB nrfx
+# driver always overwrites option from Kconfig mentioned above with the
+# imply from CONFIG_USB_NRFX.
+CONFIG_USB_DEVICE_REMOTE_WAKEUP=n
--- a/boards/arm/nucleo_f746zg/nucleo_f746zg.dts
+++ b/boards/arm/nucleo_f746zg/nucleo_f746zg.dts
@@ -74,16 +74,16 @@

 &pll {
 	div-m = <4>;
-	mul-n = <216>;
+	mul-n = <192>;
 	div-p = <2>;
-	div-q = <9>;
+	div-q = <8>;
 	clocks = <&clk_hse>;
 	status = "okay";
 };

 &rcc {
 	clocks = <&pll>;
-	clock-frequency = <DT_FREQ_M(216)>;
+	clock-frequency = <DT_FREQ_M(192)>;
 	ahb-prescaler = <1>;
 	apb1-prescaler = <4>;
 	apb2-prescaler = <2>;
--- a/boards/arm/nucleo_g0b1re/nucleo_g0b1re.dts
+++ b/boards/arm/nucleo_g0b1re/nucleo_g0b1re.dts
@@ -20,6 +20,7 @@
 		zephyr,sram = &sram0;
 		zephyr,flash = &flash0;
 		zephyr,code-partition = &slot0_partition;
+		zephyr,canbus = &can1;
 	};

 	power-states {
@@ -183,6 +184,16 @@ zephyr_udc0: &usb {
 	pinctrl-names = "default";
 };

+&can1 {
+	clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00001000>,
+		 <&rcc STM32_SRC_PLL_Q FDCAN_SEL(1)>;
+	pinctrl-0 = <&fdcan1_rx_pa11 &fdcan1_tx_pa12>;
+	pinctrl-names = "default";
+	bus-speed = <125000>;
+	bus-speed-data = <1000000>;
+	status = "okay";
+};
+
 &flash0 {
 	partitions {
 		compatible = "fixed-partitions";
--- a/boards/arm/nucleo_g431rb/Kconfig.defconfig
+++ b/boards/arm/nucleo_g431rb/Kconfig.defconfig
@@ -12,4 +12,8 @@ config SPI_STM32_INTERRUPT
 	default y
 	depends on SPI

+# LPTIM clocked by LSE, force tick freq to 4096 for tick accuracy
+config SYS_CLOCK_TICKS_PER_SEC
+	default 4096 if STM32_LPTIM_TIMER
+
 endif # BOARD_NUCLEO_G431RB
--- a/boards/arm/nucleo_g431rb/nucleo_g431rb.dts
+++ b/boards/arm/nucleo_g431rb/nucleo_g431rb.dts
@@ -56,6 +56,10 @@
 	status = "okay";
 };

+&clk_lse {
+	status = "okay";
+};
+
 &clk_hse {
 	clock-frequency = <DT_FREQ_M(24)>;
 	status = "okay";
@@ -131,6 +135,12 @@
 	};
 };

+&lptim1 {
+	clocks = <&rcc STM32_CLOCK_BUS_APB1 0x80000000>,
+		 <&rcc STM32_SRC_LSE LPTIM1_SEL(3)>;
+	status = "okay";
+};
+
 &rtc {
 	clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00000400>,
 		 <&rcc STM32_SRC_LSI RTC_SEL(2)>;
--- a/boards/arm/rpi_pico/rpi_pico_defconfig
+++ b/boards/arm/rpi_pico/rpi_pico_defconfig
@@ -1,6 +1,5 @@
 CONFIG_SOC_SERIES_RP2XXX=y
 CONFIG_SOC_RP2040=y
-CONFIG_ARM_MPU=y
 CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=125000000
 CONFIG_SERIAL=y
 CONFIG_CONSOLE=y
--- a/boards/arm/s32z270dc2_r52/doc/index.rst
+++ b/boards/arm/s32z270dc2_r52/doc/index.rst
@@ -29,9 +29,17 @@ The boards support the following hardware features:
 +-----------+------------+-------------------------------------+
 | Interface | Controller | Driver/Component                    |
 +===========+============+=====================================+
-| GIC       | on-chip    | interrupt_controller                |
+| Arm GIC   | on-chip    | interrupt_controller                |
 +-----------+------------+-------------------------------------+
-| ARM Timer | on-chip    | timer                               |
+| Arm Timer | on-chip    | timer                               |
+-----------+------------+-------------------------------------+
+| LINFlexD  | on-chip    | serial                              |
+-----------+------------+-------------------------------------+
+| MRU       | on-chip    | mbox                                |
+-----------+------------+-------------------------------------+
+| NETC      | on-chip    | ethernet                            |
+|           |            |                                     |
+|           |            | mdio                                |
 +-----------+------------+-------------------------------------+
 | SIUL2     | on-chip    | pinctrl                             |
 |           |            |                                     |
@@ -39,8 +47,6 @@ The boards support the following hardware features:
 |           |            |                                     |
 |           |            | external interrupt controller       |
 +-----------+------------+-------------------------------------+
-| LINFlexD  | on-chip    | serial                              |
-+-----------+------------+-------------------------------------+
 | SPI       | on-chip    | spi                                 |
 +-----------+------------+-------------------------------------+
 | SWT       | on-chip    | watchdog                            |
@@ -110,8 +116,17 @@ remaining are disabled and not configured.
 Watchdog
 ========

-Currently Watchdog only supports interrupt triggering, but does not support
-reset function because currently the board does not support running on flash.
+The watchdog driver only supports triggering an interrupt upon timer expiration.
+Zephyr is currently running from SRAM on this board, thus system reset is not
+supported.
+
+Ethernet
+========
+
+NETC driver supports to manage the Physical Station Interface (PSI0) and/or a
+single Virtual SI (VSI). The rest of the VSI's shall be assigned to different
+cores of the system. Refer to :ref:`nxp_s32_netc-samples` to learn how to
+configure the Ethernet network controller.

 Programming and Debugging
 *************************
--- a/boards/arm/stm32f429i_disc1/stm32f429i_disc1.dts
+++ b/boards/arm/stm32f429i_disc1/stm32f429i_disc1.dts
@@ -137,7 +137,7 @@
 		timctrlb = [00 00];
 		pwseqctrl = [64 03 12 81];
 		pumpratioctrl = [20];
-		disctrl = [08 82 27];
+		disctrl = [08 82 27 04];
 		vmctrl1 = [45 15];
 		vmctrl2 = [90];
 		enable3g = [00];
--- a/boards/arm/thingy53_nrf5340/Kconfig.defconfig
+++ b/boards/arm/thingy53_nrf5340/Kconfig.defconfig
@@ -114,12 +114,14 @@ config USB_DEVICE_REMOTE_WAKEUP
 if LOG

 # Logger cannot use itself to log
-config USB_CDC_ACM_LOG_LEVEL
-	default 0
+choice USB_CDC_ACM_LOG_LEVEL_CHOICE
+	default USB_CDC_ACM_LOG_LEVEL_OFF
+endchoice

 # Set USB log level to error only
-config USB_DEVICE_LOG_LEVEL
-	default 1
+choice USB_DEVICE_LOG_LEVEL_CHOICE
+	default USB_DEVICE_LOG_LEVEL_ERR
+endchoice

 # Wait 4000ms at startup for logging
 config LOG_PROCESS_THREAD_STARTUP_DELAY_MS
--- a/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp_defconfig
+++ b/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp_defconfig
@@ -24,3 +24,9 @@ CONFIG_UART_CONSOLE=y
 CONFIG_SERIAL=y

 CONFIG_PINCTRL=y
+
+# Board Kconfig.defconfig enables USB CDC ACM and should disable USB remote
+# wakeup by default. It needs to be disabled here, because the USB nrfx
+# driver always overwrites option from Kconfig mentioned above with the
+# imply from CONFIG_USB_NRFX.
+CONFIG_USB_DEVICE_REMOTE_WAKEUP=n
--- a/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp_ns_defconfig
+++ b/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp_ns_defconfig
@@ -27,3 +27,9 @@ CONFIG_UART_CONSOLE=y
 CONFIG_SERIAL=y

 CONFIG_PINCTRL=y
+
+# Board Kconfig.defconfig enables USB CDC ACM and should disable USB remote
+# wakeup by default. It needs to be disabled here, because the USB nrfx
+# driver always overwrites option from Kconfig mentioned above with the
+# imply from CONFIG_USB_NRFX.
+CONFIG_USB_DEVICE_REMOTE_WAKEUP=n
--- a/boards/posix/doc/arch_soc.rst
+++ b/boards/posix/doc/arch_soc.rst
@@ -26,7 +26,7 @@ target hardware in the early phases of development.

   The POSIX architecture is not related and should not be confused with the
   :ref:`POSIX OS abstraction<posix_support>`.
-   The later provides an adapatation shim that enables running applications
+   The latter provides an adaptation shim that enables running applications
   which require POSIX APIs on Zephyr.


@@ -350,10 +350,10 @@ and this thread will check what is the next
 scheduled HW event, advance simulated time until that point, and call the
 corresponding HW model event function.

-Eventually one of these HW models will raise an interrupt to the simulated CPU.
-When the IRQ controller wants to wake the simulated CPU, the HW thread is
-blocked, and the simulated CPU is awaken by letting the last SW thread continue
-executing.
+Eventually one of these HW models will raise an interrupt to the
+simulated CPU. When the IRQ controller wants to wake the simulated
+CPU, the HW thread is blocked, and the simulated CPU is awakened by
+letting the last SW thread continue executing.

 This process of getting the CPU to sleep, letting the HW models run,
 and raising an interrupt which wake the CPU again is repeated until the end
--- a/boards/posix/native_posix/native_posix_64.yaml
+++ b/boards/posix/native_posix/native_posix_64.yaml
@@ -1,6 +1,7 @@
 identifier: native_posix_64
 name: Native 64-bit POSIX port
 type: native
+simulation: native
 arch: posix
 ram: 65536
 flash: 65536
--- a/boards/riscv/esp32c3_devkitm/Kconfig.defconfig
+++ b/boards/riscv/esp32c3_devkitm/Kconfig.defconfig
@@ -7,13 +7,11 @@ config BOARD
 	default "esp32c3_devkitm"
 	depends on BOARD_ESP32C3_DEVKITM

-if BT
-
 config HEAP_MEM_POOL_SIZE
-	default 16384
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096

 choice BT_HCI_BUS_TYPE
-	default BT_ESP32
+	default BT_ESP32 if BT
 endchoice
-
-endif # BT
--- a/boards/riscv/icev_wireless/Kconfig.defconfig
+++ b/boards/riscv/icev_wireless/Kconfig.defconfig
@@ -5,13 +5,11 @@ config BOARD
 	default "icev_wireless"
 	depends on BOARD_ICEV_WIRELESS

-if BT
-
 config HEAP_MEM_POOL_SIZE
-	default 16384
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096

 choice BT_HCI_BUS_TYPE
-	default BT_ESP32
+	default BT_ESP32 if BT
 endchoice
-
-endif # BT
--- a/boards/riscv/xiao_esp32c3/Kconfig.defconfig
+++ b/boards/riscv/xiao_esp32c3/Kconfig.defconfig
@@ -10,10 +10,6 @@ config HEAP_MEM_POOL_SIZE
 	default 16384 if BT
 	default 4096

-if BT
-
 choice BT_HCI_BUS_TYPE
-	default BT_ESP32
+	default BT_ESP32 if BT
 endchoice
-
-endif # BT
--- a/boards/xtensa/esp32/Kconfig.defconfig
+++ b/boards/xtensa/esp32/Kconfig.defconfig
@@ -7,16 +7,14 @@ config BOARD
 	default "esp32"
 	depends on BOARD_ESP32

-if BT
-
-config HEAP_MEM_POOL_SIZE
-	default 16384
-
 config ENTROPY_GENERATOR
 	default y

-choice BT_HCI_BUS_TYPE
-	default BT_ESP32
-endchoice
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096

-endif # BT
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
--- a/boards/xtensa/esp32_ethernet_kit/Kconfig.defconfig
+++ b/boards/xtensa/esp32_ethernet_kit/Kconfig.defconfig
@@ -7,9 +7,6 @@ config BOARD
 	default "esp32_ethernet_kit"
 	depends on BOARD_ESP32_ETHERNET_KIT

-config ENTROPY_ESP32_RNG
-	default y if ENTROPY_GENERATOR
-
 config ESP_SPIRAM
 	default y

@@ -17,16 +14,14 @@ choice SPIRAM_TYPE
 	default SPIRAM_TYPE_ESPPSRAM64
 endchoice

-if BT
-
-config HEAP_MEM_POOL_SIZE
-	default 16384
-
 config ENTROPY_GENERATOR
 	default y

-choice BT_HCI_BUS_TYPE
-	default BT_ESP32
-endchoice
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096

-endif # BT
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
--- a/boards/xtensa/esp32_net/Kconfig.defconfig
+++ b/boards/xtensa/esp32_net/Kconfig.defconfig
@@ -7,19 +7,14 @@ config BOARD
 	default "esp32_net"
 	depends on BOARD_ESP32_NET

-config ENTROPY_ESP32_RNG
-	default y if ENTROPY_GENERATOR
-
-if BT
-
-config HEAP_MEM_POOL_SIZE
-	default 16384
-
 config ENTROPY_GENERATOR
 	default y

-choice BT_HCI_BUS_TYPE
-	default BT_ESP32
-endchoice
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096

-endif # BT
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
--- a/boards/xtensa/esp32s2_franzininho/Kconfig.defconfig
+++ b/boards/xtensa/esp32s2_franzininho/Kconfig.defconfig
@@ -9,3 +9,12 @@ config BOARD

 config ENTROPY_GENERATOR
 	default y
+
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096
+
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
--- a/boards/xtensa/esp32s2_saola/Kconfig.defconfig
+++ b/boards/xtensa/esp32s2_saola/Kconfig.defconfig
@@ -9,3 +9,12 @@ config BOARD

 config ENTROPY_GENERATOR
 	default y
+
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096
+
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
--- a/boards/xtensa/esp_wrover_kit/Kconfig.defconfig
+++ b/boards/xtensa/esp_wrover_kit/Kconfig.defconfig
@@ -7,19 +7,14 @@ config BOARD
 	default "esp_wrover_kit"
 	depends on BOARD_ESP_WROVER_KIT

-if BT
-
 config HEAP_MEM_POOL_SIZE
-	default 16384
-
-config ENTROPY_GENERATOR
-	default y
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096

 choice BT_HCI_BUS_TYPE
-	default BT_ESP32
+	default BT_ESP32 if BT
 endchoice

-endif # BT
-
 config DISK_DRIVER_SDMMC
 	default y
--- a/boards/xtensa/heltec_wifi_lora32_v2/Kconfig.defconfig
+++ b/boards/xtensa/heltec_wifi_lora32_v2/Kconfig.defconfig
@@ -6,3 +6,15 @@
 config BOARD
 	default "heltec_wifi_lora32"
 	depends on BOARD_HELTEC_WIFI_LORA32
+
+config ENTROPY_GENERATOR
+	default y
+
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096
+
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
--- a/boards/xtensa/m5stickc_plus/Kconfig.defconfig
+++ b/boards/xtensa/m5stickc_plus/Kconfig.defconfig
@@ -7,19 +7,14 @@ config BOARD
 	default "m5stickc_plus"
 	depends on BOARD_M5STICKC_PLUS

-config ENTROPY_ESP32_RNG
-	default y if ENTROPY_GENERATOR
-
-if BT
-
-config HEAP_MEM_POOL_SIZE
-	default 16384
-
 config ENTROPY_GENERATOR
 	default y

-choice BT_HCI_BUS_TYPE
-	default BT_ESP32
-endchoice
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096

-endif # BT
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
--- a/boards/xtensa/odroid_go/Kconfig.defconfig
+++ b/boards/xtensa/odroid_go/Kconfig.defconfig
@@ -13,16 +13,14 @@ config DISK_DRIVER_SDMMC
 config SPI
 	default y if DISK_DRIVER_SDMMC

-if BT
-
-config HEAP_MEM_POOL_SIZE
-	default 16384
-
 config ENTROPY_GENERATOR
 	default y

-choice BT_HCI_BUS_TYPE
-	default BT_ESP32
-endchoice
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096

-endif # BT
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
--- a/boards/xtensa/olimex_esp32_evb/Kconfig.defconfig
+++ b/boards/xtensa/olimex_esp32_evb/Kconfig.defconfig
@@ -8,4 +8,16 @@ if BOARD_OLIMEX_ESP32_EVB
 config BOARD
 	default "olimex_esp32_evb"

+config ENTROPY_GENERATOR
+	default y
+
+config HEAP_MEM_POOL_SIZE
+	default 98304 if WIFI
+	default 16384 if BT
+	default 4096
+
+choice BT_HCI_BUS_TYPE
+	default BT_ESP32 if BT
+endchoice
+
 endif # BOARD_OLIMEX_ESP32_EVB
--- a/cmake/compiler/clang/compiler_flags.cmake
+++ b/cmake/compiler/clang/compiler_flags.cmake
@@ -7,6 +7,9 @@ include(${ZEPHYR_BASE}/cmake/compiler/gcc/compiler_flags.cmake)
 set_compiler_property(PROPERTY security_fortify_compile_time)
 set_compiler_property(PROPERTY security_fortify_run_time)

+# No printf-return-value optimizations in clang
+set_compiler_property(PROPERTY no_printf_return_value)
+
 # No property flag, this is used by the native_posix, clang has problems
 # compiling the native_posix with -fno-freestanding.
 check_set_compiler_property(PROPERTY hosted)
--- a/cmake/compiler/clang/generic.cmake
+++ b/cmake/compiler/clang/generic.cmake
@@ -4,7 +4,7 @@ if(DEFINED TOOLCHAIN_HOME)
  set(find_program_clang_args PATHS ${TOOLCHAIN_HOME} NO_DEFAULT_PATH)
 endif()

-find_program(CMAKE_C_COMPILER clang ${find_program_clang_args})
+find_program(CMAKE_C_COMPILER clang ${find_program_clang_args} REQUIRED)
 find_program(CMAKE_CXX_COMPILER clang++ ${find_program_clang_args})
 find_program(CMAKE_LLVM_COV llvm-cov ${find_program_clang_args})
 set(CMAKE_GCOV "${CMAKE_LLVM_COV} gcov")
--- a/cmake/compiler/host-gcc/generic.cmake
+++ b/cmake/compiler/host-gcc/generic.cmake
@@ -2,5 +2,5 @@

 # Configures CMake for using GCC

-find_program(CMAKE_C_COMPILER gcc)
+find_program(CMAKE_C_COMPILER gcc REQUIRED)
 find_program(CMAKE_GCOV gcov)
--- a/cmake/compiler/xcc-clang/compiler_flags.cmake
+++ b/cmake/compiler/xcc-clang/compiler_flags.cmake
@@ -2,10 +2,26 @@

 include(${ZEPHYR_BASE}/cmake/compiler/clang/compiler_flags.cmake)

-# Clear "nostdinc"
+# nostdinc_include contains path to llvm headers and also relative
+# path of "include-fixed".
+# Clear "nostdinc" and nostdinc_include
 set_compiler_property(PROPERTY nostdinc)
 set_compiler_property(PROPERTY nostdinc_include)

+# For C++ code, re-add the standard includes directory which was
+# cleared up from nostdinc_inlcude in above lines with no
+# "include-fixed" this time"
+if(CONFIG_CPP)
+  execute_process(
+    COMMAND ${CMAKE_C_COMPILER} --print-file-name=include/stddef.h
+    OUTPUT_VARIABLE _OUTPUT
+    COMMAND_ERROR_IS_FATAL ANY
+    )
+  get_filename_component(_OUTPUT "${_OUTPUT}" DIRECTORY)
+  string(REGEX REPLACE "\n" "" _OUTPUT "${_OUTPUT}")
+  set_compiler_property(PROPERTY nostdinc_include "${_OUTPUT}")
+endif()
+
 if($ENV{XCC_NO_G_FLAG})
  # Older xcc/clang cannot use "-g" due to this bug:
  # https://bugs.llvm.org/show_bug.cgi?id=11740.
--- a/doc/_extensions/zephyr/kconfig/static/kconfig.css
+++ b/doc/_extensions/zephyr/kconfig/static/kconfig.css
@@ -15,13 +15,13 @@
 }

 #__kconfig-search .input-container input {
+    border-radius: 5px 0px 0px 5px;
    font-size: 18px;
    width: 90%;
    height: 100%;
    padding: 0.75rem;
    border: none;
    box-shadow: none !important;
-    background-color: white;
 }

 #__kconfig-search .input-container input:focus,
@@ -31,17 +31,19 @@

 #__kconfig-search .input-container button {
    font-size: 22px;
+    border-radius: 0px 5px 5px 0px;
    float: right;
    width: 10%;
    height: 100%;
    border: none;
-    background-color: white;
+    background-color: lightgrey;
 }

 #__kconfig-search select {
    border-radius: 5px;
    border: 1px solid rgba(149, 157, 165, 0.2);
    box-shadow: unset;
+    color: black;
 }

 #__kconfig-search .search-tools {
--- a/doc/_scripts/redirects.py
+++ b/doc/_scripts/redirects.py
@@ -113,6 +113,7 @@ REDIRECTS = [
    ('reference/misc/notify', 'services/notify'),
    ('reference/misc/timeutil', 'kernel/timeutil'),
    ('reference/modbus/index', 'services/modbus/index'),
+    ('reference/networking/sockets', 'connectivity/networking/api/sockets'),
    ('reference/peripherals/adc', 'hardware/peripherals/adc'),
    ('reference/peripherals/dac', 'hardware/peripherals/dac'),
    ('reference/peripherals/dma', 'hardware/peripherals/dma'),
--- a/doc/_static/js/ga-tracker.js
+++ b/doc/_static/js/ga-tracker.js
@@ -1,10 +0,0 @@
-// <!-- Global site tag (gtag.js) - Google Analytics -->
-
-// Copyright (c) 2019, Intel Corporation
-// SPDX-License-Identifier: Apache-2.0
-
-
-  window.dataLayer = window.dataLayer || [];
-  function gtag(){dataLayer.push(arguments);}
-  gtag('js', new Date());
-  gtag('config', 'UA-831873-47');
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -36,7 +36,7 @@ except ImportError:
 # -- Project --------------------------------------------------------------

 project = "Zephyr Project"
-copyright = "2015-2022 Zephyr Project members and individual contributors"
+copyright = "2015-2023 Zephyr Project members and individual contributors"
 author = "The Zephyr Project Contributors"

 # parse version from 'VERSION' file
@@ -137,6 +137,7 @@ html_theme_options = {
    "logo_only": True,
    "prev_next_buttons_location": None
 }
+html_baseurl = "https://docs.zephyrproject.org/latest/"
 html_title = "Zephyr Project Documentation"
 html_logo = str(ZEPHYR_BASE / "doc" / "_static" / "images" / "logo.svg")
 html_favicon = str(ZEPHYR_BASE / "doc" / "_static" / "images" / "favicon.png")
@@ -160,10 +161,11 @@ html_context = {
    "current_version": version,
    "versions": (
        ("latest", "/"),
+        ("3.3.0", "/3.3.0/"),
        ("3.2.0", "/3.2.0/"),
        ("3.1.0", "/3.1.0/"),
        ("3.0.0", "/3.0.0/"),
-        ("2.7.0", "/2.7.0/"),
+        ("2.7.4 (LTS)", "/2.7.4/"),
        ("2.6.0", "/2.6.0/"),
        ("2.5.0", "/2.5.0/"),
        ("2.4.0", "/2.4.0/"),
@@ -324,6 +326,3 @@ def setup(app):
    # theme customizations
    app.add_css_file("css/custom.css")
    app.add_js_file("js/dark-mode-toggle.min.mjs", type="module")
-
-    app.add_js_file("https://www.googletagmanager.com/gtag/js?id=UA-831873-47")
-    app.add_js_file("js/ga-tracker.js")
--- a/doc/connectivity/bluetooth/bluetooth-shell.rst
+++ b/doc/connectivity/bluetooth/bluetooth-shell.rst
@@ -0,0 +1,397 @@
+.. _bluetooth_shell:
+
+Bluetooth Shell
+###############
+
+The Bluetooth Shell is an application based on the :ref:`shell_api` module. It offer a collection of
+commands made to easily interact with the Bluetooth stack.
+
+Bluetooth Shell Setup and Usage
+*******************************
+
+First you need to build and flash your board with the Bluetooth shell. For how to do that, see the
+:ref:`getting_started`. The Bluetooth shell itself is located in
+:zephyr_file:`tests/bluetooth/shell/`.
+
+When it's done, connect to the CLI using your favorite serial terminal application. You should see
+the following prompt:
+
+.. code-block:: console
+
+        uart:~$
+
+For more details on general usage of the shell, see :ref:`shell_api`.
+
+The first step is enabling Bluetooth. To do so, use the :code:`bt init` command. The following
+message is printed to confirm Bluetooth has been initialized.
+
+.. code-block:: console
+
+        uart:~$ bt init
+        Bluetooth initialized
+        Settings Loaded
+        [00:02:26.771,148] <inf> fs_nvs: nvs_mount: 8 Sectors of 4096 bytes
+        [00:02:26.771,148] <inf> fs_nvs: nvs_mount: alloc wra: 0, fe8
+        [00:02:26.771,179] <inf> fs_nvs: nvs_mount: data wra: 0, 0
+        [00:02:26.777,984] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
+        [00:02:26.778,015] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
+        [00:02:26.778,045] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 3.2 Build 99
+        [00:02:26.778,656] <inf> bt_hci_core: bt_init: No ID address. App must call settings_load()
+        [00:02:26.794,738] <inf> bt_hci_core: bt_dev_show_info: Identity: EB:BF:36:26:42:09 (random)
+        [00:02:26.794,769] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1
+        [00:02:26.794,799] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0xffff
+
+
+Identities
+**********
+
+Identities are a Zephyr host concept, allowing a single physical device to behave like multiple
+logical Bluetooth devices.
+
+The shell allows the creation of multiple identities, to a maximum that is set by the Kconfig symbol
+:kconfig:option:`CONFIG_BT_ID_MAX`. To create a new identity, use :code:`bt id-create` command. You
+can then use it by selecting it with its ID :code:`bt id-select <id>`. Finally, you can list all the
+available identities with :code:`id-show`.
+
+Scan for devices
+****************
+
+Start scanning by using the :code:`bt scan on` command. Depending on the environment you're in, you
+may see a lot of lines printed on the shell. To stop the scan, run :code:`bt scan off`, the
+scrolling should stop.
+
+Here is an example of what you can expect:
+
+.. code-block:: console
+
+        uart:~$ bt scan on
+        Bluetooth active scan enabled
+        [DEVICE]: CB:01:1A:2D:6E:AE (random), AD evt type 0, RSSI -78  C:1 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
+        [DEVICE]: 20:C2:EE:59:85:5B (random), AD evt type 3, RSSI -62  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
+        [DEVICE]: E3:72:76:87:2F:E8 (random), AD evt type 3, RSSI -74  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
+        [DEVICE]: 1E:19:25:8A:CB:84 (random), AD evt type 3, RSSI -67  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
+        [DEVICE]: 26:42:F3:D5:A0:86 (random), AD evt type 3, RSSI -73  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
+        [DEVICE]: 0C:61:D1:B9:5D:9E (random), AD evt type 3, RSSI -87  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
+        [DEVICE]: 20:C2:EE:59:85:5B (random), AD evt type 3, RSSI -66  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
+        [DEVICE]: 25:3F:7A:EE:0F:55 (random), AD evt type 3, RSSI -83  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 us), SID: 0xff
+        uart:~$ bt scan off
+        Scan successfully stopped
+
+As you can see, this can lead to a high number of results. To reduce that number and easily find a
+specific device, you can enable scan filters. There are four types of filters: by name, by RSSI, by
+address and by periodic advertising interval. To apply a filter, use the :code:`bt scan-set-filter`
+command followed by the type of filters. You can add multiple filters by using the commands again.
+
+For example, if you want to look only for devices with the name *test shell*:
+
+.. code-block:: console
+
+        uart:~$ bt scan-filter-set name "test shell"
+
+Or if you want to look for devices at a very close range:
+
+.. code-block:: console
+
+        uart:~$ bt scan-filter-set rssi -40
+        RSSI cutoff set at -40 dB
+
+Finally, if you want to remove all filters:
+
+.. code-block:: console
+
+        uart:~$ bt scan-filter-clear all
+
+You can use the command :code:`bt scan on` to create an *active* scanner, meaning that the scanner
+will ask the advertisers for more information by sending a *scan request* packet. Alternatively, you
+can create a *passive scanner* by using the :code:`bt scan passive` command, so the scanner will not
+ask the advertiser for more information.
+
+Connecting to a device
+**********************
+
+To connect to a device, you need to know its address and type of address and use the
+:code:`bt connect` command with the address and the type as arguments.
+
+Here is an example:
+
+.. code-block:: console
+
+        uart:~$ bt connect 52:84:F6:BD:CE:48 random
+        Connection pending
+        Connected: 52:84:F6:BD:CE:48 (random)
+        Remote LMP version 5.3 (0x0c) subversion 0xffff manufacturer 0x05f1
+        LE Features: 0x000000000001412f
+        LE PHY updated: TX PHY LE 2M, RX PHY LE 2M
+        LE conn  param req: int (0x0018, 0x0028) lat 0 to 42
+        LE conn param updated: int 0x0028 lat 0 to 42
+
+You can list the active connections of the shell using the :code:`bt connections` command. The shell
+maximum number of connections is defined by :kconfig:option:`CONFIG_BT_MAX_CONN`. You can disconnect
+from a connection with the
+:code:`bt disconnect <address: XX:XX:XX:XX:XX:XX> <type: (public|random)>` command.
+
+.. note::
+
+        If you were scanning just before, you can connect to the last scanned device by
+        simply running the :code:`bt connect` command.
+
+        Alternatively, you can use the :code:`bt connect-name <name>` command to automatically
+        enable scanning with a name filter and connect to the first match.
+
+Advertising
+***********
+
+Begin advertising by using the :code:`bt advertise on` command. This will use the default parameters
+and advertise a resolvable private address with the name of the device. You can choose to use the
+identity address instead by running the :code:`bt advertise on identity` command. To stop
+advertising use the :code:`bt advertise off` command.
+
+To enable more advanced features of advertising, you should create an advertiser using the
+:code:`bt adv-create` command. Parameters for the advertiser can be passed either at the creation of
+it or by using the :code:`bt adv-param` command. To begin advertising with this newly created
+advertiser, use the :code:`bt adv-start` command, and then the :code:`bt adv-stop` command to stop
+advertising.
+
+When using the custom advertisers, you can choose if it will be connectable or scannable. This leads
+to four options: :code:`conn-scan`, :code:`conn-nscan`, :code:`nconn-scan` and :code:`nconn-nscan`.
+Those parameters are mandatory when creating an advertiser or updating its parameters.
+
+For example, if you want to create a connectable and scannable advertiser and start it:
+
+.. code-block:: console
+
+        uart:~$ bt adv-create conn-scan
+        Created adv id: 0, adv: 0x200022f0
+        uart:~$ bt adv-start
+        Advertiser[0] 0x200022f0 set started
+
+You may notice that with this, the custom advertiser does not advertise the device name; you need to
+enable it. Continuing from the previous example:
+
+.. code-block:: console
+
+        uart:~$ bt adv-stop
+        Advertiser set stopped
+        uart:~$ bt adv-param conn-scan name
+        uart:~$ bt adv-start
+        Advertiser[0] 0x200022f0 set started
+
+You should now see the name of the device in the advertising data. You can also set the advertising
+data manually by using the :code:`bt adv-data` command. The following example shows how to set the
+advertiser name with it:
+
+.. code-block:: console
+
+        uart:~$ bt adv-create conn-scan
+        Created adv id: 0, adv: 0x20002348
+        uart:~$ bt adv-data 1009426C7565746F6F74682D5368656C6C
+        uart:~$ bt adv-start
+        Advertiser[0] 0x20002348 set started
+
+The data must be formatted according to the Bluetooth Core Specification (see version 5.3, vol. 3,
+part C, 11). In this example, the first octet is the size of the data (the data and one octet for
+the data type), the second one is the type of data, ``0x09`` is the Complete Local Name and the
+remaining data are the name in ASCII. So, on the other device you should see the name
+*Bluetooth-Shell*.
+
+When advertising, if others devices use an *active* scanner, you may receive *scan request* packets.
+To visualize those packets, you can add :code:`scan-reports` to the parameters of your advertiser.
+
+Directed Advertising
+====================
+
+It is possible to use directed advertising on the shell if you want to reconnect to a device. The
+following example demonstrates how to create a directed advertiser with the address specified right
+after the parameter :code:`directed`. The :code:`low` parameter indicates that we want to use the
+low duty cycle mode, and the :code:`dir-rpa` parameter is required if the remote device is
+privacy-enabled and supports address resolution of the target address in directed advertisement.
+
+.. code-block:: console
+
+        uart:~$ bt adv-create conn-scan directed D7:54:03:CE:F3:B4 random low dir-rpa
+        Created adv id: 0, adv: 0x20002348
+
+After that, you can start the advertiser and then the target device will be able to reconnect.
+
+Extended Advertising
+====================
+
+Let's now have a look at some extended advertising features. To enable extended advertising, use the
+`ext-adv` parameter.
+
+.. code-block:: console
+
+        uart:~$ bt adv-create conn-nscan ext-adv name-ad
+        Created adv id: 0, adv: 0x200022f0
+        uart:~$ bt adv-start
+        Advertiser[0] 0x200022f0 set started
+
+This will create an extended advertiser, that is connectable and non-scannable.
+
+Filter Accept List
+******************
+
+It's possible to create a list of allowed addresses that can be used to
+connect to those addresses automatically. Here is how to do it:
+
+.. code-block:: console
+
+        uart:~$ bt fal-add 47:38:76:EA:29:36 random
+        uart:~$ bt fal-add 66:C8:80:2A:05:73 random
+        uart:~$ bt fal-connect on
+
+The shell will then connect to the first available device. In the example, if both devices are
+advertising at the same time, we will connect to the first address added to the list.
+
+The Filter Accept List can also be used for scanning or advertising by using the option :code:`fal`.
+For example, if we want to scan for a bunch of selected addresses, we can set up a Filter Accept
+List:
+
+.. code-block:: console
+
+        uart:~$ bt fal-add 65:4B:9E:83:AF:73 random
+        uart:~$ bt fal-add 73:72:82:B4:8F:B9 random
+        uart:~$ bt fal-add 5D:85:50:1C:72:64 random
+        uart:~$ bt scan on fal
+
+You should see only those three addresses reported by the scanner.
+
+Enabling security
+*****************
+
+When connected to a device, you can enable multiple levels of security, here is the list for
+Bluetooth LE:
+
+* **1** No encryption and no authentication;
+* **2** Encryption and no authentication;
+* **3** Encryption and authentication;
+* **4** Bluetooth LE Secure Connection.
+
+To enable security, use the :code:`bt security <level>` command. For levels requiring authentication
+(level 3 and above), you must first set the authentication method. To do it, you can use the
+:code:`bt auth all` command. After that, when you will set the security level, you will be asked to
+confirm the passkey on both devices. On the shell side, do it with the command
+:code:`bt auth-passkey-confirm`.
+
+Pairing
+=======
+
+Enabling authentication requires the devices to be bondable. By default the shell is bondable. You
+can make the shell not bondable using :code:`bt bondable off`. You can list all the devices you are
+paired with using the command :code:`bt bonds`.
+
+The maximum number of paired devices is set using :kconfig:option:`CONFIG_BT_MAX_PAIRED`. You can
+remove a paired device using :code:`bt clear <address: XX:XX:XX:XX:XX:XX> <type: (public|random)>`
+or remove all paired devices with the command :code:`bt clear all`.
+
+GATT
+****
+
+The following examples assume that you have two devices already connected.
+
+To perform service discovery on the client side, use the :code:`gatt discover` command. This should
+print all the services that are available on the GATT server.
+
+On the server side, you can register pre-defined test services using the :code:`gatt register`
+command. When done, you should see the newly added services on the client side when running the
+discovery command.
+
+You can now subscribe to those new services on the client side. Here is an example on how to
+subscribe to the test service:
+
+.. code-block:: console
+
+        uart:~$ gatt subscribe 26 25
+        Subscribed
+
+The server can now notify the client with the command :code:`gatt notify`.
+
+Another option available through the GATT command is initiating the MTU exchange. To do it, use the
+:code:`gatt exchange-mtu` command. To update the shell maximum MTU, you need to update Kconfig
+symbols in the configuration file of the shell. For more details, see
+:ref:`bluetooth_mtu_update_sample`.
+
+L2CAP
+*****
+
+The :code:`l2cap` command exposes parts of the L2CAP API. The following example shows how to
+register a LE PSM, connect to it from another device and send 3 packets of 14 octets each.
+
+The example assumes that the two devices are already connected.
+
+On device A, register the LE PSM:
+
+.. code-block:: console
+
+        uart:~$ l2cap register 29
+        L2CAP psm 41 sec_level 1 registered
+
+On device B, connect to the registered LE PSM and send data:
+
+.. code-block:: console
+
+        uart:~$ l2cap connect 29
+        Chan sec: 1
+        L2CAP connection pending
+        Channel 0x20000210 connected
+        Channel 0x20000210 status 1
+        uart:~$ l2cap send 3 14
+        Rem 2
+        Rem 1
+        Rem 0
+        Outgoing data channel 0x20000210 transmitted
+        Outgoing data channel 0x20000210 transmitted
+        Outgoing data channel 0x20000210 transmitted
+
+On device A, you should have received the data:
+
+.. code-block:: console
+
+        Incoming conn 0x20002398
+        Channel 0x20000210 status 1
+        Channel 0x20000210 connected
+        Channel 0x20000210 requires buffer
+        Incoming data channel 0x20000210 len 14
+        00000000: ff ff ff ff ff ff ff ff  ff ff ff ff ff ff       |........ ......  |
+        Channel 0x20000210 requires buffer
+        Incoming data channel 0x20000210 len 14
+        00000000: ff ff ff ff ff ff ff ff  ff ff ff ff ff ff       |........ ......  |
+        Channel 0x20000210 requires buffer
+        Incoming data channel 0x20000210 len 14
+        00000000: ff ff ff ff ff ff ff ff  ff ff ff ff ff ff       |........ ......  |
+
+Logging
+*******
+
+You can configure the logging level per module at runtime. This depends on the maximum logging level
+that is compiled in. To configure, use the :code:`log` command. Here are some examples:
+
+* List the available modules and their current logging level
+
+.. code-block:: console
+
+        uart:~$ log status
+
+* Disable logging for *bt_hci_core*
+
+.. code-block:: console
+
+        uart:~$ log disable bt_hci_core
+
+* Enable error logs for *bt_att* and *bt_smp*
+
+.. code-block:: console
+
+        uart:~$ log enable err bt_att bt_smp
+
+* Disable logging for all modules
+
+.. code-block:: console
+
+        uart:~$ log disable
+
+* Enable warning logs for all modules
+
+.. code-block:: console
+
+        uart:~$ log enable wrn
--- a/doc/connectivity/bluetooth/index.rst
+++ b/doc/connectivity/bluetooth/index.rst
@@ -22,3 +22,4 @@ hardware, as well as portions of a Classical Bluetooth (BR/EDR) Host layer.
   autopts/autopts-win10.rst
   autopts/autopts-linux.rst
   api/index.rst
+   bluetooth-shell.rst
--- a/doc/connectivity/bluetooth/overview.rst
+++ b/doc/connectivity/bluetooth/overview.rst
@@ -20,7 +20,7 @@ Supported Features
 Zephyr comes integrated with a feature-rich and highly configurable
 Bluetooth stack.

-* Bluetooth 5.0 compliant (ESR10)
+* Bluetooth v5.3 compliant

  * Highly configurable

@@ -31,8 +31,8 @@ Bluetooth stack.

  * Support for all combinations of Host and Controller builds:

-    * Controller-only (HCI) over UART, SPI, and USB physical transports
-    * Host-only over UART, SPI, and IPM (shared memory)
+    * Controller-only (HCI) over UART, SPI, USB and IPC physical transports
+    * Host-only over UART, SPI, and IPC (shared memory)
    * Combined (Host + Controller)

 * Bluetooth-SIG qualified
@@ -43,6 +43,7 @@ Bluetooth stack.
 * Bluetooth Low Energy Controller support (LE Link Layer)

  * Unlimited role and connection count, all roles supported
+  * All v5.3 specification features supported (except a few minor items)
  * Concurrent multi-protocol support ready
  * Intelligent scheduling of roles to minimize overlap
  * Portable design to any open BLE radio, currently supports Nordic
@@ -58,11 +59,17 @@ Bluetooth stack.

    * Peripheral & Central
    * Observer & Broadcaster
+    * Multiple PHY support (2Mbit/s, Coded)
+    * Extended Advertising
+    * Periodic Advertising (including Sync Transfer)

  * GATT (Generic Attribute Profile)

    * Server (to be a sensor)
    * Client (to connect to sensors)
+    * Enhanced ATT (EATT)
+    * GATT Database Hash
+    * GATT Multiple Notifications

  * Pairing support, including the Secure Connections feature from Bluetooth 4.2

@@ -72,7 +79,8 @@ Bluetooth stack.
  * Bluetooth mesh support

    * Relay, Friend Node, Low-Power Node (LPN) and GATT Proxy features
-    * Both Provisioning bearers supported (PB-ADV & PB-GATT)
+    * Both Provisioning roles and bearers supported (PB-ADV & PB-GATT)
+    * Foundation Models included
    * Highly configurable, fits as small as 16k RAM devices

  * IPSP/6LoWPAN for IPv6 connectivity over Bluetooth LE
@@ -93,3 +101,27 @@ Bluetooth stack.
    * Local controller support as a virtual HCI driver

  * Verified with multiple popular controllers
+
+* LE Audio in Host and Controller
+
+  * Isochronous channels
+
+    * Full Host support
+    * Initial Controller support
+
+  * Generic Audio Framework
+
+    * Basic Audio Profile
+
+      * Unicast server and client
+      * Broadcast source and sink
+      * Broadcast assistant
+      * Scan delegator
+
+    * Common Audio Profile
+
+      * Acceptor
+
+    * Volume Control Profile, Microphone Control Profile
+    * Call Control Profile, Media Control Profile
+    * Coordinated Set Identification Profile
--- a/doc/contribute/guidelines.rst
+++ b/doc/contribute/guidelines.rst
@@ -335,17 +335,23 @@ Issues`_ in Github issues.
 Tools and Git Setup
 *******************

-Signed-off-by
-=============
+.. _git-name-and-email:

-The name in the commit message ``Signed-off-by:`` line and your email must
-match the change authorship information. Make sure your :file:`.gitconfig`
-is set up correctly:
+Name and email
+==============
+
+We need to know who you are, and how to contact you. To add this
+information to your Git installation, set the Git configuration
+variables ``user.name`` to your full name, and ``user.email`` to your
+email address.
+
+For example, if your name is ``Zephyr Developer`` and your email
+address is ``z.developer@example.com``:

 .. code-block:: console

-   git config --global user.name "David Developer"
-   git config --global user.email "david.developer@company.com"
+   git config --global user.name "Zephyr Developer"
+   git config --global user.email "z.developer@example.com"

 gitlint
 =========
@@ -580,7 +586,7 @@ workflow here:

   The ``-s`` option automatically adds your ``Signed-off-by:`` to your commit
   message.  Your commit will be rejected without this line that indicates your
-   agreement with the `DCO`_.  See the `Commit Guidelines`_ section for
+   agreement with the :ref:`DCO`.  See the :ref:`commit-guidelines` section for
   specific guidelines for writing your commit messages.

 #. Push your topic branch with your changes to your fork in your personal
@@ -663,53 +669,146 @@ workflow here:
   Additional information about the CI system can be found in
   `Continuous Integration`_.

+.. _commit-guidelines:

-Commit Guidelines
-*****************
+Commit Message Guidelines
+*************************

-Changes are submitted as Git commits. Each commit message must contain:
+Changes are submitted as Git commits. Each commit has a *commit
+message* describing the change. Acceptable commit messages look like
+this:

-* A short and descriptive subject line that is less than 72 characters,
-  followed by a blank line. The subject line must include a prefix that
-  identifies the subsystem being changed, followed by a colon, and a short
-  title, for example:  ``doc: update wiki references to new site``.
-  (If you're updating an existing file, you can use
-  ``git log <filename>`` to see what developers used as the prefix for
-  previous patches of this file.)
+.. code-block:: none

-* A change description with your logic or reasoning for the changes, followed
-  by a blank line. (Every single line has to be less than 75 characters.)
+   [area]: [summary of change]

-* A Signed-off-by line, ``Signed-off-by: <name> <email>`` typically added
-  automatically by using ``git commit -s``
+   [Commit message body (must be non-empty)]

-* If the change addresses an issue, include a line of the form::
+   Signed-off-by: [Your Full Name] <[your.email@address]>

-      Fixes #<issue number>.
+You need to change text in square brackets (``[like this]``) above to
+fit your commit.

+Examples and more details follow.

-All changes and topics sent to GitHub must be well-formed, as described above.
+Example
+=======
+
+Here is an example of a good commit message.
+
+.. code-block:: none
+
+   drivers: sensor: abcd1234: fix bus I/O error handling
+
+   The abcd1234 sensor driver is failing to check the flags field in
+   the response packet from the device which signals that an error
+   occurred. This can lead to reading invalid data from the response
+   buffer. Fix it by checking the flag and adding an error path.
+
+   Signed-off-by: Zephyr Developer <z.developer@example.com>
+
+[area]: [summary of change]
+===========================
+
+This line is called the commit's *title*. Titles must be:
+
+* one line
+* less than 72 characters long
+* followed by a completely blank line
+
+[area]
+  The ``[area]`` prefix usually identifies the area of code
+  being changed. It can also identify the change's wider
+  context if multiple areas are affected.
+
+  Here are some examples:
+
+  * ``doc: ...`` for documentation changes
+  * ``drivers: foo:`` for ``foo`` driver changes
+  * ``Bluetooth: Shell:`` for changes to the Bluetooth shell
+  * ``net: ethernet:`` for Ethernet-related networking changes
+  * ``dts:`` for treewide devicetree changes
+  * ``style:`` for code style changes
+
+  If you're not sure what to use, try running ``git log FILE``, where
+  ``FILE`` is a file you are changing, and using previous commits that
+  changed the same file as inspiration.
+
+[summary of change]
+  The ``[summary of change]`` part should be a quick description of
+  what you've done. Here are some examples:
+
+  * ``doc: update wiki references to new site``
+  * ``drivers: sensor: sensor_shell: fix channel name collision``

 Commit Message Body
 ===================

-When editing the commit message, please briefly explain what your change
-does and why it's needed. A change summary of ``"Fixes stuff"`` will be rejected.
-
 .. warning::
-   An empty change summary body is not permitted. Even for trivial changes, please
-   include a summary body in the commit message.

-The description body of the commit message must include:
+   An empty commit message body is not permitted. Even for trivial
+   changes, please include a descriptive commit message body. Your
+   pull request will fail CI checks if you do not.
+
+This part of the commit should explain what your change does, and why
+it's needed. Be specific. A body that says ``"Fixes stuff"`` will be
+rejected. Be sure to include the following as relevant:

 * **what** the change does,
 * **why** you chose that approach,
 * **what** assumptions were made, and
 * **how** you know it works -- for example, which tests you ran.

+Each line in your commit message should usually be 75 characters or
+less. Use newlines to wrap longer lines. Exceptions include lines
+with long URLs, email addresses, etc.
+
 For examples of accepted commit messages, you can refer to the Zephyr GitHub
 `changelog <https://github.com/zephyrproject-rtos/zephyr/commits/main>`__.

+If the change addresses a GitHub issue, include a line of the form:
+
+.. code-block:: none
+
+   Fixes #[issue number]
+
+Where ``[issue number]`` is the relevant GitHub issue's number. For
+example:
+
+.. code-block:: none
+
+   Fixes: #1234
+
+Signed-off-by: ...
+==================
+
+.. tip::
+
+   You should have set your :ref:`git-name-and-email`
+   already. Create your commit with ``git commit -s`` to add the
+   Signed-off-by: line automatically using this information.
+
+For open source licensing reasons, your commit must include a
+Signed-off-by: line that looks like this:
+
+.. code-block:: none
+
+   Signed-off-by: [Your Full Name] <[your.email@address]>
+
+For example, if your full name is ``Zephyr Developer`` and your email
+address is ``z.developer@example.com``:
+
+.. code-block:: none
+
+   Signed-off-by: Zephyr Developer <z.developer@example.com>
+
+This means that you have personally made sure your change complies
+with the :ref:`DCO`. For this reason, you must use your legal name.
+Pseudonyms or "hacker aliases" are not permitted.
+
+Your name and the email address you use must match the name and email
+in the Git commit's ``Author:`` field.
+
 Other Commit Expectations
 =========================

--- a/doc/develop/getting_started/index.rst
+++ b/doc/develop/getting_started/index.rst
@@ -780,11 +780,14 @@ Please **copy/paste text** instead of taking a picture or a screenshot of it.
 Text includes source code, terminal commands, and their output.

 Doing this makes it easier for people to help you, and also helps other users
-search the archives.
+search the archives. Unnecessary screenshots exclude vision impaired
+developers; some are major Zephyr contributors. `Accessibility`_ has been
+recognized as a basic human right by the United Nations.

-When copy/pasting more than 5 lines of text into Discord, create a snippet using
-three backticks to delimit the snippet.
+When copy/pasting more than 5 lines of computer text into Discord or Github,
+create a snippet using three backticks to delimit the snippet.

 .. _Search archives and sign up here: https://lists.zephyrproject.org/g/users
 .. _Discord invite: https://chat.zephyrproject.org
 .. _GitHub issues: https://github.com/zephyrproject-rtos/zephyr/issues
+.. _Accessibility: https://www.w3.org/standards/webdesign/accessibility
--- a/doc/develop/toolchains/crosstool_ng.rst
+++ b/doc/develop/toolchains/crosstool_ng.rst
@@ -1,5 +1,13 @@
-Crosstool-NG
-############
+.. _toolchain_xtools:
+
+Crosstool-NG (Deprecated)
+#########################
+
+.. warning::
+
+   ``xtools`` toolchain variant is deprecated. The
+   :ref:`cross-compile toolchain variant <other_x_compilers>` should be used
+   when using a custom toolchain built with Crosstool-NG.

 You can build toolchains from source code using crosstool-NG.

--- a/doc/develop/toolchains/designware_arc_mwdt.rst
+++ b/doc/develop/toolchains/designware_arc_mwdt.rst
@@ -15,6 +15,17 @@ DesignWare ARC MetaWare Development Toolkit (MWDT)
     :envvar:`ARCMWDT_TOOLCHAIN_PATH` to ``$METAWARE_ROOT/../`` (Linux)
     or ``%METAWARE_ROOT%\..\`` (Windows)

+   .. note::
+      Even though ARC MWDT compiler is used for Zephyr RTOS sources compilation, still the GNU
+      preprocessor & GNU objcopy might be used for some steps like DTS preprocessing and ``.bin``
+      file generation. Hence we need to have either ARC or host GNU tools in :envvar:`PATH`.
+      Currently Zephyr looks for:
+
+      * objcopy binaries: ``arc-elf32-objcopy`` or ``arc-linux-objcopy`` or ``objcopy``
+      * gcc binaries: ``arc-elf32-gcc`` or ``arc-linux-gcc`` or ``gcc``
+
+      This list can be extended or modified in future.
+
 #. To check that you have set these variables correctly in your current
   environment, follow these example shell sessions (the
   :envvar:`ARCMWDT_TOOLCHAIN_PATH` values may be different on your system):
--- a/doc/hardware/arch/arc-support-status.rst
+++ b/doc/hardware/arch/arc-support-status.rst
@@ -1,3 +1,5 @@
+.. _hardware_arch_arc_support_status:
+
 Zephyr support status on ARC processors
 #######################################

--- a/doc/hardware/peripherals/canbus/controller.rst
+++ b/doc/hardware/peripherals/canbus/controller.rst
@@ -227,7 +227,7 @@ The filter for this example is configured to match the identifier 0x123 exactly.
  const struct can_filter my_filter = {
          .flags = CAN_FILTER_DATA,
          .id = 0x123,
-          .id_mask = CAN_STD_ID_MASK
+          .mask = CAN_STD_ID_MASK
  };
  int filter_id;
  const struct device *const can_dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_canbus));
@@ -250,7 +250,7 @@ The filter for this example is configured to match the extended identifier
  const struct can_filter my_filter = {
          .flags = CAN_FILTER_DATA | CAN_FILTER_IDE,
          .id = 0x1234567,
-          .id_mask = CAN_EXT_ID_MASK
+          .mask = CAN_EXT_ID_MASK
  };
  CAN_MSGQ_DEFINE(my_can_msgq, 2);
  struct can_frame rx_frame;
--- a/doc/hardware/peripherals/i3c.rst
+++ b/doc/hardware/peripherals/i3c.rst
@@ -358,5 +358,6 @@ API Reference
 .. doxygengroup:: i3c_interface
 .. doxygengroup:: i3c_ccc
 .. doxygengroup:: i3c_addresses
+.. doxygengroup:: i3c_target_device

 .. _I3C Specification: https://www.mipi.org/specifications/i3c-sensor-specification
--- a/doc/kernel/services/other/float.rst
+++ b/doc/kernel/services/other/float.rst
@@ -206,6 +206,18 @@ and potentially requesting FPU usage. Because ISR don't have a persistent
 register context, there are no provision for saving an ISR's FPU context
 either, hence the IRQ disabling.

+As an optimization, the FPU context is preemptively restored upon scheduling
+back an "active FPU user" thread that had its FPU context saved away due to
+FPU usage by another thread. Active FPU users are so designated when they
+make the FPU state "dirty" during their most recent scheduling slot before
+being scheduled out. So if a thread doesn't modify the FPU state within its
+scheduling slot and another thread claims the FPU for itself afterwards then
+that first thread will be subjected to the on-demand regime and won't have
+its FPU context restored until it attempts to access it again. But if that
+thread does modify the FPU before being scheduled out then it is likely to
+continue using it when scheduled back in and preemptively restoring its FPU
+context saves on the exception trap overhead that would occur otherwise.
+
 Each thread object becomes 136 bytes (single-precision floating point
 hardware) or 264 bytes (double-precision floating point hardware) larger
 when Shared FP registers mode is enabled.
--- a/doc/project/project_roles.rst
+++ b/doc/project/project_roles.rst
@@ -107,7 +107,8 @@ in addition to those listed for Contributors and Collaborators:
 * Right to set the overall architecture of the relevant subsystems or areas
  of involvement.
 * Right to make decisions in the relevant subsystems or areas of involvement,
-  in conjunction with the collaborators.
+  in conjunction with the collaborators and submitters.
+  See :ref:`escalation-process`.
 * Responsibility to convey the direction of the relevant subsystem or areas to
  the TSC
 * Responsibility to ensure all contributions of the project have been reviewed
@@ -341,6 +342,8 @@ Merge Criteria
  :ref:`review_time`). Hotfixes can be merged at any time after CI passes.
 * All required checks are passing

+.. _escalation-process:
+
 Escalation Process
 ++++++++++++++++++

--- a/doc/releases/release-notes-3.3.rst
+++ b/doc/releases/release-notes-3.3.rst
--- a/doc/security/vulnerabilities.rst
+++ b/doc/security/vulnerabilities.rst
@@ -1255,3 +1255,27 @@ This has been fixed in main for v3.2.0

 - `PR 48733 fix for main
  <https://github.com/zephyrproject-rtos/zephyr/pull/48733>`_
+
+CVE-2022-3806
+-------------
+
+DoS: Invalid Initialization in le_read_buffer_size_complete()
+
+- `Zephyr project bug tracker GHSA-w525-fm68-ppq3
+  <https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-w525-fm68-ppq3>`_
+
+CVE-2023-0396
+-------------
+
+Buffer Overreads in Bluetooth HCI
+
+- `Zephyr project bug tracker GHSA-8rpp-6vxq-pqg3
+  <https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8rpp-6vxq-pqg3>`_
+
+CVE-2023-0397
+-------------
+
+DoS: Invalid Initialization in le_read_buffer_size_complete()
+
+- `Zephyr project bug tracker GHSA-wc2h-h868-q7hj
+  <https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-wc2h-h868-q7hj>`_
--- a/doc/services/device_mgmt/mcumgr.rst
+++ b/doc/services/device_mgmt/mcumgr.rst
@@ -43,6 +43,15 @@ Command-line Tool
 MCUmgr provides a command-line tool, :file:`mcumgr`, for managing remote devices.
 The tool is written in the Go programming language.

+.. note::
+    This tool is provided for evaluation use only and is not recommended for
+    use in a production environment. It has known issues and will not respect
+    the MCUmgr protocol properly e.g. when an error is received, instead of
+    aborting will, in some circumstances, sit in an endless loop of sending the
+    same command over and over again. A universal replacement for this tool is
+    currently in development and once released, support for the go tool will be
+    dropped entirely.
+
 To install the tool:

 .. tabs::
--- a/doc/services/device_mgmt/smp_groups/smp_group_1.rst
+++ b/doc/services/device_mgmt/smp_groups/smp_group_1.rst
@@ -332,7 +332,8 @@ CBOR data of successful response:
 .. code-block:: none

    {
-        (str,opt)"off"  : (uint)
+        (str,opt)"off"    : (uint)
+        (str,opt)"match"  : (bool)
    }

 In case of error the CBOR data takes the form:
@@ -349,16 +350,22 @@ where:
 .. table::
    :align: center

-    +-----------------------+---------------------------------------------------+
-    | "off"                 | offset of last successfully written byte of update|
-    +-----------------------+---------------------------------------------------+
-    | "rc"                  | :ref:`mcumgr_smp_protocol_status_codes`           |
-    |                       | only appears if non-zero (error condition).       |
-    +-----------------------+---------------------------------------------------+
-    | "rsn"                 | Optional string that clarifies reason for an      |
-    |                       | error; specifically useful for error code ``1``,  |
-    |                       | unknown error                                     |
-    +-----------------------+---------------------------------------------------+
+    +-----------------------+-----------------------------------------------------+
+    | "off"                 | offset of last successfully written byte of update. |
+    +-----------------------+-----------------------------------------------------+
+    | "match"               | indicates if the uploaded data successfully matches |
+    |                       | the provided SHA256 hash or not, only sent in the   |
+    |                       | final packet if                                     |
+    |                       | :kconfig:option:`CONFIG_IMG_ENABLE_IMAGE_CHECK` is  |
+    |                       | enabled.                                            |
+    +-----------------------+-----------------------------------------------------+
+    | "rc"                  | :ref:`mcumgr_smp_protocol_status_codes` only        |
+    |                       | appears if non-zero (error condition).              |
+    +-----------------------+-----------------------------------------------------+
+    | "rsn"                 | Optional string that clarifies reason for an error; |
+    |                       | specifically useful for error code ``1``, unknown   |
+    |                       | error.                                              |
+    +-----------------------+-----------------------------------------------------+

 The "off" field is only included in responses to successfully processed requests;
 if "rc" is negative the "off' may not appear.
--- a/doc/services/dsp/index.rst
+++ b/doc/services/dsp/index.rst
@@ -11,21 +11,21 @@ The DSP API provides an architecture agnostic way for signal processing.
 Currently, the API will work on any architecture but will likely not be
 optimized. The status of the various architectures can be found below:

-+--------------+-------------+
-| Architecture | Status      |
-+--------------+-------------+
-| ARC          | Unoptimized |
-| ARM          | Optimized   |
-| ARM64        | Optimized   |
-| MIPS         | Unoptimized |
-| NIOS2        | Unoptimized |
-| POSIX        | Unoptimized |
-| RISCV        | Unoptimized |
-| RISCV64      | Unoptimized |
-| SPARC        | Unoptimized |
-| X86          | Unoptimized |
-| XTENSA       | Unoptimized |
-+--------------+-------------+
+============ =============
+Architecture Status
+============ =============
+ARC          Unoptimized
+ARM          Optimized
+ARM64        Optimized
+MIPS         Unoptimized
+NIOS2        Unoptimized
+POSIX        Unoptimized
+RISCV        Unoptimized
+RISCV64      Unoptimized
+SPARC        Unoptimized
+X86          Unoptimized
+XTENSA       Unoptimized
+============ =============

 Using zDSP
 **********
--- a/doc/services/shell/images/execution.png
+++ b/doc/services/shell/images/execution.png
--- a/doc/services/shell/index.rst
+++ b/doc/services/shell/index.rst
@@ -163,27 +163,28 @@ Abstract code for this task would look like this:

 .. code-block:: c

-        static int gain_cmd_handler(const struct shell *shell,
-                                    size_t argc, char **argv, void *data)
-        {
-                int gain;
+	static int gain_cmd_handler(const struct shell *shell,
+				    size_t argc, char **argv, void *data)
+	{
+		int gain;

-                /* data is a value corresponding to called command syntax */
-                gain = (int)data;
-                adc_set_gain(gain);
+		/* data is a value corresponding to called command syntax */
+		gain = (int)data;
+		adc_set_gain(gain);

-                shell_print(shell, "ADC gain set to: %s\n"
-                                   "Value send to ADC driver: %d",
-                                   argv[0],
-                                   gain);
+		shell_print(shell, "ADC gain set to: %s\n"
+				   "Value send to ADC driver: %d",
+				   argv[0],
+				   gain);

-                return 0;
-        }
+		return 0;
+	}

-        SHELL_SUBCMD_DICT_SET_CREATE(sub_gain, gain_cmd_handler,
-                (gain_1, 1), (gain_2, 2), (gain_1_2, 3), (gain_1_4, 4)
-        );
-        SHELL_CMD_REGISTER(gain, &sub_gain, "Set ADC gain", NULL);
+	SHELL_SUBCMD_DICT_SET_CREATE(sub_gain, gain_cmd_handler,
+		(gain_1, 1, "gain 1"), (gain_2, 2, "gain 2"),
+		(gain_1_2, 3, "gain 1/2"), (gain_1_4, 4, "gain 1/4")
+	);
+	SHELL_CMD_REGISTER(gain, &sub_gain, "Set ADC gain", NULL);


 This is how it would look like in the shell:
@@ -285,6 +286,44 @@ and a function :c:func:`shell_execute_cmd`, as shown in this example:
 Enable the DUMMY backend by setting the Kconfig
 :kconfig:option:`CONFIG_SHELL_BACKEND_DUMMY` option.

+Commands execution example
+--------------------------
+
+Let's assume a command structure as in the following figure, where:
+
+* :c:macro:`root_cmd` - root command without a handler
+* :c:macro:`cmd_xxx_h` - command has a handler
+* :c:macro:`cmd_xxx` - command does not have a handler
+
+.. image:: images/execution.png
+      :align: center
+      :alt: Command tree with static commands.
+
+Example 1
+^^^^^^^^^
+Sequence: :c:macro:`root_cmd` :c:macro:`cmd_1_h` :c:macro:`cmd_12_h`
+:c:macro:`cmd_121_h` :c:macro:`parameter` will execute command
+:c:macro:`cmd_121_h` and :c:macro:`parameter` will be passed as an argument.
+
+Example 2
+^^^^^^^^^
+Sequence: :c:macro:`root_cmd` :c:macro:`cmd_2` :c:macro:`cmd_22_h`
+:c:macro:`parameter1` :c:macro:`parameter2` will execute command
+:c:macro:`cmd_22_h` and :c:macro:`parameter1` :c:macro:`parameter2`
+will be passed as an arguments.
+
+Example 3
+^^^^^^^^^
+Sequence: :c:macro:`root_cmd` :c:macro:`cmd_1_h` :c:macro:`parameter1`
+:c:macro:`cmd_121_h` :c:macro:`parameter2` will execute command
+:c:macro:`cmd_1_h` and :c:macro:`parameter1`, :c:macro:`cmd_121_h` and
+:c:macro:`parameter2` will be passed as an arguments.
+
+Example 4
+^^^^^^^^^
+Sequence: :c:macro:`root_cmd` :c:macro:`parameter` :c:macro:`cmd_121_h`
+:c:macro:`parameter2` will not execute any command.
+

 Command handler
 ----------------
--- a/doc/services/usb/uhc.rst
+++ b/doc/services/usb/uhc.rst
@@ -5,7 +5,7 @@ USB host controller driver API

 The USB host controller (UHC) driver API implements the low level layer
 to interface with the host controller. All USB host controller drivers
-should implement the APIs described in :zephyr_file:`include/drivers/usb/uhc.h`.
+should implement the APIs described in :zephyr_file:`include/zephyr/drivers/usb/uhc.h`.

 UHC driver API is experimental and is subject to change without notice.

--- a/doc/services/zbus/images/zbus_operations.svg
+++ b/doc/services/zbus/images/zbus_operations.svg
--- a/doc/services/zbus/images/zbus_publishing_process_example.svg
+++ b/doc/services/zbus/images/zbus_publishing_process_example.svg
--- a/doc/services/zbus/images/zbus_publishing_process_example_scenario.svg
+++ b/doc/services/zbus/images/zbus_publishing_process_example_scenario.svg
--- a/doc/services/zbus/index.rst
+++ b/doc/services/zbus/index.rst
@@ -35,14 +35,13 @@ Threads can broadcast messages to all interested observers using zbus. Many-to-m

    Zbus internals details.

-The bus makes the publish, read, and subscribe actions available over channels. Publishing and reading are available in all RTOS contexts except inside an Interrupt Service Routine (ISR). The publish and read operations were designed to be simple and fast; the procedure is a mutex locking followed by a memory copy to and from a shared memory region. Zbus observers' registration can be:
+The bus makes the publish, read, and subscribe actions available over channels. Publishing and reading are available in all RTOS thread contexts. However, it cannot run inside Interrupt Service Routines (ISR) because it uses mutexes to control channels access, and mutexes cannot work appropriately inside ISRs. The publish and read operations are simple and fast; the procedure is a mutex locking followed by a memory copy to and from a shared memory region and then a mutex unlocking. Another essential aspect of zbus is the observers, which can be:

-* Static, defined in compile time. It is not possible to remove at runtime, but it is possible to suppress it by calling the :c:func:`zbus_obs_set_enable`;
-* Dynamic, it can be added and removed to and from a channel at runtime.
+* Static; defined in compile time. It is not possible to remove it at runtime, but it is possible to suppress it by calling the :c:func:`zbus_obs_set_enable`;
+* Dynamic; it can be added and removed to and from a channel at runtime.


-For illustration purposes, suppose a usual sensor-based solution in :numref:`zbus operations`. When the timer is triggered, it pushes an action to a workqueue that publishes to the ``Start trigger`` channel. As the sensor thread subscribed to the ``Start trigger`` channel, it starts to fetch the sensor data. Notice the event dispatcher executes the blink callback because it also listens to the ``Start trigger`` channel. When the sensor data is ready, the sensor thread publishes it to the ``Sensor data`` channel. The core thread as a ``Sensor data`` channel subscriber process the sensor data and stores it in a internal sample buffer. It repeats until the sample buffer is full; when it happens, the core thread aggregates the sample buffer information, prepares a package, and publishes that to the ``Payload`` channel. The Lora thread receives that because it is a ``Payload`` channel subscriber and sends the payload to the cloud. When the transmission is completed, the Lora thread publishes to the ``Transmission done`` channel. The blink callback will be executed again since it listens to the ``Transmission done`` channel.
-
+For illustration purposes, suppose a usual sensor-based solution in :numref:`zbus operations`. When the timer is triggered, it pushes an action to a work queue that publishes to the ``Start trigger`` channel. As the sensor thread subscribed to the ``Start trigger`` channel, it fetches the sensor data. Notice the VDED executes the blink callback because it also listens to the ``Start trigger`` channel. When the sensor data is ready, the sensor thread publishes it to the ``Sensor data`` channel. The core thread, as a ``Sensor data`` channel subscriber, processes the sensor data and stores it in an internal sample buffer. It repeats until the sample buffer is full; when it happens, the core thread aggregates the sample buffer information, prepares a package, and publishes that to the ``Payload`` channel. The Lora thread receives that because it is a ``Payload`` channel subscriber and sends the payload to the cloud. When it completes the transmission, the Lora thread publishes to the ``Transmission done`` channel. The VDED executes the blink callback again since it listens to the ``Transmission done`` channel.


 .. _zbus operations:
@@ -52,11 +51,96 @@ For illustration purposes, suppose a usual sensor-based solution in :numref:`zbu

    Zbus sensor-based application.

-This way of implementing the solution gives us certain flexibility enabling us to change things independently. For example, suppose we would like to change the trigger from a timer to a button press. We can do that, and the change does not affect other parts of the system. Suppose, again, we would like to change the communication interface from LoRa to Bluetooth; for that, we only need to change the LoRa thread. No other change is needed to make that work. Thus, the developer would do that for every block of the image. Based on that, there is a sign zbus promotes decoupling in the system architecture.
+This way of implementing the solution makes the application more flexible, enabling us to change things independently. For example, we want to change the trigger from a timer to a button press. We can do that, and the change does not affect other parts of the system. Likewise, we would like to change the communication interface from LoRa to Bluetooth; we only need to change the LoRa thread. No other change is required in order to make that work. Thus, the developer would do that for every block of the image. Based on that, there is a sign zbus promotes decoupling in the system architecture.

-Another important aspect of using zbus is the reuse of system modules. If a module, code portion with a set of well-defined behaviors, only uses zbus channels and not hardware interfaces, it can easily be reused in other solutions. For that, the new solution must implement the interfaces (set of channels) the module needs to work. That indicates zbus could improve the module reuse.
+Another important aspect of using zbus is the reuse of system modules. If a code portion with well-defined behaviors (we call that module) only uses zbus channels and not hardware interfaces, it can easily be reused in other solutions. The new solution must implement the interfaces (set of channels) the module needs to work. That indicates zbus could improve the module reuse.
+
+The last important note is the zbus solution reach. We can count on many ways of using zbus to enable the developer to be as free as possible to create what they need. For example, messages can be dynamic or static allocated; notifications can be synchronous or asynchronous; the developer can control the channel in so many different ways claiming the channel, developers can add their metadata information to a channel by using the user-data field, the discretionary use of a validator enables the systems to be accurate over message format, and so on. Those characteristics increase the solutions that can be done with zbus and make it a good fit as an open-source community tool.
+
+
+.. _Virtual Distributed Event Dispatcher:
+
+Virtual Distributed Event Dispatcher
+====================================
+
+The VDED execution always happens in the publishing's (thread) context. So it cannot occur inside an Interrupt Service Routine (ISR). Therefore, the IRSs must only access channels indirectly. The basic description of the execution is as follows:
+
+
+* The channel mutex is acquired;
+* The channel receives the new message via direct copy (by a raw :c:func:`memcpy`);
+* The event dispatcher logic executes the listeners in the same sequence they appear on the channel observers' list. The listeners can perform non-copy quick access to the constant message reference directly (via the :c:func:`zbus_chan_const_msg` function) since the channel is still locked;
+* The event dispatcher logic pushes the channel's reference to the subscribers' notification message queue. The pushing sequence is the same as the subscribers appear in the channel observers' list;
+* At last, the publishing function unlocks the channel.
+
+
+To illustrate the VDED execution, consider the example the :numref:`zbus vded scenario` shows. We have four threads in ascending priority T1, T2, T3, and T4 (the highest priority); two listeners, L1 and L2; and channel A. Suposing L1, L2, T2, T3, and T4 observer channel A.
+
+.. _zbus vded scenario:
+.. figure:: images/zbus_publishing_process_example_scenario.svg
+    :alt: Zbus example scenario
+    :width: 55%
+
+    Zbus VDED execution example scenario.
+
+
+The following code implements channel A. Note the ``struct a_msg`` is illustrative only.
+
+.. code-block:: c
+
+    ZBUS_CHAN_DEFINE(a_chan,                     /* Name */
+             struct a_msg,                       /* Message type */
+
+             NULL,                               /* Validator */
+             NULL,                               /* User Data */
+             ZBUS_OBSERVERS(L1, L2, T2, T3, T4), /* observers */
+             ZBUS_MSG_INIT(0)                    /* Initial value {0} */
+    );
+
+
+In :numref:`zbus vded`, the letters indicate some action related to the VDED execution. The X-axis represents the time, and the Y-axis represents the priority of threads. Channel A's message, represented by a voice balloon, is only one memory portion (shared memory). It appears several times only as an illustration of the message at that point in time.
+
+
+.. _zbus vded:
+.. figure:: images/zbus_publishing_process_example.svg
+    :alt: Zbus publish processing detail
+    :width: 85%
+
+    Zbus VDED execution detail.
+
+
+
+The :numref:`zbus vded` illustrates the actions performed during the VDED execution when T1 publishes to channel A. Thus, :numref:`zbus vded table` describes the actions (represented by a letter) of the VDED execution.
+
+
+.. _zbus vded table:
+.. list-table:: VDED execution steps in detail.
+   :widths: 5 65
+   :header-rows: 1
+
+   * - Actions
+     - Description
+   * - a
+     - T1 starts and at some point, publishes to channel A.
+   * - b
+     - The publishing (VDED) process starts. The VDED locks the channel A's mutex.
+   * - c
+     - The VDED copies the T1 message to the channel A message.
+
+   * - d, e
+     - The VDED executes L1 and L2 in the respective sequence. Inside the listeners, usually, there is a call to the :c:func:`zbus_chan_const_msg` function, which provides a direct constant reference to channel A's message. It is quick, and no copy is needed here.
+
+   * - f, g, h
+     - The VDED pushes the notification message to queues of T2, T3, and T4 sequentially. Notice the threads get ready to execute right after receiving the notification. However, they go to a pending state because they cannot access the channel since it is still locked. At that moment, the T1 thread gets its priority elevated (priority inheritance due to the mutex) to the highest pending thread (caused by channel A unavailability). In that case, T4's priority. It ensures the T1 will finish the VDED execution as quickly as possible without preemption from threads with priority below the engaged ones.
+
+   * - i
+     - VDED finishes the publishing by unlocking channel A.
+
+   * - j, k
+     - The T4 leaves the pending state since channel A is not locked. It gets in the CPU again and starts executing. As it did receive a notification from channel A, it performs a channel read (as simple as lock, memory copy, unlock), continues its execution, and goes out the CPU.
+
+   * - l,m, n
+     - Now, T3 can access the channel. It repeats the same steps from T4 (j and k). T2 does the same. That is the end of the VDED execution!

-The last important note is the zbus solution reach. We can count on many different ways of using zbus to enable the developer to be as free as possible to create what they need with it. Messages can be dynamic or static allocated, notifications can be synchronous or asynchronous, the developer can control the channel in so many different ways claiming the channel, developers can add their metadata information to a channel by using the user-data field, the discretionary use of a validator enables the systems to be accurate over message format, and so on. Those characteristics increase the solutions that can be done with zbus and make it a good fit as an open-source community tool.

 Limitations
 ===========
@@ -66,7 +150,7 @@ Based on the fact that developers can use zbus to solve many different problems,
 Delivery guarantees
 -------------------

-Zbus always delivers the messages to the listeners. However, there are no message delivery guarantees for subscribers because zbus only sends the notification, but the message reading depends on the subscriber's implementation. It is possible to increase the delivery rate by following design tips:
+Zbus always delivers the messages to the listeners. However, there are no message delivery guarantees for subscribers because zbus only sends the notification, but the message reading depends on the subscriber's implementation. This is because channels have a mutex protected singleton objects for which message transfer is used. In other words, it can be seen as a single size queue where publishers always overwrite if queue is full. It is possible to increase the delivery rate by following design tips:

 * Keep the listeners quick-as-possible (deal with them as ISRs). If some processing is needed, consider submitting a work to a work-queue;
 * Try to give producers a high priority to avoid losses;
@@ -79,10 +163,10 @@ Message delivery sequence

 The listeners (synchronous observers) will follow the channel definition sequence as the notification and message consumption sequence. However, the subscribers, as they have an asynchronous nature, all will receive the notification as the channel definition sequence but only will consume the data when they execute again, so the delivery respects the order, but the priority assigned to the subscribers will define the reaction sequence. All the listeners (static o dynamic) will receive the message before subscribers receive the notification. The sequence of delivery is: (i) static listeners; (ii) runtime listeners; (iii) static subscribers; at last (iv) runtime subscribers.

-Implementation
-**************
+Usage
+*****

-Zbus operation depends on channels and observers. Therefore, it is necessary to determine its message and observers list during the channel definition. A message is a regular C struct; the observer can be a subscriber (asynchronous) or a listener (synchronous). Channels can have a ``validator function`` that enables a channel to accept only valid messages.
+Zbus operation depends on channels and observers. Therefore, it is necessary to determine its message and observers list during the channel definition. A message is a regular C struct; the observer can be a subscriber (asynchronous) or a listener (synchronous).

 The following code defines and initializes a regular channel and its dependencies. This channel exchanges accelerometer data, for example.

@@ -94,13 +178,13 @@ The following code defines and initializes a regular channel and its dependencie
            int z;
    };

-    ZBUS_CHAN_DEFINE(acc_chan,				     /* Name */
-             struct acc_msg,			     /* Message type */
+    ZBUS_CHAN_DEFINE(acc_chan,                           /* Name */
+             struct acc_msg,                             /* Message type */

-             NULL,					     /* Validator */
-             NULL,					     /* User Data */
+             NULL,                                       /* Validator */
+             NULL,                                       /* User Data */
             ZBUS_OBSERVERS(my_listener, my_subscriber), /* observers */
-             ZBUS_MSG_INIT(.x = 0, .y = 0, .z = 0)	     /* Initial value {0} */
+             ZBUS_MSG_INIT(.x = 0, .y = 0, .z = 0)       /* Initial value */
    );

    void listener_callback_example(const struct zbus_channel *chan)
@@ -135,7 +219,8 @@ The following code defines and initializes a regular channel and its dependencie
 .. note::
    It is unnecessary to claim/lock a channel before accessing the message inside the listener since the event dispatcher calls listeners with the notifying channel already locked. Subscribers, however, must claim/lock that or use regular read operations to access the message after being notified.

-The following code defines and initializes a :dfn:`hard channel` and its dependencies. Only valid messages can be published to a :dfn:`hard channel`. It is possible because a ``Validator function`` passed to the channel's definition. In this example, only messages with ``move`` equal to 0, -1, and 1 are valid. Publish function will discard all other values to ``move``.
+
+Channels can have a ``validator function`` that enables a channel to accept only valid messages. Publish attempts invalidated by hard channels will return immediately with an error code. This allows original creators of a channel to exert some authority over other developers/publishers who may want to piggy-back on their channels. The following code defines and initializes a :dfn:`hard channel` and its dependencies. Only valid messages can be published to a :dfn:`hard channel`. It is possible because a ``Validator function`` passed to the channel's definition. In this example, only messages with ``move`` equal to 0, -1, and 1 are valid. Publish function will discard all other values to ``move``.

 .. code-block:: c

@@ -151,22 +236,24 @@ The following code defines and initializes a :dfn:`hard channel` and its depende

    static int message_count = 0;

-    ZBUS_CHAN_DEFINE(control_chan,     /* Name */
+    ZBUS_CHAN_DEFINE(control_chan,    /* Name */
             struct control_msg,      /* Message type */

             control_validator,       /* Validator */
             &message_count,          /* User data */
             ZBUS_OBSERVERS_EMPTY,    /* observers */
-             ZBUS_MSG_INIT(.move = 0) /* Initial value {.move=0} */
+             ZBUS_MSG_INIT(.move = 0) /* Initial value */
    );

 The following sections describe in detail how to use zbus features.


+.. _publishing to a channel:
+
 Publishing to a channel
 =======================

-Messages are published to a channel in zbus by calling :c:func:`zbus_chan_pub`. For example, the following code builds on the examples above and publishes to channel ``acc_chan``. The code is trying to publish the message ``acc1`` to channel ``acc_chan``, and it will wait up to one second for the message to be published. Otherwise, the operation fails.
+Messages are published to a channel in zbus by calling :c:func:`zbus_chan_pub`. For example, the following code builds on the examples above and publishes to channel ``acc_chan``. The code is trying to publish the message ``acc1`` to channel ``acc_chan``, and it will wait up to one second for the message to be published. Otherwise, the operation fails. As can be inferred from the code sample, it's OK to use stack allocated messages since VDED copies the data internally.

 .. code-block:: c

@@ -176,6 +263,8 @@ Messages are published to a channel in zbus by calling :c:func:`zbus_chan_pub`.
 .. warning::
    Do not use this function inside an ISR.

+.. _reading from a channel:
+
 Reading from a channel
 ======================

@@ -189,10 +278,13 @@ Messages are read from a channel in zbus by calling :c:func:`zbus_chan_read`. So
 .. warning::
    Do not use this function inside an ISR.

+.. warning::
+    Choose the timeout of :c:func:`zbus_chan_read` after receiving a notification from :c:func:`zbus_sub_wait` carefully because the channel will always be unavailable during the VDED execution. Using ``K_NO_WAIT`` for reading is highly likely to return a timeout error if there are more than one subscriber. For example, consider the :numref:`zbus vded` again and notice how ``T3`` and ``T4's`` read attempts would definitely fail with K_NO_WAIT. For more details, check the `Virtual Distributed Event Dispatcher`_ section.
+
 Forcing channel notification
 ============================

-It is possible to force zbus to notify a channel's observers by calling :c:func:`zbus_chan_notify`. For example, the following code builds on the examples above and forces a notification for the channel ``acc_chan``. Note this can send events with no message, which does not require any data exchange.
+It is possible to force zbus to notify a channel's observers by calling :c:func:`zbus_chan_notify`. For example, the following code builds on the examples above and forces a notification for the channel ``acc_chan``. Note this can send events with no message, which does not require any data exchange. See the code example under `Claim and finish a channel`_ where this may become useful.

 .. code-block:: c

@@ -204,7 +296,7 @@ It is possible to force zbus to notify a channel's observers by calling :c:func:
 Declaring channels and observers
 ================================

-For accessing channels or observers from files other than its defining files, it is necessary to declare them by calling :c:macro:`ZBUS_CHAN_DECLARE` and :c:macro:`ZBUS_OBS_DECLARE`. It is possible to declare more than one channel or observer at the same call. The following code builds on the examples above and displays the defined channels and observers.
+For accessing channels or observers from files other than its defining files, it is necessary to declare them by calling :c:macro:`ZBUS_CHAN_DECLARE` and :c:macro:`ZBUS_OBS_DECLARE`. In other words, zbus channel definitions and declarations with the same channel names in different files would point to the same (global) channel. Thus, developers should be careful about existing channels, and naming new channels or linking will fail. It is possible to declare more than one channel or observer on the same call. The following code builds on the examples above and displays the defined channels and observers.

 .. code-block:: c

@@ -215,7 +307,7 @@ For accessing channels or observers from files other than its defining files, it
 Iterating over channels and observers
 =====================================

-There is an iterator mechanism in zbus that enables the developer to execute some procedure per channel and observer. The sequence executed is sorted by channel or observer name.
+Zbus subsystem also implements :ref:`Iterable Sections <iterable_sections_api>` for channels and observers, for which there are supporting APIs like :c:func:`zbus_iterate_over_channels` and :c:func:`zbus_iterate_over_observers`. This feature enables developers to call a procedure over all declared channels, where the procedure parameter is a :c:struct:`zbus_channel`. The execution sequence is in the alphabetical name order of the channels (see :ref:`Iterable Sections <iterable_sections_api>` documentation for details). Zbus also implements this feature for :c:struct:`zbus_observer`.

 .. code-block:: c

@@ -268,15 +360,17 @@ The code will log the following output:
    D: 1 - Subscriber my_subscriber


+.. _Claim and finish a channel:
+
 Advanced channel control
 ========================

-Zbus was designed to be as flexible and extensible as possible. Thus there are some features designed to provide some control and extensibility to the bus.
+Zbus was designed to be as flexible and extensible as possible. Thus, there are some features designed to provide some control and extensibility to the bus.

 Listeners message access
 ------------------------

-For performance purposes, listeners can access the receiving channel message directly since they already have the mutex lock for it. To access the channel's message, the listener should use the ``zbus_chan_const_msg`` because the channel passed as an argument to the listener function is a constant pointer to the channel. The const pointer ensures that the message will be kept unchanged during the notification process.
+For performance purposes, listeners can access the receiving channel message directly since they already have the mutex lock for it. To access the channel's message, the listener should use the :c:func:`zbus_chan_const_msg` because the channel passed as an argument to the listener function is a constant pointer to the channel. The const pointer return type tells developers not to modify the message.

 .. code-block:: c

@@ -294,8 +388,8 @@ For performance purposes, listeners can access the receiving channel message dir

 User Data
 ---------
+It is possible to pass custom data into the channel's ``user_data`` for various purposes, such as writing channel metadata. That can be achieved by passing a pointer to the channel definition macro's ``user_data`` field, which will then be accessible by others. Note that ``user_data`` is individual for each channel. Also, note that ``user_data`` access is not thread-safe. For thread-safe access to ``user_data``, see the next section.

-There is a possibility of injecting data into the channel's metadata by passing the ``user_data`` pointer to the channel's definition macro. The ``user_data`` field enables others to access the data. Note that it needs to be set individually for each channel.

 Claim and finish a channel
 --------------------------
@@ -303,20 +397,43 @@ Claim and finish a channel
 To take more control over channels, two function were added :c:func:`zbus_chan_claim` and :c:func:`zbus_chan_finish`. With these functions, it is possible to access the channel's metadata safely. When a channel is claimed, no actions are available to that channel. After finishing the channel, all the actions are available again.

 .. warning::
-    Never change the fields of the channel struct directly. It may cause zbus behavior inconsistencies and concurrency issues.
+    Never change the fields of the channel struct directly. It may cause zbus behavior inconsistencies and scheduling issues.
+
+.. warning::
+    Do not use these functions inside an ISR.

 The following code builds on the examples above and claims the ``acc_chan`` to set the ``user_data`` to the channel. Suppose we would like to count how many times the channels exchange messages. We defined the ``user_data`` to have the 32 bits integer. This code could be added to the listener code described above.

 .. code-block:: c

    if (!zbus_chan_claim(&acc_chan, K_MSEC(200))) {
-            int *message_counting = (int *) zbus_chan_user_data(acc_chan);
+            int *message_counting = (int *) zbus_chan_user_data(&acc_chan);
            *message_counting += 1;
            zbus_chan_finish(&acc_chan);
    }

-.. warning::
-    Do not use these functions inside an ISR.
+The following code has the exact behavior of the code in :ref:`publishing to a channel`.
+
+.. code-block:: c
+
+    if (!zbus_chan_claim(&acc_chan, K_MSEC(200))) {
+            struct acc_msg *acc1 = (struct acc_msg *) zbus_chan_msg(&acc_chan);
+            acc1.x = 1;
+            acc1.y = 1;
+            acc1.z = 1;
+            zbus_chan_finish(&acc_chan);
+            zbus_chan_notify(&acc_chan, K_SECONDS(1));
+    }
+
+The following code has the exact behavior of the code in :ref:`reading from a channel`.
+
+.. code-block:: c
+
+    if (!zbus_chan_claim(&acc_chan, K_MSEC(200))) {
+            const struct acc_msg *acc1 = (const struct acc_msg *) zbus_chan_const_msg(&acc_chan);
+            // access the acc_msg fields directly.
+            zbus_chan_finish(&acc_chan);
+    }


 Runtime observer registration
@@ -376,10 +493,10 @@ For enabling zbus, it is necessary to enable the :kconfig:option:`CONFIG_ZBUS` o

 Related configuration options:

-* :kconfig:option:`CONFIG_ZBUS_CHANNEL_NAME`
-* :kconfig:option:`CONFIG_ZBUS_OBSERVER_NAME`
-* :kconfig:option:`CONFIG_ZBUS_STRUCTS_ITERABLE_ACCESS`
-* :kconfig:option:`CONFIG_ZBUS_RUNTIME_OBSERVERS_POOL_SIZE`
+* :kconfig:option:`CONFIG_ZBUS_CHANNEL_NAME` enables the name of channels to be available inside the channels metadata. The log uses this information to show the channels' names;
+* :kconfig:option:`CONFIG_ZBUS_OBSERVER_NAME` enables the name of observers to be available inside the channels metadata;
+* :kconfig:option:`CONFIG_ZBUS_STRUCTS_ITERABLE_ACCESS` enables :ref:`Iterable Sections <iterable_sections_api>` to on zbus channels and observers;
+* :kconfig:option:`CONFIG_ZBUS_RUNTIME_OBSERVERS_POOL_SIZE` enables the runtime observer registration. It is necessary to set a value to be greater than zero.

 API Reference
 *************
--- a/drivers/adc/adc_mcux_lpadc.c
+++ b/drivers/adc/adc_mcux_lpadc.c
@@ -27,6 +27,14 @@
 #include <zephyr/irq.h>
 LOG_MODULE_REGISTER(nxp_mcux_lpadc);

+/*
+ * Currently, no instance of the ADC IP has more than
+ * 8 channels present. Therefore, we treat channels
+ * with an index 8 or higher as a side b channel, with
+ * the channel index given by channel_num % 8
+ */
+#define CHANNELS_PER_SIDE 0x8
+
 #define ADC_CONTEXT_USES_KERNEL_TIMER
 #include "adc_context.h"

@@ -196,7 +204,11 @@ static void mcux_lpadc_start_channel(const struct device *dev)
 	lpadc_conv_command_config_t cmd_config;

 	LPADC_GetDefaultConvCommandConfig(&cmd_config);
-	cmd_config.channelNumber = data->channel_id;
+	cmd_config.channelNumber = data->channel_id % CHANNELS_PER_SIDE;
+	/* Select channel side based on next bit */
+	cmd_config.sampleChannelMode = (data->channel_id < CHANNELS_PER_SIDE) ?
+		kLPADC_SampleChannelSingleEndSideA :
+		kLPADC_SampleChannelSingleEndSideB;
 #if defined(FSL_FEATURE_LPADC_HAS_CMDL_MODE) \
 	&& FSL_FEATURE_LPADC_HAS_CMDL_MODE
 	cmd_config.conversionResolutionMode = data->resolution;
--- a/drivers/counter/Kconfig.stm32_rtc
+++ b/drivers/counter/Kconfig.stm32_rtc
@@ -40,8 +40,8 @@ endchoice #COUNTER_RTC_STM32_CLOCK_SRC

 config COUNTER_RTC_STM32_SAVE_VALUE_BETWEEN_RESETS
 	bool "Save rtc time value between resets"
-	default y
+	default n
 	help
-	  Do not reset the rtc time and date after each reset.
+	  Keep the counter value after each reset.

 endif # COUNTER_RTC_STM32
--- a/drivers/counter/counter_nrfx_timer.c
+++ b/drivers/counter/counter_nrfx_timer.c
@@ -13,7 +13,7 @@
 #include <zephyr/irq.h>
 LOG_MODULE_REGISTER(LOG_MODULE_NAME, LOG_LEVEL);

-#define TIMER_CLOCK 16000000
+#define TIMER_CLOCK(timer_instance) NRF_TIMER_BASE_FREQUENCY_GET(timer_instance)

 #define CC_TO_ID(cc_num) (cc_num - 2)

@@ -48,7 +48,7 @@ struct counter_nrfx_config {
 struct counter_timer_config {
 	nrf_timer_bit_width_t bit_width;
 	nrf_timer_mode_t mode;
-	nrf_timer_frequency_t freq;
+	uint32_t prescaler;
 };

 static int start(const struct device *dev)
@@ -240,7 +240,6 @@ static int set_top_value(const struct device *dev,
 	NRF_TIMER_Type *timer = nrfx_config->timer;
 	struct counter_nrfx_data *data = dev->data;
 	int err = 0;
-
 	for (int i = 0; i < counter_get_num_of_channels(dev); i++) {
 		/* Overflow can be changed only when all alarms are
 		 * disables.
@@ -286,7 +285,7 @@ static int init_timer(const struct device *dev,

 	nrf_timer_bit_width_set(reg, config->bit_width);
 	nrf_timer_mode_set(reg, config->mode);
-	nrf_timer_prescaler_set(reg, config->freq);
+	nrf_timer_prescaler_set(reg, config->prescaler);

 	nrf_timer_cc_set(reg, TOP_CH, counter_get_max_top_value(dev));

@@ -418,7 +417,7 @@ static const struct counter_driver_api counter_nrfx_driver_api = {
 	{								       \
 		TIMER_IRQ_CONNECT(idx);					       \
 		static const struct counter_timer_config config = {	       \
-			.freq = TIMER_PROP(idx, prescaler),		       \
+			.prescaler = TIMER_PROP(idx, prescaler),	       \
 			.mode = NRF_TIMER_MODE_TIMER,			       \
 			.bit_width = (TIMER##idx##_MAX_SIZE == 32) ?	       \
 					NRF_TIMER_BIT_WIDTH_32 :	       \
@@ -434,7 +433,7 @@ static const struct counter_driver_api counter_nrfx_driver_api = {
 		.info = {						       \
 			.max_top_value = (TIMER##idx##_MAX_SIZE == 32) ?       \
 					0xffffffff : 0x0000ffff,	       \
-			.freq = TIMER_CLOCK /				       \
+			.freq = TIMER_CLOCK(NRF_TIMER##idx) /		       \
 					(1 << TIMER_PROP(idx, prescaler)),     \
 			.flags = COUNTER_CONFIG_INFO_COUNT_UP,		       \
 			.channels = CC_TO_ID(TIMER##idx##_CC_NUM),	       \
--- a/drivers/disk/Kconfig
+++ b/drivers/disk/Kconfig
@@ -11,5 +11,6 @@ if DISK_DRIVERS
 source "drivers/disk/Kconfig.ram"
 source "drivers/disk/Kconfig.flash"
 source "drivers/disk/Kconfig.sdmmc"
+source "drivers/disk/Kconfig.mmc"

 endif # DISK_DRIVERS
--- a/drivers/disk/Kconfig.mmc
+++ b/drivers/disk/Kconfig.mmc
@@ -0,0 +1,37 @@
+# Copyright 2023 NXP
+# SPDX-License-Identifier: Apache-2.0
+
+config DISK_DRIVER_MMC
+	bool "MMC card driver"
+	default y if DT_HAS_ZEPHYR_MMC_DISK_ENABLED
+	help
+	  MMC card driver.
+
+if DISK_DRIVER_MMC
+
+config SD_INIT_PRIORITY
+	int "Init priority"
+	default 90
+	help
+	  MMC controller driver initialization priority.
+
+config MMC_VOLUME_NAME
+	string "MMC Disk mount point or drive name"
+	default "SD" if FAT_FILESYSTEM_ELM
+	default "MMC"
+	help
+	  Disk name as per file system naming guidelines.
+
+config MMC_SUBSYS
+	bool "MMC access via SD subsystem"
+	select MMC_STACK
+	default y
+	depends on DT_HAS_ZEPHYR_MMC_DISK_ENABLED
+	help
+	  Enable MMC access via SD subsystem.
+
+module = MMC
+module-str = mmc
+source "subsys/logging/Kconfig.template.log_config"
+
+endif # DISK_DRIVER_MMC
--- a/drivers/disk/Kconfig.sdmmc
+++ b/drivers/disk/Kconfig.sdmmc
@@ -6,7 +6,8 @@ DT_STM32_SDMMC_HAS_DMA := $(dt_nodelabel_has_prop,sdmmc,dmas)

 config DISK_DRIVER_SDMMC
 	bool "SDMMC card driver"
-	default y if DT_HAS_ZEPHYR_SDMMC_DISK_ENABLED || DT_HAS_ZEPHYR_MMC_DISK_ENABLED
+	default y if DT_HAS_ZEPHYR_SDMMC_DISK_ENABLED || \
+			DT_HAS_ST_STM32_SDMMC_ENABLED
 	help
 	  SDMMC card driver.

@@ -18,13 +19,6 @@ config SD_INIT_PRIORITY
 	help
 	  SDMMC controller driver initialization priority.

-config MMC_VOLUME_NAME
-	string "MMC Disk mount point or drive name"
-	default "SD" if FAT_FILESYSTEM_ELM
-	default "SDMMC"
-	help
-	  Disk name as per file system naming guidelines.
-
 config SDMMC_VOLUME_NAME
 	string "SDMMC Disk mount point or drive name"
 	default "SD" if FAT_FILESYSTEM_ELM
@@ -40,14 +34,6 @@ config SDMMC_SUBSYS
 	help
 	  Enable SDMMC access via SD subsystem.

-config MMC_SUBSYS
-	bool "MMC access via SD subsystem"
-	select MMC_STACK
-	default y
-	depends on DT_HAS_ZEPHYR_MMC_DISK_ENABLED
-	help
-	  Enable MMC access via SD subsystem.
-
 config SDMMC_STM32
 	bool "STM32 SDMMC driver"
 	default y
--- a/drivers/dma/dma_mcux_edma.c
+++ b/drivers/dma/dma_mcux_edma.c
@@ -94,7 +94,6 @@ struct dma_mcux_edma_data {
 	struct dma_context dma_ctx;
 	struct call_back data_cb[DT_INST_PROP(0, dma_channels)];
 	ATOMIC_DEFINE(channels_atomic, DT_INST_PROP(0, dma_channels));
-	struct k_mutex dma_mutex;
 };

 #define DEV_CFG(dev) \
@@ -504,7 +503,6 @@ static int dma_mcux_edma_init(const struct device *dev)
 	config->irq_config_func(dev);
 	memset(dev->data, 0, sizeof(struct dma_mcux_edma_data));
 	memset(tcdpool, 0, sizeof(tcdpool));
-	k_mutex_init(&data->dma_mutex);
 	data->dma_ctx.magic = DMA_MAGIC;
 	data->dma_ctx.dma_channels = config->dma_channels;
 	data->dma_ctx.atomic = data->channels_atomic;
--- a/drivers/dma/dma_stm32u5.c
+++ b/drivers/dma/dma_stm32u5.c
@@ -188,6 +188,14 @@ void stm32_dma_enable_stream(DMA_TypeDef *dma, uint32_t id)
 	LL_DMA_EnableChannel(dma, dma_stm32_id_to_stream(id));
 }

+bool stm32_dma_is_enabled_stream(DMA_TypeDef *dma, uint32_t id)
+{
+	if (LL_DMA_IsEnabledChannel(dma, dma_stm32_id_to_stream(id)) == 1) {
+		return true;
+	}
+	return false;
+}
+
 int stm32_dma_disable_stream(DMA_TypeDef *dma, uint32_t id)
 {
 	/* GPDMA channel abort sequence */
@@ -196,7 +204,7 @@ int stm32_dma_disable_stream(DMA_TypeDef *dma, uint32_t id)
 	/* reset the channel will disable it */
 	LL_DMA_ResetChannel(dma, dma_stm32_id_to_stream(id));

-	if (!LL_DMA_IsEnabledChannel(dma, dma_stm32_id_to_stream(id))) {
+	if (!stm32_dma_is_enabled_stream(dma, id)) {
 		return 0;
 	}

@@ -552,6 +560,11 @@ static int dma_stm32_start(const struct device *dev, uint32_t id)
 		return -EINVAL;
 	}

+	/* Repeated start : return now if channel is already started */
+	if (stm32_dma_is_enabled_stream(dma, id)) {
+		return 0;
+	}
+
 	/* When starting the dma, the stream is busy before enabling */
 	stream = &config->streams[id];
 	stream->busy = true;
@@ -617,6 +630,11 @@ static int dma_stm32_stop(const struct device *dev, uint32_t id)
 		return -EINVAL;
 	}

+	/* Repeated stop : return now if channel is already stopped */
+	if (!stm32_dma_is_enabled_stream(dma, id)) {
+		return 0;
+	}
+
 	LL_DMA_DisableIT_TC(dma, dma_stm32_id_to_stream(id));

 	dma_stm32_clear_stream_irq(dev, id);
--- a/drivers/ethernet/eth_stm32_hal.c
+++ b/drivers/ethernet/eth_stm32_hal.c
@@ -80,8 +80,7 @@ LOG_MODULE_REGISTER(LOG_MODULE_NAME);
 	    DT_NODE_HAS_STATUS(DT_CHOSEN(zephyr_dtcm), okay)
 #define __eth_stm32_desc __dtcm_noinit_section
 #define __eth_stm32_buf  __dtcm_noinit_section
-#elif defined(CONFIG_SOC_SERIES_STM32H7X) && \
-		DT_NODE_HAS_STATUS(DT_NODELABEL(sram3), okay)
+#elif defined(CONFIG_SOC_SERIES_STM32H7X)
 #define __eth_stm32_desc __attribute__((section(".eth_stm32_desc")))
 #define __eth_stm32_buf  __attribute__((section(".eth_stm32_buf")))
 #elif defined(CONFIG_NOCACHE_MEMORY)
@@ -254,17 +253,19 @@ static inline void setup_mac_filter(ETH_HandleTypeDef *heth)
 #else
 	uint32_t tmp = heth->Instance->MACFFR;

-	/* disable multicast perfect filtering */
+	/* clear all multicast filter bits, resulting in perfect filtering */
 	tmp &= ~(ETH_MULTICASTFRAMESFILTER_PERFECTHASHTABLE |
-#if !defined(CONFIG_ETH_STM32_MULTICAST_FILTER)
 		 ETH_MULTICASTFRAMESFILTER_HASHTABLE |
-#endif /* CONFIG_ETH_STM32_MULTICAST_FILTER */
-		 ETH_MULTICASTFRAMESFILTER_PERFECT);
+		 ETH_MULTICASTFRAMESFILTER_PERFECT |
+		 ETH_MULTICASTFRAMESFILTER_NONE);

-#if defined(CONFIG_ETH_STM32_MULTICAST_FILTER)
-	/* enable multicast hash receive filter */
-	tmp |= ETH_MULTICASTFRAMESFILTER_HASHTABLE;
-#endif /* CONFIG_ETH_STM32_MULTICAST_FILTER */
+	if (IS_ENABLED(CONFIG_ETH_STM32_MULTICAST_FILTER)) {
+		/* enable multicast hash receive filter */
+		tmp |= ETH_MULTICASTFRAMESFILTER_HASHTABLE;
+	} else {
+		/* enable receiving all multicast frames */
+		tmp |= ETH_MULTICASTFRAMESFILTER_NONE;
+	}

 	heth->Instance->MACFFR = tmp;

@@ -1224,6 +1225,23 @@ static int eth_initialize(const struct device *dev)

 	k_thread_name_set(&dev_data->rx_thread, "stm_eth");

+#if defined(CONFIG_SOC_SERIES_STM32H7X) || defined(CONFIG_ETH_STM32_HAL_API_V2)
+	/* Adjust MDC clock range depending on HCLK frequency: */
+	HAL_ETH_SetMDIOClockRange(heth);
+
+	/* @TODO: read duplex mode and speed from PHY and set it to ETH */
+
+	ETH_MACConfigTypeDef mac_config;
+
+	HAL_ETH_GetMACConfig(heth, &mac_config);
+	mac_config.DuplexMode = ETH_FULLDUPLEX_MODE;
+	mac_config.Speed = ETH_SPEED_100M;
+	hal_ret = HAL_ETH_SetMACConfig(heth, &mac_config);
+	if (hal_ret != HAL_OK) {
+		LOG_ERR("HAL_ETH_SetMACConfig: failed: %d", hal_ret);
+	}
+#endif /* CONFIG_SOC_SERIES_STM32H7X || CONFIG_ETH_STM32_HAL_API_V2 */
+
 #if defined(CONFIG_ETH_STM32_HAL_API_V2)

 	/* prepare tx buffer header */
@@ -1259,19 +1277,7 @@ static int eth_initialize(const struct device *dev)

 	setup_mac_filter(heth);

-#if defined(CONFIG_SOC_SERIES_STM32H7X) || defined(CONFIG_ETH_STM32_HAL_API_V2)
-	/* Adjust MDC clock range depending on HCLK frequency: */
-	HAL_ETH_SetMDIOClockRange(heth);

-	/* @TODO: read duplex mode and speed from PHY and set it to ETH */
-
-	ETH_MACConfigTypeDef mac_config;
-
-	HAL_ETH_GetMACConfig(heth, &mac_config);
-	mac_config.DuplexMode = ETH_FULLDUPLEX_MODE;
-	mac_config.Speed = ETH_SPEED_100M;
-	HAL_ETH_SetMACConfig(heth, &mac_config);
-#endif /* CONFIG_SOC_SERIES_STM32H7X || CONFIG_ETH_STM32_HAL_API_V2 */

 	LOG_DBG("MAC %02x:%02x:%02x:%02x:%02x:%02x",
 		dev_data->mac_addr[0], dev_data->mac_addr[1],
--- a/drivers/flash/flash_stm32l5x.c
+++ b/drivers/flash/flash_stm32l5x.c
@@ -358,11 +358,13 @@ void flash_stm32_page_layout(const struct device *dev,
 {
 	FLASH_TypeDef *regs = FLASH_STM32_REGS(dev);
 	static struct flash_pages_layout stm32_flash_layout[3];
+	static size_t stm32_flash_layout_size;

 	*layout = stm32_flash_layout;

 	if (stm32_flash_layout[0].pages_count != 0) {
 		/* Short circuit calculation logic if already performed (size is known) */
+		*layout_size = stm32_flash_layout_size;
 		return;
 	}

@@ -386,7 +388,7 @@ void flash_stm32_page_layout(const struct device *dev,
 		stm32_flash_layout[2].pages_count = PAGES_PER_BANK;
 		stm32_flash_layout[2].pages_size = FLASH_PAGE_SIZE;

-		*layout_size = ARRAY_SIZE(stm32_flash_layout);
+		stm32_flash_layout_size = ARRAY_SIZE(stm32_flash_layout);
 	} else {
 		/*
 		 * For stm32l562xx & stm32l552xx with 512 flash or stm32u58x
@@ -410,6 +412,8 @@ void flash_stm32_page_layout(const struct device *dev,
 		 * In this case the stm32_flash_layout table has one single element
 		 * when read by the flash_get_page_info()
 		 */
-		*layout_size = 1;
+		stm32_flash_layout_size = 1;
 	}
+
+	*layout_size = stm32_flash_layout_size;
 }
--- a/drivers/gpio/gpio_cy8c95xx.c
+++ b/drivers/gpio/gpio_cy8c95xx.c
@@ -287,7 +287,7 @@ static const struct cy8c95xx_config cy8c95xx_##idx##_cfg = { \
 	.common = { \
 		.port_pin_mask = 0xFF, \
 	}, \
-	.i2c = I2C_DT_SPEC_INST_GET(idx), \
+	.i2c = I2C_DT_SPEC_GET(DT_PARENT(DT_INST(idx, DT_DRV_COMPAT))), \
 	.port_num = DT_INST_REG_ADDR(idx), \
 }; \
 static struct cy8c95xx_drv_data cy8c95xx_##idx##_drvdata = { \
--- a/drivers/gpio/gpio_ite_it8xxx2.c
+++ b/drivers/gpio/gpio_ite_it8xxx2.c
@@ -480,11 +480,17 @@ static int gpio_ite_get_config(const struct device *dev,
 	/* 1.8V or 3.3V */
 	reg_1p8v = &IT8XXX2_GPIO_GCRX(
 			gpio_1p8v[gpio_config->index][pin].offset);
-	mask_1p8v = gpio_1p8v[gpio_config->index][pin].mask_1p8v;
-	if (*reg_1p8v & mask_1p8v) {
-		flags |= IT8XXX2_GPIO_VOLTAGE_1P8;
-	} else {
-		flags |= IT8XXX2_GPIO_VOLTAGE_3P3;
+	/*
+	 * Since not all GPIOs support voltage selection, voltage flag
+	 * is only set if voltage selection register is present.
+	 */
+	if (reg_1p8v != &IT8XXX2_GPIO_GCRX(0)) {
+		mask_1p8v = gpio_1p8v[gpio_config->index][pin].mask_1p8v;
+		if (*reg_1p8v & mask_1p8v) {
+			flags |= IT8XXX2_GPIO_VOLTAGE_1P8;
+		} else {
+			flags |= IT8XXX2_GPIO_VOLTAGE_3P3;
+		}
 	}

 	/* set input or output. */
--- a/drivers/gpio/gpio_keys_zephyr.c
+++ b/drivers/gpio/gpio_keys_zephyr.c
@@ -36,7 +36,6 @@ struct gpio_keys_pin_data {

 struct gpio_keys_data {
 	gpio_keys_callback_handler_t callback;
-	int num_keys;
 	struct gpio_keys_pin_data *pin_data;
 };

@@ -82,9 +81,8 @@ static void gpio_keys_interrupt(const struct device *dev, struct gpio_callback *
 	struct gpio_keys_pin_data *pin_data =
 		CONTAINER_OF(cbdata, struct gpio_keys_pin_data, cb_data);
 	const struct gpio_keys_config *cfg = pin_data->dev->config;
-	struct gpio_keys_data *data = pin_data->dev->data;

-	for (int i = 0; i < data->num_keys; i++) {
+	for (int i = 0; i < cfg->num_keys; i++) {
 		if (pins & BIT(cfg->pin_cfg[i].spec.pin)) {
 			gpio_keys_change_call_deferred(pin_data, cfg->debounce_interval_ms);
 		}
@@ -118,7 +116,7 @@ static int gpio_keys_zephyr_enable_interrupt(const struct device *dev,
 	struct gpio_keys_data *data = dev->data;

 	data->callback = gpio_keys_cb;
-	for (int i = 0; i < data->num_keys; i++) {
+	for (int i = 0; i < cfg->num_keys; i++) {
 		retval = gpio_keys_interrupt_configure(&cfg->pin_cfg[i].spec,
 						       &data->pin_data[i].cb_data,
 						       cfg->pin_cfg[i].zephyr_code);
@@ -134,7 +132,7 @@ static int gpio_keys_zephyr_disable_interrupt(const struct device *dev)
 	struct gpio_keys_data *data = dev->data;
 	const struct gpio_dt_spec *gpio_spec;

-	for (int i = 0; i < data->num_keys; i++) {
+	for (int i = 0; i < cfg->num_keys; i++) {
 		gpio_spec = &cfg->pin_cfg[i].spec;
 		retval = z_impl_gpio_pin_interrupt_configure(gpio_spec->port, gpio_spec->pin,
 							     GPIO_INT_MODE_DISABLED);
@@ -195,7 +193,7 @@ static int gpio_keys_init(const struct device *dev)
 	const struct gpio_keys_config *cfg = dev->config;
 	int ret;

-	for (int i = 0; i < data->num_keys; i++) {
+	for (int i = 0; i < cfg->num_keys; i++) {
 		const struct gpio_dt_spec *gpio = &cfg->pin_cfg[i].spec;

 		if (!gpio_is_ready_dt(gpio)) {
@@ -239,7 +237,6 @@ static const struct gpio_keys_api gpio_keys_zephyr_api = {
 	static struct gpio_keys_pin_data                                                           \
 		gpio_keys_pin_data_##i[ARRAY_SIZE(gpio_keys_pin_config_##i)];                      \
 	static struct gpio_keys_data gpio_keys_data_##i = {                                        \
-		.num_keys = ARRAY_SIZE(gpio_keys_pin_config_##i),                                  \
 		.pin_data = gpio_keys_pin_data_##i,                                                \
 	};                                                                                         \
 	DEVICE_DT_INST_DEFINE(i, &gpio_keys_init, NULL, &gpio_keys_data_##i,                       \
--- a/drivers/ieee802154/ieee802154_rf2xx.c
+++ b/drivers/ieee802154/ieee802154_rf2xx.c
@@ -267,7 +267,7 @@ static void rf2xx_process_tx_frame(const struct device *dev)
 	struct rf2xx_context *ctx = dev->data;

 	ctx->trx_trac = (rf2xx_iface_reg_read(dev, RF2XX_TRX_STATE_REG) >>
-			 RF2XX_TRAC_STATUS) & 7;
+			 RF2XX_TRAC_STATUS) & RF2XX_TRAC_BIT_MASK;
 	k_sem_give(&ctx->trx_tx_sync);
 	rf2xx_trx_set_rx_state(dev);
 }
--- a/Show More
+++ b/Show More