Mark Kettenis [Sat, 9 May 2026 20:31:36 +0000 (22:31 +0200)]
smbios: Do not fall back on devicetree without valid mapping
The smbios_get_val_si() function may get called for a sysinfo
property for which there is no mapping to a devicetree property.
Avoid a NULL pointer dereference in this case by skipping the
read of the mapped property from the device tree.
Fixes: 83b28b55d74f ("smbios: add support for dynamic generation of Type 9 system slot tables") Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
Vincent Jardin [Sun, 10 May 2026 22:07:30 +0000 (00:07 +0200)]
board: nxp: common: support CONFIG_FSL_USE_PCA9547_MUX
Use select_i2c_ch_pca9547() only when CONFIG_FSL_USE_PCA9547_MUX
is set, but several call in board/nxp/lx2160a/lx2160a.c invoke
it unconditionally,
or using unrelated Kconfigs (CONFIG_EMC2305, CONFIG_VID).
Compilation with LX2160A target that omits the mux therefore fails with
error: implicit declaration of function 'select_i2c_ch_pca9547'
Add a static inline stub with -EOPNOTSUPP for the
!CONFIG_FSL_USE_PCA9547_MUX case so all cases compile cleanly.
Adapted from the convention used by include/scmi_nxp_protocols.h for
SCMI subprotocol stubs.
There is no functional change for NXP boards: all eight upstream
LX2160A defconfigs (lx2160ardb / lx2160aqds / lx2162aqds and their
secure / stmm / verified_boot variants) already set
CONFIG_FSL_USE_PCA9547_MUX=y, so the real declaration wins.
The purpose is to support new boards that do not use the PCA9547.
Signed-off-by: Vincent Jardin <vjardin@free.fr> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Vincent Jardin [Mon, 11 May 2026 07:37:34 +0000 (09:37 +0200)]
board: nxp: lx2160a: without QIXIS, MC-ENET, PCI, LTC3882
The shared LX2160A board file calls helpers that only exist when
their subsystem is enabled. Gate them on the matching CONFIG_*:
- pci_init() under CONFIG_PCI.
- fdt_fixup_mc_ddr() and fsl_rgmii_init() under CONFIG_FSL_MC_ENET.
- qixis_*() and the QIXIS branch of checkboard() under
CONFIG_FSL_QIXIS; cpu_name(buf) moves out so the non-QIXIS path
still prints "Board: <name>".
- EVENT_SPY_SIMPLE on init_func_vid moves inside the
CONFIG_VOL_MONITOR_LTC3882_READ guard (was outside, dangling
symbol when LTC3882 off).
#if / #ifdef, not IS_ENABLED(), because the helpers are themselves
conditionally compiled.
While here, lx2160a_common.h: fix BOOT_TARGET_DEVICES_MMC
1 arg vs 2 args and gate the MMC target on CONFIG_CMD_MMC,
not CONFIG_MMC.
No functional change for NXP boards: LX2160ARDB, LX2160AQDS, or
LX2162AQDS, but mainly build clean up in order to support
other NXP lx2160a boards without those HW dependencies.
Signed-off-by: Vincent Jardin <vjardin@free.fr> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Francois Berder [Sat, 9 May 2026 19:24:17 +0000 (21:24 +0200)]
board: ten64: Fix OOB read in ft_board_setup
base and size arrays can both contain up to total_memory_banks
elements.
This commit fixes the for loop condition to ensure that it does
not attempt to read past the end of both arrays.
Signed-off-by: Francois Berder <fberder@outlook.fr> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Francois Berder [Sat, 9 May 2026 19:20:18 +0000 (21:20 +0200)]
board: nxp: Fix OOB read in ft_board_setup
base and size arrays can both contain up to total_memory_banks
elements.
This commit fixes the for loop condition to ensure that it does
not attempt to read past the end of both arrays.
Signed-off-by: Francois Berder <fberder@outlook.fr> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Peng Fan [Fri, 15 May 2026 04:26:19 +0000 (12:26 +0800)]
p2041rdb: remove NAND defconfig
The RDB doesn't support NAND boot at all, remove the config for it.
Apparently, it was introduced by commit dd84058d24ff ("kconfig: add
board Kconfig and defconfig files") which ran some scripts. Maybe that
script was wrong or the source boards.cfg was wrong. In any case, there
is no NAND flash on the RDB.
Signed-off-by: Michael Walle <mwalle@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Michael Walle [Wed, 6 May 2026 12:34:14 +0000 (14:34 +0200)]
boards/nxp: remove board_eth_init()
board_eth_init() is dead code since commit e524f3a449f5 ("net: Remove
eth_legacy.c"). Remove it.
I'm not sure, all the shenanigans are covered by the new DM-version. The
MDIO mux and iomux controls probably are. The fman configuration
probably isn't. OTOH, nobody cared for years and the called
fm_info_set_phy_address() was also removed years ago.
This also removes fdt_fixup_board_enet() for the ls1043a and ls1046a
because it relies on the local variable "mdio_mux" being initialized by
the board_eth_init().
Signed-off-by: Michael Walle <mwalle@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Michael Walle [Wed, 6 May 2026 12:34:12 +0000 (14:34 +0200)]
spi: fsl_espi: fix read transactions
Since commit 7917c2e35604 ("spi: fsl_espi: fix din offset") MTD is
basically broken because any read transaction will get wrong data. While
the commit in question will fix simple transfers (where both
SPI_XFER_BEGIN and SPI_XFER_END is set), it will break the most common
case, where opcode and address is send first and then data comes as a
second transfer.
This basically reverts commit 7917c2e35604 ("spi: fsl_espi: fix din
offset") and make the fix particular for this simple case. Instead of
providing two buffers for reading and writing, just malloc one which is
used for both. This will work because the data is first written on the
SPI bus and then it will be read (and overwite the written data) into
the same buffer.
Suggested-by: Tomas Alvarez Vanoli <tomas.alvarez-vanoli@hitachienergy.com> Fixes: 7917c2e35604 ("spi: fsl_espi: fix din offset") Signed-off-by: Michael Walle <mwalle@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Michael Walle [Wed, 6 May 2026 12:34:11 +0000 (14:34 +0200)]
caam: don't write memory at 0 on PPC
For non-secure boot environments pamu_init() isn't called but the CAAM
will still call sec_config_pamu_table() -> config_pamu() which then uses
an uninitialized ppaact variable. In fact, that variable is initialized
with 0, so the config_pamu() will happily assume the structure is there
and will operate on that memory. Call pamu_init() in the non-secure boot
case, too.
Signed-off-by: Michael Walle <mwalle@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Michael Walle [Wed, 6 May 2026 12:34:10 +0000 (14:34 +0200)]
powerpc: fix call to cpu_init_r
Commit 6c171f7a184c ("common: board: make initcalls static") broke the
call to cpu_init_r. That is because PPC is already defined to 1, see:
powerpc-linux-gnu-gcc -dM -E - < /dev/null
This will conflict with the CONFIG_IS_ENABLED(PPC). Change it to
IS_ENABLED(CONFIG_PPC).
Fixes: 6c171f7a184c ("common: board: make initcalls static") Signed-off-by: Michael Walle <mwalle@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
The combined boot firmware firmware-aquila-am69-gp.bin depends on
tiboot3-am69-gp-aquila.bin, which in turn requires the GP variant
of the TI system firmware blob (ti-fs-firmware-j784s4-gp.bin).
Fix the combined boot firmware image build by adding the missing binman
nodes.
The virtio_blk_do_single_req function returns ulong, which normally is
the processed size, but in an error case can be the actual error. Use
the special IS_ERR_VALUE macro to test for error.
Addresses-Coverity-ID: CID 645833 (DEADCODE) & CID 645834 (NO_EFFECT) Signed-off-by: Christian Pötzsch <christian.poetzsch@kernkonzept.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Janne Grunau [Thu, 7 May 2026 08:41:40 +0000 (10:41 +0200)]
arm: apple: Add Apple M3 (t8122) support
Apple's M3 SoC is similar to M1 and M2 but uses a different memory map.
The main difference is that RAM starts at 0x100_0000_0000 like on t600x
and t602x (M1 and M2 Pro/Max/Ultra). Otherwise IO blocks have been
rearranged.
U-boot's existing drivers are compatible with the hardware and M3 device
trees will carry "apple,t8103-*" compatible strings. Only
apple-atcphy-reset might need a new compatible due to USB4 / DisplayPort
changes the Linux driver has to deal with.
Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Mark Kettenis <kettenis@openbsd.org>
Tom Rini [Tue, 12 May 2026 18:11:17 +0000 (12:11 -0600)]
Merge patch series "Switch Apple silicon boards to upstream device trees"
Janne Grunau <j@jannau.net> says:
The Linux device trees for Apple silicon devices cover now most of the
hardware as u-boot's internal device trees for M1 devices. Linux has in
addition device trees M2 and M1 and M2 Pro/Max/Ultra devices which were
never added in u-boot.
The most common use case for u-boot on Apple silicon devices does not
use DTBs from u-boot but passes runtime modified device trees from an
earlier boot loader (m1n1).
This change regresses support for the SPI on M1 and M1 Pro/Max notebooks
as SPI keyboard support is not in upstream Linux. This regression is in
my opinion acceptable due to the limited use of u-boot's DTBs for these
targets.
Janne Grunau [Thu, 7 May 2026 08:05:51 +0000 (10:05 +0200)]
arm: dts: Switch Apple silicon devices to dts/upstream
The device tree on Apple silicon devices is passed from a previous
bootloader stage. The bootloader fills in dynamic information so
u-boot can not use its own device tree.
As documented in doc/board/apple/m1.rst it is possible to build boot
bundles (bootloader + device tree + gzipped u-boot binary). These are
useful for testing.
Instead of using u-boot's own device trees for M1 (t8103) devices use
upstream device trees from dts/upstream/src/arm64/apple. The u-boot
device trees have not seen updates since 2022. The upstream linux device
trees have feature parity for the M1 devices. In addition linux has
device trees for M1 Pro/Max/Ultra, M2 and M2 Pro/Max/Ultra devices.
Keep t8103-j274 as default device tree to avoid further updates.
Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Mark Kettenis <kettenis@openbsd.org>
Janne Grunau [Thu, 7 May 2026 08:05:49 +0000 (10:05 +0200)]
doc: board: apple: Mention M2 and M2 Pro/Max/Ultra SoCs
These SoCs are supported since 2022/2023 but were never added to the
documentation. The devices very similar to the equivalent M1 devices.
The biggest difference is that the M2 and M2 Pro/Max based laptops no
longer use SPI for the keyboard.
Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Mark Kettenis <kettenis@openbsd.org>
Janne Grunau [Thu, 30 Apr 2026 22:31:16 +0000 (00:31 +0200)]
arm: apple: Switch to board based text env
The main use case for u-boot on Apple silicon based devices is to
provide an EFI based bootloader for operating systems. This uses a
generic u-boot image with DTBs passed from an earlier boot loader
(m1n1). Use the generic board name "mac" for this purpose.
Janne Grunau [Thu, 30 Apr 2026 21:34:43 +0000 (23:34 +0200)]
watchdog: apple: Add "apple,t8103-wdt" compatible
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,wdt" anymore [1]. Use
"apple,t8103-wdt" as base compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,wdt".
Janne Grunau [Thu, 30 Apr 2026 21:33:25 +0000 (23:33 +0200)]
spi: apple: Add "apple,t8103-spi" compatible
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,spi" anymore [1]. Use
"apple,t8103-spi" as base compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,spi".
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,pmgr-pwrstate" anymore [1]. Use
"apple,t8103-pmgr-pwrstate" as base compatible as it is the SoC driver
and bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,pmgr-pwrstate".
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,pinctrl" anymore [1]. Use
"apple,t8103-pinctrl" as fallback compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,t8103-pinctrl".
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,nvme-ans2" anymore [1]. Add
"apple,t8103-nvme-ans2" as fallback compatible as this is the SoC the
driver and bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,t8103-nvme-ans2".
Add nodes to the binman configuration to create single binaries that
combine tiboot3-am69-*-aquila.bin, tispl.bin and u-boot.img into
firmware-aquila-am69-*.bin, with the proper offsets.
These binaries can be used to flash U-Boot via a single binary of three,
as it is done now.
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Tze Yee Ng [Tue, 5 May 2026 02:36:03 +0000 (19:36 -0700)]
mmc: sdhci-cadence: trigger tuning for SD HS mode on SD6HC (v6) PHY
The Cadence SD6HC (SDHCI spec v4.20+) controller uses a soft PHY whose
DLL delay characteristics vary with PVT (Process, Voltage, Temperature)
and board-level trace routing.
A static delay value programmed via device tree for SD High Speed mode is
insufficient because the optimal sampling point varies per board, SD card,
and operating conditions. Runtime calibration is required.
While the SD Physical Layer Specification does not mandate tuning for
SD HS mode (only for UHS-I SDR50/SDR104), the Cadence SD6HC PHY
requires runtime calibration of its receive data delay line to find a
valid sampling window under constrained clock conditions.
The tuning is triggered from the set_ios_post callback because at that
moment hardware has committed the new bus width, clock frequency, and speed
mode to the controller registers. This ensuring the tuning sequence runs
at the correct SD HS operating conditions.
The tuning is gated by a device tree property "cdns,sd-hs-tuning" so
that only boards requiring runtime calibration opt in. When enabled,
the driver performs a 40-tap DLL sweep using CMD19 to find the largest
consecutive passing window, then programs the midpoint into
PHY_DLL_SLAVE_CTRL_REG.
To enable on a board, add to the MMC node in device tree:
The following compilation error occurs when environment variable
KBUILD_OUTPUT is not set :
drivers/reset/stm32/stm32-reset-mp21.c:8:10: fatal error: stm32-reset-core.h: No such file or directory
8 | #include <stm32-reset-core.h>
| ^~~~~~~~~~~~~~~~~~~~
As stm32-reset-core.h is located in same directory than stm32-reset-mp21.c,
we should use #include "stm32-reset-core.h".
board: st: stm32mp25: support dynamic A/B bank bootup
Enable automatic detection of the active A/B bank by retrieving
partition GUIDs from FWU metadata.
This ensures the system correctly identifies the bootable partitions
even in multi-bank scenarios, falling back to a standard bootable flag
scan if the UUIDs are missing.
To enable A/B bank bootup on stm32mp25 boards, add the following Kconfig
options to the stm32mp25_defconfig:
Extend the 'part' command unit tests to include partition lookup via
UUID.
This ensures that the 'number', 'start', and 'size' subcommands
consistently handle UUIDs as partition identifiers, maintaining
parity with the name-based lookup functionality.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
The 'part' command currently allows looking up a partition only by its
number or name.
Extend the 'number', 'start', and 'size' subcommands to support looking
up the partition via its UUID. Unlike names, UUIDs guarantee unique
partition identification, avoiding ambiguity.
The logic is updated to check if the provided string is a valid UUID
before falling back to a name-based search. The help strings for these
subcommands are updated accordingly.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Add unit tests for the 'part' command, specifically for the 'number',
'start', and 'size' subcommands.
These tests establish a baseline for the current partition lookup
functionality by name. This foundation will be used by subsequent
patches to extend the command, ensuring consistent behavior as new
features are introduced.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
lib: uuid: add partition type GUID for extended bootloader
The Extended Boot Loader Partition (XBOOTLDR) is a standard defined by
the Discoverable Partitions Specification (DPS) to host boot loader
resources outside of the EFI System Partition ([1], [2]).
Defining this GUID (bc13c2ff-59e6-4262-a352-b275fd6f7172) allows U-Boot
to correctly identify and label these partitions using the "xbootldr"
shorthand.
Austin Shirley [Wed, 6 May 2026 22:37:58 +0000 (16:37 -0600)]
configs: stm32mp13: add SPI-NAND UBI boot support
The STM32MP13 default environment only handles MMC and serial/USB boot.
When TF-A reports BOOT_FLASH_SPINAND the boot_device variable is set to
'spi-nand' but bootcmd_stm32mp never redirects boot_targets to ubifs0,
so distro_bootcmd falls through to MMC/USB.
This change mirrors the STM32MP15 logic:
- Add a BOOT_TARGET_UBIFS entry to BOOT_TARGET_DEVICES so that
bootcmd_ubifs0 is defined (ubi part UBI; ubifsmount ubi0:boot).
- Add the 'spi-nand' / 'nand' clause to bootcmd_stm32mp so that
boot_targets is set to 'ubifs0' when booting from NAND.
Signed-off-by: Austin Shirley <austin@deadband.dev> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Tom Rini <trini@konsulko.com> Cc: uboot-stm32@st-md-mailman.stormreply.com
tools: fwumdata: Fix use-after-free in parse_config()
In parse_config(), devname is dynamically allocated by sscanf().
When sscanf() fails to fill enough fields (rc < 3), devname is freed and
the loop continues to the next line. However, if the next call to sscanf()
fails to match (rc == 0), devname is not written and still holds the stale
freed pointer. The subsequent free(devname) then operates on
already-freed memory.
Fix this by resetting devname to NULL before each sscanf() call, so
that a non-matching call leaves a NULL pointer and the subsequent
free() becomes a harmless no-op.
arch: mach-k3: j784s4_init: Add workaround for errata i2437
Add the workaround proposed for J784S4 errata i2437 (link) for SE
clock-gating turning off too early. Without this, a hardware bug present
in C7120 leads to C7120 CPU hanging.
arch: mach-k3: j721s2_init: Add workaround for errata i2437
Add the workaround proposed for J721S2 errata i2437 (link) for SE
clock-gating turning off too early. Without this, a hardware bug present
in C7120 leads to C7120 CPU hanging.
Add a helper macro to write and verify a 32-bit value to a memory-mapped
register. This is essential for hardware errata workarounds that require
confirmation that register writes have taken effect before proceeding with
initialization.
fs: ubifs: fix bugs involving symlinks in ubifs_findfile
When encountering a symlink pointing to an absolute path, ubifs_findfile
would return the target of the symlink as the result instead of resolving
any following components in the original path. Fix it by following the
same code path that is used for relative paths except that we set the
next inode to the root if we see a leading slash.
The existing code used memcpy and sprintf to copy the symlink target
into a fixed size stack buffer and was therefore vulnerable to buffer
overflows with a sufficiently long symlink target. Fix it by using a
heap buffer for the temporary path during path resolution.
Signed-off-by: Peter Collingbourne <peter@pcc.me.uk> Fixes: 9d7952e4c636 ("ubifs: Add support for looking up directory and relative symlinks")
Simon Glass [Tue, 5 May 2026 18:12:55 +0000 (12:12 -0600)]
binman: Use bintool wrappers for PKCS#11 tools in tests
The PKCS#11 signing tests in ftest.py call tools.run('softhsm2-util', ...)
directly (and the equivalent for pkcs11-tool and p11-kit), even though
the test setup has already constructed the corresponding Bintool
instances. As Quentin Schulz observed on v1, the bintool wrapper for
these tools is currently used only as an "is this installed?" probe.
Route the eight remaining call sites in ftest.py through
<bintool>.run_cmd(...), which the Bintool base class already provides.
The change is test-side only; no production binman code calls these
tools.
Suggested-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 5 May 2026 18:12:54 +0000 (12:12 -0600)]
binman: Flesh out the softhsm2-util bintool docstring
The Sphinx-generated bintools.rst currently produces an empty section
for this bintool, since its class docstring is only a single line and
so the body under the heading is blank.
Extend the docstring with a short description of what softhsm2-util
does and how binman uses it, so the generated documentation has useful
content.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 5 May 2026 18:12:53 +0000 (12:12 -0600)]
binman: Flesh out the pkcs11-tool bintool docstring
The Sphinx-generated bintools.rst currently produces an empty section
for this bintool, since its class docstring is only a single line and
so the body under the heading is blank.
Extend the docstring with a short description of what pkcs11-tool does
and how binman uses it, so the generated documentation has useful
content.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 5 May 2026 18:12:52 +0000 (12:12 -0600)]
binman: Flesh out the p11-kit bintool docstring
The Sphinx-generated bintools.rst currently produces an empty section
for this bintool, since its class docstring is only a single line and
so the body under the heading is blank.
Extend the docstring with a short description of what p11-kit does and
how binman uses it, so the generated documentation has useful content.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
Ludwig Nussel [Wed, 29 Apr 2026 12:18:51 +0000 (14:18 +0200)]
patman: fix use in worktree
When using a worktree '.git' actually is a file and pygit2
init_repository() does not like that. The intention is not to create
a new git repo anyway so use normal constructor instead of
init_repository().
Signed-off-by: Ludwig Nussel <ludwig.nussel@siemens.com> Reviewed-by: Simon Glass <sjg@chromium.org>
When creating the RSDT and the XSDT table they contain no entries.
The table size therefore must equal the header size.
Without this change a NULL deference has been observed in
acpi_find_table() when running `ut dm` on sandbox64_defconfig
executed via `sudo ./u-boot -D`.
Fixes: 94ba15a3f13f ("x86: Move base tables to a writer function") Fixes: 7e586f69070d ("acpi: Put table-setup code in its own function") Fixes: ab5efd576c4e ("x86: acpi: Adjust order in acpi_table.c") Fixes: 867bcb63e79f ("x86: Generate a valid ACPI table") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Update dm_test_acpi_ctx_and_base_tables() in test/dm/acpi.c to expect
sizeof(struct acpi_table_header) for the initial table length (instead
of sizeof(*rsdt) / sizeof(*xsdt)), and to compute the checksum over
header->length bytes rather than the full struct size: Signed-off-by: Simon Glass <sjg@chromium.org>
usb: dwc3: Fix crash on fastboot exit due to incorrect memory free
The dwc3_free_one_event_buffer() function incorrectly called free()
on event buffer structures allocated with devm_kzalloc(). This
caused heap corruption and a synchronous abort when exiting
fastboot mode via "fastboot continue".
Device-managed memory is automatically freed when the device is
removed, so manual deallocation causes the heap allocator to access
corrupted metadata.
Fixes: 884b10e86a05 ("usb: dwc3: core: fix memory leaks in event buffer cleanup") Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com> Reviewed-by: Marek Vasut <marek.vasut+usb@mailbox.org>
Tom Rini [Mon, 23 Mar 2026 14:38:36 +0000 (08:38 -0600)]
usb: Correct dependencies around USB_EMUL
The symbol USB_EMUL is how sandbox has access to USB. It's
implementation however enforces a few other requirements. It must have
SCSI enabled, and in turn that means it must have BLK enabled. Finally,
we should not be using SANDBOX itself as a symbol to decide what to
build or not build here, as SANDBOX is selected for COMPILE_TEST builds
as well and so may not have enabled the sandbox specific USB support.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Marek Vasut <marek.vasut+usb@mailbox.org>
Tom Rini [Mon, 23 Mar 2026 14:32:02 +0000 (08:32 -0600)]
reset: Correct dependencies for RESET_RZG2L_USBPHY_CTRL
As exposed by "make randconfig", we have an issue with the dependencies
for RESET_RZG2L_USBPHY_CTRL. As this functionally depends on
REGULATOR_RZG2L_USBPHY, express this dependency directly in Kconfig as
well.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Aristo Chen [Fri, 1 May 2026 05:51:04 +0000 (05:51 +0000)]
test: fit: Use shared make_fname from fit_util
test_fit.py declares a local make_fname closure that is byte-identical
to fit_util.make_fname. Drop the local copy and call the shared helper
at all seven call sites so there is one definition to maintain.
No behavioural change. Both implementations return
os.path.join(ubman.config.build_dir, basename).
Signed-off-by: Aristo Chen <aristo.chen@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Ludwig Nussel [Mon, 4 May 2026 07:10:23 +0000 (09:10 +0200)]
virtio: fix boot device hunting in qemu with virtio
Commit 70101c3217ae ("virtio: mmio: Return error codes on probe
failures") returns -ENODEV where it would return 0 before. That path is
apparently hit in qemu and breaks boot device discovery
(virtio_bootdev_hunt() expects only ENOENT). So return -ENOENT in
that path instead.
The remaining two error returns in the function are untouched as I
don't know where they play a role.
Signed-off-by: Ludwig Nussel <ludwig.nussel@siemens.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Kuan-Wei Chiu <visitorckw@gmail.com>
boot: image-fit.c: check target, not source, for 8-byte alignment when loading FDT
A number of our boards no longer boot with v2026.04, ironically as a
result of the effort to ensure 8-byte alignment of the dtb passed to
the kernel and getting rid of the fdt_high=0xffffffff.
The problem exists when the FIT image does specify a (properly
aligned) load address to use for the fdt. For example, we have
fdt-am335x-boneblack.dtb {
description = "Flattened Device Tree blob";
data = /incbin/(...);
...
load = <0x88000000>;
}
Now, with v2026.04 and depending on just exactly where that data ends
up, in a good case we see
Loading fdt from 0x8a8c6e10 to 0x88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Using Device Tree in place at 88000000, end 8801af2f
Working FDT set to 88000000
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
and the board boots (though with that ominous warning). However,
modifying the .its file a little, e.g. just removing the word "blob"
from the description, we end up with
Loading fdt from 0x8a8c6e14 to 0x88000000
Booting using the fdt blob at 0x9df94718
Working FDT set to 9df94718
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Failed to reserve memory for fdt at 0x9df94718
FDT creation failed!
resetting ...
Notice how the "Loading fdt from" line still claims to load the fdt to
that 0x88000000 address, but since this "else if" clause looks at the
source address (buf) and comes before the "else if (load != data)"
clause, we end up doing the "allocate another buffer to use as target"
instead of actually copying to 0x88000000, but then the "fdt_high=~0"
logic in boot_relocate_fdt() obviously fails to do an lmb-reservation
of that area, and the boot fails.
When there's no load= property in the fdt node, this should not change
anything. But when there is, it is the alignment of that target which
is relevant, not the alignment of the fdt blob within the FIT
image. With this patch applied, we instead get the expected
Loading fdt from 0x8a8c6e14 to 0x88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Using Device Tree in place at 88000000, end 8801af2f
Working FDT set to 88000000
Starting kernel ...
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk> Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address") Reviewed-by: Simon Glass <sjg@chromium.org>
Raymond Mao [Wed, 6 May 2026 14:55:33 +0000 (10:55 -0400)]
lib: fdtdec: validate bloblist FDT before consuming libfdt size
Coverity Scan defects are observed in fdtdec_apply_bloblist_dtos(),
since the live FDT taken from the bloblist is passed to libfdt helpers
which consume header size/offset fields:
- fdt_open_into()
- fdt_pack()
Validate the bloblist FDT with fdt_check_full() before calling
fdt_open_into() and again after applying overlays before calling
fdt_pack(). This makes the libfdt consumers operate on a checked FDT
blob while keeping the existing flow unchanged.
Also normalize libfdt return codes from this path to errno values,
including the overlay callback path through bloblist_apply_blobs().
Fixes: b70cbbfbf94f ("fdtdec: apply DT overlays from bloblist")
Addresses-Coverity-ID: CID 645837: (TAINTED_SCALAR) Signed-off-by: Raymond Mao <raymond.mao@riscstar.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Brad Klingerman [Fri, 1 May 2026 14:38:50 +0000 (09:38 -0500)]
Makefile: remove block from conv=block, sync in SPL alignment dd
The line that produces $(SPL_BIN)-align.bin invokes dd with
conv=block,sync but no cbs= operand. The result of dd conv=block
without cbs= is unspecified. GNU coreutils outputs anyway, but
uutils (default in Ubuntu 26.04 LTS) errors out for files with
newlines, including SPL binaries, producing:
dd: conv=block or conv=ubnblock specified without cbs=N
Either the block operand must be removed, or cbs=N must be added.
conv=block is for converting newline-terminated variable-length
records to fixed-length space-padded ones, which is meaningless
for a binary SPL image. The intent of the rule is 4-byte
alignment, which conv=sync alone provides by padding the final
block to bs= bytes with NULs.
During build, u-boot-spl-align.bin errors silently due to '@'.
* initialize variables in efi_dp_from_http()
* cmd: eficonfig: adjust struct eficonfig_entry, field key
* efi_dt_fixup: use fdtdec_get_bool() for reading boolean no-map property
* efi_selftest_memory: check for duplicates first
* simplify efi_mem_sort() using list_for_each_entry_safe
net:
- phy: dp83867: default to 2ns delay if unspecified in device-tree
- nfs: fix buffer overflow in nfs_readlink_reply()
- cpsw: Add cpsw-switch DT binding support
- phy: add common PHY polarity properties support
- phy: adin: add support for the ADIN1200 phy
- macb: support for instances with less features
- phy: mscc: add support for the VSC8572
Shiji Yang [Sun, 12 Apr 2026 12:12:25 +0000 (20:12 +0800)]
mips: mtmips: align MT7621 image blobs to 8-byte boundary
MT7621 doesn't boot on u-boot v2026.04. Fix it by correcting the
u-boot aligned offset.
Fixes: d9e183a04c92 ("MIPS: Assure end of U-Boot is at 8-byte aligned offset") Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Reviewed-by: Weijie Gao <weijie.gao@mediatek.com>
Christian DREHER [Tue, 28 Apr 2026 18:04:08 +0000 (20:04 +0200)]
net: macb: add gigabit implementation for fixed-link
A fixed gigabit link on a non-gigabit controller is only rejected
during PHY init (even though there is no PHY to init), because, on
device-tree parsing, the controller is not probed, and it is still
unknown whether it is gigabit-capable.
This code was only tested on emulator with a full-duplex RGMII
interface, but is expected to work in GMII or half-duplex as well.
Signed-off-by: Christian DREHER <christian.dreher@nanoxplore.com>
Christian DREHER [Tue, 28 Apr 2026 18:04:07 +0000 (20:04 +0200)]
net: macb: do not set user_io when it does not exist
Cadence Ethernet MAC has a feature named user_io, which provides
some input and some output signals for arbitrary purpose in the SoC.
From the driver code, I understand that, on Atmel SoC, it is used to
drive the PHY mode.
At least on Cadence IP7014 r1p12, this feature is optional, and I am
working on a SoC that does not instantiate it. The presence of this
feature is advertised in DCFG1, this patch merely disables the access
to the user_io register based on this information.
I did not apply this change to the non-gigabit capable versions of
the IP, as I do not have documentation for them, and a new non-gigabit
instance is unlikely to appear. I prefer avoiding regressions on old
systems.
Signed-off-by: Christian DREHER <christian.dreher@nanoxplore.com>
Christian DREHER [Tue, 28 Apr 2026 18:04:06 +0000 (20:04 +0200)]
net: macb: use SA1 for MAC filtering on GEM
The MACB uses specific address registers (SA Top and Bottom) to
filter source or destination MAC addresses.
On the Gigabit Ethernet version, SA1B is @0x88.
On the non-GEM version, SA1B is @0x98.
Before this commit, the code was always writing 0x98. By chance,
on GEM, this is the address of SA3B, allowing the driver to work
anyway.
The motivation for this change is to be able to use the driver on
an instance of the GEM with less than 4 SA registers.
Signed-off-by: Christian DREHER <christian.dreher@nanoxplore.com>
Christian DREHER [Tue, 28 Apr 2026 18:04:05 +0000 (20:04 +0200)]
net: macb: include arch/clk.h only when necessary
It does not exist in my setup (an on-going arm64 SoC), and removing
it does not cause any missing declaration, but some code called when
CONFIG_CLK is missing calls get_macb_pclk_rate, which is only defined
in arch/arm/mach-at91/include/mach/clk.h
Signed-off-by: Christian DREHER <christian.dreher@nanoxplore.com>
test: dm: add PHY common props unit tests and sandbox DT nodes
Add sandbox DM unit tests for the PHY common properties library and the
corresponding device tree test nodes to arch/sandbox/dts/test.dts.
Also enable CONFIG_PHY_COMMON_PROPS in configs/sandbox_defconfig so
the tests are built and run in the sandbox environment.
The test file covers rx/tx polarity lookups for all relevant cases:
- missing property (defaults to PHY_POL_NORMAL)
- single value without names array (applies to all modes)
- count mismatch between values and names arrays (-EINVAL)
- name found by exact match
- name not found with no "default" fallback (-EINVAL)
- name not found with a "default" entry (uses fallback value)
- unsupported polarity value (-EOPNOTSUPP)
Ported from Linux KUnit test:
linux/drivers/phy/phy-common-props-test.c
net: phy: airoha: air_en8811: use standard rx-polarity/tx-polarity properties
Replace the proprietary airoha,pnswap-rx / airoha,pnswap-tx boolean
device tree properties with the standard rx-polarity and tx-polarity
properties defined in phy-common-props.yaml.
Backward compatibility is maintained by reading the legacy boolean
properties first and passing them as the default_pol argument to
phy_get_rx/tx_polarity(). If the standard properties are absent the
legacy values are used transparently, so existing device trees remain
functional without modification.
The dt-bindings/phy/phy.h header with PHY_POL_NORMAL, PHY_POL_INVERT,
and PHY_POL_AUTO constants is provided via dts/upstream/include, which
is already in the build include path.
Ported from Merge tag 'phy-for-7.0':
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy
Upstream devicetrees use a newer DT binding using cpsw-switch
compatibles. The bindings are a bit different, so two functions are
introduced to capture the differences, cpsw_eth_of_to_plat_switch() and
cpsw_eth_of_to_plat_legacy().
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
If wget_info->silent is set, we should not print anything.
If wget_info->silent we print the received content size.
Printing the value of the Content-Length header is redundant
For chunked transfer no Content-Length header is sent.
The content length is returned as HTTPC_CONTENT_LEN_INVALID by the LwIP
library. In this case we were incorrectly printing '4 GiB'.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
net: nfs: fix buffer overflow in nfs_readlink_reply()
nfs_readlink_reply() validates rlen only against the incoming packet
length (inherited from CVE-2019-14195), but not against the destination
buffer nfs_path_buff[2048]. A malicious NFS server can send a valid
READLINK reply where pathlen + rlen exceeds sizeof(nfs_path_buff),
overflowing the BSS buffer into adjacent memory.
The recent fix in fd6e3d34097f addressed the same overflow class in
net/lwip/nfs.c but left the legacy path in net/nfs-common.c unpatched.
Add bounds checks before both memcpy calls in nfs_readlink_reply():
- relative path branch: reject if pathlen + rlen >= sizeof(nfs_path_buff)
- absolute path branch: reject if rlen >= sizeof(nfs_path_buff)
Fixes: cf3a4f1e86 ("net: nfs: Fix CVE-2019-14195") Cc: stable@vger.kernel.org Signed-off-by: Sebastian Alba Vives <sebasjosue84@gmail.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
projects / thirdparty / u-boot.git / log
