board: samsung: e850-96: Keep public functions together

Move DRAM init functions close to other public functions, to make things
visually distinct and improve the readability.

No functional change.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

gpio: s5p: increment bank base address only if bank is initialized

There is a condition guard which ensures that the GPIO node, indeed
describes a GPIO controller.

if (!fdtdec_get_bool(blob, node, "gpio-controller"))
continue;

Since the bank base is being incremented in the loop, it is done so
irrespective of whether the node is a GPIO controller or not. This leads
to the incorrect resolution of bank base addresses.

Move it out of the loop, and instead increment the bank base address
only if the driver successfully binds a GPIO controller.

Reviewed-by: Henrik Grimler <henrik@grimler.se>
Fixes: b8809e60cdb5 ("dm: exynos: gpio: Convert to driver model")
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

soc: exynos-pmu: add support for Exynos7 PMU

Add the compatible string of Exynos7's PMU as defined in upstream
dt-schema. This also supports derivative PMUs as defined in schema.
There's no additional setup required here, so pmu_init is skipped.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

serial: s5p: add compatible for exynos8895

Add the compatible for Exynos8895 UART as described in upstream
devicetree bindings. This enables support for Exynos8895 and other
similar UART devices, such as Exynos7870. Other than that, the driver
works as-is.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

pinctrl: exynos78x0: add proper support for exynos7870 pinctrl

The pinctrl blocks for Exynos7870 and Exynos7880 are similar, however in
Exynos7870, the CCORE block is actually referred to as MIF. Since
ordering happens lexically, it isn't directly compatible with
samsung,exynos78x0-pinctrl.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

pinctrl: exynos: bind GPIO driver along with pinctrl

The devicetree of Samsung devices typically have the pin controller and
GPIO bank descriptors under the same pinctrl node. In U-Boot, these are
handled by two separate drivers. It is not possible to invoke both
drivers from a single node compatible.

Bind the GPIO driver on pinctrl driver bind, with the same OF node as
the pinctrl driver. This solution is already being used in other pinctrl
drivers. The hierarchy, as represented in `dm tree`, is as follows:

  pinctrl@13750000
  |-- gpio-banks
  |   |-- gpr0-gpio-bank
  |   |-- gpr1-gpio-bank
  |   |-- gpr2-gpio-bank
  |   |-- gpr3-gpio-bank
  |   `-- gpr4-gpio-bank
  |-- sd0-bus-width1-pins
  |-- sd0-bus-width4-pins
  |-- sd0-bus-width8-pins
  `-- sd0-clk-pins

Since a bind function doesn't exist, create and add it to all pinctrl
drivers.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

clk: use private clk struct to access clock flags

There may be cases where the flags set for a clock is not available.
This is usually the case with clocks which have been retrieved using
clk_request(). However, clock flags are found in their respective
private clock struct, so use that instead.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

clk: exynos: add support for Exynos7870 CMU

Introduce a simple clock driver for Exynos7870's CMU blocks, more
specifically, CMU_MIF, CMU_FSYS, and CMU_PERI banks. This should be
enough to serve U-Boot's minimal requirements.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

clk: exynos: add function for Samsung CMU ops->request

The request function performs a simple check if the clock with the
provided ID is present or not. This is done with a simple call to
clk_get_by_id(). A non-zero return value indicates that the requested
clock is not available.

In some cases, clk->dev points to the clock bank device instead of
the clock device. This pointer is therefore overwritten in order to
reference to the correct device instance.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

clk: exynos: add support for PLL1417X

PLL1417X seem to be compatible with PLL0822X, as also seen in the
respective Linux kernel driver. Add an enum entry for the type, while
merely being an alias for PLL0822X.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

clk: exynos: add support for fixed rate and fixed factor clocks

Add register functions for fixed rate and fixed factor clock drivers.
The vendor-specific structs defined are borrowed from the CCF driver
found in the Linux kernel.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

clk: exynos: provide device pointer to clk_register_* functions

The device pointer set as NULL causes problems when clock banks depend
on clocks from another clock bank. In such case, the appropriate clock
needs to be resolved from OF phandle arguments, which is not possible if
the associated device is not provided. Make necessary changes to make
the correct device pointer available.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

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

Merge patch series "board: ti: am62x: Add EEPROM support and refactor board detection"

Guillaume La Roque (TI.com) <glaroque@baylibre.com> says:

This series adds EEPROM board detection support for AM62x and refactors
the board detection code across AM6x family boards to eliminate code
duplication.

The series introduces two new generic functions for AM6x boards:
- do_board_detect_am6(): Reads the on-board EEPROM with fallback logic
  to alternate I2C addresses
- setup_serial_am6(): Sets up the serial number environment variable
  from EEPROM data

Link: https://lore.kernel.org/r/20251103-am62xeeprom-v3-0-e390779c0fc5@baylibre.com

Merge patch series "arm: airoha: add support for en7523 based boards"

Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> says:

This patch series adds basic support for the boards based on Airoha
EN7523/EN7529/EN7562 SoCs. Due to ATF restrictions these boards are
able to run 32-bit OS only.

This patch series adds support for the following hardware:
 * console UART
 * ethernet controller/switch
 * spinand flash (in non-dma mode)

The following issues may be expected:
 * Extra slow UBI attaching in U-Boot (up to 20 sec with fastmap enabled).
   This is caused by the lack of DMA support in the U-Boot airoha-snfi driver.
 * Linux airoha-snfi driver in some cases might damage you flash data
   (see: https://lore.kernel.org/lkml/20251012121707.2296160-15-mikhail.kshevetskiy@iopsys.eu/)
 * Latest linux kernel is recommended to properly support flashes
   with more than one plane per lun
   (see: https://lore.kernel.org/lkml/20251012121707.2296160-7-mikhail.kshevetskiy@iopsys.eu/)
 * It's NOT recommended to use flashes working in continuous mode because
   U-Boot airoha-snfi driver does not support such flashes properly.

The patches was tested on the board:
 - SoC: Airoha EN7562
 - RAM: 512 MB
 - SPI NAND: 4 Gbit, made by Toshiba
 - Linux boot: was NOT tested

The U-Boot was chain-loaded from the running U-Boot. Airoha ATF-2.3 does
not allow easily chain-loading of U-Boot from U-Boot, so a special FIT
image (mimic linux kernel) was created

1) Create u-boot.its file with the following contents:

=== cut here ===
/dts-v1/;

/ {
description = "ARM OpenWrt FIT (Flattened Image Tree)";
#address-cells = <1>;

images {
u-boot-ram {
description = "OpenWrt U-Boot RAM image";
data = /incbin/("u-boot.bin.lzma");
type = "kernel";
arch = "arm";
os = "linux";
compression = "lzma";
load = <0x81e00000>;
entry = <0x81e00000>;
hash@1 {
algo = "crc32";
};
hash@2 {
algo = "sha1";
};
};

fdt-1 {
description = "OpenWrt device tree blob";

data = /incbin/("dts/upstream/src/arm/airoha/en7523-evb.dtb");
type = "flat_dt";

arch = "arm";
compression = "none";
hash@1 {
algo = "crc32";
};
hash@2 {
algo = "sha1";
};
};
};

configurations {
default = "config-ram-uboot";
config-ram-uboot {
description = "OpenWrt RAM U-Boot";
kernel = "u-boot-ram";
fdt = "fdt-1";
};
};
};
==================

2) Create u-boot.itb image to chain-load new u-boot from the old one

  lzma_alone e u-boot.bin u-boot.bin.lzma
  mkimage -f u-boot.its u-boot.itb

3) Load new u-boot from the old one

  U-Boot> tftpboot u-boot.itb && bootm

Link: https://lore.kernel.org/r/20251101004503.2379529-1-mikhail.kshevetskiy@iopsys.eu

ti: add support for AM6254atl SiP

TI's AM6254atl (or AM62x SiP for short) provides the existing AM62x SoC
with 512MiB of DDR integrated in a single package.

This patch adds the necessary U-Boot devie tree files, the required
defconfigs along with the documentation for the AM62x SiP EVM.

AM62x SiP differs from the already supported AM62x in following ways:

- OP-TEE for the AM62x resides from 0x9e800000 to 0xa0000000 which needs
  to be moved to 0x80080000 to free up space at end of DDR in AM62x SiP
  with 512MiB of memory. This is required to allow U-Boot to relocate to
  end of DDR before booting to the kernel.

- Changes to the env:
   1. splashimage address updated from 0x80200000 to 0x81a00000
   2. DFU addresses updated to match updated TEXT_BASE for SPL and U-Boot

Signed-off-by: Anshul Dalal <anshuld@ti.com>

arm64: dts: ti: Add support for AM6254atl SiP SK

This patch adds the dt for SK-AM62-SIP, which uses the existing
SK-AM62 board design with the new AM6254atl SiP. This changes the
location of memory node from the board dts to SoC level dtsi
(k3-am6254atl in our case).

Therefore this patch introduces the new 'k3-am625-sk-common.dtsi'
which represents the common hardware used for both 'am625-sk' and
'am6254atl-sk' boards with the inheritance hierarchy modified to:

k3-am625-sk.dts:

     k3-am62    k3-am62x-sk-common
        |            |
    k3-am625    k3-am625-sk-common
        |            |
        +-----+------+
              |
         k3-am625-sk

k3-am6254atl-sk.dts:

     k3-am62
        |
     k3-am625       k3-am62x-sk-common
        |                |
    k3-am6254atl    k3-am625-sk-common
        |                |
        +-------+--------+
                |
         k3-am6254atl-sk

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-5-anshuld@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: 2517e476b819df986fa1fe53927c099032bb72dc ]

(cherry picked from commit 58cd89aff167661dbae0c9911282ea3f1b8212cc)

arm64: dts: ti: Introduce base support for AM6254atl SiP

This patch adds the top level dtsi for AM6254atl SiP which integrates
the existing AM625 SoC with 512MiB of DDR in a single package.

More information about the package can be found here:
https://www.ti.com/lit/ds/symlink/am625sip.pdf

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-4-anshuld@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: 7c1d13a14e61ab33eec330cb6cabbddb37eecaa9 ]

(cherry picked from commit fa5a6a6e784bde78c6ec74eccd92d51fb9fd49e8)

arm64: dts: ti: k3-am62*: remove SoC dtsi from common dtsi

The k3-am62x-sk-common dtsi represents the common hardware used across
am62x EVMs which can be configured with various DDR sizes or none (with
DDR integrated in the package) based on the specific am62x SoC used.

Therefore this patch moves the memory node and the SoC specific k3-am625
dtsi out of sk-common and into the board dts files. No functional change
is intended from this patch. The device-tree inheritance is changed as
follows:

Before:

               k3-am62
                 ^
               k3-am625
                 ^
         k3-am62x-sk-common
                 ^
  am62x EVMs (k3-am625-sk, k3-am62-lp-sk)

After:

        k3-am62
          ^
        k3-am625    k3-am62x-sk-common
          ^              ^
  am62x EVMs (k3-am625-sk, k3-am62-lp-sk)

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20250814134531.2743874-2-anshuld@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: e0b9feca7329c495a76891d7766a781dea73787d ]

(cherry picked from commit 0b0edbbdf43bac6b28dd59c88647bd5e0b73ffea)

arm64: dts: ti: k3-am6*-boards: Add label to reserved-memory node

Add the label name 'reserved_memory' to the reserved-memory node in all
K3 AM6* board level dts files. This is done so that the node can be
referenced and extended to add more carveout entries as needed in future
refactoring patches.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20250908142826.1828676-13-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: 4f1aee4723a796a92f17b23699dc861b582ddfd2 ]

(cherry picked from commit 58c447fe500d78f5adc373b4945d8317e11df072)

configs: j784s4_evm_a72_defconfig: Enable configs for PCI Endpoint mode

TI's J784S4 SoC has two instances of PCIe Controller namely PCIe0 and
PCIe1 which are Cadence PCIe Controllers. Enable corresponding configs
to support PCIe Endpoint mode of operation on these instances.

Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>

pci_endpoint: pci_cdns_ti_ep: Enable PCIe Endpoint mode in J784S4 SoC

TI's J784S4 SoC has two instances of PCIe Controller namely PCIe0 and
PCIe1 which are Cadence PCIe Controllers. Add support to configure PCIe
instances in Endpoint mode of operation.

While at it disable all endpoint functions except function 0 during
probe to prevent the Root Complex from enumerating unconfigured
functions. This ensures only  properly configured endpoint functions
are visible to the host and avoids enumeration issues with
multi-function devices.

Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>

pci_endpoint: pci_cdns_ti_ep: Add SERDES mux configuration support

Probe the mux device early in the SERDES configuration flow to ensure
proper lane routing before PHY initialization. This is required for SoCs
where SERDES lanes can be muxed between different controllers
(PCIe, USB, etc), and different mux configurations are required between
different boot phases.

Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>

pci_endpoint: pci_cdns_ti_ep: Add delay after power domain reset

Add a 1ms delay after powering on the PCIe power domain to ensure
the controller stabilizes before subsequent operations. This prevents
potential timing issues during PCIe endpoint initialization.

The delay allows sufficient time for the power domain to fully come
up and the hardware to be in a stable state before configuration
begins.

Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>

board: am65x: Use generic AM6x board detection function

Replace the board-specific implementation of do_board_detect()
with a call to the generic do_board_detect_am6() function to
avoid code duplication across AM6x family boards.

The generic function provides the same functionality with
additional fallback logic to try alternate EEPROM addresses.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>

board: am64x: Use generic AM6x board detection functions

Replace the board-specific implementation of do_board_detect() and
setup_serial() with calls to the generic do_board_detect_am6() and
setup_serial_am6() functions.

The generic function provides the same functionality with
additional fallback logic to try alternate EEPROM addresses.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>

board: am62x: Add support for reading eeprom data

I2C EEPROM data contains the board name and its revision.
Add support for:
- Reading EEPROM data and store a copy at end of SRAM
- Updating env variable with relevant board info
- Printing board info during boot

Use the generic do_board_detect_am6() and setup_serial_am6()
functions to avoid code duplication across AM6x family boards.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>

board: ti: common: Add generic AM6x board detection functions

Add two new generic functions for AM6x family boards to simplify
board-specific implementations:

- do_board_detect_am6(): Generic board detection function that reads
  the on-board EEPROM. It first attempts to read at the configured
  address, and if that fails, tries the alternate address
  (CONFIG_EEPROM_CHIP_ADDRESS + 1). This provides a common
  implementation that can be used across different AM6x boards.

- setup_serial_am6(): Sets up the serial number environment variable
  from the EEPROM data. The serial number is converted from
  hexadecimal string format to a 16-character hexadecimal
  representation and stored in the "serial#" environment variable.

Both functions are protected by CONFIG_IS_ENABLED(TI_I2C_BOARD_DETECT)
and are designed to be used by AM62x, AM64x, AM65x, and other AM6x
family boards.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>

configs: airoha: en7523: enable spinand flashes support

This patch enable spinand flashes support for en7523 based boards

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

dts: airoha: en7523: add spinand flash support

This patch adds spinand flashes support to en7523 dts

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

configs: airoha: en7523: enable ethernet controller support

This patch activates ethernet controller support for en7523 based boards

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

dts: airoha: en7523: add ethernet controller support

This patch adds integrated ethernet controller support to en7523 dts

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

net: airoha: add support for airoha en7523 SoC family

Add support for Ethernet controller present in Airoha en7523/en7529/en7562.

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

net: airoha: unify code using SCU regmap helper

This allow us remove some an7581/an7583 specific code and use a common
code instead.

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

configs: airoha: en7523: enable reset controller support

This patch activates reset controller support for en7523 based boards

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

dts: airoha: en7523: add reset controller support

This patch adds reset controller support to en7523 dts

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

reset: airoha: add support for airoha en7523 SoC family

This adds reset controller support for airoha en7523/en7529/en7562 SoCs.

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

dt-bindings: reset: Add reset support for Airoha EN7523

Introduce reset capability for EN7523 device-tree binding

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

reset: airoha: unify code using SCU regmap helper

This patch unify probing code using airoha SCU regmap helper, thus a
common function can be used instead of an7581/an7583 specific ones.

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

reset: airoha: convert to regmap API

In preparation for support for Airoha AN7583, convert the driver to
regmap API. This is needed as Airoha AN7583 will use syscon to access
reset registers.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>

configs: airoha: en7523: enable clk support

This patch activates clk support for en7523 based boards

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

clk: airoha: add support for airoha en7523 SoC family

This adds clock driver for airoha en7523/en7529/en7562 SoCs. The code
is based on corresponding linux driver.

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

clk: airoha: use CHIP_SCU regmap helper

Use common helper to get CHIP_SCU registers.

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

arm: airoha: introduce EN7523 helpers to get SCU and CHIP_SCU regmaps

We need access SCU and CHIP_SCU regmaps in several places (clk-airoha,
reset-airoha, airoha_eth). Unfortunately these regmaps can't be easily
retrieved with a common code, because of different Airoha SoCs uses
a different dts structure.

To make life easy we can write a commonly named SoC specific helpers
for these tasks. This patch implements helpers for Airoha EN7523 SoC.

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

arm: airoha: introduce AN7581 helpers to get SCU and CHIP_SCU regmaps

We need access SCU and CHIP_SCU regmaps in several places (clk-airoha,
reset-airoha, airoha_eth). Unfortunately these regmaps can't be easily
retrieved with a common code, because of different Airoha SoCs uses
a different dts structure.

To make life easy we can write a commonly named SoC specific helpers
for these tasks. This patch implements helpers for Airoha AN7581 SoC.

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

arm/airoha: add support for airoha en7523 SoC family

Basic support for en7523/en7529/en7562 SoCs. Within a patch
only serial console will be supported.

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

airoha/an7581: add CONFIG_TARGET_AN7581=y to the defconfig

This is required because airoha/en7523 will be added with the following
patches. Without this line config for en7523 will be created instead of
an7581.

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

block: typo 'to be write'

%s/to be write/to write/

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

virtio: typo 'private date'

%s/private date/private data/

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

virtio: typo complaint

%s/v1.0 complaint/v1.0 compliant/

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

sound: typos 'to be write', 'writen'

%s/to be write/to be written/
%s/writen/written/

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

sound: all sound devices must depend on CONFIG_SOUND

Clean up the sound Kconfig options to let all sound devices depend on
CONFIG_SOUND.

Before this patch it was possible to select CONFIG_SOUND_MAX98357A even
with CONFIG_SOUND=n.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

toradex: verdin-am62: sync rm-cfg with SDK 11.01.05.03 baseline

Update the resource management configuration (rm-cfg.yaml) to align
with the default configuration provided in TI's AM62xx Processor SDK
Linux version 11.01.05.03, generated using the K3 Resource Partitioning
Tool.

This matches the configuration from board/ti/am62x/rm-cfg.yaml and the
notable change is the sharing of MCU GPIO interrupts between DM R5 and
A53 cores, and reservation of an additional virtual interrupt and event
for TIFS usage.

Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>

ext4: include missing blk.h

If missing, lbaint_t typedef will not be found in some cases.

[The proper fix for the commit above at the time would have been to
 include ide.h as only since commit 1a73661bc7a7 ("dm: Add a new header
 for block devices") is the typedef in blk.h]

Fixes: 04735e9c5578 ("Fix ext2/ext4 filesystem accesses beyond 2TiB")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

test/py: multiplexed_log.py: Clean up and correct RunAndLog()

The general python documentation for the subprocess class recommends
that run() be used in all cases that it can handle. What we do in
RunAndLog is simple enough that run() is easy to switch to. In fact,
looking at this exposed a problem we have today, which is that we had
combined stdout and stderr but then looked at both stdout and stderr as
if they were separate. Stop combining them.

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

Merge patch series "pwm: put symbols into a menu + use if DM_PWM block instead of depends on"

Quentin Schulz <foss+uboot@0leil.net> says:

This improves readability in menuconfig by putting PWM symbols under a
Kconfig menu.

It also groups PWM symbols that depend on DM_PWM together under an if
DM_PWM block so that we don't need to always list the dependency in the
depends on of the symbol.

No intended change in behavior except how it shows in menuconfig.

Link: https://lore.kernel.org/r/20251030-pwm-kconfig-v2-0-d151a42784ce@cherry.de

pwm: fix typo in PWM_MESON help text

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

pwm: put all PWM DM drivers under an if condition on DM_PWM

This simplifies the "depends on" since we don't need DM_PWM listed
explicitly there as it already is made explicit via the surrounding
"if". No intended change in behavior.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

pwm: make sandbox depend on DM_PWM

Since it is registered as a U_CLASS_DRIVER, Sandbox PWM driver is a
Driver Model Driver and thus to be usable depends on DM_PWM to be
selected.

Let's make sure of that via the appropriate Kconfig option.

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

pwm: move all PWM related topics inside a Kconfig menu

So it's visually better split from the other subsystems when using
menuconfig.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

mmc: renesas-sdhi: Add R-Car Gen5 support

Add support for R-Car Gen5 SoCs into the driver.
The default quirk is identical to previous generation.

Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Tweak commit message

mailbox: Allow operation without .recv callback

Some shared memory mailboxes may have empty receive operation,
because the data are polled by upper layers directly from the
shared memory region, and there is no completion interrupt or
bit of any sort. Allow empty .recv callback, and if the .recv
callback is empty, exit from mbox_recv() right away, because
any polling for completion here would be meaningless.

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

clk: renesas: Isolate R-Car Gen3 driver to Gen3, Gen4 and RZ/G2L

Isolate Renesas R-Car Gen3 clock driver to R-Car Gen3 and Gen4 and RZ/G2L.
The Renesas R-Car Gen5 uses SCMI clock protocol driver instead. This is
a preparatory change for R-Car Gen5. No functional change.

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

configs: Resync with savedefconfig

Resync all defconfig files using qconfig.py

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

Merge tag 'u-boot-dfu-20251107' of https://source.denx.de/u-boot/custodians/u-boot-dfu

u-boot-dfu-20251107:

CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/28223

Android:
* Add bootargs environment to kernel commandline

DFU:
* Support DFU over PCIe in SPL

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

Pull request efi-2026-01-rc2

CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28208

Documentation:

* bootstd: Describe environment variable extension_overlay_addr
  environment and remove extension support from TODO list

EFI:

* Correct the detection of the video mode in the EFI payload app:
  - Use struct efi_gop_mode_info in the definition of struct
    efi_entry_gopmode.
  - In function get_mode_from_entry() use the correct type for the video
    mode structure.
* Use a valid error code as return value in efi_store_memory_map().
* Avoid a memory leak for the variable name in efi_bl_create_block_device().
* Correct the code indentation in efi_uc_stop().
* Correct the description of struct efi_priv.
* Fix typos in code comments.

Other:

* qfw: Add more fields and a heading to qfw list
* Fix the support for ACPI pass-through on ARM and RISC-V:
  Avoid zeroing out the XSDT address
* test: provide unit test for 'acpi list' command

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmkNj/kACgkQxIHbvCwF
# GsS8NQ/6Aj+Z54HJTIEfoXssvElLr5ATactrCxszq42i/yy6dLqa2Ym1afG6w1XS
# 1ZbCeU/bCXFke5Tsz+x89gEfckUm83oTwngwcID0WR1qn8mWjwR7tM5MuORq8NxU
# 7NwLuFs9O/QZihagKdz6hv1/Y+cBwiAYLY16EYVSuUlbLaKQo3QvxwWkqG3jdKWV
# Rm58/PolU+2h04MBwP0SxSduX4OyRF/tMOGjf5RGLyqCyj8kIgdu7PvUAPMM+Gps
# KemL59V0Bdv8hlF4JknmPz+idtZg2nHIDdNrBZvoxwzwGQeRZ1YXAMruRxZXqDYL
# tiuDp6HMv/GfIIGkz14tJtJMdboaAybAnluPWGalx8JQJqJzEPww0R+9s4KKQeWL
# mHgRyl6PxVV9p19f79Qq6q6ETwrFDX0YH3pdrGUk3DBa3lDt0UsEAnuW4FvaJ8tx
# 3PMrjKAxpxocT0hglsMVnptnfvDEigMsjwH/TWrau83mY+juxFQLjm+U4vye+qCa
# 4zXjjLas18+eRcrv2KxU7teakyi1Jp+WbqHq37L26YcQMaLq/RkBc0bTrsreKKLu
# jprYFpvc7EJpH2Fd1XWaZ2EnxXcVSJSvrY/iwRQqb6wbwQ6XGtMvSh3IFY8IzAoh
# N2Pj78oaYqyL1q/TftuZWhEHo3a0M/HfM4D+oMSHzJtWCb0wZHE=
# =OGcS
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 07 Nov 2025 12:21:45 AM CST
# gpg:                using RSA key 6DC4F9C71F29A6FA06B76D33C481DBBC2C051AC4
# gpg: Good signature from "Heinrich Schuchardt <xypron.glpk@gmx.de>" [unknown]
# gpg:                 aka "[jpeg image of size 1389]" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC 2C05 1AC4

Merge tag 'mmc-master-2025-11-07' of https://source.denx.de/u-boot/custodians/u-boot-mmc

CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/28218

- Disabling FMP on Exynos850 to make eMMC functional when U-Boot is
  executed during USB boot
- Drop extra included errno.h

spl: mmc: avoid including errno.h twice

Each include should only be included once.

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

mmc: exynos_dw_mmc: Disable FMP for Exynos850 chip

Add DWMCI_QUIRK_DISABLE_FMP flag to Exynos850 driver data to make the
driver disable FMP in case of Exynos850 chip. That makes eMMC on
Exynos850 functional when U-Boot is executed during USB boot.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

mmc: exynos_dw_mmc: Add exynos850 compatible

Up until now "samsung,exynos7-dw-mshc-smu" compatible was used for
Exynos850 SoC, as it's present in its device tree. But Exynos850 device
tree also supports "samsung,exynos850-dw-mshc-smu" compatible string.
Add it in compatible ID list in the driver so that it can be matched
against this string for Exynos850 device tree.

No functional change, as the driver data is just a copy of
"samsung,exynos7-dw-mshc-smu" data for now.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

mmc: exynos_dw_mmc: Add quirk for disabling FMP

Add DWMCI_QUIRK_DISABLE_FMP which disables Flash Memory Protector (FMP)
during driver's init. It's usually done by early bootloaders, but in
some cases (like USB boot) the FMP may be left unconfigured. The issue
was observed on Exynos850 SoC (the E850-96 board). Enabling this quirk
makes eMMC functional even in such cases.

No functional change, as this feature is only added here but not enabled
for any chips yet.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

mmc: exynos_dw_mmc: Improve coding style

Exynos DW MMC glue layer driver have seen a lot of changes recently.
Stabilize the coding style.

No functional change.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

mmc: dw_mmc: Do not export dwmci_send_cmd() and dwmci_set_ios()

Do not over-expose the private dw_mmc API. The glue layer drivers at
this point shouldn't be aware and shouldn't use the generic
dwmci_send_cmd() and dwmci_set_ios() functions. Making those functions
public causes a "leaky abstraction" issue. It clutters the public
interface of generic dw_mmc driver and possibly leads to improper usage
of those functions, so it's a bad design.

If struct dm_dwmci_ops has to be extended, do so by copying it first
(like it's done for example in snps_dw_mmc driver). That also makes sure
the future changes to struct dm_dwmci_ops in dw_mmc driver will be
automatically reflected in all extended copies, and avoid code
duplication.

This effectively reverts commit ef3b16bb8e73 ("mmc: dw_mmc: export
dwmci_send_cmd() and dwmci_set_ios()").

No functional change.

Fixes: ef3b16bb8e73 ("mmc: dw_mmc: export dwmci_send_cmd() and dwmci_set_ios()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

mmc: exynos_dw_mmc: Extend dm_dwmci_ops without code duplication

Instead of extending dm_dwmci_ops by copy-pasting the structure code
first, copy the actual structure data with memcpy() and then set the
.execute_tuning field. Now if struct dm_dwmci_ops gets modified in
future, these changes will be automatically reflected in struct
exynos_dwmmc_ops, which prevents possible issues in future. It also
avoids code duplication.

No functional change, but it can prevent possible isssues in future.

Fixes: eda4bd29929c ("mmc: exynos_dw_mmc: add support for MMC HS200 and HS400 modes")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

spl: remove redundant prints in boot_from_devices

The null check for loader in boot_from_devices was moved earlier in the
code path by the commit ae409a84e7bff ("spl: NULL check variable before
dereference"), therefore the subsequent null checks for loader are not
necessary.

This patch removes those checks and refactors the prints to be more
useful in case of errors.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

Merge patch series "Allow falcon boot from R5 SPL on TI's AM62 devices"

Anshul Dalal <anshuld@ti.com> says:

This patch set adds support for falcon boot on AM62a, 62p and 62x by bypassing
A53 SPL and U-boot.

Existing Boot flow:
R5 SPL -> ATF -> A53 SPL -> U-Boot -> Linux Kernel

Updated flow:
R5 SPL -> ATF -> Linux Kernel

U-Boot's falcon mode expects the jump from SPL to kernel to happen on the same
core which is not directly applicable for our heterogeneous platforms since
ATF, OPTEE and other non SPL binaries from tispl.bin should be loaded before the
kernel by the R5 SPL.

So we have to use a different flow to bypass A53 SPL and U-Boot, we first load
the newly added tispl_falcon.bin instead of tispl.bin which lacks u-boot-spl.bin
(A53's SPL) and the corresponding fdt. This sets up dm, tifs, optee and
atf. Once loaded, we load the kernel and the dtb (with fixups) at ATF's
PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE.

NOTE:

Since we're now using the SPL to load the kernel and kernel expects a 2MiB
aligned load address, the existing PRELOADED_BL33_BASE has to be changed for ATF
to 0x82000000 with K3_HW_CONFIG_BASE set to 0x88000000 for the DTB.

Link: https://lore.kernel.org/r/20251031073800.344500-1-anshuld@ti.com

doc: ti: document R5 falcon mode for AM62 platforms

This patch adds user documentation for R5 falcon mode for AM62
platforms. The main section is added to am62x_sk.rst and other documents
just include the relevant sections. Steps to build falcon support, usage
and the modified R5 memory map have been documented.

Two svg images have also been added for reference, one for the modified
tifalcon.bin and other for the fitImage format specific to R5 falcon
mode.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

mach-k3: r5: common: add bootargs to kernel's dtb

The bootargs are passed to the kernel in the chosen node, this patch
adds support for populating bootargs in the dtb if missing.

The values for kernel boot params is taken from the env, with 'boot' and
'bootpart' specifying the rootfs for the kernel similar to the
non-falcon boot flow.

Signed-off-by: Anshul Dalal <anshuld@ti.com>