sunxi: add support for Liontron H-A133L board

The Liontron H-A133L is an industrial development board based on the
Allwinner A133 SoC. It uses LPDDR4 DRAM, eMMC, and an AXP707 PMIC.

Add a defconfig with the required DRAM settings.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

arm64: dts: allwinner: a100: add Liontron H-A133L board support

The H-A133L board is an industrial development board made by Liontron.
It contains a number of dedicated JST connectors, to connect external
peripherals. It features:

- Allwinner A133 SoC (4 * Arm Cortex-A53 cores at up to 1.6 GHz)
- 1 GiB, 2 GiB or 4 GiB of LPDDR4 DRAM
- between 16 and 128 GiB eMMC flash
- AXP707 PMIC (compatible to AXP803)
- 100 Mbit/s RJ45 Ethernet socket, using an JLSemi JL1101 PHY
- XR829 WIFI+Bluetooth chip
- 2 * USB 2.0 USB-A ports, plus three sets of USB pins on connectors
  (connected via a USB hub connected to USB1 on the SoC)
- microSD card slot
- 3.5mm A/V port
- 12V power supply
- connectors for an LVDS or MIPI-DSI panel

Add the devicetree describing the board's peripherals and their
connections.

Despite being a devboard, the manufacturer does not publish a schematic
(I asked), so the PMIC rail assignments were bases on BSP dumps,
educated guesses and some experimentation. Dropping the always-on
property from any of the rails carrying it will make the board hang as
soon as the kernel turns off unused regulators.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250505164729.18175-4-andre.przywara@arm.com
[wens@csie.org: fix property in &usbphy; fix comment typo in &usb_otg]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
[ upstream commit: a3cd12acb7b74d9b243cd893209972fc657d0bd3 ]

(cherry picked from commit 4062957c0797752dcf8b71f99c7aa47301c70aac)

arm64: dts: allwinner: a100: set maximum MMC frequency

The manual for the Allwinner A133 SoC mentions that the maximum
supported MMC frequency is 150 MHz, for all of the MMC devices.

Describe that in the DT entry, to help drivers setting the right
interface frequency.

Fixes: fcfbb8d9ec58 ("arm64: allwinner: a100: Add MMC related nodes")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250505202416.23753-1-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
[ upstream commit: d8f10550448b03d3c5c6d9392119205c65ebfc89 ]

(cherry picked from commit 85e37e6a8a002eb231df8209478d7ff2b134a451)

sunxi: add support for the Allwinner A100/A133 SoC

The Allwinner A100 SoC has been around for a while, mostly on cheap
tablets, but didn't generate much interest in the community so far.
There were some efforts by two Allwinner employees in 2020, which led
to basic upstream Linux support for that SoC, although this momentum
dried up pretty quickly, leaving a lot of peripherals unsupported.

The A100 was silently replaced with the seemingly identical Allwinner
A133, which is reportedly a better bin of the A100. So far we assume
that both are compatible from a software perspective. There are some
more devices with the A133 out there now, so people are working on
filling the gaps, and adding U-Boot (and TF-A) support.

Based on the just added pinctrl, clock and DRAM support, this adds the
missing bits, mostly addresses and values for the SPL.

The A133 seems to be an predecessor to the H6, so we can share a lot of
code with that (and the H616 code), and just need to adjust some details.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: A133: add DRAM init code

This adds preliminary support for the DRAM controller in the Allwinner
A100/A133 SoCs.
This is work in progress, and has rough edges, but works on at least
three different boards. It contains support for DDR4 and LPDDR4.

Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest>
[Andre: formatting fixes, adapt to mainline, drop unused parameters,
remove struct struct sunxi_mctl_com_reg, hardcode MR registers,
switch to mctl_check_pattern(), remove simple DRAM check]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Merge tag 'v2025.07-rc5' into next

Prepare v2025.07-rc5

With this merge, tighten up the LTO_FLAGS removal we added to not
trigger on ARMv7 (which is Thumb-2 and should be fine).

Prepare v2025.07-rc5

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

arm: kirkwood: fix freeze on boot

Commit 6fe50e395080 ("arm: asm/system.h: mrc and mcr need .arm if
__thumb2__ is not set") is not a proper fix for the LTO link error
mentioned in its description. It causes 32-bit arm instructions to be
mixed with thumb instructions, which the Kirkwood SoCs do not support.
For example, board_init_r() is mostly generated in Thumb-1 mode as
expected since the build flags contain -mthumb -mthumb-interwork. The
MCR instruction corresponding to writefr_extra_feature_reg() is also
correcly emitted as a 32-bit ARM instruction (it cannot be encoded in
Thumb-1 anyways). The problem is, the compiler inlines the MCR without
generating the BX or BLX instruction which are needed to transition
between the ARM and the Thumb-1 states. From the objdump output:

006186a0 <board_init_r>:
board_init_r():
/home/jerome/work/u-boot/common/board_r.c:799
  6186a0:       b5f0            push    {r4, r5, r6, r7, lr}
  6186a2:       b0ab            sub     sp, #172        @ 0xac
get_gd():
/home/jerome/work/u-boot/./arch/arm/include/asm/global_data.h:127
  6186a4:       464a            mov     r2, r9
...
/home/jerome/work/u-boot/arch/arm/mach-kirkwood/cpu.c:242
  619aae:       9b15            ldr     r3, [sp, #84]   @ 0x54
writefr_extra_feature_reg():
/home/jerome/work/u-boot/./arch/arm/include/asm/arch/cpu.h:100
  619ab0:       ee2f3f11        mcr     15, 1, r3, cr15, cr1, {0}
                ^^^^^^^^
                32-bit ARM instruction

Further investigation is needed to understand how to fix the issue so
that the code size is minimal for all boards. In the mean time, this
fix disables LTO for the two problematic files (common/board_f.c and
common/board_r.c). This makes the Kirkwood-based boards bootable again.
The binary size is increased by 1048 bytes which is perfectly
acceptable.

Fixes: 6fe50e395080 ("arm: asm/system.h: mrc and mcr need .arm if __thumb2__ is not set")
Reported-by: Tony Dinh <mibodhi@gmail.com>
Tested-by: Tony Dinh <mibodhi@gmail.com>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

Merge patch series "rsa and fit_check_sign build fix for v2025.07-rc"

Shiji Yang <yangshiji66@outlook.com> says:

This patchset fixes some compilation errors that I caught in version
v2025.07-rc4 and branch next. If they are acceptable, please apply
them to the master branch. If anyone has a better way to fix these
issues, it's fine to ignore this patchset.

Link: https://lore.kernel.org/r/OSBPR01MB16702ED24460D23A7ED63440BC7DA@OSBPR01MB1670.jpnprd01.prod.outlook.com

tools/fit_check_sign: make the module dependent on CONFIG_FIT_SIGNATURE

The function definition of fit_check_sign() is guarded by
"#ifdef CONFIG_FIT_SIGNATURE" in "tools/image-host.c". If we try
to build it without CONFIG_FIT_SIGNATURE, we will get an error:

/usr/bin/ld: tools/fit_check_sign.o: in function `main':
fit_check_sign.c:(.text.startup+0x165): undefined reference to `fit_check_sign'
collect2: error: ld returned 1 exit status

Fixes: 9c79c8fe70da ("tools/fit_check_sign: make key optional")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>

lib: rsa: fix compilation error without openssl

The symbol TOOLS_IMAGE_PRE_LOAD doesn't depend on TOOLS_LIBCRYPTO.
If we choose to build tools without openssl, rsa_verify_openssl()
will attempt to call the unavailable openssl library functions.

Fixes: 942c8c8e6697 ("rsa: Add rsa_verify_openssl() to use openssl for host builds")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>

net: designware: fix bus address dereference

Device bus address might not be valid for direct access when the bus
address and CPU address are not the same. Use dev_bus_to_phys() to
translate bus address back to CPU address.

Fixes: 3d98b8c504e15 ("net: designware: Invalidate RX buffer cache before freeing the DMA descriptor")
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>

board: samsung: e850-96: Load LDFW in board_late_init()

As stated in 5e847f7729b3 ("efi_loader: call efi_init_early() earlier"):

    efi_init_early() creates an event hook for block device probing.
    It has to be called before any block device is probed.

Indeed, efi_bl_init() registers EVT_DM_POST_PROBE event, which calls
efi_disk_probe() whenever any block device is probed. And to make that
hook work, the initialization of all block devices was put after
efi_init_early() in initcall_run_r():

    INITCALL(efi_init_early);
    INITCALL(initr_nand);
    INITCALL(initr_onenand);
    INITCALL(initr_mmc);

Because LDFW firmware is being read from MMC, attempt to load LDFW in
board_init() causes MMC driver to be probed. And because board_init() is
executed before efi_init_early(), the hook mentioned above won't work
for MMC devices anymore. So EFI disk objects won't be created, which in
turn makes the EFI subsystem non-functional, showing next symptoms:
  - 'efidebug dh' output is empty
  - attempt to add boot devices in 'eficonfig' shows this message:
    "No block device found!"
  - 'bootefi selftest $fdtcontroladdr' shows this warning:
    "Cannot persist EFI variables without system partition"
  - booting GRUB with 'bootefi' runs minimal GRUB shell which doesn't
    see any block devices as well, probably because EFI vars weren't
    passed

Load LDFW in board_late_init() instead, as it's called after
efi_init_early(). This fixes the described problem and makes it possible
to run EFI apps like GRUB correctly, add entries in 'eficonfig', and
makes 'efivar --list' command in Linux rootfs actually show EFI
variables.

The only user of LDFW at the moment is the TRNG driver, and it's probed
later, only when it's going to be used (e.g. on "rng" command). So it's
fine to load LDFW in board_late_init(). Now the corresponding call order
will look like this:

    efi_init_early()
    initr_mmc()
      mmc_probe()
        EVT_DM_POST_PROBE -> efi_disk_probe()
    board_late_init()
      load_ldfw() -> fs_read(), blk_dread()
    exynos_trng_probe()

Fixes: ccfd8de541a8 ("board: samsung: e850-96: Report LDFW loading failures")
Fixes: f04e58cc9788 ("board: samsung: e850-96: Load LDFW firmware on board init")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

Merge tag 'doc-2025-07-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request doc-2025-07-rc5

* in wget documentation remove erroneous note about CAs

doc: cmd: wget: remove erroneous note

The note about U-Boot not being able to verify server certificates is
false now that WGET_CACERT and WGET_BUILTIN_CACERT have been added.
Remove it.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

arm: kirkwood: Maintainer for RaidSonic ICY BOX ib62x0 board

Add me as  maintainer for the RaidSonic ICY BOX ib62x0.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>

Merge patch series "Consistent Kconfig environment options CONFIG_ENV_ prefix"

Marek Vasut <marek.vasut+renesas@mailbox.org> says:

Rename the environment related variables and add ENV_ prefix, so that
all configuration options which are related to environment would have
an CONFIG_ENV_ prefix. No functional change.

Link: https://lore.kernel.org/r/20250609192701.20260-1-marek.vasut+renesas@mailbox.org

env: Drop DELAY_ENVIRONMENT

There are no users of DELAY_ENVIRONMENT and the same effect can
be achieved either using DT /config/load-environment property,
or by using ENV_IS_NOWHERE . Remove this configuration option
and matching functionality.

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

env: Rename DEFAULT_ENV_FILE to ENV_DEFAULT_ENV_TEXT_FILE

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Also rename USE_DEFAULT_ENV_FILE to USE_ENV_DEFAULT_ENV_TEXT_FILE .

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

env: Rename ENV_MMC_PARTITION to ENV_MMC_SW_PARTITION

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Use ENV_MMC_SW_PARTITION to clarify this is the SD/MMC software
partition table entry selector. Update the help text accordingly.

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

env: Rename SYS_MMC_ENV_PART to ENV_MMC_EMMC_HW_PARTITION

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Use ENV_MMC_EMMC_HW_PARTITION to clarify this is the eMMC hardware
partition selector, not a software partition table entry selector.
Retain the ENV_MMC_ prefix to make it easier to search for all the
SD/MMC related ENV options. Update the help text accordingly.

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

env: Rename SYS_MMC_ENV_DEV to ENV_MMC_DEVICE_INDEX

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Use ENV_MMC_DEVICE_INDEX to clarify this is the SD/MMC device
index, a number, as enumerated by U-Boot. Update the help text
accordingly.

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

env: Rename SYS_RELOC_GD_ENV_ADDR to ENV_RELOC_GD_ENV_ADDR

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

env: Rename SYS_REDUNDAND_ENVIRONMENT to ENV_REDUNDANT

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

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

env: Rename OVERWRITE_ETHADDR_ONCE to ENV_OVERWRITE_ETHADDR_ONCE

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Merge patch series "bootstd: Fix efi_mgr usage in bootmeths env var"

Sam Protsenko <semen.protsenko@linaro.org> says:

Defining the 'bootmeths' environment variable with efi_mgr causes NULL
pointer dereference when running 'bootflow scan' on the E850-96 board.
This patch series fixes that, and cleans up the surrounding code a
little while at it.

Link: https://lore.kernel.org/r/20250112034213.13153-1-semen.protsenko@linaro.org

bootstd: Fix incorrect struct name in bootmeth_setup_iter_order()

There is no such thing as struct bootmeth, it's probably a typo. This
issue doesn't affect the execution as it's a pointer, and pointer sizes
are the same for all data types. But it can be confusing, so make it
struct udevice, as it should be.

Fixes: a950d31abe98 ("bootstd: Add the bootmeth uclass and helpers")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

bootstd: Probe bootmeth devices for bootmeths env var

Specifying efi_mgr in 'bootmeths' environment variable leads to NULL
pointer dereference when 'bootflow scan' is executed, with call trace
like this:

    priv->fake_dev // NULL pointer dereference
    .read_bootflow = efi_mgr_read_bootflow()
    bootmeth_get_bootflow()
    bootflow_check()
    bootflow_scan_first()
    do_bootflow_scan()
    'bootflow scan -l'

That happens because in case when 'bootmeths' env var is defined the
bootmeth_efi_mgr driver is not probed, and the memory for its private
data isn't allocated by .priv_auto. In case when 'bootmeths' env var is
not defined, the std->bootmeth_count is 0, and the execution flow in
bootmeth_setup_iter_order() takes "no ordering" path, which in turn runs
uclass_get_device_by_seq() -> ... -> device_probe(), so issue isn't
present there. But when 'bootmeths' is defined and contains efi_mgr, the
std->bootmeth_count > 0, so bootmeth_setup_iter_order() follows the "we
have an ordering" path, where devices are not probed. In other words:

    'bootmeths' defined           'bootmeths' not defined
    --------------------------------------------------------
    priv == NULL                    priv != NULL
         ^                                ^
         |                        device_alloc_priv()
     no probe                     device_of_to_plat()
         ^                        device_probe()
         |                        uclass_get_device_tail()
    dev = order[i]                uclass_get_device_by_seq()
         ^                                ^
         | have an ordering               | no ordering
         +----------------+---------------+
                          |
             bootmeth_setup_iter_order()
             bootflow_scan_first()
             do_bootflow_scan()

Add an explicit device_probe() call in "we have an ordering" case to fix
the issue.

Fixes: c627cfc14c08 ("bootstd: Allow scanning for global bootmeths separately")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

bootstd: Fix memleak on errors in bootmeth_setup_iter_order()

Free memory allocated for 'order' (array of bootmeths) on error paths in
bootmeth_setup_iter_order() function.

Fixes: c627cfc14c08 ("bootstd: Allow scanning for global bootmeths separately")
Fixes: 10d16faa436c ("bootstd: Detect empty bootmeth")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge tag 'u-boot-at91-2025.10-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next

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

This feature set includes the addition of new sam9x7 SoC and a new board
named sam9x7-curiosity. There is also new support for sam9x60 compatible
at91 watchdog.

dtc: Add Kconfig option to pad device tree blob

This will allow arch(s) that use device tree blobs to pad the end of the
device tree so they can be modified by board files at run time. This will
help prevent errors such as FDT_ERR_NOSPACE from occurring.

Signed-off-by: Eric Schikschneit <eric.schikschneit@novatechautomation.com>
[trini: Change default order so that X86 && EFI_APP works correctly]

Merge patch series "common/spl fixes"

This series from Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
fixes some regressions related to handling of FIT images with broken
contents that was introduced in this merge window.

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

common/spl: improve error handling in spl_fit

This fix a possible NULL pointer dereference.

There is also a risk of memory leaking within the same portion of code.
The leak will happen if loaded image is bad or damaged. In this case
u-boot-spl will try booting from the other available media. Unfortunately
resources allocated for previous boot media will NOT be freed.

We can't fix that issue as the memory allocation mechanism used here
is unknown. It can be different kinds of malloc() or something else.

To somewhat reduce memory consumption, one can try to reuse previously
allocated memory as it's done in board_spl_fit_buffer_addr() from
test/image/spl_load.c.

The corresponding comment was put to the code as well.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Anshul Dalal <anshuld@ti.com>

common/spl: handle properly images with bad checksum

load_simple_fit() returns -EPERM for the images with broken signatures.
Unfortunately this may conflict with image loaging selection on the base
of boot phase. See commit 873112db9ce68c38984ff25808dde726f8dd5573
("spl: Support selecting images based on phase in simple FIT").

Thus loading of

configurations {
uboot {
description = "u-boot";
firmware = "atf";
loadables = "atf", "tee", "uboot";
};
};

with damaged "tee" image may finish without errors. This may results in
board bricking.

This patch fixes commit 873112db9ce68c38984ff25808dde726f8dd5573
("spl: Support selecting images based on phase in simple FIT")
by replacing EPERM with EBADSLT places where it should be done.

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

common/spl: fix potential out of buffer access in spl_fit_get_image_name function

The current code have two issues:
1) ineffective NULL pointer check

str = strchr(str, '\0') + 1
if (!str || ...

   The str here will never be NULL (because we add 1 to result of strchr())

2) strchr() may go out of the buffer for the special forms of name variable.
   It's better use memchr() function here.

   According to the code the property is a sequence of C-string like
   shown below:

     'h', 'e', 'l', 'l', 'o', '\0', 'w', 'o', 'r', 'l', 'd', '\0', '!', '\0'

   index is the string number we are interested, so

     index = 0   =>  "hello",
     index = 1   =>  "world",
     index = 2   =>  "!"

   The issue will arrise if last string for some reason have no terminating
   '\0' character. This can happen for damaged or specially crafted dtb.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm/airoha: reset_cpu() does not take any params

According to include/sysreset.h the reset_cpu() function does not take any args

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Tom Rini <trini@konsulko.com>

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

- Move early SPL stack on R-Car V4H boards

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

- Assorted cleanups and R-Car Gen4 watchdog driver

configs: sam9x75_curiosity: Add initial mmc default config

Add default configuration for sd-card to boot the linux kernel.

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>

board: sam9x75_curiosity: Add support for sam9x75 curiosity

Add board specific functions for sam9x75 curiosity

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>

ARM: dts: at91: sam9x75_curiosity: add tweaks for sam9x75 curiosity board

Since the SoC and board DT are already available in dts/upstream,
add the difference from upstream DTS to at91-sam9x75_curiosity-u-boot.dtsi

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>

ARM: at91: Add sam9x7 soc

Add new Microchip sam9x7 SoC based on an ARM926.

Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>

clk: at91: sam9x7: add pmc driver for sam9x7 SoC family

Add PMC driver support for sam9x7 SoC family

Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
[balamanikandan.gunasundar@microchip.com: Add peripheral clock id for pmecc]
Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>

clk: at91: clk-main: drop parent_name check when registering main_rc oscillator

The clk_register function logs an error if parent_name is missing from the
Device Tree.On the SAM9X7, the main_rc node is omitted to stay aligned with
the Linux Device Tree.Remove the parent_name check in at91_clk_main_rc()
to allow it to pass NULL when the parent is not specified.

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>

clk: at91: sam9x60-pll: add support for HW PLL freq dividers

Add support for hardware dividers for PLL IDs.In sam9x7 SoC,
PLL_ID_PLLA and PLL_ID_PLLA_DIV2 has /2 hardware dividers
each.

fcorepllack -----> HW Div = 2 -+--> fpllack
                               |
                               +--> HW Div = 2 ---> fplladiv2ck

Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>

clk: at91: sam9x60-pll: add support for core clock frequency inputs

Add support for different core clock frequency input ranges
for different PLL IDs in the PLL driver and align sam9x60, sama7g5 SOC
platforms.

Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>

dt-bindings: drop at91.h from clock includes

Remove clock/at91.h file as it is subset of
dts/upstream/include/dt-bindings/clock/at91.h.
The constants defined in this header are being used only in dts

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>

board: sama5d27_wlsom1_ek: Get RAM size and base from devicetree

Instead of using defines for the RAM size and base address, retrieve these
information from the devicetree.

This aligns with the sama5d27_som1_ek board in commit 73c1589f025d9
("board: sama5d27_som1_ek: Get dram size and base from device tree").

While at it, remove a spurious '/* SPL */' comment.

Signed-off-by: Fabio Estevam <festevam@denx.de>

ARM: dts: at91: sam9x60-curiosity: Enable watchdog node

Enable watchdog node on SAM9X60-Curiosity board.

A default timeout of 16s is added which is the maximum supported value,
also matching Linux driver's behavior.

Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
Reviewed-by: Stefan Roese <sr@denx.de>

ARM: dts: sam9x60: Add watchdog DT node

Add the watchdog timer node for the sam9x60 SoC's.

Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
Reviewed-by: Stefan Roese <sr@denx.de>

watchdog: at91sam9_wdt: Add SAM9X60 support

SAM9X60 has a slightly different watchdog implementation:
- Timer value moved into a new register WLR
- Some MR register fields have their position changed

This patch add SAM9X60 support, also adds a compatible
for SAMA5D4 which is the same as existing SAM9260.

Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Stefan Roese <sr@denx.de>

watchdog: at91sam9_wdt: Rename priv to wdt

"wdt" is a better name for watchdog rather than generic "priv".

Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: at91: wdt: Rename regval in priv data to mr

Use the name "mr" since we are referring to timer mode register.

Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: at91: wdt: Remove at91_wdt struct

at91_wdt struct is only used by spl, remove this reference and the struct
itself.

Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge patch series "Print version of the DM firmware"

Moteen Shah <m-shah@ti.com> says:

This patch series adds the functionality to print the DM firmware
version being used. Before requesting TISCI for the DM version we
first check if the DM split mode capability exists, if yes, we proceed
onto making the call to TISCI for retrieving the version information.

DM split mode capability indicates that the DM is a separate binary
altogether and has its own versioning information similar to TIFS.

Boot Logs: https://gist.github.com/Jamm02/37864f605445944a0c0caf426e0aba50

Link: https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-fw-caps
Link: https://lore.kernel.org/r/20250609081434.1000377-1-m-shah@ti.com

Merge patch series "Add IPC support on MCU R5F cluster in Split Mode"

Beleswar Padhi <b-padhi@ti.com> says:

This series adds remoteproc support on MCU R5F in Split mode.

During boot, ROM can bring up the boot R5F cores in either lockstep or
split mode based on X509 certificate flags. If booted in lockstep mode,
the MCU R5F cores will run first the R5 SPL, and then once A72 comes up,
will run the Device Manager (DM) firmware. But if booted in split mode, core
0 will run DM firmware and second core sits in WFI. Shut it down so that
other firmwares can later be loaded on them.

The shutdown of MCU R5 Core 1 is invoked at A72 SPL init, as by that
time Device Manager (DM) is up and running on R5 Core 0. The shutdown
of MCU R5 Core 1 is handled by Device Manager itself.

Test logs:
https://gist.github.com/3V3RYONE/ee8e3cb9aa5f4c5c00b059b9c14bfa98

Link: https://lore.kernel.org/r/20250609081429.1724643-1-b-padhi@ti.com

Merge patch series "bootstd: New bootmeth for RAUC A/B systems"

Martin Schwan <m.schwan@phytec.de> says:

This series implements a new bootmeth for RAUC A/B systems. RAUC (Robust
Auto Update Controller) is a lightweight update client, providing "Safe
and Secure OTA Updates for Embedded Linux". See the following links for
more information about RAUC:

  https://rauc.io/
  https://rauc.readthedocs.io/en/latest/

PHYTEC uses RAUC in its Yocto based distribution "Ampliphy" as the
default way of updating embedded devices based on PHYTEC hardware. So
far, the logic selecting the correct partitions and files to boot was
being implemented in the U-Boot environment. While this is a
straightforward way to do it, adding and supporting new platforms became
somewhat tedious and is platform-specific. The introduction of U-Boot's
"Standard Boot" provided a convincing alternative, promising a simpler
and more portable way of booting, even for RAUC systems. This led me to
implement a new bootmeth supporting RAUC A/B systems. Note, that this
new bootmeth is not proprietary to PHYTEC products and is designed to
work on other hardware with a RAUC A/B system, too.

The bootmeth currently only supports symmetric A/B partitioning layouts.
E.g. A/rescue is not (yet) supported. The partition indexes and default
slot tries can be specified via configuration options.

For now, the bootmeth_rauc uses a similar approach for loading the
Kernel and device tree as the bootmeth_script, in that it requires a FIT
containing a U-Boot script loading the desired distro. It could be
possible to support booting without a script and load the Kernel and DT
directly with this bootmeth, but I found the script method to be very
flexible for now, in letting the distro decide what to load.

The bootmeth_rauc was tested on a phyBOARD-Pollux i.MX8M Plus [1] with
BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 [2].

Supported boot devices are currently only MMC devices, but it should be
possible to add SPI flashes in the future.

To test this patch stack with PHYTEC's phyBOARD-Pollux i.MX8M Plus
board, you need to adjust the boot files to include the boot.scr.uimg
containing the distro's boot script and set "optargs" to "${raucargs}"
in it. Also disable any legacyboot in the U-Boot environment and simply
boot with Standard Boot:

  bootmeth order rauc
  bootflow scan -lb

[1]: https://www.phytec.eu/en/produkte/single-board-computer/phyboard-pollux/
[2]: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/

Link: https://lore.kernel.org/r/20250604-wip-bootmeth-rauc-v3-0-f9fad913c57e@phytec.de
[trini: Don't enable by default]

arm: mach-k3: Print version of DM firmware during boot process

Print DM firmware's version in the boot up process of K3 devices,
having DM capability(DM as a separate binary).

Signed-off-by: Moteen Shah <m-shah@ti.com>

arm: mach-k3: Add a function for printing DM version

Add a function to print version of the DM firmware in use.
The function queries the firmware capabilities first and if
DM split mode bit is set, sends a request to TISCI for
retrieving the version information.

The DM split mode bit indicates that DM is a separate binary
altogether and hence it will have its own versioning.

Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>

firmware: ti_sci.c: Add a function to request DM metadata using ti_sci* calls

Add a function to retrieve information of the DM firmware's ABI versions,
RM/PM HAL, firmware version, etc using TI_SCI protocol.

Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>

firmware: ti_sci.c: Add a function to query DM firmware's capability

Add a new function to query the capabilities of the DM firmware, using
TI SCI protocol to retrieve a 64-bit firmware capability, where each bit
represents a specific capability supported by the firmware.

Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>

ti_sci_* : Add capability to access DM firmware's metadata

Introduce response and request structs to receive and request
information regarding DM version, etc from TI SCI.

Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>

ti_sci_*: Add utility to access tisci firmware and SOC capability

Introduce response and request structs for receiving information
regarding FW/SOC capability from DM. The received capability can
further be used to call certain API's based on the feature supoorted
by the DM firmware.

Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>

board: ti: j7*: Add firmware for MCU R5 core1

Link the default firmware in the environment variable for MCU R5 core1
for all J7 platforms.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>

remoteproc: k3-r5: Acquire processor control before reset ops

Acquire processor control before doing core reset operations in probe
routine. Release the control afterwards, so that it can be acquired
during core loading operations.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>

arch: mach-k3: common: Add support to shutdown MCU R5 Core 1

During boot, ROM can bring up the MCU R5F cores in either lockstep or
split mode based on X509 certificate flags. If booted in split mode,
core 0 will run DM firmware and second core sits in WFI. Add support to
shut down core 1 so that other firmwares can later be loaded on them.

The shutdown of MCU R5 Core 1 is invoked at A72 SPL init, as by that
time Device Manager (DM) is up and running on R5 Core 0. The shutdown
request of Core 1 is handled by Device Manager itself.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>

arm: mach-k3: {am6/j7}*_hardware.h: Expose MCU R5 proc and device ids

Currently the MCU R5 processor ids and device ids are only defined for
R5 SPL Stage. Expose these ids always so that A72 SPL can utilize this
information to shutdown MCU R5 Core 1 when booted in Split mode.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>

doc: Add description for bootmeth rauc

Add documentation for the bootmeth "rauc", which boots an A/B system
with RAUC from MMC.

Signed-off-by: Martin Schwan <m.schwan@phytec.de>

bootstd: Add implementation for bootmeth rauc

Add a bootmeth driver which supports booting A/B system with RAUC as
their update client.

Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

renesas: Renesas R-Car Gen4 watchdog driver

Add support of Renesas R-Car Gen4 watchdog timer. Timeouts up to
8184.0s are supported (CKS1 register is not involved). The watchdog
uses the clock of type CLK_TYPE_GEN4_MDSEL.

The timeout is set in
dts/upstream/src/arm64/renesas/r8a779f0-spider-cpu.dtsi section &rwdt.

This driver is based on upstream linux commit:
e70140ba0d2b("Get rid of 'remove_new' relic from platform driver struct")

Signed-off-by: Shmuel Leib Melamud <smelamud@redhat.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

arm64: renesas: Move early SPL stack into System RAM SRAM on R-Car V4H boards

The CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xeb300000 does not make it into
board .config on either R-Car V4H White Hawk or Sparrow Hawk, remove
this configuration option. The early SPL stack is however pointing
into the RT-VRAM and may corrupt payload loaded into the RT-VRAM by
the BootROM. Set the early SPL stack at fixed location at the end of
System RAM instead, where it cannot interfere with the payload loaded
into RT-VRAM.

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

Merge patch series "list.h/treewide: get rid of no-op prefetch()"

Rasmus Villemoes <ravi@prevas.dk> says:

While looking through list.h, I saw that the regular list_* helpers
(and one of the hlist_* ones) still contain the prefetch() that was
removed in linux 14 years ago. It doesn't do anything, but makes the
macros harder to read, so get rid of it, and the fallback, no-op
definition that they relied on. That requires removing a few uses
outside list.h as well.

checkpatch warns about some whitespace issues in list.h, but as I've
copied whole kerneldoc+#define blocks directly from the linux kernel,
I think it's better to just accept that so that we don't introduce
needless diffs. The "macro argument reuse" arguments should also be
ignored, as e.g. the "member" arguments are obviously always just bare
identifiers, and the "pos" arguments must be assigned to multiple
times.

Link: https://lore.kernel.org/r/20250507121246.518691-1-ravi@prevas.dk

linux/list.h: drop fallback definition of prefetch()

None of the list helpers use prefetch() anymore, and no C code relies
on getting this definition from list.h. In any case, such an arch/cpu
specific thing does not belong in a header that just consists of cpp
helper macros.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>

mips: drop unused prefetch code and logic

AFAICT, CONFIG_CPU_HAS_PREFETCH has never existed as a proper Kconfig
symbol in U-Boot, nor has any board include file ever defined it.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>

treewide: drop no-op prefetch() calls

These all end up using the no-op prefetch() defined in linux/list.h,
because the only possible real implementation is in
arch/mips/include/asm/processor.h, which is behing
CONFIG_CPU_HAS_PREFETCH which is nowhere defined.

In order to be able to drop that fallback definition from list.h,
first remove all uses.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>

linux/list.h: drop use of prefetch()

The use of prefetch() in these list helpers was dropped back in 2011
in linux (e66eed651fd1 ("list: remove prefetching from regular list
iterators")). No arch in U-Boot defines any actual prefetch(), and as
the referenced commit says, it's usually not a win anyway.

Whole-sale sync of list.h is not really feasible, but we can
synchronize the macros containing a prefetch() with their linux
implementations as of v6.15-rc5, also importing the various helpers
needed, e.g. list_is_head() and list_next_entry().

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>

clk: renesas: Handle CLK_TYPE_GEN4_MDSEL in gen3_clk_get_rate64()

Add support of CLK_TYPE_GEN4_MDSEL clock type to gen3_clk_get_rate64()
function. In particular, this type of clock is used by Renesas R-Car
Gen4 watchdog. It operates similarly to CLK_TYPE_GEN3_MDSEL clock.

Signed-off-by: Shmuel Leib Melamud <smelamud@redhat.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Stefan Roese <sr@denx.de>

ARM: dts: renesas: Drop most of bootph-* tags

The bootph-* tags are now part of mainline Linux DTs as commits:
f1a1268572cc ("ARM: dts: renesas: rcar-gen2: Add boot phase tags")
399f14ff6625 ("arm64: dts: renesas: rcar: Add boot phase tags")
624b2a23d46a ("arm64: dts: renesas: rzg2: Add boot phase tags")
Drop local duplicates of the same tags, as well as duplicate
property assignments which are part of the core DTs themselves.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>

Merge patch series "Restore support of short name for type UUID parameter"

Patrick Delaunay <patrick.delaunay@foss.st.com> says:

Fix and add documentation/tests for selection by string for known
partition type GUID introduced by bcb41dcaefac ("uuid: add
selection by string for known partition type GUID"):

- split list_guid for short name (used also for partiton
  description with type parameter) and full name to display
  information

- as the function are uuid_str_to_bin() / uuid_guid_get_str()
  are no more under CONFIG_PARTITION_TYPE_GUID,  since commit
  31ce367cd100 ("lib/uuid.c: change prototype of uuid_guid_get_str()")
  and commit c1528f324c60 ("lib: compile uuid_guid_get_str if
  CONFIG_LIB_UUID=y") move the content of array under EFI_PARTITION
  and linker will remove it is not used it (in SPL)

- Add and fix documentation for gpt command

- Add test test_gpt_write_part_type to test "type=" parameters

This first patch solves an issue for the "system" shortcut for ESP,
removed by commit d54V3 version solve issue for "ESP" support when
CONFIG_CMD_EFIDEBUG and CONFIG_EFI is not activated
for example for test with qemu-arm-sbsa defconfige1004b8b1 ("lib/uuid.c: use unique name
for PARTITION_SYSTEM_GUID") but used in 2 location (at least):

1- board/samsung/e850-96/e850-96.env:10:

partitions=name=esp,start=512K,size=128M,bootable,type=system;
partitions+=name=rootfs,size=-,bootable,type=linux

2- arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:1151

case PART_ESP:
/* EFI System Partition */
459219 type_str = "system"
....
offset += snprintf(buf + offset,
   buflen - offset,
   ",type=%s", type_str);

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

Link: https://lore.kernel.org/r/20250616112749.17311-1-patrick.delaunay@foss.st.com

test/py: tests: gpt: add test_gpt_write_part_type

Add sandbox test on gpt command with partition type for known type.

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

doc: cmd: gpt: add information on type partition

Add information on type partition, copied from README.gpt.

I also correct issue for gpt_parts variable and add example of
"gpt read" usage.

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

lib/uuid.c: restore support of system partition type for ESP

Add support of optional shortname for parameter 'type' of gpt
command (limited by UUID_STR_LEN) and a separate 'description'
for UID format "%pUs" used in 'part list' output.

When 'description' is absent in list_guid[], the optional
shortname is used as fallback.

Many partition types for EFI have no shortcut yet, but only
description as they are only used to display information.

This patch also restores the "system" as short name for EFI
System Partition (ESP).

Fixes: d54e1004b8b1 ("lib/uuid.c: use unique name for PARTITION_SYSTEM_GUID")
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

Merge tag 'u-boot-imx-next-20250617' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/26728

- Add support for imx28 BTT boards.

ARM: imx: mxs: Add support for imx287 based BTT devices

The btt[c3] devices are based on imx287 SoC.

U-Boot SPL 2025.04-01081-g07e086681d26 (Apr 16 2025 - 12:24:36 +0200)
Trying to boot from MMC1

U-Boot 2025.04-01081-g07e086681d26 (Apr 16 2025 - 12:24:36 +0200)

CPU:   Freescale i.MX28 rev1.2 at 454 MHz
BOOT:  SSP SPI #3, master, 3V3 NOR
Model: BTT3
Board: LWE BTT SoM HW rev 0
DRAM:  256 MiB
Core:  86 devices, 15 uclasses, devicetree: separate
MMC:   MXS MMC: 0
Loading Environment from SPIFlash... SF: Detected is25lp128 with page
                    size 256 Bytes, erase size 64 KiB, total 16 MiB
OK
In:    serial@80074000
Out:   serial@80074000
Err:   serial@80074000
Net:   eth0: ethernet@800f0000
Hit any key to stop autoboot:  0

Signed-off-by: Lukasz Majewski <lukma@denx.de>

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

u-boot-dfu-next-20250616

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

Usb gadget:
- Atmel: Improve gadget disconnect stability by power cycling

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

u-boot-dfu-next-20250616

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

Usb gadget:
- Fix ti_musb driver in gadget mode (with DM_USB_GADGET)

DFU:
- mmc/scsi backends when using 10 or more partitions

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

u-boot-dfu-20250616

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

Usb gadget:
- Fix ti_musb driver in gadget mode (with DM_USB_GADGET)

DFU:
- mmc/scsi backends when using 10 or more partitions

usb: gadget: atmel: reliably generate disconnect by disabling controller

Contrary to the datasheet, setting both DETACH and PULLD_DIS bits to 1
does not always drive the DP and DM lines to high-impedance. This
prevents the host from reliably detecting a USB disconnect and subsequent
reconnect.

The symptom is that the first gadget command (e.g., dhcp) succeeds, while
subsequent commands (e.g., nfs) fail.

Disabling and re-enabling the controller entirely, instead of toggling the
PULLD_DIS bit, reliably generates a disconnect event.

The Linux driver works correctly because gadget_disconnect/gadget_connect
are always followed by gadget_udc_start/gadget_udc_stop. In U-Boot
pullup() is used solely.

This behavior has been observed on the SAM9X60-Curiosity and
AT91SAM9G25-EK boards and has been reported to Microchip.

Signed-off-by: Zixun LI <admin@hifiphile.com>
Link: https://lore.kernel.org/r/20250602-pullup-v1-1-edcde5a050dd@hifiphile.com
[mkorpershoek: reworded commit title + comment to usba_udc_pullup()]
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

usb: gadget: musb: Fix duplicate ops assignment in ti_musb_peripheral

Remove duplicate .ops assignment that was overriding the correct
ti_musb_gadget_ops with musb_usb_ops (host ops) in the ti_musb_peripheral
driver. This was causing U-Boot crashes when trying to call the
handle_interrupts operation since the wrong ops structure was being used.

Fixes: 7d98dbcc3dc ("usb: musb-new: Add support for DM_USB")
Fixes: 281eaf1ed83a ("usb: gadget: musb: Convert interrupt handling to usb_gadget_generic_ops")
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20250611171031.840277-1-kory.maincent@bootlin.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

dfu: fix dev_part_str for file operations

The third_arg for a dfu alt is read as an integer and is overloaded for
different supported backends. For ext4 and fat, this third_arg
represents the partition and forms the dev part string, which should
have its partition in hex. This commit fixes dfu ext4/fat usage for
devices with ten or more partitions.

Signed-off-by: Ivan Pang <ipman@amazon.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Link: https://lore.kernel.org/r/20250611050127.38011-1-ipman@amazon.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

Merge tag 'rpi-2025.07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-raspberrypi

Updates for RPi for 2025.07-rc5:

- configs: rpi: set NR_DRAM_BANKS to 8 to accommodate RAM on 16GB models

arm: dts: rockchip: Fix eMMC write on RK3528

Writing to eMMC on RK3528 is affected with the same or a similar issue
as on RK3588, where eMMC must init to HS200 at least once to fully work.

Trying to write u-boot-rockchip.bin to eMMC fails with:

  => mmc write $fileaddr 40 5000
  MMC write: dev # 0, block # 64, count 20480 ... mmc write failed
  0 blocks written: ERROR

For U-Boot to enable HS200 mode the mmc-hs200-1_8v prop must be defined
in the device tree. Linux does not seem to be affected and is able to
detect and use HS200 without this prop.

Enable use of HS200 and fix eMMC write on RK3528 by adding the missing
mmc-hs200-1_8v prop for affected boards:

  => mmc write $fileaddr 40 5000
  MMC write: dev # 0, block # 64, count 20480 ... 20480 blocks written: OK

Fixes: b112a44531cb ("board: rockchip: Add minimal generic RK3528 board")
Fixes: ccbddf645310 ("board: rockchip: Add Radxa E20C")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>

configs: rpi: set NR_DRAM_BANKS to 8 to accommodate RAM on 16GB models

Raspberry Pi 5 can now have up to 16 GiB of RAM where the memory spans 8
DRAM banks in total. Increase the config value to 8 to initialize the
whole RAM. Without this change, kernel only sees 8 GiB of RAM on the 16
GiB CM5 as reported in [1].

[1] https://github.com/home-assistant/operating-system/issues/3989

Signed-off-by: Jan Čermák <sairon@sairon.cz>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>

Merge patch series "linux/bitfield.h: sync <linux/bitfield.h> from Linux 6.15 + winbond"

Christian Marangi <ansuelsmth@gmail.com> says:

This small series sync linux/bitfield.h from Linux 6.15 and fix all
the compilation error due to a change in the header include.

The sync is needed to make it easier to support the winbond changes.

The changes are CI test with [1]

[1] https://github.com/u-boot/u-boot/pull/777

Link: https://lore.kernel.org/r/20250607211133.2005-1-ansuelsmth@gmail.com

mtd: spinand: winbond: add Winbond W25N04KV flash support

Add Winbond W25N04KV flash support that use a different value to detect
ECC bitflip.

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

linux/bitfield.h: sync <linux/bitfield.h> from Linux 6.15

Sync bitfield.h header with Linux 6.15 version. Mainly is to permit the
introduction of FIELD_PREP_CONST. The bug.h header changed to
build_bug.h doesn't cause any regression as we also ship split header
similar to how it's done with in Linux.

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

arm: apple: rtkit: add missing header linux/bug.h and linux/bitops.h

The GENMASK/GENMASK_ULL macro requires inclusion of linux/bitops.h
header. It does currently work as bitfield.h includes it indirectly
but this will change when bitfield.h will be synced with new Linux
version.

Also raw printf require linux/bug.h header (also currently included
indirectly by bitfield.h)

Explicitly include the headers to fix future compilation error.

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

iommu: qcom-smmu: add missing linux/bug.h header for WARN_ON

The WARN macro requires inclusion of linux/bug.h header. It does
currently work as bitfield.h includes it indirectly but this will
change when bitfield.h will be synced with new Linux version.

Explicitly include the header to fix future compilation error.

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

clk: imx: add missing linux/bug.h header for WARN

The WARN macro requires inclusion of linux/bug.h header. It does
currently work as bitfield.h includes it indirectly but this will
change when bitfield.h will be synced with new Linux version.

Explicitly include the header to fix future compilation error.

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

Merge patch series "Hex value prefix case cleanup"

E Shattow <e@freeshell.de> says:

Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot.

There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix
or placeholder in documentation and error messages.

External devicetree-rebasing dts/upstream and the generated code of
xilinx/zynq are ignored for the series.

Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de