Philip Molloy <philip@philipmolloy.com> says:

This series updates the maintainers for the ADI ADSP platform. It
follows Greg's series adding support for ADI ADSP SoCs.

Timesys spent years developing and maintaining Linux support for ADI
ADSP SoCs. The maintenance contract has ended and ADI has brought that
effort in-house. Additionally, Timesys was acquired by another company.

Thanks to everyone at Timesys for all of their hard work over the years!

Link: https://lore.kernel.org/r/20260226111136.354009-1-philip@philipmolloy.com

After years of developing the ADI ADSP platform, Timesys was purchased
by another company and is no longer contracted to maintain the platform.

Signed-off-by: Philip Molloy <philip.molloy@analog.com>
Reviewed-by: Greg Malysa <malysagreg@gmail.com>

Commit 067c1b033282 ("ufs: Call ufs_scsi_bind() from uclass .post_bind")
inlined ufs_scsi_bind() into ufs_post_bind() as trivial
device_bind_driver() call.

ufs_scsi_bind() is no longer referenced anywhere in the codebase, so
drop its declaration from include/ufs.h.

Drivers used to include <ufs.h> to include prototype of ufs_scsi_bind()
function, so we can now safely remove such includes.

Fixes: 067c1b033282 ("ufs: Call ufs_scsi_bind() from uclass .post_bind")
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260203-cleanup-ufs-header-v1-1-4c10424485f0@baylibre.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>

STM32MP21 application processors (STM32 MPUs) based on a single
Arm Cortex®-A35 core running up to 1.5 GHz and Cortex®-M33 core
running at 300 MHz.

It is pin-compatible with the STM32MP2 series in the VFBGA361
10×10 mm package: the STM32MP21 uses a subset of the STM32MP23
pinout, which itself is a subset of the STM32MP25.

More details available here :
https://www.st.com/en/microcontrollers-microprocessors/stm32mp2-series.html

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

Add clock driver support for STM32MP21 SoCs.

Signed-off-by: Nicolas Le Bayon <nicolas.le.bayon@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

Since commit 27cc5951c862 ("include: env: ti: add default for
do_main_cpsw0_qsgmii_phyinit"), the value of the environment variable
do_main_cpsw0_qsgmii_phyinit happened to remain '0' and couldn't be
changed without user intervention. This behavior is due to the following
cyclic dependency:
A) ti_common.env sets do_main_cpsw0_qsgmii_phyinit to '0' and its value
   can only be updated automatically by main_cpsw0_qsgmii_phyinit.
B) main_cpsw0_qsgmii_phyinit is defined in j721e.env and it can run only
   if 'do_main_cpsw0_qsgmii_phyinit' is already '1' which isn't possible
   unless the user manually assigns the value.

Fix the aforementioned cyclic dependency by using board_late_init() to
detect the QSGMII Daughtercard and set do_main_cpsw0_qsgmii_phyinit.

Additionally, to address the issue of do_main_cpsw0_qsgmii_phyinit being
'undefined' for other platforms, replace:
	if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1;
with:
	if env exists do_main_cpsw0_qsgmii_phyinit;
in ti_common.env.

Fixes: 27cc5951c862 ("include: env: ti: add default for do_main_cpsw0_qsgmii_phyinit")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>

Versal2 was using wrong GIC base mappings, causing GICR_TYPER reads to
not match EL1 MPIDR. This led U-Boot to walk beyond the per-CPU GICR
frames, access out-of-range addresses, and hit a synchronous exception
during early gic init percpu while booting up on alternate core
i.e., non cpu0.

Update Versal Gen 2 headers to the correct Versal Gen 2 bases.

Signed-off-by: Maheedhar Bollapalli <maheedharsai.bollapalli@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d0bc3fe1af8409fcfe505e55fb7042a33b845a4e.1770721325.git.michal.simek@amd.com

First set of u-boot-at91 features for the 2026.04 cycle:

This small fixes set includes fixing 64 bit builds and some warnings for
the at91 serial driver, and some cleanup on the nand driver.

The only call site of gzwrite() is cmd/unzip.c do_gzwrite(), where
the 'len' parameter passed to gzwrite(..., len, ...) function is of
type unsigned long. This usage is correct, the 'len' parameter is
an unsigned integer, and the gzwrite() function currently supports
input data 'len' of up to 4 GiB - 1 .

The function signature of gzwrite() function in both include/gzip.h
and lib/gunzip.c does however list 'len' as signed integer, which
is not correct, and ultimatelly limits the implementation to only
2 GiB input data 'len' .

Fix this, update gzwrite() function parameter 'len' data type to
size_t consistently in include/gzip.h and lib/gunzip.c .

Furthermore, update gzwrite() function 'szwritebuf' parameter in
lib/gunzip.c from 'unsigned long' to 'size_t' to be synchronized
with include/gzip.h . Rewrite the other parameters to size_t and
off_t and propagate the change too.

Since the gzwrite() function currently surely only supports input
data size of 4 GiB - 1, add input data size check. The limitation
comes from the current use of zlib z_stream .avail_in parameter,
to which the gzwrite() function sets the entire input data size,
and which is of unsigned int type, which cannot accept any number
beyond 4 GiB - 1. This limitation will be removed in future commit.

Reported-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Pointer size cannot be assumed to be 32-bit, so use uintptr_t instead of
uint32_t.

Fixes the below build warning on 64-bit builds:
drivers/serial/atmel_usart.c: In function ‘atmel_serial_probe’:
drivers/serial/atmel_usart.c:275:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  275 |         priv->usart = (atmel_usart3_t *)plat->base_addr;

Signed-off-by: Robert Marko <robert.marko@sartura.hr>