Merge tag 'xilinx-for-v2026.01-rc3' of https://source.denx.de/u-boot/custodians/u-boot-microblaze

CI: https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/28413

AMD/Xilinx/FPGA changes for v2026.01-rc3

- Align brcp1 boot.bin location
- Fix MB-V compilation warning when AXI enet is enabled

Merge branch 'u-boot-nand-20250918' of https://source.denx.de/u-boot/custodians/u-boot-nand-flash

CI: https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/28408

This pull request enhances NAND and SPI flash support, primarily
focusing on the Airoha EN7523 platform. The Airoha SPI driver receives
a major update, adding DMA, dual/quad-wire modes, and a critical
workaround to prevent flash damage if the UART_TXD pin shorts to Ground.

New chips supported include FudanMicro FM25S01A SPI-NAND and several
Winbond SPI NOR devices. Fixes include correcting Kconfig dependencies,
updating the mtd benchmark command to use lldiv(), and addressing minor
bugs in the generic spi-mem and SPL NAND code.

net: axi_emac: Fix compilation warnings

Fix compiler warnings about casting integers to pointers of different
sizes by using uintptr_t as intermediate type. This ensures proper
type conversion across 32-bit and 64-bit architectures.

Signed-off-by: Sai Varun Venkatapuram <saivarun.venkatapuram@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/11b1d9b1a5589d06cff724e807832f366794c075.1762510401.git.michal.simek@amd.com

arm: dts: brcp1: Move SPL partition to offset 0x8000 in SPI flash

The ROM code of Xilinx Zynq searches the boot flash for a "BootROM header"
at increments of 32k (0x8000), beginning with 0x0000 for a
configuration without authentication and beginning with 0x8000
for a configuration with authentication. [1]

Move the offset of the SPL partition on the brcp1 board to 0x8000
so that both cases are the same, e.g. a board that is configured
without authentication can boot an SPL partition with or without
authentication.

[1] Zynq 7000 TRM, section 6.3 "BootROM Code"

Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251029092252.115582-1-wolfgang.wallner@br-automation.com

mailmap: Add entry for Sam Protsenko

Use 'Sam Protsenko' as my name consistently in git-shortlog. Also map my
home email address (which I used at some point) to my current work
email.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

.mailmap: add Raymond Mao

The Linaro email address is no longer valid.
See commit 4cad9faf8d28 ("MAINTAINERS: update my email address")

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

lib: optee: forbid OP-TEE OS loading without adding OP-TEE OS reserved-memory nodes

I've spent time trying to figure out why my board (Rockchip PX30-based)
suddenly boot loops when running a specific program in Linux userspace
after working on a U-Boot upgrade. I actually inadvertently had the TEE
environment variable set for a device which doesn't actually need to run
any TEE OS (so had OPTEE_LIB disabled).

It is currently possible to build an image with an OP-TEE OS (via the
TEE environment variable) without OPTEE_LIB. U-Boot will happily load
the TEE OS and the next OS (e.g. the Linux kernel).

This is an issue because on FDT-enabled devices, OP-TEE OS adds nodes to
the reserved-memory FDT node for the memory regions it just reserved for
itself. This updated FDT is then passed to U-Boot proper which should
know better not to use memory from there. The actual issue is that
without OPTEE_LIB and OF_LIBFDT enabled, U-Boot proper will not copy
those nodes over to the next OS's FDT before starting it. This results
in the next OS's (e.g. Linux kernel) to not be aware of reserved memory,
incurring random crashes or device reboots when it tries to access
secure reserved memory area.

On Rockchip, the U-Boot FIT image which contains both the TEE OS and
U-Boot proper is generated by binman. Unfortunately, binman doesn't seem
to have access to Kconfig symbols (grep CONFIG_ doesn't return anything
meaningful and binman is either configured through FDT nodes or via CLI
arguments, c.f. cmd_binman in the root Makefile) so we cannot try to be
smart and guide the user to the correct Kconfig option to select if TEE
is set. We could add a property based on the presence of OPTEE_LIB in
rockchip-u-boot.dtsi for example and have a custom message based on
that, the issue is that I assume all FDT-based platforms do actually
need to do this dance, and not only Rockchip.

Another option could be to add a CLI argument to binman through which
we would pass the state of OPTEE_LIB and error out the build in that
case, but that feels like opening the door to other various dirty hacks.

Another option is to propagate the TEE environment variable to the
preprocessor of the FDT (via dtc_cpp_flags) and then we can do

  #if defined(TEE) && !IS_ENABLED(CONFIG_OPTEE_LIB)
  #error "CONFIG_OPTEE_LIB must be enabled!"
  #endif

but we have the same issue as above, it is then Rockchip-specific and
doesn't feel right to me.

Yet another option is to remove the @tee-SEQ node from the binman FIT
description when OPTEE_LIB isn't set but then we would lose the
following nice message when no TEE is provided:

Image 'simple-bin' is missing optional external blobs but is still functional: tee-os

and even worse, build without any TEE OS even though we could provide
one via the TEE environment variable.

Finally, another option could be to move this hack under
arch/arm/mach-rockchip/Kconfig to make it Rockchip-specific or add a
depends on ARCH_ROCKCHIP. However OP-TEE OS on Aarch32 Rockchip boards
doesn't actually need any of that if SPL_OPTEE_IMAGE is set because
arch/arm/mach-rockchip/sdram.c then marks some hardcoded memory regions
in RAM as holes in DRAM, which has the same effect as reserved memory
regions I guess. I assume other platforms may use something different,
so it may be casting too wide of a net.

This commit is what I could come up with as a stopgap measure to avoid
building images that simply cannot reliably work and fail randomly.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

smbios: Fix warning when building with clang

When building with clang, we see warnings such as:
error: field max_size within 'struct smbios_type7' is less aligned than
'union cache_size_word' and is usually due to 'struct smbios_type7'
being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building drivers/sysinfo/smbios.c. Resolve this error by packing
the unions as well after verifying they are complete (16 or 32 bits).

Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

Merge patch series "Fixes for Clang builds for AArch64, improve CROSS_COMPILE handling"

Dmitrii Sharshakov <d3dx12.xx@gmail.com> says:

Initially fix the inconsistency reported in reply to the previous
series and also make sure AArch64 images can be built with latest
Clang versions by guarding AArch32-specific options behind extra
config checks.

Tested qemu_arm_defconfig and qemu_arm64_defconfig with Clang 21,
mainline (to be 22) ce7f9f9c and also Clang 18 (for AArch64 only, as I
have not managed to build an AArch32 image with clang-18).

Link: https://lore.kernel.org/r/20251108-clang-cross-fixes-v1-0-ea6c4282844a@gmail.com

arch: arm: fix AArch64 builds with Clang 21+

Clang is strict with respect to unknown options.

Therefore, only enable AArch32-specific options when CONFIG_ARM64
is not set.

Signed-off-by: Dmitrii Sharshakov <d3dx12.xx@gmail.com>

build: fix prefix for Clang when CROSS_COMPILE is an absolute path

Clang cross-compilation worked when cross binutils were available
in PATH. However, when binutils are not in the PATH clang failed to
discover the assembler, falling back to host one.

Make --prefix always absolute, Clang supports this and will search for
e.g. $(prefix)-as for assembler. This makes sure user does not have to
add cross binutils to PATH for Clang build.

Fixes build for these examples (with qemu_arm(64)_defconfig):

make CC=clang-21 CROSS_COMPILE=/.../bin/arm-none-eabi-
make CC=clang-20 CROSS_COMPILE=/.../bin/aarch64-linux-gnu-

Also validated for the case when provided with cross toolchain on PATH:

PATH=/.../bin:$PATH make CC=clang-21 CROSS_COMPILE=arm-none-eabi- -j20

This patch does not affect GCC builds, and they have _not_ been
validated against regressions.

Reported-by: Tom Rini <trini@konsulko.com>
Closes: https://lore.kernel.org/u-boot/20251106221355.GZ6688@bill-the-cat/
Signed-off-by: Dmitrii Sharshakov <d3dx12.xx@gmail.com>

spi: airoha: en7523: workaround flash damaging if UART_TXD was short to GND

We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of it's BOOT pins. This will lead
to booting in RESERVED boot mode.

It was found that some flashes operates incorrectly in RESERVED mode.
Micron and Skyhigh flashes are definitely affected by the issue,
Winbond flashes are NOT affected.

Details:
--------
DMA reading of odd pages on affected flashes operates incorrectly. Page
reading offset (start of the page) on hardware level is replaced by 0x10.
Thus results in incorrect data reading. Usage of UBI make things even
worse. Any attempt to access UBI leads to ubi damaging. As result OS loading
becomes impossible.

Non-DMA reading is OK.

This patch detects booting in reserved mode, turn off DMA and print big
fat warning.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: avoid usage of flash specific parameters

The spinand driver do 3 type of dirmap requests:
 * read/write whole flash page without oob
   (offs = 0, len = page_size)
 * read/write whole flash page including oob
   (offs = 0, len = page_size + oob_size)
 * read/write oob area only
   (offs = page_size, len = oob_size)

The trick is:
 * read/write a single "sector"
 * set a custom sector size equal to offs + len. It's a bit safer to
   round up "sector size" value 64.
 * set the transfer length equal to custom sector size

And it works!

Thus we can find all data directly from dirmap request, so flash specific
parameters is not needed anymore. Also
 * airoha_snand_nfi_config(),
 * airoha_snand_nfi_setup()
functions becomes unnecessary.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: set custom sector size equal to flash page size

Set custom sector size equal to flash page size including oob. Thus we
will always read a single sector. The maximum custom sector size is
8187, so all possible flash sector sizes are supported.

This patch is a necessary step to avoid usage of flash specific
parameters.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: reduce the number of modification of REG_SPI_NFI_CNFG and REG_SPI_NFI_SECCUS_SIZE registers

This just reduce the number of modification of REG_SPI_NFI_CNFG and
REG_SPI_NFI_SECCUS_SIZE registers during dirmap operation.

This patch is a necessary step to avoid usage of flash specific
parameters.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: avoid setting of page/oob sizes in REG_SPI_NFI_PAGEFMT

spi-airoha-snfi uses custom sector size in REG_SPI_NFI_SECCUS_SIZE
register, so setting of page/oob sizes in REG_SPI_NFI_PAGEFMT is not
required.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

dts: airoha: en7523: enable double speed flash reading

it should work properly after the airoha-snfi driver patches

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: buffer must be 0xff-ed before writing

During writing, the entire flash page (including OOB) will be updated
with the values from the temporary buffer, so we need to fill the
untouched areas of the buffer with 0xff value to prevent accidental
data overwriting.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: support of dualio/quadio flash reading commands

Airoha snfi spi controller supports acceleration of DUAL/QUAD
operations, but does not supports DUAL_IO/QUAD_IO operations.
Luckily DUAL/QUAD operations do the same as DUAL_IO/QUAD_IO ones,
so we can issue corresponding DUAL/QUAD operation instead of
DUAL_IO/QUAD_IO one.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: return an error for continuous mode dirmap creation cases

This driver can accelerate single page operations only, thus
continuous reading mode should not be used.

Continuous reading will use sizes up to the size of one erase block.
This size is much larger than the size of single flash page. Use this
difference to identify continuous reading and return an error.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: add dma support

This patch speed up cache reading/writing/updating opearions.
It was tested on en7523/an7581 and some other Airoha chips.

It will speed up
 * page reading/writing without oob
 * page reading/writing with oob
 * oob reading/writing (significant for UBI scanning)

The only know issue appears in a very specific conditions for en7523 family
chips only.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: add support of dual/quad wires spi modes to exec_op() handler

Booting without this patch and disabled dirmap support results in

[    2.980719] spi-nand spi0.0: Micron SPI NAND was found.
[    2.986040] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
[    2.994709] 2 fixed-partitions partitions found on MTD device spi0.0
[    3.001075] Creating 2 MTD partitions on "spi0.0":
[    3.005862] 0x000000000000-0x000000020000 : "bl2"
[    3.011272] 0x000000020000-0x000010000000 : "ubi"
...
[    6.195594] ubi0: attaching mtd1
[   13.338398] ubi0: scanning is finished
[   13.342188] ubi0 error: ubi_read_volume_table: the layout volume was not found
[   13.349784] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22
[   13.356897] UBI error: cannot attach mtd1

If dirmap is disabled or not supported in the spi driver, the dirmap requests
will be executed via exec_op() handler. Thus, if the hardware supports
dual/quad spi modes, then corresponding requests will be sent to exec_op()
handler. Current driver does not support such requests, so error is arrised.
As result the flash can't be read/write.

This patch adds support of dual and quad wires spi modes to exec_op() handler.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: airoha: remove unnecessary operation adjust_op_size

This operation is not needed because airoha_snand_write_data() and
airoha_snand_read_data() will properly handle data transfers above
SPI_MAX_TRANSFER_SIZE.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

spi: spi-mem: fix coverity report CID 537478

Coverity finds a potential integer overflow in the following code:

  ncycles += ((op->data.nbytes * 8) / op->data.buswidth) / (op->data.dtr ? 2 : 1);

A quick analysis shows that the only caller of the suspicious code is the
spinand_select_op_variant() function from the drivers/mtd/nand/spi/core.c
file.

According to the code the value of op->data.nbytes is equal to

  nanddev_per_page_oobsize(nand) + nanddev_page_size(nand)

Therefore it's maximum value a bit larger than 4Kb (I never seen flashes
with page size large than 4Kb). So op->data.nbytes always fits within
13 bits. As result an overflow will never happen.

Anyway it's better fix an issue to eliminate the error message.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

mtd: nand: raw: Drop SYS_NAND_SOFT_ECC from NAND_SANDBOX

This option is only meaningful within the davinci nand driver, so drop
the statement here (which had no effect).

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

mtd: spinand: add support for FudanMicro FM25S01A

Add support for FudanMicro FM25S01A SPI NAND.

This driver is ported from linux v6.18 and tested on a MT7981 board.

Link: https://lore.kernel.org/linux-mtd/20250824170013.3328777-1-cnsztl@gmail.com/
Reviewed-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>

spl: nand: typo 'destintion'

%s/destintion/destination/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

cmd: mtd: benchmark: use lldiv() instead of 64-bit division

As was noted by Heinrich Schuchardt, some SoCs may not support 64-bit
divisions. Fix an issue by using lldiv() instead.

The code assumes that the benchmark never takes more than 4294 seconds
and thus the difference will be less than U32_MAX.

Also replace (speed / 1024) by (speed >> 10) to avoid potential 64-bit
division.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

nand: raw: Kconfig: Correct some dependency issues

The hidden symbol SPL_SYS_NAND_SELF_INIT was not being used correctly
leading to Kconfig dependency issues seen with "make allyesconfig". As
it's a select'd symbol we don't need to have a depends line on it, and
then in turn we need to also update the logic on SYS_NAND_PAGE_SIZE and
SYS_NAND_OOBSIZE.

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

mtd: spinor: winbond: Describe several chips

All these chips are dual and quad capable. They are also DTR capable,
but the core is not yet ready for that.

Performances of all chips are comparable at 30MHz and are as follow:
Eraseblock single read speed: 938kiB/s
Eraseblock dual read speed:  1068kiB/s
Eraseblock quad read speed:  3751kiB/s

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Merge tag 'u-boot-stm32-20251117' of https://source.denx.de/u-boot/custodians/u-boot-stm

CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/28392

dhelectronics:
  - Move dh_add_item_number_and_serial_to_env() to common code
  - Read values from M24256 write-lockable page on STM32MP13xx DHCOR
  - Add MAC address readout from fuses on DH STM32MP1 DHSOM
  - Keep the reg11 and reg18 regulators always enabled on STM32MP13xx DHCOR.
  - Fix boot for stm32mp15xx-dhsom.
  - Fix build of ST DFU virt code on DH STM32MP1 DHSOM
  - Introduce DH STM32MP13x target.

STM32MP2:
  - Add support for stm32mp257-dk board.
  - Fix arm, smc-id value for stm32mp23/25.
  - Fix stm32mp235f-dk boot (add syscon compatible, add txbyteclk).
  - Add display support:
    - Introduce LVDS driver.
    - Add LTDC support.
  -  Add Ethernet support for stm32mp255.

STM32MP13:
  - Add ADC support.
  - Add power check for stm32mp135f-dk board.

ARM: stm32: Add MAC address readout from fuses on DH STM32MP1 DHSOM

Add support for reading out the MAC address from SoC fuses on DH STM32MP1 DHSOM.
The DH STM32MP1 DHSOM may contain external ethernet MACs, which benefit from the
MAC address stored in SoC fuses as well, handle those consistently. This however
means the architecture setup_mac_address() cannot be used and instead a simpler
local fuse read out is implemented in the board file.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: stm32: Read values from M24256 write-lockable page on STM32MP13xx DHCOR

The STM32MP13xx DHCOR SoM is populated with M24256 EEPROM that contains
an additional write-lockable page called ID page, which is populated with
a structure containing ethernet MAC addresses, DH item number and DH serial
number.

Read out the MAC address from the WL page between higher priority SoC fuses
and lower priority plain EEPROM storage area. Read out the DH item and serial
numbers and set environment variables accordingly.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

board: dhelectronics: Move dh_add_item_number_and_serial_to_env() to common code

Move dh_add_item_number_and_serial_to_env() to common code, so it
can be used by both STM32MP13xx and iMX8MP DHSOM. No functional
change.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: stm32: Add missing build of ST DFU virt code on DH STM32MP1 DHSOM

Commit 6d91f0a3a14d ("board: st: common: cleanup dfu support") split
the vendor-specific DFU implementation into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
with plain simple dfu-util, but it makes the ST proprietary programmer
CLI tool end in an infinite loop. Update the Makefile accordingly to
allow even that kind of tooling to work.

Fixes: 6d91f0a3a14d ("board: st: common: cleanup dfu support")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: dts: stm32: Introduce DH STM32MP13x target

Split the DH STM32MP13x based boards from ST STM32MP13x target,
this way the DH board specific code can be reused for STM32MP13x
DHSOM.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: dts: stm32: Keep the reg11 and reg18 regulators always enabled on STM32MP13xx DHCOR

Do not disable reg11 and reg18, disabling these regulators causes
the SoC to hang.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: dts: stm32: Fix STM32MP15xx DHSOM boot breakage due to ETZPC

Switch etzpc bus to simple-bus to prevent breakage on non-TFA systems.
This fixes boot of every STM32MP15xx DHSOM device.

Fixes: ad3cdc677dda ("ARM: stm32mp: add ETZPC system bus driver for STM32MP1")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

arm: stm32mp25: add ethernet support for stm32mp255 series

Add missing CPU_STM32MP255* cases in get_eth_nb() so that U-Boot
correctly reports 2 Ethernet interfaces on stm32mp255 devices.
This fixes the "ethernet not found" error during boot.

Signed-off-by: Md Asadullah <md.asadullah@eds-india.com>

configs: stm32mp25: enable LVDS display support

Compile VIDEO_STM32 and VIDEO_STM32_LVDS by default.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>

video: stm32: ltdc: properly search the first available panel

Initially there was only one DSI bridge with one panel attached to this
device. This explained the call to uclass_first_device_err(UCLASS_PANEL,
...) which worked fine at the time.

Now that multiple bridges and panels, with different technologies, can
be plugged onto the board this way to get the panel device is outdated.

The lookup is done is two steps. First we circle through the
UCLASS_VIDEO_BRIDGE, and once we get one, we search through its
endpoints until we get a UCLASS_PANEL device available.

Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

video: stm32: ltdc: support new hardware version for STM32MP25 SoC

STM32MP2 SoCs feature a new version of the LTDC IP.  This new version
features a bus clock, as well as a 150MHz pad frequency.  Add its
compatible to the list of device to probe and handle quirks.  The new
hardware version features a bus clock.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>

video: stm32: STM32 driver support for LVDS

The LVDS Display Interface Transmitter handles the LVDS protocol:
it maps the pixels received from the upstream Pixel-DMA (LTDC)
onto the LVDS PHY.

The LVDS controller driver supports the following high-level features:
        • FDP-Link-I and OpenLDI (v0.95) protocols
        • Single-Link or Dual-Link operation
        • Single-Display or Double-Display (with the same content
          duplicated on both)
        • Flexible Bit-Mapping, including JEIDA and VESA
        • RGB888 or RGB666 output
        • Synchronous design, with one input pixel per clock cycle
        • No resolution limitation.

Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>

video: simple_panel: add support for "panel-lvds" display

Add the compatible "panel-lvds" for simple-panel driver in U-Boot.  In
Linux this compatible is managed by the driver
drivers/gpu/drm/panel/panel-lvds.c but in U-Boot the specific LVDS
features (bus_format/bus_flags) are not supported.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>

ofnode: support panel-timings in ofnode_decode_display_timing

The "Display Timings" in panel-common.yaml can be provided by 2 properties
- panel-timing: when display panels are restricted to a single resolution
                the "panel-timing" node expresses the required timings.
- display-timings: several resolutions with different timings are supported
                   with several timing subnode of "display-timings" node

This patch update the parsing function to handle this 2 possibility
when index = 0.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>

ARM: dts: Add st, adc_usb_pd property for stm32mp135-dk-u-boot

Add st,adc_usb_pd property in /config node for stm32mp135-dk-u-boot.
This needed to check board USB power delivery.

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

configs: stm32: Enable ADC support for stm32mp13_defconfig

Enable STM_ADC and CM_ADC for stm32mp13_defconfig

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

adc: stm32mp13: add support of adc to stm32mp13

Add support of STM32 ADCs to STM32MP13x. This patch introduces
stm32_adc_regspec structure, as this is already done in kernel
driver, to manage smartly the differences in register set
between STMP32MP15 and STM32MP13 ADCs.

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

stm32mp: Add stm32mp23 support for syscon driver

Add "st,stm32mp23-syscfg" compatible.

Fixes: fdd30ee308a2 ("ARM: stm32mp: Add STM32MP23 support")

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

ARM: dts: Add txbyteclk clock in stm32mp235f-dk-u-boot.dtsi

Add txbyteclk to avoid error during clock registration.

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

ARM: dts: Fix "arm, smc-id" value for stm32mp25-u-boot.dtsi

OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.

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

ARM: dts: Fix "arm, smc-id" value for stm32mp23-u-boot.dtsi

OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.

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

ARM: dts: Add stm32mp257f-dk-u-boot.dtsi

Add U-Boot support for stm32mp257f-dk board.

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

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

Pull request efi-2026-01-rc3

CI:

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

Documentation:

* Correct the linux/arm64 platform string for Docker builds
* Complete pytest dependencies list with missing packages

UEFI:

* Use Sphinx style comments in efi_selftest_console.c
* Don't include asm/global_data.h in lib/efi_client/efi_app.c twice
* efi_client: correct memset() return value
* Assure fitImage from capsule is used from 8-byte aligned address
* Fix warning when building efi_selftest_snp with clang

Merge tag 'i2c-updates-for-2026.01-rc3' of https://source.denx.de/u-boot/custodians/u-boot-i2c

I2C updates for 2026.01-rc3

- i2c: mux: declare staic functions where posible
  from Michal

efi_loader: Assure fitImage from capsule is used from 8-byte aligned address

The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_selftest: efi_selftest_snp: Fix warning when building with clang

When building with clang, we see a warning:
lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within
'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due
to 'struct dhcp' being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by
packing struct dhcp_hdr as well, as the only place it is used also is
packed.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

docker: Correct the linux/arm64 platform string

The Dockerfile is using linux/arm64 without the /v8 suffix.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_client: correct memset() return value

Memset() must return a pointer to the start of the updated memory block.

Fixes: 476476e73b14 ("efi: Add support for loading U-Boot through an EFI stub")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_client: don't include asm/global_data.h twice

Remove duplicate #include.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: typo 'eventfor' in efi_ipconfig.c

%s/eventfor/event for/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_selftest: use Sphinx style comments in efi_console.c

Convert function comments in efi_selftest_console.c to match
Sphinx style.

Correct function name in print_uuid() comment.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: pytest: Complete dependencies list with missing packages

Add missing dependencies to the pytest usage documentation and correct
the device tree compiler package name from 'dtc' to 'device-tree-compiler'.

This ensures users have the complete list of dependencies needed to run
the pytest test suite without errors.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

i2c: muxes: i2c_mux_select/deselect() should be static

i2c_mux_select/deselect() are not called out of i2c-mux-uclass.c that's why
they should be static.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Heiko Schocher <hs@nabladev.com>

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh

- R-Car Gen4 pinctrl alignment with latest reference manual.

pinctrl: renesas: r8a779h0: Remove STPWT_EXTFXR

Rev.0.81 of the R-Car V4M Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables.  As this is
further unused in the pin control driver, it can be removed safely.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

pinctrl: renesas: r8a779h0: Remove CC5_OSCOUT

Rev.0.71 of the R-Car V4M Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables.  As this is
further unused in the pin control driver, it can be removed safely.

Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

pinctrl: renesas: r8a779g0: Remove STPWT_EXTFXR

Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables.  As this is
further unused in the pin control driver, it can be removed safely.

Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

pinctrl: renesas: r8a779g0: Remove CC5_OSCOUT

Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables.  As this is
further unused in the pin control driver, it can be removed safely.

Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

pinctrl: renesas: r8a779g0: Remove AVB[01]_MII

Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"AVB[01]_MII_*" signals from the pin control register tables.  As these
are further unused in the pin control driver, they can be removed
safely.

Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Merge branch 'master' of git://source.denx.de/u-boot-usb

- Remove some legacy code and tighten Kconfig dependencies.

usb: gadget: Tighten CI_UDC dependencies

This driver cannot build when DM_USB_GADGET is enabled as both options
control building of files that use the same global namespace and
functionality. In this case make CI_UDC depend on DM_USB_GADGET being
disabled as non-DM support is the legacy choice.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

usb: host: xhci: Make U_BOOT_DRIVER entries unique

All instances of the U_BOOT_DRIVER must use a unique name or they will
lead to link time failures due to name space conflicts when both are
present. Most of the XHCI drivers follow pattern of xhci_xxx in their
name, but a few used "usb_xhci". Change these to follow the pattern of
the rest of the XHCI glue drivers.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>

usb: gadget: Tighten the dependency for DWC2 OTG support

The DWC2 OTG driver depends on an ARM-specific header file to compile,
so make it depend on ARM.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

usb: musb: drop musb legacy drivers

The last of the users of the legacy musb drivers have been
migrated so now remove the old musb stack, all users should
now be using the new musb stack if they need this functionality.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[trini: Remove a Makefile reference that was missed in v1]
Signed-off-by: Tom Rini <trini@konsulko.com>

omap3: evm: Drop old musb omap3 driver

The USB_OMAP3 driver was (re)added in commit e74e9f620a6 as part
of migrating to DM_USB but the config already had MUSB_OMAP2PLUS
which is the newer musb driver and what other omap3 devices use.
So drop it so we can drop the old driver.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>

usb: gadget: spl: Add missing dependency for SPL_USB_GADGET

It makes no sense to ask about nor enable SPL_USB_GADGET without
SPL_FRAMEWORK being enabled. Attempting to do so leads to Kconfig noting
dependency issues. Add the missing dependency.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

Gitlab: Optimize the job dependency list more

In general, we want to fail the whole pipeline as soon as we can if we
spot an error while also letting bigger jobs get started as soon as
possible. Currently we use the "Run binman, buildman, dtoc, Kconfig and
patman testsuites" job from the testsuite stage to unblock the next
stage as this test is complex enough that if it passes, likely the whole
stager will pass. Using this same logic, unblock the world build (and
sjg-lab) stages if "sandbox test.py" has completed as if there's no
failures here, there's likely not failures in the rest of the test.py
stages.

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

Gitlab: Prefix more of the sjg lab with "sjg"

In preparation for adding more labs to CI, prefix more of the sjg lab
components with "sjg".

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

dm: typo programmaticaly

%s/programmaticaly/programmatically/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

ARM: Fix HAS_ARMV7_SECURE_BASE help text

Drop the 'a' from 'ahardware', no functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

.gitignore: ignore more files generated for the sandbox

Change the existing regex "/capsule.*.efi-capsule" to
also ignore the following files when building the sandbox:

capsule_in.capsule1.efi-capsule
capsule_in.capsule10.efi-capsule
capsule_in.capsule11.efi-capsule
capsule_in.capsule2.efi-capsule
capsule_in.capsule3.efi-capsule
capsule_in.capsule4.efi-capsule
capsule_in.capsule5.efi-capsule
capsule_in.capsule6.efi-capsule
capsule_in.capsule7.efi-capsule
capsule_in.capsule8.efi-capsule
capsule_in.capsule9.efi-capsule

As test/overlay folder was renamed to test/fdt_overlay,
fix the related ignore entries:

test/fdt_overlay/test-fdt-overlay-stacked.dtbo.S
test/fdt_overlay/test-fdt-overlay.dtbo.S

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>

scsi: Fix the name string memory leak during scsi scan

There is a memory leak during the scsi scan process due to the
strdup'ed name string is never freed. Actually it is unnecessary
to pass a strdup'ed name string to blk_create_devicef() as we can
use the name string on the stack directly.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

gpio: OMAP: add dependency to TI_SYSC

OMAP GPIO driver needs TI_SYSC to initialize its clocks when
using a devicetree-based setup.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>

qfw: Fix segfault from uninitialized variables in sandbox

There are cases where qfw_read_entry() does not set the output parameter
passed by address. This occurs with qfw_sandbox_read_entry_dma, which
leaves the size variables uninitialized and causes a segfault when running
bootflow scan in U-Boot sandbox.

$ ./u-boot
...
U-Boot 2026.01-rc1-00199-gc2637036b8f0 (Nov 04 2025 - 10:32:21 +0100)
...
Hit any key to stop autoboot: 0
=> bootflow scan
     efi_var_to_file() Cannot persist EFI variables without system partition
   efi_tcg2_register() Missing TPMv2 device for EFI_TCG_PROTOCOL
    efi_rng_register() Missing RNG device for EFI_RNG_PROTOCOL
scanning bus for devices...
[3]    1015761 segmentation fault (core dumped)  ./u-boot

Initalize all these variables to 0 to fix this issue.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>

Merge tag 'scmi-master-2025-11-11' of https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq

CI: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/28272

- Support scmi v3.2 CONFIG_SET for clock protocol
- A patchset from Marek to optimize the scmi clk booting time
- Fix scmi clk set_parent in non-CCF case
- Drop mmu_set_region_dcache_behaviour in firmware scmi

Prepare v2026.01-rc2

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

dm: Remove pre-schema tag support

Support for using "u-boot,dm-..." rather than "bootph-..." has been
deprecated since February 2023. Any platforms using this have had a
console message saying to migrate by 2023.07. Go and remove all support
here now, for the v2026.01 release.

The results of this change that aren't clear from the above are that we
still have a checkpatch.pl error message, and document in
doc/develop/spl.rst that they have been migrated since 2023. We also
change the key2dtsi.py tool to use the correct bootph phase rather than
the legacy phase.

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

clk: scmi: Defer issue of SCMI_CLOCK_ATTRIBUTES

Instead of resolving clock control flags using SCMI_CLOCK_ATTRIBUTES
during probe for each and every clock, resolve the clock control
flags using SCMI_CLOCK_ATTRIBUTES when the clock control flags are
first used. Because most clock are never used by U-Boot, this allows
reducing the amount of SCMI_CLOCK_ATTRIBUTES considerably, and this
improve probe time of the scmi clock driver and U-Boot start up time.

On Renesas X5H, with 1700+ SCMI clock, the boot time improved by 1.7s .

Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

clk: scmi: Postpone clock name resolution

The clock names are retrived via SCMI_CLOCK_ATTRIBUTES, called for each
clock ID. This may take a lot of time to complete and is not strictly
necessary. Register each clock as "scmi-%zu" instead, and let the first
call of SCMI_CLOCK_ATTRIBUTES fill in the actual clock name.

This has a side effect, which can be considered both an upside and also
a downside. Unused clock are never renamed and retain their placeholder
"scmi-%zu" name, which avoids empty clock names for nameless SCMI clock,
and avoids the name resolution and improves boot time. But for those
SCMI clock which do have name, that name is not listed until the clock
are used.

This is a preparatory patch for deferred issue of SCMI_CLOCK_ATTRIBUTES.

Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

clk: scmi: Factor out clock control flags resolution

Pull clock control flags resolution into dedicated function and
call it from each site that does access clock control flags. No
functional change.

This is a preparatory patch for deferred issue of SCMI_CLOCK_ATTRIBUTES.

Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

clk: scmi: Bulk allocate all sub-driver instance data

Allocate all sub-driver instance data at once. The amount of data that
have to be allocated is known up front, so is the size of the data, so
there is no need to call malloc() in a loop, mallocate all data at once.

The upside is, less heap fragmentation and fewer malloc() calls overall,
and a faster boot time.

The downside is, if some of the clock fail to register, then the clock
driver cannot free parts of the bulk allocated sub-driver instance data.
Such a failure can only occur if clk_register() were to fail, and if that
happens, the system has more significant problems. Worse, if a core clock
driver fails to probe, the system has even bigger problem.

Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

clk: scmi: fix set_parent support when CCF is not being used

When not using Common clock framework(CCF), calls to
scmi_clk_set_parent returns -ENOTSUPP, which should not be the case.
Fix that.

Fixes: 15fdfef6642c ("clk: scmi: check the clock state/parent/rate
control permissions)

Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

firmware: scmi: Add clock v3.2 CONFIG_SET support

SCMI v3.2 introduces a new clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests. Add support to use such new format when
talking to a v3.2 compliant SCMI platform.

Support existing enable/disable operations across different clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.

No functional change for the SCMI drivers users of the related enable and
disable clock operations.

[Marek: Remodel after Linux e49e314a2cf7 ("firmware: arm_scmi: Add clock v3.2 CONFIG_SET support")
        Support both old < 2.1 and new >= 2.1 protocol versions.
Update commit message based on Linux one]

Signed-off-by: Vinh Nguyen <vinh.nguyen.xz@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

firmware: scmi: Drop mmu_set_region_dcache_behaviour() misuse

MMU region cache behavior configuration for SCMI/SMT mailboxes is
platform specific. Even on ARM systems, the mailbox memory may not
even be located in any cacheable MMU region and may instead reside
in some SRAM. Remove this non-generic cache behavior configuration
code from generic code path.

It is unlikely that any platform is affected by this change if it
did configure its MMU regions correctly on start up. Platforms
which might be affected are i.MX94/95 and STM32MP.

Fixes: 240720e9052f ("firmware: scmi: mailbox/smt agent device")
Fixes: 2a3f161c8b16 ("scmi: correctly configure MMU for SCMI buffer")
Fixes: b2ae10970d40 ("firmware: scmi: use PAGE_SIZE alignment for ARM64")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Alice Guo <alice.guo@nxp.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

firmware: scmi: Fix up code comments

Fix multiple instances of copy-paste errors. Fill in missing
headers for CLOCK_GET_PERMISSIONS message and response.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

configs: Resync with savedefconfig

Resync all defconfig files using qconfig.py

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

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh

Remaining R-Car Gen5 driver patches, MMC, clock. Also a trivial
adjustment for mailbox core to allow operation without .recv callback.

Merge patch series "Add support for TI AM6254atl SiP"

Anshul Dalal <anshuld@ti.com> says:

This patch series adds support for AM6254atl SiP (or AM62x SiP for
short) to U-Boot.

The OPN (Orderable Part Number) 'AM6254atl' expands as follows[1]:

AM6254atl
     ||||
     |||+-- Feature Lookup (L indicates 512MiB of integrated LPDDR4)
     ||+--- Device Speed Grade (T indicates 1.25GHz on A53 cores)
     |+---- Silicon PG Revision (A indicates SR 1.0)
     +----- Core configuration (4 indicates A53's in Quad core config)

AM62x SiP provides the existing AM62x SoC with 512MiB of DDR
integrated in a single packages. The first 4 patches in the series
are cherry-picked from the devicetree-rebasing repository at
'v6.18-rc2-dts'.

Link: https://lore.kernel.org/r/20251025-62sip_support-v3-0-b4c8314d0055@ti.com

Merge patch series "Add PCIe Endpoint controller support for TI J784S4 SoC"

Hrushikesh Salunke <h-salunke@ti.com> says:

This series enables PCIe Endpoint mode on TI's J784S4 SoC. The J784S4
SoC features two Cadence PCIe controller instances (PCIe0 and PCIe1)
that can operate in endpoint mode. This series adds support for
configuring these controllers with up to 4 lanes.

Key changes include:
- Adding a stabilization delay after power domain reset to prevent
  timing-related initialization issues
- SERDES mux configuration support for proper lane routing, which is
  essential for SoCs where SERDES lanes are shared between multiple
  controllers (PCIe, USB, etc.) with different configurations across
  boot phases
- J784S4 SoC endpoint configuration with 4-lane support
- Disabling unconfigured endpoint functions to prevent enumeration
  issues on the Root Complex side

This series has been tested on J784S4 EVM with PCIe endpoint boot
configuration. Following are the corresponding test logs.

https://gist.github.com/hrushikesh221/331d65f45f43fd138f57e6adb61c4332

Link: https://lore.kernel.org/r/20251023114604.3655625-1-h-salunke@ti.com